New SAS Viya Deployment Methods

8 Likes

Sometime ago, I wrote a blog to introduce and compare the Viya 4 deployment methods, called “All roads lead to Rome : Three Tables and one Diagram to review the SAS Viya 4 deployment methods”

As we begin 2023, and several things have been changing in this area, I thought it was a good time to revisit the Viya 4 deployment methods landscape.

After a small recap of the existing methods, we will present the new "sas-orchestration command" deployment method, explain recent significant changes in the DaC (Deployment as Code) project and even compare the 4 official ways to deploy SAS Viya.

Recap

Let’s start with a little recap on the SAS Viya deployment methods.

At the beginning we only had the so-called “manual” deployment method, where you were simply applying to the cluster the Kubernetes manifest that was generated by the Kustomize build (the famous “site.yaml” file), by running the kubectl apply commands.

…Then the Deployment Operator method was introduced. It leverages the Kubernetes Operator concept where you can create your own custom resource definitions in Kubernetes.

So we first need to install the SAS Deployment Operator and it will then manage and watch any change happening in the "SASDeployment" Custom Resources (CR) that were applied in the cluster.

Each "SASDeployment" CR corresponds to a distinct SAS Viya Deployment within the same cluster.

The Deployment Operator monitors the Custom Resource specification and automatically pulls the corresponding deployment assets (sas-base folder) then run the kustomize build and kubectl apply commands for you.

Once you are familiar with it, it really simplifies the deployment and update steps.

However there is no magic, even with the Deployment Operator method you still need to write the kustomization.yaml and various kustomize override yaml files (placed in the “site-config” folder) by yourself…

It would be so nice if we could avoid to do that…but wait a minute…actually there is one deployment method that saves you from these tedious, error-prone and always changing tasks!

Here comes the 3^rd method : The SAS Viya 4 deployment GitHub project (aka "DaC" for "Deployment as Code"). Let’s explain a little bit more what it is.

Deployment as Code ( DaC)

This method relies on a project that is maintained in one of the sassoftware GitHub repository which is simply called “The SAS Viya 4 deployment tool”.

The SAS Viya 4 deployment tool contains Ansible code that :

Creates the cluster "baseline" in an existing Kubernetes environment for use with SAS Viya 4,
- Install all the pre-requisites (Ingress NGINX Controller, NFS provisioner, cert-manager, metrics server,…)
Generates the manifest for a SAS Viya software order,
- It can automatically implement several common customizations (number of CAS workers, mirror, etc…), depending on the values given in the ansible vars file (see the CONFIG-VARS page for all the capabilities).
and then deploys that order into the specified Kubernetes environment.

One of the major limitations, that one needs to know though, is that the DaC viya4-deployment cannot be used to perform SAS Viya versions updates.

If you have an existing SAS Viya environment that you initially installed with the viya4-deployment project, you’ll need to follow the instructions in "Updating Software" in the SAS Viya Operations Guide where you apply the standard re-deployment methods and you are also expected to modify the documented steps to accommodate the slightly different directory structure.

So, what’s new ?

If you are familiar with SAS Viya deployments, you were probably already aware of the 3 methods presented above.

So what is changing, with the new SAS Viya Stable version 2022.12 ?

Firstly, there is now a 4th deployment method. And secondly, the DaC method is also being changed.

A fourth method

The new method (introduced in the Viya 2022.12 stable version) is called "sas-orchestration command" because it relies on the same sas-orchestration Docker image that we already use with the Deployment Operator method to create the Deployment CR.

But this time, instead of using the "create" function of the sas-orchestration container, we use the "deploy" function which successively pulls the deployment assets, build the manifest (with kustomize) and apply it (with kubectl apply commands).

With this fourth method, while we perform an "orchestrated" deployment, we don't need to deploy the SAS Deployment Operator into the Kubernetes cluster. The deployment is managed from "outside" of the cluster, whereas with the Deployment Operator, the deployment is done by the Operator, inside the cluster.

The main reason to offer this alternative method was to remove the need to create a cluster wide Operator with the associated Cluster privileges (which is not acceptable to all customers).

In terms of utilization, you can run it from any machine (with Docker installed) from where you can connect to the Kubernetes cluster API as a Kubernetes administrator with cluster permissions.

You need to download the license, certificate files and deployment assets, then pull the corresponding sas-orchestration Docker image, and from there you can run the docker run command and call the deploy function to deploy or update your SAS Viya deployment to any specific version or cadence (as long as it is a supported version).

Here is the syntax :

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

And a simple example :

When you run the deploy command (and assuming your configuration is correct), it will output the executed steps, for example :

We can see that a lot of things are happening behind the scenes (artifacts generation, kustomization and manifest generation, version check, pre-deployment steps, kubectl apply, post deployment steps, etc…)

