Search the Community

Amazon OpenSearch Service is now extending the ability to update the number of data nodes without requiring a blue/green deployment for clusters without dedicated cluster manager (master) nodes. This change will allow you to make node count changes faster. Clusters with dedicated cluster manager nodes already supported updating the data node count without a blue/green deployment. View the full article

Customers often ask for help with implementing Blue/Green deployments to Amazon Elastic Container Service (Amazon ECS) using AWS CodeDeploy. Their use cases usually involve cross-Region and cross-account deployment scenarios. These requirements are challenging enough on their own, but in addition to those, there are specific design decisions that need to be considered when using CodeDeploy. These include how to configure CodeDeploy, when and how to create CodeDeploy resources (such as Application and Deployment Group), and how to write code that can be used to deploy to any combination of account and Region. Today, I will discuss those design decisions in detail and how to use CDK Pipelines to implement a self-mutating pipeline that deploys services to Amazon ECS in cross-account and cross-Region scenarios. At the end of this blog post, I also introduce a demo application, available in Java, that follows best practices for developing and deploying cloud infrastructure using AWS Cloud Development Kit (AWS CDK)... View the full article

Amazon OpenSearch Service now provides improved visibility into validation failures during domain updates. You can monitor the progress of a domain update, which could involve a blue/green deployment, from the OpenSearch Service console, or through the configuration APIs. OpenSearch Service will publish any validation failure events to Amazon EventBridge. You can also view these validation events in the Notifications tab of the OpenSearch Service console. View the full article

In a traditional approach to application deployment, you typically fix a failed deployment by redeploying an older, stable version of the application. Redeployment in traditional data centers is typically done on the same set of resources due to the cost and effort of provisioning additional resources. Applying the principles of agility, scalability, and automation capabilities of AWS can shift the paradigm of application deployment. This enables a better deployment technique called blue/green deployment... View the full article

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. Component Version Red Hat OpenShift Container Platform 4.5.7 Red Hat Advanced Cluster Management 2.0 Fix Pack 2.0.2 Git Repository We are using the same Git repository from the previous post. Branch Description config Stores the base files for our APPs that apply to every environment prod Stores the overlay files for our APPs that apply to production environments stage Stores the overlay files for our APPs that apply to staging environments 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. 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/ 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 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 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 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 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 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 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 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 Go to our cloned Git repository. cd /path/to/acm-app-lifecycle-blog/forked/repository/ 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 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 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 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 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 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 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. View the full article