Speed dialing: Connecting SAS Enterprise Guide to a containerized SAS workspace on Windows

7 Likes

I should warn you that this post has a bit of a “nerdy” attitude to it ... I’ll describe how you can run a SAS programming-only Docker container on your local Windows machine and make SAS Enterprise Guide 8.2 connect to it as a client. This certainly sounds like fun (at least to me), but it also has a more serious point.

Over the years, I’ve met many customers with decentralized SAS environments where users run SAS sessions on their Windows desktops, enjoying the maximum control of local SAS workspaces. On the other hand, there’s the IT perspective – the challenging task to keep track of a large user base working with decentralized SAS deployments. How do you:

Maintain a standardized and up-to-date SAS environment?
Keep users informed if changes are needed for shared data sources, such as NFS shares or databases?
Simplify the annual process of renewing the licenses?

Over the years, SAS administrators have found many different ways to ensure governance and support in scenarios like these. In this post, I’d like to describe an additional approach, not claiming that this should replace other solutions. Take it as it’s meant – just “food for thought” – and see if it's reasonable for you or not.

Running a SAS workspace in a container

As you probably are aware, SAS is currently undertaking a major change in the way we build and distribute our software. Listening to customers increasingly demand a shift to cloud-native architectures, SAS is putting great effort into containerizing the SAS platform (mainly SAS Viya, but this also applies to the SAS9.x stack) with the goal of offering container images (“Docker images”) as the units of deployment. For this blog I am focusing on the feature set of a SAS Viya programming-only container image, which means that we will have both the CAS and the SAS runtime engine at our disposal. Usually SAS Studio will be the default user interface for this type of container, hence the label "programming only".

There are multiple ways how to create a SAS Viya Docker image: you might want to download an existing container image prepared by SAS or you might prefer to give it a try and “roll your own.”(Hint: head over to @joeFurbee’s excellent article on Getting started with SAS Containers if you feel the need for a refresher on the topic before continuing.)

Creating a container image from scratch is a bit more involved, but it is certainly the more rewarding approach if you’re interested in learning about SAS in containers and Docker in general. For this approach you will need a Linux-based machine to create the Docker image. This node can also host the Docker registry from which you can “pull” your image to your Windows machine.

For the sake of keeping this short, I’m going to assume you are familiar with the basic steps of how to set up Docker and a Docker registry on Linux. I’ll also refer you to the wiki pages of the public Github project hosting the SAS provided container recipes, which explain how to create a Viya programming-only runtime container image.

If you work with the container recipes, I’d recommend adding the “auth-demo” overlay to the base image so that you later can specify the user account which you want to use for logging in. Note that the “addons” folder in the recipes collection contains a lot of examples of how to include support for various SAS/Access engines as well. Here’s a sample command that will build your container image and push it to your local Docker registry:

./build.sh \
  --type single \
  --zip ~/path/to/SAS_Viya_deployment_data.zip \
  --docker-registry-url myregistry.myhost.com \
  --docker-registry-namespace sas-poac \
  --addons "auth-demo"

After this has completed, it’s time to switch to the client side of things.

Docker for Desktop

Installing Docker for Desktop is the first thing you need to do. The installation should be straightforward, however, be aware that installing the Docker software will disable other virtualization software on your local machine such as VMWare or Virtualbox.

Now that you have Docker for Desktop running on Windows, open a Powershell prompt to download (“docker pull”) the container image you created before. Depending on the addons you had included, the startup command for your container (“docker run”) might be different. Here’s a typical example of both steps (note the port mappings):

Ok, give it a try! Launch a browser and point to http://localhost:8080 (or whatever port you’ve chosen) – you should be welcomed by SAS Studio. Login using the username and password you specified and you’re good to go.

While this is already pretty cool, you’ll soon discover that it has limitations because everything inside the container is basically ephemeral – meaning that it is lost if the container is stopped. Docker for Desktop allows you to map Windows drives to the container’s filesystem, so this might be a solution for storing your SAS codes and data. However, in my experience, this feature is not fully stable and sometimes corporate security policies will prevent you from using it altogether.

SAS Enterprise Guide 8.2

Oh my, what now? We’ve been so close! But wait, what if we had a client outside the container that could connect to the engines (SAS and CAS) inside? So that all your programs are safely stored locally on your desktop? And the same should be possible for data as well, of course.

Enter SAS Enterprise Guide 8.2. The latest release of Enterprise Guide features one particular capability which makes it well suited for working with containers: it can directly connect to a remote SAS server using hostname and port - in our case: localhost:8591.

Once you have added this connection to the list of SAS Workspace servers (again use the user account that you specified when launching the container), you can use Enterprise Guide to submit your programs to the SAS and CAS engines in the container. And while your code is executed by the SAS or CAS engine inside the container, it is safely stored on your local Windows machine.

And what about data? Nothing special here: You can import local data in the same way you are used to. Simply go to “File/Open” and select the file you want to upload to your container. Just remember to “export” output tables back to your local machine before you shut down your container.

A little bonus at the end

I’d like to end with a little bonus tip: Enterprise Guide is not the only client that can be used to work with the SAS container – Python can do this as well with the help of the SAS SWAT package (the “SAS Scripting Wrapper for Analytics Transfer”). For example if you have installed the Anaconda distribution on your laptop and added SWAT (a simple “pip install swat” might be all that is needed), then the Jupyter notebook application can be your client for running analytics on the CAS server in your container. Note: For this to work you need to set the port mappings when launching your container (the CAS ports 5570 and/or 8777 need to be available from outside the container).

Conclusion

Above, I described a way to connect to a local SAS programming environment running in a Docker container by using the latest SAS Enterprise Guide release (8.2). As I mentioned at the beginning, this can be a mere fun exercise for those of you interested in learning more about SAS and containers, but there might also be some real benefit to it in decentralized environments where supporting a large SAS user base can be challenging.

I hope you liked the post and I’m curious to hear your feedback. Please feel to add your thoughts and comments below!