At the end, we should see a “success” message.

To summarize, this fourth method reduces the level of complexity by removing the need to go through many of the individual commands that an administrator would see in a manual deployment. It also embeds various checks and controls, for example to prevent you from doing something that would not be supported in terms of versions update.

New DaC release with SAS deployment operator and orchestration commands support

While it does not change anything from a usability perspective, the underlying Viya deployment method used by the DaC has changed.

Until very recently, the method used by the DaC to deploy Viya was the manual method (with the kustomize and kubectl apply commands).

However since the release of stable 2022.12, the DaC has been updated to use either the SAS Deployment Operator or the new “sas-orchestration command” method (described above).

Several new variables, such as V4_DEPLOYMENT_OPERATOR_ENABLED, V4_DEPLOYMENT_OPERATOR_SCOPE, V4_DEPLOYMENT_OPERATOR_NAMESPACE, V4_DEPLOYMENT_OPERATOR_CRB have been introduced to allow the DaC user to choose which of the two methods to use and how to configure them.

When not specified explicitly in the ansible vars file, the default for the DaC is to deploy the Deployment Operator with a "cluster" scope (in its own "sasoperator" namespace).

This change means that from now, the DaC always uses the sas-orchestration tooling, which introduces a new requirement : you need to have Docker installed on the machine from where you run the DaC tool and the executing user should be able to access it.

Comparing the methods

Choosing the right method is one of the key decisions that needs to be made during the Architecture design phase of the Viya implementation project.

The choice, not only impacts the way the initial deployment is performed, but also the way the future update operations will be done and how the customer’s specific configuration changes will be made…

The tables below can be used as a starting point of your conversation with the customer.

Benefits, Capabilities, Restrictions and use cases

Method

Benefits and Capabilities

Restrictions, additional considerations

Target use case

Deployment Operator

· Automates deployment steps (pull assets, kustomize, kubectl apply)

· During updates, automates the pull of newer deployment assets and several Deployment notes steps

· Manage the deployment / update of multiple Viya deployments of the same version within the same cluster

· Feature to schedule daily automated release updates (within the same version)

· Validation of adherence to the Viya policy (e.g.: Version update path controls)

· Requires service account to run the operator with cluster-wide RBAC permissions in the cluster

· Requires docker on the jump host to generate the SAS Deployment CR

· No capability to apply resources based on permissions level (cluster-wide, namespace-scoped, etc...)

· Takes longer to apply configuration changes. For most (all ?) configuration changes - like changing the number of CAS workers - the reconcile operation redeploy, restart postgres instances.

· Increased complexity of configuring a private registry for the Viya images.

· Use in offline/dark sites (no internet access) requires extra httpd server with a mirror of the entitlements

· Operator driven Viya deployment happening within the cluster (it might meet the customer preferences or requirements).

· SAS-Supplied automation (“Black box*” deployment).

sas-orchestration commands

· Automates deployment steps (pull assets, kustomize, kubectl apply)

· During updates, automates the pull of newer deployment assets and several Deployment notes steps.

· Does not require a service account to run the operator with cluster-wide RBAC

· Validation of adherence to the Viya policy (e.g.: Version update path controls)

·The sas-orchestration image includes a supported version of kubectl and Kustomize

· Requires docker on the jump host to deploy SAS Viya

· No capability to apply resources based on permissions level (cluster-wide, namespace-scoped, etc...)

· Takes longer to apply configuration changes.

· Container-driven Viya deployment

· A Docker image, “sas-orchestration”, is used to automate the deployment process from outside the cluster.

· SAS-Supplied automation.

Kubectl apply commands (“manual”)

· Better control of the process

· Kustomize-generated manifest file is available for troubleshooting and further processing (for example security scans).

· The most flexible method when integrating with customer automation tooling

· Declarative - The kubernetes way

· No SAS-supplied automation features

· No validation of adherence to Viya Policy

· Full control is required

· Customers who want to use standard native Kubernetes deployment process (kubectl commands)

· Customers with strict requirements on Kubernetes permissions with distinct roles to perform deployment and configuration operations.

SAS Viya 4 Deployment GitHub project

· Automates everything (initial config, pull assets, kustomize, kubectl apply)

· Automates several common customizations documented in component’s specific READMEs

·The source code is open and can be customized/changed if needed

· Can use either the Deployment Operator Method or the sas-orchestration commands

· Can automate the pre-requisite installation (ingress nginx, nfs provisioner, etc…)

· Can automate Viya monitoring tools deployments

· Same considerations as “Deployment Operator” or “sas-orchestration” command methods

· Specific way to change the configuration, with adjustments

· Does not perform updates (documented steps must be followed with adjustments regarding the directory structure)

· Not supported for Red Hat OpenShift

