Deployment Automation series #2: How?

1 Like

In the first part of this blog series we focused on the “Why”. Why would you want to automate your deployments and when is deployment automation a good fit for your deployments?

This second installment will give you a foundation on how to start creating your deployment pipeline. An important note here is that no deployment pipeline will be exactly the same. Any pipeline will have to interface with existing infrastructure and fulfill specific requirements that may be unique to your situation. This blog will therefore not contain code, but merely link to existing assets that you can use to build your pipeline. This blog post will focus on Viya 4 deployments.

Automation Tooling

As mentioned in the previous blog post, the automation tooling that you use to build your deployment pipelines is usually a given. It will probably be standardized for the entire company or an entire division. We will therefore not spend too much time on this topic.

One important consideration for choosing automation tooling should be the capability to have well versioned pipeline definitions. As we will see in the next part of this blog series, pipelines consist of many moving parts that need to work together to deliver the environments you require. Keeping all components in line with each other, both in terms of versioning and configuration is a challenge that requires frequent updates to your pipelines. Keeping a version and change history of your pipeline definitions is therefore very important. Make sure the automation tooling that you use offers or integrates with a versioning system like Git.

Platforms

A choice of automation tooling might also be influenced by the platform on which you will eventually deploy your environments. When deploying your software to Azure, the natural choice will generally be to use Azure DevOps. It comes with its own Git repository for each project you create and provides out-of-the-box tasks for working with the Azure CLI and extensions for working with Terraform for example.

Although Azure DevOps can also be used to deploy infrastructure in AWS or GCP, a more platform agnostic choice might be more logical. Examples of these include Gitlab, which comes with extensive support for CI/CD pipelines and Jenkins with a very modular plugin-based approach.

Your platform might also come with predefined automation tooling. When deploying RedHat OpenShift for example it provides three CI/CD solutions: OpenShift Build, OpenShift Pipelines and OpenShift GitOps.

Pipeline Phases

Although terminology differs between different automation tooling, pipelines usually consist of three levels of building blocks: phases, jobs and tasks. A task is the smallest element in a pipeline and executes a single instruction, a job is a sequence of tasks and a phase is a collection of jobs that ideally can be executed in parallel. By dividing your pipeline into phases you can parallelize where possible while maintaining a sequence where this is necessary.

Phase 1: Infrastructure Provisioning

The first phase of your pipeline will usually provision the infrastructure needed to support your deployments. This phase uses Infrastructure as Code scripts to accomplish this. The sassoftware Github project provides four different IaC templates to help you get started with creating this phase:

The IaC templates for Azure, AWS and Google Cloud use Terraform to define and provision the required infrastructure. Terraform is also used when deploying Open Source Kubernetes to VMWare vSphere. When deploying Open Source Kubernetes to existing physical or virtual machines, the IaC template will use Ansible scripts to deploy Kubernetes on the existing machines.

For RedHat OpenShift and Google Anthos on VMWare there are no templates available. These Kubernetes environments have their own deployment mechanisms, which can be found here:

Phase 2: Installation Prerequisites

Before SAS can be deployed, the prerequisites needed for the deployment need to be satisfied. These requirements include deploying an Ingress Controller in the Kubernetes cluster and/or creating a PostgreSQL database. Steps like obtaining the software license or mirroring the SAS container images are also part of this installation prerequisites phase.

Satisfying these installation requirements can be done by using native tasks available in the automation tooling. A number of these requirements can be fulfilled by leveraging an Ansible playbook provided on the sassoftware Github project.

SAS Viya 4 Deployment

This project contains ansible code that creates a baseline cluster in an existing Kubernetes environment for use with the SAS Viya platform, generates the manifest for a SAS Viya platform software order, and then deploys that order into the specified Kubernetes environment. As such the SAS Viya 4 Deployment repository can do more than implement prerequisites and can also be used in to implement phase 3: Software deployment.

Phase 3: Software Deployment

Once all prerequisites have been put into place, deploying the SAS software is pretty straightforward. There are a couple of options documented in the Operations Guide: SAS Help Center: Deploy the Software

For automated deployments, using the sas-orchestration docker image is probably the easiest approach. One of the sas-orchestration command parameters is the location of the deployment files. It is advisable to store these deployment files in a Git repository as well alongside the pipeline definition. This way any changes required to the deployment files will be versioned and deployments of specific SAS versions can reference the deployment assets corresponding to that version.

Alternatively, you can use the SAS Viya 4 Deployment project mentioned above.

Phase 4: Post-Installation Tasks

There are a number of post-installation tasks that need to be performed depending on your software bundle. These are listed here:

SAS Help Center: Post-Installation Tasks

A lot of these tasks include changes that can be incorporated into the SAS deployment assets (preferably stored in Git). For changes that cannot be incorporated into the SAS deployment assets, the sas-viya CLI is the best way to introduce changes to a system post-deployment.

SAS Help Center: Command-Line Interface: Overview

In the end you will end up with a pipeline that combines all these phases: