Applications Here, Applications There! - Part 2 - Blue/Green Deployments

What does it mean to manage your apps with Red Hat Advanced Cluster Management?

In the previous blog posts of this series, we introduced the basic concepts for Application Lifecycle on Red Hat Advanced Cluster Management and deployed an application to multiple clusters.

If you haven't read the previous blog post yet, go ahead and read it since this post is a continuation. You will need the context from the previous post: Part 1.

We are using the same infrastructure we used in the previous post. See the following diagram:

NOTE: Pay special attention to the different labels, as they will be used during the blog posts examples.

Git Repository

We are using the same Git repository from the previous post.

Blue / Green Deployments on Red Hat Advanced Cluster Management

In the previous post we deployed our application to multiple environments, being those Development and Production. At this point, we have our Application running v0.0.3 on Development and v0.0.2 on Production.

The development team has just released the version v0.0.4 and we want to perform a blue green deployment to Development and Production using Advanced Cluster Management and its GitOps capabilities.

If you remember, we already have the required Channel, PlacementRules, Subscriptions and Applications created in Advanced Cluster Management, which means that we only need to work with Git in order to deploy this new application version to both clusters.

Upgrading the application on the development environment

As stated before, we already have all the required resources in place, we only need to update our application definitions in Git in order to get the new application version to the different environments.

NOTE: In this blog post, as we're just demonstrating the GitOps capabilities, we will push our changes directly to the different branches, this is not a good practice, for real world use cases, there should be a well-defined workflow for bringing new changes to the different environments. You can read more about it here.

1. Go to our cloned Git repository.

   NOTE: If you are following the blog post in your environment, you should already have a fork from this repository cloned in your system

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

2. We want to upgrade the application version on Development in order to validate the release is working properly before pushing the change to Production environment, so we will be working on stage branch.

   git checkout stage

3. Next, the overlay for the application deployment must be updated so the deployment uses the new image version (v0.0.4).

   Development was using v0.0.3 release

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

4. Before committing the change, we are going to review the current state of our 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, v0.0.3 is the current version running in our Development environment

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

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

   NOTE: As a reminder, this is not a good practice, real world use cases should follow a well-defined workflow.

   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. We already have the required Subscription in place, which means that after Advanced Cluster Management detects the new commit in our repository and branch, the product will go ahead and make the required changes to move the current state to the desired state defined in Git.

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

   You can see how the change has been detected and a new version of the pod is being deployed with the new version.

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

7. We can now query our application and see that we deployed the v0.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. We also keep the production release untouched.

   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. Validation tests should occur now, and once validation tests are passed, we will go ahead and deploy the new app version to production.

Upgrading the application on the production environment

1. Go to our cloned Git repository.

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

2. We already upgraded and validated the new application version on Development. This time we are going to make the required changes to get this new version to Production environment, so we will be working on prod branch.

   git checkout prod

3. Next, the overlay for the application deployment must be updated so the deployment uses the new image version (v0.0.4).

   Production was using v0.0.2 release

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

4. Before committing the change, we are going to review the current state of our 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, v0.0.3 is the current version running in our Development environment

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

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

   NOTE: As a reminder, this is not a good practice, real world use cases should follow a well-defined workflow

   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. We already have the required Subscription in place, that means that after Advanced Cluster Management detects the new commit in our repository and branch, the product will go ahead and make the required changes to move the current state to the desired state defined in Git.

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

   You can see how the change has been detected and a new version of the pod is being deployed with the new version.

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

7. We can now query our application and see that we deployed the v0.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. At this point, we have upgraded the reverse-words application version to v0.0.4 in Development and Production environments.

What's next

In the next blog post of this series, we will be demonstrating how Application Migrations can be performed using Advanced Cluster Management and GitOps.