· Issues with the Deployment method fell under the sassoftware GitHub support policy (instead of standard support)

· Simplified initial deployments, with Maximum automation (PoC, tests)

· Combination/ Integration with the IaC

· All target use cases listed for “Deployment operator” and “sas-orchestration commands” methods

· SAS-provided open-source deployment automation

Overall Deployment and Update steps

Standard steps for a new Deployment (with no multi-tenancy, no SingleStore, no mirror registry):

Manual

DepOp

Orchestration command

DAC

1. Install all the Viya pre-requisites or ensure they are in place.

2. Pull the Deployment assets

3. Prepare the Viya Kustomization.yaml and site-config custom configuration

4. Build the manifest with Kustomize

5. Apply the manifest (4 commands to apply per type of Kubernetes objects)

1. Install all the Viya pre-requisites or ensure they are in place.

2. Pull the Deployment assets

3. Configure and Install the Deployment Operator

4. Prepare the Viya Kustomization.yaml and site-config custom configuration

5. Pull the orchestration CLI image

6. Generate the SAS Deployment CR

7. Apply the SAS Deployment CR

1. Install all the Viya pre-requisites or ensure they are in place.

2. Pull the Deployment assets

3. Prepare the Viya Kustomization.yaml and site-config custom configuration

4. Pull the orchestration CLI image

5. Run the orchestration “deploy” command

1. Pull the DaC git repository

2. Configure the deployment in the ansible vars.yaml

3. Run the playbook/docker command to install the pre-requisites and deploy Viya

Standard steps for a version update (with no multi-tenancy, no SingleStore, no mirror registry):

Manual

DepOp

Orchestration command

DAC

Prepare for the update:

1. Create a Backup

2. Review System Requirements and Resources

3. Download New Deployment Assets

4. Read the Deployment Notes and apply “before deployment commands”

5. Perform Required Tasks by Component

Deploy the new version

6. Re-build the manifest with Kustomize

7. Apply the manifest (4 commands to apply per type of Kubernetes objects)

Apply “After Deployment commands” in Deployment notes

Prepare for the update:

1. Create a Backup

2. Review System Requirements and Resources

3. Optional : update the Deployment Operator

4. Download New Files from My SAS

5. Read the Deployment Notes and apply "before deployment commands"*

Apply the SASDeployment Custom Resource

6. Update the orchestration image.

7. Create the SASDeployment custom resource with updated values.

8. Apply the SASDeployment CR

Apply “After Deployment commands” in Deployment notes*

Prepare for the update:

1. Create a Backup

2. Review System Requirements and Resources

3. Download New Files from My SAS

4. Read the Deployment Notes and apply "before deployment commands"*

Deploy the new version

5. Update the orchestration image (must match the version defined in the deployment assets README).

6. Run the sas-orchestration deploy command with updated version value

Apply “After Deployment commands” in Deployment notes*

Depending on the underlying method (Deployment operator or sas-orchestration), follow the documented steps and make the correct adjustments as the files organization, Kustomization.yaml form and ways to redeploy with the updated version will be different.

(*) When using the deployment operator or the sas-orchestration command, some deployment notes are not required.

Overall Summary

Manual

DepOp

Orchestration command

DAC

· Standard Kubernetes deployment with kubectl apply command, more control but no SAS Automation.

· SAS automated /orchestrated deployment with an Operator.

· Follows the K8s Operator pattern but more Complex and many steps.

· Reduces the number of steps in the update process.

· SAS automated/orchestrated deployment, without the need of a full blown Operator.

· Ansible driven method with a variable files. Simplifies the pre-requisites setup, common configurations and deployment for initial deployments.

· But version updates and non-standard configuration requires adjustments.

These methods are using the DaaS (for "Deployment as a Service") orchestration tooling which is aimed to embed additional automation and product specific configurations and checks for SAS Viya deployments in the future.

Changing method

Changing from one deployment method to another is possible but requires an outage and a redeployment of the software and possibly a migration of content.

Moving away from the Deployment Operator is the operation that requires the most amount of work (full redeployment with backup and restore operations).

The possible scenarios are officially documented here.

Conclusion

The key takeaway of this post is that there were 2 significant changes made to the deployment methods with the last 2022 SAS Viya version (stable 2022.12):

A fourth deployment method "sas-orchestration command" has been introduced.
The DaC tool now relies on the Orchestrated deployment methods (instead of the “manual” apply commands).

The deployment method choice is important as it determines how to manage your Viya platform in the long term.

It is something that must be discussed and agreed with the customer as part of the Architecture design and documented in the D30 (or equivalent Architecture Definition document).

Hopefully this post will be helpful to achieve this objective.

Thanks for reading !

Find more articles from SAS Global Enablement and Learning here.