11 software delivery problems solved by intelligence software delivery platform  Download
Select Page

The Benefits of Modern Continuous Delivery with Spinnaker and OpenShift

Marky Jackson October 29, 2020
Share

Continuous Delivery 

Continuous Delivery (CD) is the approach to get a new software release deployed into production quickly, safely, and in a sustainable manner through a straightforward and repeatable deployment process. The new release version of Spinnaker, a tool for Continuous Delivery, incorporates change requests, bug fixes, configuration changes, and so on. It aims at building, testing, and releasing software with greater speed and frequency.

The goal of CD is to make deployments safe and predictable while achieving the ability for faster release cadence. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production.

Be it for a large-scale distributed system, a complex production environment, an embedded system, or an app CD ensures that the software can be reliably released at any time and, when releasing the software, doing so manually.

The Continuous Delivery Pipeline represents the workflows, activities, and automation needed to guide and manage a new piece of functionality from the ideation to an on-demand release of value to the end-user.

Spinnaker for Continuous Delivery – An Introduction

For those who are new to Spinnaker, it is a part of the Continuous Delivery (CD) pipeline. It takes care of all of the deployment phases of the applications being deployed. Spinnaker supports Application Management. It can be used in conjunction with Continuous Integration (CI) Technologies like Jenkins, Circle CI, Travis CI, BitBucket, TeamCity, and so on. Using Spinnaker you can deploy apps that are supported by all major cloud providers like AWS, GCP, Azure, IBM Cloud, Kubernetes, and so on.

What is the Spinnaker Continuous Delivery platform?

Spinnaker is an open-source multi-cloud Continuous Delivery platform. It is used for building and releasing software changes with high velocity and confidence. It is designed with pluggability in mind. As already mentioned it supports deployment to all major cloud providers like AWS, GCP, Google App Engine, Azure, IBM Cloud, OpenStack Kubernetes, Oracle Cloud, and so on. You can create deployment pipelines that run integration and system tests and then deploy them back to a given environment. You can set up webhooks (“user-defined HTTP callbacks”) triggered by git events, Jenkins, Travis CI, Docker, CRON, or others in your Spinnaker pipeline. You can also create and deploy immutable images for faster rollouts, easier rollbacks, and the elimination of hard-to-debug configuration drift issues. (During software development, when you are building Docker images and need to deploy them, you will need a good set of automation tools in case you need to rollback. You can do your deployments with Spinnaker.)  There is a large community that supports and contributes to the Spinnaker project; the Community includes- Netflix, Google Microsoft, Veritas, Target, Kaizen, Schibsted, and many more.  

Why would you need Spinnaker for Continuous Delivery?

The goal of Spinnaker is to make reliable deployments. Jenkins as a tool excels in CI but when it comes to CD you have to rely on other plugins or write custom scripts to do so whereas Spinnaker does this out-of-the-box and integrates perfectly with Jenkins. Spinnaker makes deployments cost-effective and easier. 

Spinnaker deployment pipelines allow easy rollbacks. If you have deployed a Docker image to production after debugging and error fixes and yet find issues with the new deployment Spinnaker allows you to easily rollback to your earlier image. 

With Spinnaker, you can deploy faster at high velocity, deploy reliably with confidence, and deploy often. A flexible pipeline management system allows you to use various parameters, event triggers, a gated approval process throughout the pipeline. 

Like Kubernetes or Jenkins, Spinnaker is an open-source application with a wide vibrant community supporting it and a lot of active contributors making it successful. Spinnaker has integration with all the major cloud providers supporting both on-premise and cloud Kubernetes. Spinnaker even supports air-gapped environments. 

Spinnaker is feature-rich with :

  • CI -Integration
  • CLI for setup and admin console
  • VM Bakery
  • Role-Based Access Control(RBAC)
  • Allow listed execution window
  • Monitoring Integration
  • Notification and manual judgment (e.g. Plugins for Slack, Jira)
  • Chaos Monkey integration (To stress-test your environments)

Spinnaker Architecture

Spinnaker consists of a number of individual components and they follow a microservices architecture ( refer to the image below). The major components are:

  • Deck (UI to access Spinnaker)
  • Gate (Manages API calls)
  • Orca (Orchestration engine responsible for pipeline and other operations)
  • Cloud Driver (Responsible to make calls to different providers e.g. AWS, Azure, Google)
  • Front50 (Hold metadata of applications, pipelines, projects, and notifications)
  • Rosco (Responsible for produce immutable VM images)
  • Igor (Responsible to trigger pipeline)
  • Echo (Responsible for event triggers, send notifications to Slack, email, and so on).
  • Fiat (Responsible for authorization in Spinnaker).
  • Kayenta (Responsible for Canary Analysis)
  • Halyard (Responsible for managing all Spinnaker services and configuration using CLI, using this we can update, rollback, and so on) 
