Highlander deployment

There can be only one !

Highlander deployment

In the previous exercise we set up the wonderfulapp deployment pipelines. An issue remains: the successive execution of each Pipeline creates outdated but still active Server Groups. If you encountered issues with your deployments, you may have to manually delete some of these server groups.

Is there a way to delete automatically old Server Groups when deploying new ones ?

Using stages

The Kubernetes V2 Cloud Driver we use in this hands-on provides stages to interact with Kubernetes manifests:

• Bake (Manifest): turns a template into a manifest using a template Engine (HELM2 by default)

• Patch (Manifest): Patch a Kubernetes manifest

• Scale (Manifest): scale the number of replicas managed by this manifest

• Delete (Manifest): delete the specified manifest

• Deploy (Manifest): deploy the specified manifest

• Enable (Manifest): enable the specified manifest by switching its traffic on

• Disable (Manifest): disable the specified manifest by switching its traffic off

• Run Job (Manifest): run a kubernetes job

• Undo Rollout (Manifest): Rollback a manifest

Exercise:

We can use the Delete (Manifest) stages in order to implement a simple Highlander deployment. Modify the depoy-dev Pipeline:

• add a new Delete (Manifest) stage

• select the account ${account}-account

• select the namespace ${account}

• select "Choose a target dynamically"

• select the kind "replicaSet"

• select the cluster "replicaSet wonderfulapp-replica"

• select the target "Second Newest"

• name the stage "Delete old replicaSet"

• save your changes

Head to the Infrastructure page, and manually delete all Server Groups running in the Cluster "replicaSet wonderfulapp".

Get back to the Pipelines page:

• run the Pipeline "deploy-dev" with the parameter version=blue

• wait for completion: the last stage fails after some times, because Spinnaker can't resolve the second oldest manifest :/

• run the Pipeline "deploy-dev" with the parameter version=green

First, the new Server Group being deployed appears, but no instance has spawn yet.

Then an instance spawn, and the Load Balancer (Service) is attached to the Server Group.

Finally, as the new Server Group stabilizes, the old one is removed.

Built-in deployment strategies

Spinnaker provides a set of built-in deployment strategies, such as Highlander, Red/Black or Canary. These strategies implementations are tightly coupled with the Cloud Provider in use (here: Kubernetes Cloud Provider v2), performing deployment in regard of Cloud Provider constraints and deployment's best practices.

Exercise

We will copy the previous pipeline into another, in order to use the Highlander built-in strategy:

• Click the "create" button in the pipeline page

• Name the new pipeline "built-in-strategy"

• Select Copy From "deploy-dev"

Head to the new pipeline "built-in-strategy", and remove the "Delete old Manifest" stage copied from the previous exercise.

Modify the Service manifest and the ReplicaSet manifest according to the followings YAML:

• Service Manifest

  apiVersion: v1
  kind: Service
  metadata:
    name: wonderfulapp-service
    namespace: ${account}
  spec:
    ports:
      - port: 80
        protocol: TCP
    selector:
      workload-app: wonderfulapp
      workload-environment: dev

• ReplicaSet manifest

  apiVersion: apps/v1
  kind: ReplicaSet
  metadata:
    name: wonderfulapp-replica
    namespace: ${account}
  spec:
    replicas: 1
    selector:
      matchLabels:
        app: wonderfulapp
        environment: dev
    template:
      metadata:
        labels:
          app: wonderfulapp
          environment: dev
      spec:
        containers:
          - image: 'jcalderan/wonderfulapp:${parameters.version}'
            name: wonderfulapp
            ports:
              - containerPort: 80

You may have notice the Service's selectors doesn't match anymore the ReplicaSet's labels: when we use a Spinnaker built-in deployment strategy, it will dynamically update in place (Patch) the ReplicaSet manifest with the Service's labels. If selector and labels are already using the same name, the Patch will fail.

• go to the "Deploy ReplicaSet" stage

• in the Manifest section, in the "Rollout Strategy Options" sub-section, enable "Spinnaker manages traffic based on your selected strategy"

• select the namespace ${account}

• select the service "wonderfulapp-service"

• check "Send client requests to new pods"

• select the strategy "Highlander"

• save your changes

Head to the Infrastructure page, and manually delete all Server Groups running in the Cluster "replicaSet wonderfulapp". Get back to the Pipelines page:

• run the Pipeline "built-in-strategy" with the parameter version=blue

• wait for completion: the last stage fails after some times, because Spinnaker can't resolve the second oldest manifest -_-'

• run the Pipeline "built-in-strategy" with the parameter version=green

Spinnaker deploys a disabled Server Group, unable to accept traffic. At some point, both Server Group are enabled and accept traffic. When the new Server Group is ready, the old one is automatically deleted.

Summary

We can either implement our own deployment strategy, or rely on one of the built-in strategies Spinnaker provides. Combining stages allows to fine tune the deployment strategy in order to match complex use cases and requirements, while the built-in strategies provided by Spinnaker ensure deployment best practices are in use.