Red Hat Advanced Cluster Management and Application Management, Part 2. Blue / Green Deployment, Migration ...

Hello everyone on this blog! In the previous post, we covered the basic concepts of the application lifecycle in Red Hat Advanced Cluster Management (ACM) and showed how to apply them by deploying an application across two clusters. Today we'll show you how to use ACM for blue-green deployments, cross-cluster application migration, and disaster recovery.







Recall that we are using the model configuration shown in the diagram below, and please pay attention to the labels available there, since we will actively use them in our examples.



Software components Versions
Red Hat OpenShift Container Platform 4.5.7
Red Hat Advanced Cluster Management 2.0 Fix Pack 2.0.2


Git repository



We'll also be using the Git repository from the previous article:



Branch Description
config Stores base files for applications that are used in all environments.
Prod Stores overlay files for applications used in production environments.
stage Stores overlay files for applications that are used in test environments


Blue / Green Deployment with Red Hat ACM



In the previous article, we deployed our reversewords application in two environments, development and production. Let's say, in Development, we have version 0.0.3, and in Production - 0.0.2.



Now let's say that the developers have released version 0.0.4 and we want to do a blue-green deployment to the Development and Production clusters using the GitOps capabilities of ACM.



In the previous article, we created the necessary Channel, PlacementRules, Subscriptions, and Applications resources in ACM, so that when we deploy the new version, only Git will work in both clusters.



Updating the application in the development environment



Since all the required resources have already been created, we only need to change the application descriptions in Git in order to update the versions in the corresponding environments.



NOTE. Since here we are only demonstrating the GitOps capabilities of ACM, we will push changes directly to the branches of the repository, which is not good. In real life, you should have a well-written process for making changes to different environments, you can read more about this here .



1. Go to our cloned Git repository:



NOTE: If you reproduced the examples from the previous article, then you already have a cloned branch of this repository .



cd /path/to/acm-app-lifecycle-blog/forked/repository/


2. First, we want to update the version of the application in the Development environment so that we can test it before pushing changes to the Production environment. Therefore, we will be working with the stage branch.



git checkout stage


3. Now you need to update the overlay for the application deployment so that this deployment uses the new version image (0.0.4).



So far, release 0.0.3 is running in the Development cluster.



sed -i "s/v0.0.3/v0.0.4/g" apps/reversewords/overlays/deployment.yaml


4. Before committing changes, check the current state of the application in the development cluster.



curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080


As you can see, version 0.0.3 is currently running in the Development environment:



Reverse Words Release: Stage Release v0.0.3. App version: v0.0.3


5. Commit the file and push it to the stage branch.



NOTE. Once again, in real life you shouldn't. You must have a well-defined process for this.



git add apps/reversewords/overlays/deployment.yaml
git commit -m "Pushed development reverse-words app version to v0.0.4"
git push origin stage


6. Since we already have a Subscription, upon detecting a new commit to our repository and branch, ACM will perform actions to change the state from the current to the desired one, as written in Git.



oc --context dev -n reverse-words-stage get pods


As you can see, changes have been detected and the new version of the pod is deployed with the new version of the application.



NAME                             READY   STATUS              RESTARTS   AGE
reverse-words-5ff744d4bd-kkfvn   0/1     ContainerCreating   0          3s
reverse-words-68b9b894dd-jfgpf   1/1     Running             0          109m


7. Now let's run the request to the application and make sure that we have deployed the 0.0.4 release.



curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080

Reverse Words Release: Stage Release v0.0.4. App version: v0.0.4


8. The production release remains intact.



curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080

Reverse Words Release: Production release v0.0.2. App version: v0.0.2


9. Now you can run the validation tests and, if everything is fine, roll out the new version of the application into production.



Updating the application in the production environment



1. Go to the cloned Git repository.



cd /path/to/acm-app-lifecycle-blog/forked/repository/


2. We believe that we have successfully tested the new version of the application in the Development cluster and it is time to make the appropriate changes to deploy it to the Production cluster, so now we will work with the prod branch.



git checkout prod


3. You need to update the overlay for the application deployment so that this deployment uses the new version image (0.0.4).



So far, release 0.0.2 is running in the Production cluster



sed -i "s/v0.0.2/v0.0.4/g" apps/reversewords/overlays/deployment.yaml


4. Before committing changes, check the current state of the application in the production cluster.



curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080


As you can see, version 0.0.2 is currently running in the Production environment:



Reverse Words Release: Stage Release v0.0.2. App version: v0.0.2


5. Commit the file and push it to the prod branch.



NOTE. Once again, in real life you shouldn't. You must have a well-defined process for this.



git add apps/reversewords/overlays/deployment.yaml
git commit -m "Pushed production reverse-words app version to v0.0.4"
git push origin prod


6. Since we already have a Subscription, upon detecting a new commit to our repository and branch, ACM will perform actions to change the state from the current to the desired one, as written in Git.



oc --context pro -n reverse-words-prod get pods


As you can see, changes have been detected and the new version of the pod is deployed with the new version of the application.



NAME                             READY   STATUS              RESTARTS   AGE
reverse-words-68795d69ff-6t4c7   0/1     ContainerCreating   0          5s
reverse-words-7dd94446c-vkzr8    1/1     Running             0          115m


7. Now let's run the request to the application and make sure that we have deployed the 0.0.4 release.



curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080

Reverse Words Release: Production Release v0.0.4. App version: v0.0.4


8. That's it, we have updated our application to version 0.0.4 in both environments: Development and Production.



Conclusion



In the first part of this series, we covered the aspects of ACM that fall under the GitOps category. Today we learned how to use ACM for blue-green deployments, application migration between clusters, and disaster recovery. In the next post, we'll show you how to seamlessly migrate your reversewords application between our clusters using ACM.



All Articles