Application Update Lifecycle
With containers based applications, frequent releases by multiple development teams make changes throughout the codebase. With this increasing number of moving parts, there is a likelihood that something could go wrong. To minimize these risks, container based applications need complete automation including CI and CD.
On one end, you need integration with a CI tool like Jenkins or CircleCI to push the latest updates to the code. Manually integrating CI with every Docker container in an application would be a tedious and nonproductive activity.
On the other end, developers need to use deployment strategies such as Canary and Blue Green for a controlled delivery process. In the case of Blue/Green Deployment, Kubernetes requires multiple deployments for each container and manually switching between these deployments by upscaling or downscaling each container. In the case of Canary deployment, developers are required to manually review and analyze application statistics and manually change the weight for each stage based on those statistics.
The following is an example snippet for a Blue/Green Deployment YAML. Here Tomcat v7 is deployed as Blue and Tomcat v8 is deployed as Green.
Complete Manifest files:
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: tomcat-deployment-blue spec: replicas: 2 template: metadata: labels: app: tomcat role: blue spec: containers: - name: tomcat-container image: tomcat:7 ports: - containerPort: 8080 readinessProbe: httpGet: path: / port: 8080
kind: Service apiVersion: v1 metadata: name: tomcat-service labels: app: tomcat role: blue env: prod spec: type: LoadBalancer selector: app: tomcat role: blue ports: - port: 80 targetPort: 8080
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: tomcat-deployment-green spec: replicas: 2 template: metadata: labels: app: tomcat role: green spec: containers: - name: tomcat-container image: tomcat:8 ports: - containerPort: 8080 readinessProbe: httpGet: path: / port: 8080
In order to upgrade an existing container (for example v7 in blue deployment) to a newer version (say v8), first you need to put the blue deployment in inactive state, and then you have to assign green label to the newer version v8 ..then change the label in service to Green. This will shift all the traffic from Blue to Green. This process requires a lot of manual configuration changes from the developer at the time of rollout and rollback.
How CloudPlex addresses your pain
CloudPlex supports all major CI tools (e.g. Jenkins, CircleCI, Bitbucket etc. ). You just have to integrate webhook in your CI pipeline which is just a simple copy paste operation. Deploying Blue/Green, Canary, and Highlander version upgrades are super easy with Cloudplex. Developers can design multi-stage deployment pipelines and deployment strategy visually. All the configurations required are handled by the platform.
If the developer uses Blue/Green Deployment strategy, it requires very simple visual configuration. There is no intervention needed from the developer at rollout or rollback.
Dashboard to view all deployment pipelines
The following screenshot shows an Admin dashboard where the developer can view all the deployed pipelines in a single window.