A Survey of Install Tools for SAS Viya
The SAS Viya platform is delivered as containerized executables which run in a Kubernetes cluster that's often deployed to run in virtualized hardware hosted in a managed cloud environment. That means there's a lot of moving pieces and variables to deal with. And looking beyond the initial installation effort, we must also handle regular improvements to the software delivered as interim patches and scheduled version updates.
To achieve the myriad goals of installing and updating the Viya platform in a diverse range of deployment options, SAS currently supports four distinct deployment methodologies which we will survey in this post.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Infrastructure first
SAS supports the Viya platform running in Kubernetes hosted on any of several different infrastructure providers. For more information about getting started with provisioning a Kubernetes environment in the cloud or on-premise at your site, check out the public Infrastructure-as-Code projects that SAS provides on the github.com site:
- viya4-iac-azure: AKS on Microsoft Azure
https://github.com/sassoftware/viya4-iac-azure/
- viya4-iac-aws: EKS on Amazon Web Services
https://github.com/sassoftware/viya4-iac-aws/
- viya4-iac-gcp: GKE on Google Cloud Platform
https://github.com/sassoftware/viya4-iac-gcp/
- viya4-iac-k8s: Upstream, open-source Kubernetes on premise at your site
https://github.com/sassoftware/viya4-iac-k8s/
Alternatively, the Viya platform can also deploy to sites that rely on RedHat OpenShift Kubernetes Engine (OKE) or Red Hat OpenShift Container Platform (OCP) as satisfies the platform requirements.
Second, prerequisite services
Neither Kubernetes nor Viya provide all of the requisite software needed to operate. Some additional software must be installed for Viya to operate properly with appropriate access to resources. The exact list of items will vary depending on your site's needs, but we can provide an example list here to make the point:
- Kubernetes RBAC permissions
- Kubernetes cluster autoscaler
- Kubernetes metrics server
- Container Storage Interface(s)
- Container Network Interface(s)
- NGINX Ingress Controller
- LoadBalancer(s)
- TLS certificate generator (if not using Viya's internal OpenSSL-based generator)
- External Postgres Server (if not using Viya's internal Crunchy Postgres)
- And so on
Viya software assets next
We also will need to acquire the SAS Viya software assets, which include the configuration files, license files, and certificates for secure communication with the SAS container repository. Optionally (but recommended), we can stand up a mirror repository for hosting the SAS Viya container images, too.
Now we can talk about installing the Viya platform
With the necessary infrastructure along with prerequisite software in place, we can focus on the different technology options that SAS provides for installing the Viya platform. We'll touch on each of the four possibilities and highlight key points to consider.
Primary tools:
Performing the manual approach means we'll use some specific utilities to do the job:
- Kustomize to process the configuration files and generate the site manifest
- Kubectl to manage the Kubernetes cluster and apply the site manifest directives
Note: there are plenty of other tools and utilities (like a good text editor and the yq utility, shell scripting, CI/CD pipelines, etc.) that you'll use when administering a Viya deployment, but for this post, we'll keep focus on the primary driving components that do the most lifting when deploying Viya.
Capabilities checklist:
Next, here's a simple list of deployment capabilities we can use to compare the different deployment approaches:
The first item in the table - install Viya - is a given since that's the topic of this post.
The manual approach can be used to make simple configuration changes to an existing Viya deployment, like changing the number of CAS workers or defining new requests and limits for CPU and RAM of the containerized services.
Order updates are when patches or subsequent upgrade to later releases of the Viya platform software are applied to the cluster and the manual approach can handle this as well.
And last, we can use the manual approach to uninstall Viya from the Kubernetes cluster if needed.
Process:
Stripped down to its essence, the steps for installing (or updating) the Viya platform with the manual approach are:
- Update the Viya platform configuration with kustomization.yaml and site-config files
- Use the `kustomize` utility to `build` the site.yaml manifest file
- Use the `kubectl` utility to `apply` the manifest directives which installs Viya software to the Kubernetes cluster
Outlook:
The manual approach to installing the Viya platform is powerful and flexible. Kubernetes administrators at your site might already be comfortable with the utilities employed and can script their own steps to create a repeatable process.
The sas-orchestration approach means that we employ the sas-orchestration utility for installing the SAS Viya platform. The sas-orchestration utility is a piece of software we download and run outside of the Kubernetes cluster. Because it's designed to help streamline Viya deployment, the sas-orchestration utility eliminates several steps in the process compared to the manual approach.
Primary tools:
The main touchpoint for this approach:
- sas-orchestration is provided as a Docker container and downloaded from the SAS container registry.
As a Docker container, the sas-orchestration utility also includes other software that's needed and familiar, including:
- Kustomize to process the configuration files and generate the site manifest
- Kubectl to manage the Kubernetes cluster and apply the site manifest directives
Capabilities checklist:
Next, here's a simple list of deployment capabilities we can use to compare the different deployment approaches:
We can use the sas-orchestration utility to install and update SAS Viya.
An optional configuration we can enable is to automatically restart the SAS Cloud Analytic Services (CAS) when updates are applied to the cluster. Note that auto-restart of CAS cannot be enabled if CAS state transfer is active instead.
Notice, however, that we won't use sas-orchestration to uninstall SAS Viya. That task can be accomplished using the manual approach to uninstall Viya instead.
Process:
Stripped down to its essence, the steps for installing (or updating) the Viya platform with the sas-orchestration utility are:
- Update the Viya platform configuration with kustomization.yaml and site-config files
- Use the `sas-orchestration` container to `deploy` so it will create (using builtin kustomize) and apply (using builtin kubectl) the site manifest which installs Viya software to the Kubernetes cluster
Note we don't need to execute `kustomize build` - the sas-orchestrator handles that itself. And for updates to the configuration after initial deployment, the sas-orchestration utility will also bounce the CAS server (if enabled).
Outlook:
The sas-orchestration approach to installing the Viya platform offers a targeted strategy that focuses on streamlining the install and update processes for the Viya platform.
The SAS Deployment Operator offers another approach for installing the SAS Viya platform. It acts like an independent agent that runs in the Kubernetes cluster to manage the Viya platform deployment. Indeed, one Deployment Operator can manage multiple Viya deployments in a single Kubernetes cluster, if needed. The Deployment Operator takes a CRD (custom resource definition) file as input and then reconciles the desired state that the CRD declares with the current state of Viya to make changes, either for an initial install or for subsequent updates.
Primary tools:
The Deployment Operator uses two items to do its job:
- The custom resource definition (CRD) file
- The `sas-deployment-operator` pod running in Kubernetes
To generate the CRD file, we must install the sas-orchestration utility.
As a Docker container, the sas-orchestration utility also includes other software that's needed and familiar, including:
- Kustomize to process the configuration files and generate the site manifest
- Kubectl to manage the Kubernetes cluster and apply the site manifest directives
Capabilities checklist:
Next, here's a simple list of deployment capabilities we can use to compare the different deployment approaches:
We can use the SAS Deployment Operator to install and update SAS Viya. It can also auto-restart CAS for updates, if enabled. We can also uninstall Viya using the Deployment Operator, too.
Process:
Stripped down to its essence, the steps for installing (or updating) the Viya platform with the SAS Deployment Operator are:
- Install (or update, if needed) the SAS Deployment Operator in Kubernetes
- Update the Viya platform configuration with kustomization.yaml and site-config files
- Use the `sas-orchestration` container's `create` directive to generate the CRD file which declares the desired state of Viya (install or update)
- Use the `kubectl` utility to `apply` the CRD to the Kubernetes cluster. The Deployment Operator will notice the change to the CRD and reconcile changes to install (or update) Viya.
Outlook:
The Deployment Operator approach is a little more complicated, relying on additional processes and steps to accomplish the tasks for installing or updating the Viya platform. However, it offers a unique feature where a single Deployment Operator can be used to manage multiple Viya deployments (running in dedicated namespaces) in a single Kubernetes cluster.
Earlier in this post, the Infrastructure-as-Code projects were mentioned. The Deployment-as-Code project is a parallel effort to the IAC and simplifies the process for getting the Viya platform up and running. There's just one Deployment-as-Code project and it can be used for any of the supported infrastructure platforms.
As a project, the DAC can be downloaded as a set of directories and text files to work with -or- it can be downloaded and compiled to run as a Docker container including the necessary software utilities. The latter approach is recommended.
Primary tools:
The DAC project can be compiled to provide the main utility:
- The `viya4-deployment` Docker container
As a Docker container, the DAC also includes other software that's needed and familiar, including:
- Kustomize to process the configuration files and generate the site manifest
- Kubectl to manage the Kubernetes cluster and apply the site manifest directives
- The SAS Deployment Operator is the default approach used by DAC to install the Viya platform
- Alternatively, the sas-orchestration utility can specified as the approach for installing the Viya platform instead
Capabilities checklist:
Next, here's a simple list of deployment capabilities we can use to compare the different deployment approaches:
For the tagline of this approach, I said that it under promises and over delivers because you thought you were only getting a way to install the Viya platform but the DAC does much more. It goes above and beyond by installing many "baseline" components (like the NGINX ingress controller, container storage interface drivers (as needed), TLS certificate generators, and more.
It also can install post-deployment components for monitoring and logging as well. These are very useful components and getting them in your environment is as simple as including their tag labels on the install command.
The main thing to watch for is that the DAC is not intended to support updates to Viya which increase the version level. It's possible when leveling up from one version to another that manual tasks must be addressed and the DAC has no mechanism to reconcile that. Instead, follow the procedures for order updates (like patches and new versions) as documented for either the sas-orchestation or Deployment Operator approaches, depending on which was used by the DAC when it initially installed Viya.
Process:
Stripped down to its essence, the steps for installing the Viya platform with the Deployment-as-Code project are:
- Edit the CONFIG-VARS file with directives for the DAC to follow
- Update the Viya platform configuration site-config files (no need to create or edit the kustomization.yaml)
- Execute the `viya4-deployment` container with tags for "install, baseline, viya" - optionally include additional tags for "cluster-logging,cluster-monitoring,viya-monitoring" as well
Outlook:
The Deployment-as-Code project does a lot more than just install the Viya platform - it also handles a lot of the software prerequisites as well as deploying monitoring and logging tools to the Kuberenetes cluster. Once Viya is live in the environment, ongoing updates to later releases should employ the sas-orchestration utility or SAS Deployment Operator approaches instead.
All together now!
Whew... that's a lot of ground to cover. To help review and compare capabilities, here's a summary table with all approaches:
Hybrid approaches
It's common to combine these approaches to achieve specific goals. You're not necessarily locked into one approach in most cases.
As noted for the Deployment-as-Code project, we might need to revert to using the SAS Deployment Operator or sas-orchestrator approaches for order updates that occur after initial deployment.
We've also see the DAC used to deploy the "baseline" prerequisite components, but then opt to explicitly use the sas-orchestrator or SAS Deployment Operator approaches for the initial install and ongoing lifecycle operations.
Notice the following in the Primary Tools sections for each approach above:
DAC includes and relies on:
- SAS Deployment Operator -or- sas-orchestration
- kustomize
- kubectl
And besides its own features, SAS Deployment Operator relies on:
- sas-orchestration
- kustomize
- kubectl
And besides its own features, sas-orchestration relies on:
- kustomize
- kubectl
And, of course, the manual approach relies on:
- kustomize
- kubectl
In other words, no matter what technique we use to deploy Viya, we can revert back to constituent components when needed. So, the manual approach is always available to us. If you used the Deployment Operator approach, you can revert back to either sas-orchestration or manual approach. And so on.
Generally speaking, however, we can't go "uphill". If we use manual deployment, then we should stick with that and not try to update the Viya platform using the other approaches. The same idea applies to other "uphill" scenarios (like sas-orch ==> DepOp).
In all cases, take care to follow the logical chain of execution. So, if you go "downhill" from Deployment Operator to continue lifecycle operations with the manual approach, then you might not be able to go back to DepOp. Or, if you want to, then you'll need to ensure that whatever you did manually in the environment is properly reflected in the DepOp's configuration, too.
Recommendations
We've covered a lot of ground up to this point, but for my own circumstances, I don't blindly recommend using one approach over any of the others. It makes more sense to identify your Viya platform deployment goals and then evaluate the approaches you might want to use.
That said, I can imagine certain scenarios where I might easily prefer one approach over the others.
For example, if you need to deploy Viya for a single use, then delete it all, and later repeat the process, then you might want to use the DAC approach. One aspect of the DAC project I really enjoy is that it is setup to deploy software components at specific version levels that have been vetted to work together. So, if you need a simple way to repeatedly deploy Viya (and its prerequisite software as well as logging and monitoring) over time, the DAC can simplify resolving many of the dependencies across disparate software components.
For long-term deployments in production environments, I might lean to using the sas-orchestration approach. I enjoy the fact that it targets specific steps to streamline deployment and updates, but still gives me access to interim steps (and logs and config files) to help with troubleshooting.
As a Kubernetes and software management purist, I also might prefer relying on the manual approach. It's more involved and puts more responsibility on my shoulders to ensure everything is done right but, on the other hand, it also means that I have the most flexbility for managing the Viya platform deployment process.
In all cases, your mileage may vary. 🙂
More information
This post builds upon a number of concepts and technologies. If you're not already familiar with those, then check out the following GEL workshops in the SAS Virtual Learning Environment:
Find more articles from SAS Global Enablement and Learning here.
