The SAS Deployment Operator makes light work of many deployment and administration tasks. My colleague Mike Goddard wrote a great introductory post about what it is, how it works, and deployment options. In this post, we'll look at the steps required to update the SAS Deployment Operator to keep it running smoothly with all the latest fixes and features.
Updating the updater?
Using the Deployment Operator is the recommended approach for applying updates (patches or version updates) to your SAS Viya deployment. In fact, if you don't have it deployed in your Viya environment, the recommended approach for applying Viya software updates is to first deploy it, and then use it to apply the updates. But what about updating the Deployment Operator itself? The Deployment Operator and the rest of your deployed Viya software can generally be updated independently from each other, and the Deployment Operator is backwards compatible with older versions of Viya. As a general recommendation, consider updating the Deployment Operator at least each time you update your Viya software to the latest version. Deploying the latest and greatest will help keep your environment well-oiled. In some cases, it is actually a requirement to upgrade the Deployment Operator as part of a version update to SAS Viya. The good news is that it is a relatively a straight-forward process!
Step 1: Back up and obtain new Deployment Assets
OK, so technically this is more than one step. The intial step requires you to get new Deployment Assets from the MySAS portal or using the viya4-orders CLI to replace the existing assets. The new assets contain the new transformers and manifests for the operator deployment.
First, back up the existing $operator-deploy directory (in this example, the operator is deployed in cluster-wide mode😞
cp -r /home/cloud-user/project/deploy/operator-deploy /home/cloud-user/project/deploy/operator-deploy-orig
Then delete the operator's existing/old sas-bases directory:
cd /home/cloud-user/project/deploy/operator-deploy
rm -rf sas-bases
After getting the new assets (for the later/latest version), extract the tarball to create a new sas-bases directory.
tar xvfz SASViyaV4_9CKY1V_stable_2022.09_20221010.1665437790467_deploymentAssets_2022-10-10T224758.tgz
Step 2: Copy new operator files
Copy the required operator files to the top-level $operator-deploy directory and make them writable.
cd /home/cloud-user/project/deploy/operator-deploy
sudo cp -r sas-bases/examples/deployment-operator/deploy/* .
chmod +w site-config/transformer.yaml
Step 3: Restore YAMLs from backups
Rather than making required updates to the kustomization.yaml and transformer.yaml files manually, restore the files from the backups taken earlier, which already contains the necessary customisations such as setting required ClusterRoleBindings, configuring a mirror registry and choosing between cluster-wide mode and namespace mode.
# restore from backups
cp ../operator-deploy-orig/site-config/transformer.yaml site-config/
cp ../operator-deploy-orig/kustomization.yaml .
If necessary, make any additional configuration changes after restoring. Be sure to glance over the deployment instructions to verify whether any new customisations are requried. If you repeat this process the next time you update the operator, new additions will be retained next time around.
Step 4: Deploy
And the last step is to deploy. In cluster-wide mode, specify the name of the operator's namespace.
kustomize build . | kubectl -n sasoperator apply -f -
As demonstrated, the process is essentially a redeployment using new assets (but note that fields in transformers.yaml refer to existing values). No clean up is necessary before or after the update, and the operator should not be stopped prior to commencing the update. The new Deployment Operator will be available once the operator pod starts after you deploy (in the last step). Be sure to read the documentation just in case any additional changes are required to transformer.yaml or kustomization.yaml after restoring them.
Thanks for reading.
