In the past, poor canaries were used as guinea pigs to test methane levels in coal mines. A cage containing a canary is lowered into the mine with a rope for a certain period of time, and then pulled up. If the canary is still alive, the mine can be mined safely. If the canary dies, it can’t be mined. Now, this method has been abandoned because it is too inhumane to the animals.

The canary was always hovering over the miners. If it stopped singing, it meant the miners had to leave the mine.

A Canary deployment is when two versions of an application coexist and the new version starts out smaller and handles less load traffic. As the new deployment is analyzed, all requests are gradually switched to the new version and the old version of the application is removed.

It is widely believed that managing traffic for these deployments requires using a Service Mesh. To manage inbound traffic, however, you only need to set Annotations on the Nginx Ingress Controller:

nginx.ingress.kubernetes.io/canary:  "true"
nginx.ingress.kubernetes.io/canary-weight:  <num>
Copy the code

The downside of this approach is that it has to be managed manually. To automate, we can use Argo Rollouts (argoproj.github. IO /argo-rollou…

Run the Argo Rollouts

Add the helm – repo: argoproj. Making. IO/Argo – helm

Argo – rollouts chart:

Helm – values:

installCRDs: true
Copy the code

Modify the Deployment and run the Rollouts CRD

ScaleDown deployment, Replicas 0:

Run the service

apiVersion: v1 kind: Service metadata: annotations: argo-rollouts.argoproj.io/managed-by-rollouts: rollout-pregap name: Rollouts-pregap - Canary Namespace: pregap spec: clusterIP: 10.43.139.197 Ports: -name: HTTP port: 8080 protocol: TCP targetPort: 8080 selector: app: test2-pregap sessionAffinity: None type: ClusterIPCopy the code
apiVersion: v1 kind: Service metadata: annotations: argo-rollouts.argoproj.io/managed-by-rollouts: rollout-pregap spec: ClusterIP: 10.43.61.221 Ports: -name: HTTP port: 8080 Protocol: TCP targetPort: 8080 Selector: app: test2-pregap sessionAffinity: None type: ClusterIPCopy the code

Run Rollouts CRD

Since we do not want to change Deployment, we refer to it in the Rollout manifest: workloadRef.kind: Deployment, workloadRef.name

Running the manifest creates additional ingress:

Argo Rollouts dashboard

Other steps in CD-pipeline

Add lifting steps to.drone.yml:

- name: promote - release - Dr Image: plugins/docker Settings: repo: 172.16.77.115:5000 / pregap registry: 172.16.77.115:5000 insecure: true dockerFile: dockerfile. Multistage tags: - latest - ${DRONE_TAG##v} when: event: - promote target: - production - name: promote-release-prod image: plugins/webhook settings: username: admin password: The admin urls: http://172.16.77.118:9300/v1/webhooks/native the debug: true content_type: application/json template: | {" name ":" 172.16.77.115:5000 / pregap ", "tag" : "${DRONE_TAG # # v}"} the when: the event: - promote target: - productionCopy the code

Add Keel approval:

conclusion

Canary deployment or green/Blue deployment is not difficult at all – it will improve the reliability of the production environment and reduce the area affected if any design errors occur. In the future, I will add RAM to the server, and possibly enable Prometheus monitoring and Istio, and try to perform analysis and experiment phases to implement Argo Rollouts.