My SAS Analytics Pro License Says Linux but I Run Windows!
Customers who are opting for the new SAS® Analytics Pro offering may experience some confusion when they receive the license for the product. When viewing the order information, customer’s will see that the product is licensed to run on the Linux operating system however they may be using Microsoft Windows on their desktop. Further to this, when running the Analytics Pro container, some customers may wonder why their folders and paths to files are different. This article aims to help explain why this is and help you understand these differences so you can fully utilise the numerous advantages of running SAS inside containers.
The SAS Analytics Pro Cloud Native product runs as one or more Docker Containers either via the Docker runtime or packaged as a Kubernetes deployment or service in a k8s cluster. This is a smart approach:
- Containers are highly portable and remove many of the quirks of building software for multiple operating systems.
- They are fast and scalable and more lightweight than servers.
- They are disposable. You can say good bye to the traditional dev / production environment approach.
The underlying root cause of the differences you see is due to how Docker works. While your desktop or server host may be running Windows, the container image is running Linux. Programs and files inside the Analytics Pro container act and look like they would on Linux.
What is a Container?
Containers were launched in 2013 as part of the open-source Docker Engine. Containers were built on existing concepts used in operating systems like Solaris and other unix based operating systems. Over the years, containers have become a reference standard. They are not tied to the Docker Inc. company and numerous vendors implement container technology.
Containers abstract application and deployment dependencies and run against a common OS kernel but run within an isolated user space.
This typically consumes less resources than using Virtual Machines. A Virtual Machine approach packages an entire operating system by abstracting physical hardware processes. A virtual machine also uses a Hypervisor which manages the capability to run virtual machines within a single physical host. Virtual machines consume more space and resources as they normally require a full copy of the target operating system and binaries. This also results in slower boot times to containers.
Docker formed a partnership with Microsoft to bring containers to the Windows operating system to allow Docker to run natively within Windows. On modern Windows hosts, the common kernel is the Windows Subsystem for Linux. When Docker Desktop was released in 2013, WSL did not exist. As a result, older versions of Docker Desktop would run within a Virtual Machine on Windows. This Virtual Machine would house a common Linux Kernel and required docker binaries.
Already it is easy to see the advantages of a technology like Docker for application development.
- Standardise the delivery of applications to run on either Windows or Linux with a single code base.
- Low-cost testing of applications on a variety of operating systems and their variants easily.
- Throw everything away when you don’t need it.
Containers, Images, Networks, Volumes, Ports
Containers are an instance of an Image which is a compressed file of binaries and libraries containing all the required components to execute within the Docker runtime. Images are created using a Dockerfile which is a file format developed by Docker.
As mentioned previously, containers are isolated. That means they typically need to be given references to files and folders to use from your operating system and also be told what ports they can communicate on.
A container will typically contain one or more volume mappings, port mappings and instructions for networking.
Volume mappings are given to a container to expose files and folders on your host to the container so they can be used. This might include things like your source code, configuration files, data etc.
As well as this, an application hosted in a container may need to be told what port to let your host communicate on. Let’s take a web application as an example that runs on port 8080 within docker. On your host you want to access it on the standard web address port of 80. You will tell your Docker container to expose port 8080 in the container to port 80 on your host.
Docker containers can also run within completely self-contained networks and have multiple containers running. A simple version of this is using Docker Compose which comes with most Docker installations. This allows you to define container configurations using a yaml based file format and each container is managed from a created network object and can talk to each other easily.
SAS in the New World
Using containers means that you can also create multiple container instances easily with specific configuration tailored to the purpose you are trying to achieve. In many cases, this means you no longer need to maintain separate non production / production environments. Your user’s can have development environments locally, push their code to version control including the container configuration required and then have your cloud or hosted infrastructure run as isolated production containers. SAS can now sit easily alongside modern CI/CD approaches.
How the Analytics Pro Container uses Linux on Windows
The SAS Analytics Pro for Cloud Native container contains all the required binaries and libraries to execute Base SAS, SAS/STAT, SAS/GRAPH and over 20 SAS/ACCESS engines as well as the Basic deployment of SAS Studio. For further information on the inclusions of SAS Analytics Pro Cloud Native, please see our previous post. If your current SAS usage is focused on the SAS programming interface as opposed to the newer visual interfaces, then it’s a smart modernization choice to make.
As a user, you need to supply the image the following information at a minimum:
- A SAS License (as a .jwt file) and deployment certificates (.zip file).
- Configuration for mapping files and folders
- Environment variables to configure port mappings
- Driver and configuration files for whichever access engines you want to use.
The SAS Analytics Pro Container
The current Analytics Pro container comes in at just under 10GB in size. This is opposed to the older SAS9 Depot which would be anywhere up to 30GB in size.
The image is downloadable from SAS using the mirror manager command line tool. You can then also use another command line tool, the SAS Order manager (or manually at my.sas.com) to download licenses and certificate files required. There is also an API available to automate the download of certificates and licenses.
The container runs using the Red Hat Linux base container image. This means that from the application’s perspective, SAS is running with a Linux operating system even though the machine you are running the container from may be Microsoft Windows. This is why when you receive your SAS licensing paperwork, it will say that it is licensed for the Linux operating system.
Analytics Pro can be configured for personal or shared use. The full range of configuration options are too vast to completely cover here. Watch this space as we will be providing deep dives into the various configuration approaches that can be taken. What we will cover here are the most visible differences you will see when using SAS through a container. The most visible are mount volumes and mappings.
Making directories/files available in the Container
The Analytics Pro container needs at a minimum two Volume mappings:
- A Data folder mapped to
/datain the container. This acts like your Linux home directory. It is typically used to store your SAS programs and any permanent data, etc. - A folder mapped to
/sasinside. This stores your SAS licence, deployment certificates and any configuration overrides such as a customautoexec_usermods.sasandsasv9_usermods.cfgfiles.
You can also mount any other additional folders from your host machine to the container. Some typical scenarios include:
- Creating a mapping for
/sasworkand/sasutilfor SAS temporary datasets and util files. - Creating a mapping for
/var/logfor system logs - One or more volumes for permanent SAS Datasets.
- A python runtime to support the usage of
PROC PYTHON
Volumes inside the Analytics Pro container act like Linux mount points. For those who come from a Windows background, this may be confusing at first.
- Linux volumes don’t have the same concept of Drive names like
C:\,D:\, etc. - Linux volumes do not use back slashes. They use forward slashes.
- Linux mounts can be either a directory or a single file.
Say for example, you decide you want to have the following mappings in your Analytics Pro container.
| Host Path | Container Path |
| C:\env\data | /data |
| C:\shared\sasinside | /sasinside |
| C:\shared\data | /sasdata |
When you use Analytics Pro, your programs will need to reference files and folders by their container path. So a libname statement like libname myenv "/sasdata"; would point to the directory C:\shared\data on your host.
It is important to note that the SAS analytics pro container will also apply permissions to some configuration files. Typically you won’t notice this except in cases such as mapping public/private keys for ssh which require restrictive permissions.
Credentials/Authentication
The 2nd most visible difference is that by default, your host username and password won’t be used. In SAS9, SAS will use the authentication provided by your local machine or server you are connecting to.
The Docker container does not have access to this by default due to the isolation principals mentioned previously.
By default, Analytics Pro will create a user account within the container which it uses to allow logging into SAS Studio. It will look for a .authinfo.txt file within your /data mount point. This is a simple text file which has the following contents:
default user myusername password mypassword!
| Profile | Username | Password |
| default | user myusername | password mypassword! |
If this file does not exist, SAS will create a default account called sasdemo and generate a random password for you and create this authinfo file in the /data folder.
If you choose to run Analytics Pro in a multi user scenario, then you may need to configure the container to utilise PAM authentication. This is done the same as you would normally within a Linux server.
There are also methods for tying user accounts inside a Docker container to the host’s authentication provider. We’ll cover these approaches in separate articles to give them justice.
Selerity Desktop to Make This Easier
We’ve created the Selerity Desktop (Personal) tool to help make deployments easier if you are uncomfortable with the above concepts. This personal edition allows you to deploy container environments with a series of additional options such as Python, Clinical Standards Toolkit and SAS OQ testing without needing to know any of the technical details. If you are interested in further information please see our product page for further information or reach out to us to discuss more complex deployments or licensing requirements.
Also stay tuned for future posts where we delve deeper into use cases that SAS Analytics Pro Cloud Native can support and other, more advanced, deployment options.
