OpsMx Enterprise for Spinnaker 3.2 is Generally Available

The month of November has started and startled all with the hint of incessant efforts humanity has made towards progression; “effective and safe” covid-19 antidote to stop the pandemic. We at OpsMx similarly did not cease to make progress in software delivery in our own way.

Increasing number of customers are downloading and using OpsMx Enterprise for Spinnaker (OES). But to configure the production grade Spinnaker with enterprise grade features used to take many days.

Thus, to make the process of production grade Spinnaker easy, we have introduced compelling life cycle management (LCM 1.0) features and enterprise capabilities in OES 3.2.

Following features we have introduced under  each category:

1. Enterprise capabilities
   1. High Availability of Spinnaker
   2. Secret Management
   3. Dynamic Configuration of accounts
2. Life Cycle Management ( LCM 1.0)
   1. Configuration Management in GitOps
   2. Spinnaker Upgradation using Git
   3. Installation Modes

Now the best part, customers can install production-ready Spinnaker (LCM and enterprise capabilities) with just a single command.

$ helm install <release-name> opsmx/oes --set gitopsHalyardInit.enabled=true

Following are the detailed updates in OES 3.2 release:

Enterprise Capabilities

1. High Availability(HA) Spinnaker to Extend Reliability: 

Enterprise that uses multiple Spinnakers for app deployments into production more than 100 times per day, regards availability as the first priority to them. They could be required to run Spinnaker instances in various availability zones, and making Spinnaker highly available is not an easy task. 

An Ops person should have the right context and knowledge about halyard configurations, ability to correctly modify hal config files, set right capacity and resources to Spinnaker instances,  and deploy (hal deploy apply). Moreover, he should be ready for service in the time of disaster. 

For Spinnaker used in production we have tried to minimize the risk of manual errors during configuring in production by providing HA Spinnaker, as default, with LCM 1.0. ( below image represents the type of environment (large/medium/small) and the resources required for HA Spinnaker namespaces, are automatically configured)

With LCM 1.0, enterprise will get Spinnaker installed in HA mode for Clouddriver and Echo services.

Well what happens to clouddriver and echo services in HA mode?

Like in the above image, Clouddriver will have four different services in HA mode, namely- 

• Clouddriver caching: to cache and retrieve cloud infrastructure data
• Clouddriver-rw: to handle all mutating operations aside from what the clouddriver-caching service does
• Clouddriver-ro: to control all read requests to Clouddriver
• Clouddriver-ro-deck: to take all read requests to Clouddriver from Deck (through Gate)

Echo will be split into two different services, namely

• Echo-scheduler: to handle scheduled tasks or cron jobs
• Echo-Worker: to manage all operations of Echo besides the cron jobs

In HA mode, Clouddriver-rw, Clouddriver-ro, Clouddriver-ro-deck, and Echo-Worker services can be scaled to multiple pods based on requirements.

2. Secrets Management for Improved Security of Continuous Delivery

Storing sensitive information in Halyard or plain text is not a good security practice. For improved security, we have come up with enhanced secret management. Secrets related to accounts (e.g., Jenkins passwords, k8s kubeconfig files, tokens, etc.) are encrypted and stored in git/S3 instead of using Halyard. 

[Note: We always supported secrets management for OSS and OES. But from OES 3.2 secrets management is offered as a part of LCM 1.0.]

The screenshot below which highlights the git path for a secret reference.

secret management in Spinnaker using GitOps

3. Dynamic Configuration of New Accounts in 4 mins

There are situations when the infrastructure or admin team has to create a new cloud provider account in Spinnaker during run-time, say, a new Kubernetes cluster during the pipeline deployment or before the pipeline deployment. Typically they have to modify yaml files and deploy those changes using ‘hal deploy apply’. And to initiate those changes, Spinnaker has to be restarted, which will fail all your pipelines in execution. This will negatively impact releases planned for encashing new business opportunities.

 The default installation of Spinnaker through LCM 1.0 comes with pre-configuration for dynamic Kubernetes accounts. Admin team can now control new Kubernetes clusters from the dynamic account by placing the files in Git. And automatically, Spinnaker will identify new accounts and show them in the Spinnaker applications. Add, update, or delete Kubernetes accounts in Spinnaker without the need for restarting Spinnaker.

Below video shows how accounts can be configured dynamically in halyard.

LCM 1.0 Features

1. Configuration Management using GitOps for enhanced flexibility

We have enabled Gitops style Spinnaker configuration management. Halyard does not have persistent storage, so all configuration information is stored in the git repository or S3. In case a halyard pod crashes, or the entire node goes down, then, as part of disaster recovery, spinning up a Spinnaker instance with the same configuration is accessible by only using Git repo. Before OES 3.2, to configure Halyard, the Ops person connected to the Halyard, ran a set of commands and configured everything manually. It would take the Ops manager a bit of context to write scripts to configure an instance (typically used to take a few hours). However, when Spinnaker instances fail, an Ops manager needs to install a Helm chart and instruct to fetch configuration details from Git (takes only minutes). 

2. Hassle-free Spinnaker Upgradion with GitOps

It is best practice to not provide access, to any users, to access those Kubernetes clusters which run Spinnaker instances for modification such as version upgrade.

In a large production environment, where multiple Spinnaker instances are running on Kubernetes usually, a default (or say master) Spinnaker is commissioned to manage or deploy all those Spinnaker instances. 

Spinnaker releases new versions almost every month. Enterprises need to update their Spinnaker to enjoy the latest features.  When they want to update a single instance of Spinnaker, then in OES 3.2, it just takes a two-step process for version upgrade- change the version in the configuration file, and restart the instance in master Spinnaker. 

The moment the Spinnaker instance is restarted, halyard gets restarted, and a newer version of the spinnaker will be installed with minimal effort. 

Note that all your pipeline data and account data will be in persistent volume to be restored automatically. 

3. Installations Options

We have also introduced various installation modes. By selecting different installationmode parameter values, customers can choose different modes- Open Source Spinnaker (without enterprise-grade features and intelligent verification platform), OpsMx Enterprise for Spinnaker (OES), and Autopilot. , they can do it in one click.

Refer: https://github.com/OpsMx/enterprise-spinnaker

OpsMx is a leading provider of Continuous Delivery solutions that help enterprises safely deliver software at scale and without any human intervention. We help engineering teams take the risk and manual effort out of releasing innovations at the speed of modern business. For additional information, contact us.