Spinnaker Architecture

Spinnaker Architecture

Continuous Delivery pipelines with Spinnaker      

Use Spinnaker to create CD pipelines that join various stages of deployment – code check-in, continuous integration, bake image, prod deploy & test, hotfix, canary, and live deployment.

Spinnaker Continuous Delivery pipeline stages

Spinnaker Continuous Delivery pipeline stages

Methods of Spinnaker Installation

Spinnaker installation methods include:

  • Local Debian (Standalone not recommended for production)   
  • Distributed Method (Kubernetes, Openshift, AWS, GKE…)
  • HELM
  • Operator

Click here if you are interested to install and configure enterprise Spinnaker for your environment

What is HELM?

The basic idea of Helm is to enable the reusability of Kubernetes YAML artifacts through templatization. The benefits of Helm are- easy to deploy an application and update the application, using the YAML files. The Helm project has gained considerable popularity as it solves one of the key problems the enterprise-creating YAMLs for deploying the same application workload with different settings or deploying it in different environments ( dev/test/prod).  OpsMx does support Helm-based installation too.

What is SpinnakerOperator?

  • The Spinnaker Operator is used for the method of building and driving an application on top of Kubernetes. You can easily use the Kubernetes tools to help you solve the complex application.
  • The benefit of using a Spinnaker Operator is that you can use a stateful application through writing a custom controller with domain-specific knowledge.
  • The automation of infrastructure that is needed to run the containerized application is rendered possible through Kubernetes. It can be difficult to translate human knowledge into software.  Instead, Kubernetes operators take knowledge from a DevOps team and systemize it, until it is completely automated. 

For example, let’s say there is a Cassandra cluster, and in that Cassandra cluster, there is a ring of six nodes. In case one of those nodes close down a DevOps engineer will need to run a series of steps to locate and fix the problem like:

  • Is the ring healthy?
  • How to propagate data when a node is added?

The Operator takes this knowledge from DevOps teams and systemizes it to automate the troubleshooting processes. It is a major advantage for the companies as it saves costs, labor, and time.

Helm vs Spinnaker Operators

  • Helm and SpinnakerOperators represent two different phrases in managing application workloads on Kubernetes.
  • Helm’s primary focus is on the day-1 operation of deploying Kubernetes artifacts/application in a cluster
  • On the other hand, the Spinnaker Operator is focused on addressing on day-2 management tasks of stateful/ complex workloads such as Postgres, Cassandra, Spark, Kafka, SSL Cert Mgmt, etc. on Kubernetes, the Spinnaker Operator is used.   

Spinnaker Operator Architecture

The Operator has two important components and they are:

  • CRD (Custom Resource Definition)
  • OLM (Operator Lifecycle Manager)

CRD – CRD will act as the brain of the operator, which holds data that represents the application and its core is stored here.

OLM – OLM is responsible for the upgrade, Metadata, Dependency Resolution, install multiple versions on the same node. 

Spinnaker Operator Architecture

Spinnaker Operator Architecture

Spinnaker Deploy Steps

  1. Register the CRD
  2. Create any needed Role-Based Access Control (RBAC)
  3. Deploy the operator
  4. Create an instance

Here is the sample code:

Steps to deploy Spinnaker

Steps to deploy Spinnaker

YAML – CRD Manifest

Using the OpsMx Enterprise for Spinnaker (OES) Operator. 

YAML - CRD Manifest

YAML – CRD Manifest

YAML – Service Account

A service account is needed for using the Spinnaker Operator in a cluster.

YAML - Service Account

YAML – Service Account

 

YAML Operator

YAML - Operator

YAML – Operator

YAML Deploy

Deploying the OpsMx Enterprise for Spinnaker:

YAML Deploy

YAML Deploy

Benefits of Spinnaker Operator

Having the Spinnaker Operator for Openshift gives a lot of flexibility to the DevOps team as the deployments are automated and are easier to rollback when needed. OpsMx’s Spinnaker Operator is trusted as it comes with Red Hat certification. An enterprise-grade solution for CD means no plugins or custom coding is required unlike deploying with Jenkins which is specialized for CI. You get a built-in policy engine for all your compliance requirements. Finally with the Spinnaker Operator for Openshift upgrading the Kubernetes cluster in production (say from 1.15 to 1.16) is a complex job made simple. It is really easy and well managed because of the following reasons:

  • Automated Releases: Automate releases with flexible pipeline builder, built-in policy control to dynamically alter multi-service composite application deployment.
  • Red Hat certified and tested
  • Enterprise-grade solution for CD 
  • Adhere to compliance (SOX, GxP, HIPAA, etc…)
  • Easy upgrade

Content Download and Contact Information

In case you are interested to know more please visit the following link:

If you want to know more about the Spinnaker or request a demonstration, please book a meeting with us.


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

You May Like