{"id":2126,"date":"2024-05-13T04:25:32","date_gmt":"2024-05-13T04:25:32","guid":{"rendered":"https:\/\/www.aviator.co\/blog\/?p=2126"},"modified":"2025-09-25T13:13:12","modified_gmt":"2025-09-25T13:13:12","slug":"how-to-manage-rollouts-and-rollbacks-using-argocd","status":"publish","type":"post","link":"https:\/\/www.aviator.co\/blog\/how-to-manage-rollouts-and-rollbacks-using-argocd\/","title":{"rendered":"How to manage rollouts and rollbacks using ArgoCD"},"content":{"rendered":"\n<figure class=\"wp-block-image size-full\"><img fetchpriority=\"high\" decoding=\"async\" width=\"1024\" height=\"576\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/argocd-banner.jpg\" alt=\"\" class=\"wp-image-4418\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/argocd-banner.jpg 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/argocd-banner-300x169.jpg 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/argocd-banner-768x432.jpg 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>Imagine you&#8217;re implementing a critical backend update through your typical continuous integration, continuous deployment (CI\/CD) pipeline and the new version of the application unexpectedly crashes. This would disrupt the entire user base. This inconvenience underscores the critical role of strategic deployment patterns. Utilizing methods like&nbsp;<a href=\"https:\/\/developers.redhat.com\/blog\/2022\/10\/07\/coming-terms-canary-deployment\">canary<\/a>&nbsp;or&nbsp;<a href=\"https:\/\/developers.redhat.com\/blog\/2022\/10\/07\/coming-terms-bluegreen-deployment\">blue-green<\/a>&nbsp;releases can greatly reduce downtime, ensuring reliable, smooth updates for uninterrupted online engagements. However, manually implementing these strategies is out of the question since, far from helping, they would add a layer of complexity regarding traffic routing and application management.<\/p>\n\n\n\n<p><a href=\"https:\/\/argoproj.github.io\/rollouts\/\">Argo Rollouts<\/a>&nbsp;is a progressive delivery tool that uses the&nbsp;<a href=\"https:\/\/kubernetes.io\/docs\/concepts\/architecture\/controller\/\">Kubernetes controller<\/a>&nbsp;and&nbsp;<a href=\"https:\/\/kubernetes.io\/docs\/tasks\/extend-kubernetes\/custom-resources\/custom-resource-definitions\/\">custom resource definition (CRD)<\/a>&nbsp;constructs to enhance the&nbsp;<a href=\"https:\/\/kubernetes.io\/docs\/concepts\/workloads\/controllers\/deployment\/\">Kubernetes built-in deployment capabilities<\/a>. This provides more control during the application deployment process and allows you to implement blue-green and canary deployments easily. Moreover, if necessary, you can use Argo Rollouts to roll back to a previous version, ensuring minimal downtime and improving the reliability of your application deployments.<\/p>\n\n\n\n<p>This tutorial explains canary and blue-green deployments, compares their differences, and shows how to implement both strategies using Argo Rollouts.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Before Getting Started<a href=\"https:\/\/github.com\/jain-av\/mq-demo\/new\/main#before-getting-started\"><\/a><\/h2>\n\n\n\n<p>While you can read this article without completing the tutorial steps, following along will give you firsthand experience of the capabilities of Argo Rollouts. Before starting, you need the following:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A functional Kubernetes cluster, whether local or remote. The tutorial uses&nbsp;<a href=\"https:\/\/minikube.sigs.k8s.io\/docs\/start\/\">minikube<\/a>&nbsp;for its simplicity.<\/li>\n\n\n\n<li>The&nbsp;<a href=\"https:\/\/kubernetes.io\/docs\/tasks\/tools\/\">kubectl command line tool<\/a>&nbsp;installed and properly configured to access the Kubernetes cluster.<\/li>\n\n\n\n<li>The&nbsp;<a href=\"https:\/\/kustomize.io\/\">Kustomize configuration management tool<\/a>&nbsp;installed on your local machine.<\/li>\n\n\n\n<li>The&nbsp;<a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/installation\/\">Argo Rollouts Kubernetes controller and kubectl plugin<\/a>&nbsp;installed on your cluster and local machine, respectively.<\/li>\n<\/ul>\n\n\n\n<p>Install the controller using these commands:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl create namespace argo-rollouts\nkubectl apply -n argo-rollouts -f https:\/\/github.com\/argoproj\/argo-rollouts\/releases\/latest\/download\/install.yaml<\/code><\/pre>\n\n\n\n<p>Install the plugin on macOS with this command:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>curl -LO https:\/\/github.com\/argoproj\/argo-rollouts\/releases\/latest\/download\/kubectl-argo-rollouts-darwin-amd64<\/code><\/pre>\n\n\n\n<p>Make sure that you replace&nbsp;<code>darwin<\/code>&nbsp;with&nbsp;<code>linux<\/code>&nbsp;if you have a Linux machine.<\/p>\n\n\n\n<p>Lastly, clone the tutorial repository to an appropriate location:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>git clone https:\/\/github.com\/argoproj\/rollouts-demo.git<\/code><\/pre>\n\n\n\n<p>With these requirements out of the way, it&#8217;s time to explore canary and blue-green deployment strategies.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><a href=\"https:\/\/www.aviator.co\/merge-queue\" target=\"_blank\" rel=\" noreferrer noopener\"><img decoding=\"async\" width=\"1940\" height=\"500\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-service-page-cta-photo-min-1.png\" alt=\"Mergequeue CTA\" class=\"wp-image-4920\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-service-page-cta-photo-min-1.png 1940w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-service-page-cta-photo-min-1-300x77.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-service-page-cta-photo-min-1-1024x264.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-service-page-cta-photo-min-1-768x198.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-service-page-cta-photo-min-1-1536x396.png 1536w\" sizes=\"(max-width: 1940px) 100vw, 1940px\" \/><\/a><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Canary Releases and Blue-Green Deployments Explained<a href=\"https:\/\/github.com\/jain-av\/mq-demo\/new\/main#canary-releases-and-blue-green-deployments-explained\"><\/a><\/h2>\n\n\n\n<p><a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/features\/canary\/\">Canary<\/a>&nbsp;and&nbsp;<a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/features\/bluegreen\/\">blue-green<\/a>&nbsp;deployments are two strategies used in Argo Rollouts to manage the progressive delivery of applications. While both methods aim to minimize downtime and enhance user experience, their approach differs.<\/p>\n\n\n\n<p>Canary deployments start by releasing new versions to a few users. If things go well, everyone else gets the update. This approach lets you test new features safely and pull back if needed without impacting all users.<\/p>\n\n\n\n<p>During canary deployments with Argo Rollouts, two key aspects are managed: splitting traffic between the current (stable) and new (canary) versions and keeping a mix of replicas of both versions active. There are three main phases in a standard canary deployment process:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Argo initially directs all user traffic to the current production version with all replicas running it. For instance, if you have five replicas, all five are serving the stable version.<\/li>\n\n\n\n<li>Argo starts the canary deployment based on your setup when you introduce a new version. If you choose to route 20 percent of traffic to the new version, then one out of five replicas will run this new version, and the&nbsp;<code>canaryService<\/code>&nbsp;will manage user traffic to it. You can pause the rollout at this stage to evaluate the new version&#8217;s performance.<\/li>\n\n\n\n<li>Argo gradually replaces old replicas with the new version in set increments, say from 20 percent to 100 percent, if the new version performs well and you opt to proceed. During this process, Argo ensures the total number of replicas remains constant, like keeping five replicas active.<\/li>\n<\/ol>\n\n\n\n<p><a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/features\/bluegreen\/\">Blue-green deployments<\/a>&nbsp;use two identical environments: one hosts the stable version (blue) and the other the new version (green). This method is perfect for updates with no downtime as the new version matches the live environment, letting you switch all users to it at once.<\/p>\n\n\n\n<p>Meanwhile, blue-green deployments with Argo Rollouts involves the following process:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Argo directs all traffic to the stable version with&nbsp;<code>activeService<\/code>. If you have three replicas, all three serve the production version.<\/li>\n\n\n\n<li>Argo, upon updating the app, sets up a new (preview) environment with&nbsp;<code>previewService<\/code>, deploying three replicas of the new version. You typically pause here to check if the new version aligns well with production.<\/li>\n\n\n\n<li>You promote the rollout after verifying everything works as expected, which then leads Argo to switch&nbsp;<code>activeService<\/code>&nbsp;to the new version and ends the use of the old version&#8217;s replicas.<\/li>\n<\/ol>\n\n\n\n<p>The following diagram shows you an overview of both strategies and how they carry out the update process:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" width=\"1024\" height=\"789\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-20-1024x789.png\" alt=\"canary vs blue-green deployment\" class=\"wp-image-2151\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-20-1024x789.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-20-300x231.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-20-768x592.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-20-1536x1184.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-20-2048x1579.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>After this high-level overview of how Argo Rollouts performs updates, it&#8217;s time to move on to how you can implement each strategy.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Implementing Canary Deployments with Argo Rollouts<a href=\"https:\/\/github.com\/jain-av\/mq-demo\/new\/main#implementing-canary-deployments-with-argo-rollouts\"><\/a><\/h2>\n\n\n\n<p>For simplicity, you&#8217;ll use the same example for this canary deployment; that is, an application with five replicas is updated in 20 percent increments with intermediate pauses for performance monitoring. During the initial stage, Argo routes 20 percent of users to the new version, which means that one out of five replicas will run the new version, while the remaining four replicas will continue with the stable version. At that point, the process stops, waiting for you to confirm that it&#8217;s time to start promoting the rest of the users to the new version.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Setting Up a Canary Release<a href=\"https:\/\/github.com\/jain-av\/mq-demo\/new\/main#setting-up-a-canary-release\"><\/a><\/h3>\n\n\n\n<p>To set up a canary deployment, you create&nbsp;<a href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/ingress\/\">Ingress controllers<\/a>&nbsp;to control the routing traffic and corresponding&nbsp;<a href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/service\/\">services<\/a>. You will find these files in&nbsp;<code>rollouts-demo\/examples\/base\/canary<\/code>. Additionally, you must create a file where you set up Argo Rollouts; this example uses the name&nbsp;<code>canary-rollout.yaml<\/code>.<\/p>\n\n\n\n<p>You can find the file in&nbsp;<code>rollouts-demo\/examples\/canary\/canary-rollout.yaml<\/code>.&nbsp;<code>canary-rollout.yaml<\/code>&nbsp;uses the&nbsp;<a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/architecture\/#rollout-resource\">Rollout resource<\/a>&nbsp;to set up the canary deployment:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>apiVersion: argoproj.io\/v1alpha1\nkind: Rollout\nmetadata:\n  name: canary-demo\nspec:\n  replicas: 5\n  revisionHistoryLimit: 1\n  selector:\n    matchLabels:\n      app: canary-demo\n  template:\n    metadata:\n      labels:\n        app: canary-demo\n    spec:\n      containers:\n      - name: canary-demo\n        image: argoproj\/rollouts-demo:blue\n        imagePullPolicy: Always\n        ports:\n        - name: http\n          containerPort: 8080\n          protocol: TCP\n        resources:\n          requests:\n            memory: 32Mi\n            cpu: 5m\n  strategy:\n    canary:\n      canaryService: canary-demo-preview\n      steps:\n      - setWeight: 20\n      - pause: {}\n      - setWeight: 40\n      - pause: {duration: 10}\n      - setWeight: 60\n      - pause: {duration: 10}\n      - setWeight: 80\n      - pause: {duration: 10}<\/code><\/pre>\n\n\n\n<p>Let&#8217;s break down the code:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><code>kind: Rollout<\/code><\/strong>&nbsp;identifies the resource as a Rollout.<\/li>\n\n\n\n<li><strong><code>name: canary-demo<\/code><\/strong>&nbsp;names the Rollout&nbsp;<code>canary-demo<\/code>.<\/li>\n\n\n\n<li><strong><code>revisionHistoryLimit: 1<\/code><\/strong>&nbsp;restricts the stored revisions for the Rollout to one.<\/li>\n\n\n\n<li><strong><code>image: argoproj\/rollouts-demo:blue<\/code><\/strong>&nbsp;sets the initial image for the&nbsp;<code>canary-demo<\/code>&nbsp;as&nbsp;<code>argoproj\/rollouts-demo:blue<\/code>.<\/li>\n\n\n\n<li><strong><code>strategy<\/code><\/strong>&nbsp;specifies the deployment strategy to use, such as&nbsp;<code>canary<\/code>&nbsp;or&nbsp;<code>blue-green<\/code>, determining how updates are introduced to your environment.<\/li>\n\n\n\n<li><strong><code>canary<\/code><\/strong>&nbsp;defines this rollout as a canary deployment, allowing incremental updates with a subset of users before full rollout.<\/li>\n\n\n\n<li><strong><code>steps<\/code><\/strong>&nbsp;outlines a sequence of actions (steps) to be executed during the rollout process. In this example, eight steps were defined, but you can adjust the number of steps to your requirements.<\/li>\n\n\n\n<li><strong><code>setWeight<\/code><\/strong>&nbsp;adjusts the percentage of traffic directed to the new version (canary) during an update, facilitating gradual exposure to users. In this example, the initial step redirects 20 percent of the traffic to the new version and then halts. After promotion, the process resumes in 20 percent increments until the update is completed.<\/li>\n\n\n\n<li><strong><code>pause: {duration: TIME}<\/code><\/strong>&nbsp;temporarily halts the rollout process for a specified duration, providing a window to validate stability before proceeding. Not specifying the duration means pausing indefinitely until manually resumed (promotion). In this example, the first pause is indefinite, while the duration of the rest is ten seconds each. You could set each pause to indefinite or any combination that works for you.<\/li>\n<\/ul>\n\n\n\n<p>This simple rollout works to explain the canary strategy in a tutorial; for a comprehensive list of all the fields available in the Rollout specification, you can check the&nbsp;<a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/features\/specification\/\">docs<\/a>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Rolling Out a New Version Using a Canary Release<a href=\"https:\/\/github.com\/jain-av\/mq-demo\/new\/main#rolling-out-a-new-version-using-a-canary-release\"><\/a><\/h3>\n\n\n\n<p>To implement the rollout, begin by navigating to the root directory of the demo repository:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cd \/rollouts-demo\/<\/code><\/pre>\n\n\n\n<p>Create a new namespace for the rollout, which is named&nbsp;<code>canary<\/code>&nbsp;in this example:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl create ns canary<\/code><\/pre>\n\n\n\n<p>Run&nbsp;<code>kustomize<\/code>&nbsp;to deploy the rollout in your Kubernetes cluster:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kustomize build examples\/canary | kubectl -n canary apply -f -<\/code><\/pre>\n\n\n\n<p>To verify that everything is working as expected, run the following command to list all rollouts in the&nbsp;<code>canary<\/code>&nbsp;namespace:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl argo rollouts list rollouts -n canary<\/code><\/pre>\n\n\n\n<p>The output should be similar to the following:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">NAME         STRATEGY   STATUS        STEP  SET-WEIGHT  READY  DESIRED  UP-TO-DATE  AVAILABLE\ncanary-demo  Canary     Healthy       8\/8   100         5\/5    5        5           5  <\/pre>\n\n\n\n<p>Now, you know the rollout is active, but you lack visibility into the ongoing processes. With Argo, you can monitor the progressive deployment using either the CLI or your browser. For a comprehensive view, the rest of the tutorial features split-screen screenshots, displaying the CLI output on the left and the&nbsp;<a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/dashboard\/\">Argo Rollouts Dashboard<\/a>&nbsp;on the right.<\/p>\n\n\n\n<p>If you want to achieve a similar result, you need to have at least two terminal windows open simultaneously, both at the&nbsp;<code>rollouts-demo<\/code>&nbsp;root directory.<\/p>\n\n\n\n<p>In the first one, run the command that executes Argo&#8217;s dashboard UI:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl argo rollouts dashboard<\/code><\/pre>\n\n\n\n<p>Leave the terminal open and, using your browser, go to this address:&nbsp;<code>http:\/\/localhost:3100\/rollouts<\/code><\/p>\n\n\n\n<p>Then from the second terminal, run the following command:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl argo rollouts get rollout canary-demo -n canary --watch<\/code><\/pre>\n\n\n\n<p>The command uses the Argo Rollouts&nbsp;<a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/generated\/kubectl-argo-rollouts\/kubectl-argo-rollouts_get\/\"><code>get<\/code><\/a>&nbsp;command with the&nbsp;<code>--watch<\/code>&nbsp;flag to provide a live view of the&nbsp;<code>canary-demo<\/code>&nbsp;rollout in the&nbsp;<code>canary<\/code>&nbsp;namespace.<\/p>\n\n\n\n<p>The following image shows both outputs:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"423\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-21-1024x423.png\" alt=\"incremental\" class=\"wp-image-2152\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-21-1024x423.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-21-300x124.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-21-768x317.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-21-1536x635.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-21-2048x846.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>You are now at the starting point of the diagram shown in the last section. There are five replicas running the&nbsp;<code>argoproj\/rollouts-demo:blue<\/code>&nbsp;image, which is currently the stable version.<\/p>\n\n\n\n<p>To start the canary deployment, open a third terminal and use the command&nbsp;<a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/generated\/kubectl-argo-rollouts\/kubectl-argo-rollouts_set_image\/\"><code>argo rollouts set image<\/code><\/a>. This command sets the image&nbsp;<code>argoproj\/rollouts-demo:yellow<\/code>&nbsp;as the new version you want to deploy:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl argo rollouts set image canary-demo -n canary \"*=argoproj\/rollouts-demo:yellow\"<\/code><\/pre>\n\n\n\n<p>After a few seconds, you should see the following:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"423\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-22-1024x423.png\" alt=\"update is paused\" class=\"wp-image-2153\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-22-1024x423.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-22-300x124.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-22-768x317.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-22-1536x635.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-22-2048x846.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>As specified in&nbsp;<code>canary-rollout.yaml<\/code>, 20 percent of users are using the new version (canary), and the rest are using the version that is still considered stable. The deployment is indefinitely halted as instructed.<\/p>\n\n\n\n<p>To continue, you can either use the&nbsp;<strong>Promote<\/strong>&nbsp;button from the UI or run the command&nbsp;<a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/generated\/kubectl-argo-rollouts\/kubectl-argo-rollouts_promote\/\"><code>promote<\/code><\/a>&nbsp;from the CLI:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl argo rollouts promote canary-demo -n canary<\/code><\/pre>\n\n\n\n<p>You will see the execution of the rest of the steps with their respective ten-second pauses. Once the promotion of the canary version is finished, you will see an output similar to this:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"423\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-8-1024x423.png\" alt=\"fully deployed\" class=\"wp-image-2140\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-8-1024x423.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-8-300x124.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-8-768x317.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-8-1536x635.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-8-2048x846.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Rolling Back a Canary Release<a href=\"https:\/\/github.com\/jain-av\/mq-demo\/new\/main#rolling-back-a-canary-release\"><\/a><\/h3>\n\n\n\n<p>In this first run, everything went well. But what would happen if it didn&#8217;t?<\/p>\n\n\n\n<p>One of the advantages of canary deployments is that you can roll back the process if the new version is not yet ready for production. To simulate such a scenario, run the following command:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl argo rollouts set image canary-demo -n canary \"*=argoproj\/rollouts-demo:red\"<\/code><\/pre>\n\n\n\n<p>It is the same command that you used for the first update; the difference is that it now points to the&nbsp;<code>rollouts-demo:red<\/code>&nbsp;image, which you can consider as another app version.<\/p>\n\n\n\n<p>The output should now be like this:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"423\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-16-1024x423.png\" alt=\"process paused\" class=\"wp-image-2146\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-16-1024x423.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-16-300x124.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-16-768x317.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-16-1536x635.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-16-2048x846.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>The canary release is paused; however, instead of promoting the changes, roll back to the latest stable version. To do this, click the&nbsp;<strong>Abort<\/strong>&nbsp;button in the UI or use the command&nbsp;<a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/generated\/kubectl-argo-rollouts\/kubectl-argo-rollouts_abort\/\"><code>abort<\/code><\/a>, which reverts all steps:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl argo rollouts abort canary-demo -n canary <\/code><\/pre>\n\n\n\n<p>Here&#8217;s what you will see once the rollback is completed:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"423\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-17-1024x423.png\" alt=\"rollback to previous image\" class=\"wp-image-2148\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-17-1024x423.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-17-300x124.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-17-768x317.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-17-1536x635.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-17-2048x846.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>Note that although all replicas are healthy and are running the previous version, the status is&nbsp;<a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/getting-started\/#4-aborting-a-rollout\">degraded<\/a>. This is because the update process was unsuccessful, and Argo is waiting for your next action: either insist on another update or set the current version as stable. Do the latter with this command:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl argo rollouts set image canary-demo -n canary \"*=argoproj\/rollouts-demo:yellow\"<\/code><\/pre>\n\n\n\n<p>As expected, everything now looks good, and the system is ready for the next update:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"423\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-18-1024x423.png\" alt=\"healthy again\" class=\"wp-image-2147\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-18-1024x423.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-18-300x124.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-18-768x317.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-18-1536x635.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-18-2048x846.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Implementing Blue-Green Deployments with Argo Rollouts<a href=\"https:\/\/github.com\/jain-av\/mq-demo\/new\/main#implementing-blue-green-deployments-with-argo-rollouts\"><\/a><\/h2>\n\n\n\n<p>Similar to the approach used for the canary deployment, you&#8217;ll use the scenario from the diagram, starting with three replicas of the application running the stable version. As before, the progressive deployment unfolds in three stages: setting up the deployment, preparing the preview environment, and executing the update.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Setting Up a Blue-Green Deployment<a href=\"https:\/\/github.com\/jain-av\/mq-demo\/new\/main#setting-up-a-blue-green-deployment\"><\/a><\/h3>\n\n\n\n<p>This time, you will find all the required files in the&nbsp;<code>rollouts-demo\/examples\/blue-green<\/code>&nbsp;location:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><code>bluegreen-ingress.yaml<\/code><\/strong>&nbsp;defines an Ingress resource named&nbsp;<code>bluegreen-demo<\/code>&nbsp;with annotations for Nginx settings.<\/li>\n\n\n\n<li><strong><code>bluegreen-preview-ingress.yaml<\/code><\/strong>&nbsp;defines an Ingress resource named&nbsp;<code>bluegreen-demo-preview<\/code>.<\/li>\n\n\n\n<li><strong><code>bluegreen-preview-service.yaml<\/code><\/strong>&nbsp;creates the corresponding&nbsp;<code>bluegreen-demo-preview<\/code>&nbsp;service.<\/li>\n\n\n\n<li><strong><code>bluegreen-service.yaml<\/code><\/strong>&nbsp;creates the corresponding&nbsp;<code>bluegreen-demo<\/code>&nbsp;service.<\/li>\n\n\n\n<li><strong><code>bluegreen-rollout.yaml<\/code><\/strong>&nbsp;defines the blue-green rollout.<\/li>\n<\/ul>\n\n\n\n<p>As before, let&#8217;s focus on the file that matters,&nbsp;<code>bluegreen-rollout.yaml<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>apiVersion: argoproj.io\/v1alpha1\nkind: Rollout\nmetadata:\n  name: bluegreen-demo\n  labels:\n    app: bluegreen-demo\nspec:\n  replicas: 3\n  revisionHistoryLimit: 1\n  selector:\n    matchLabels:\n      app: bluegreen-demo\n  template:\n    metadata:\n      labels:\n        app: bluegreen-demo\n    spec:\n      containers:\n      - name: bluegreen-demo\n        image: argoproj\/rollouts-demo:blue\n        imagePullPolicy: Always\n        ports:\n        - name: http\n          containerPort: 8080\n          protocol: TCP\n        resources:\n          requests:\n            memory: 32Mi\n            cpu: 5m\n  strategy:\n    blueGreen:\n      autoPromotionEnabled: false\n      activeService: bluegreen-demo\n      previewService: bluegreen-demo-preview<\/code><\/pre>\n\n\n\n<p>The structure of the rollout is very similar to that of the canary deployment, but instead of steps, there are three fields that define the process:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><code>autoPromotionEnabled: false<\/code><\/strong>&nbsp;disables automatic promotion of the new&nbsp;<code>ReplicaSet<\/code>&nbsp;to the active service. In this example, the process is indefinitely paused, just as it was done with the canary deployment. However, you can use&nbsp;<a href=\"https:\/\/argoproj.github.io\/argo-rollouts\/features\/bluegreen\/#autopromotionenabled\">a combination of&nbsp;<code>autoPromotionEnabled: true<\/code>&nbsp;and&nbsp;<code>autoPromotionSeconds<\/code><\/a>&nbsp;to automatically promote the rollout after a stipulated time.<\/li>\n\n\n\n<li><strong><code>activeService<\/code><\/strong>&nbsp;specifies the active service for the blue-green deployment.<\/li>\n\n\n\n<li><strong><code>previewService<\/code><\/strong>&nbsp;sets the preview service for the blue-green deployment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Rolling Out a New Version Using a Blue-Green Deployment<a href=\"https:\/\/github.com\/jain-av\/mq-demo\/new\/main#rolling-out-a-new-version-using-a-blue-green-deployment\"><\/a><\/h3>\n\n\n\n<p>Implementing the blue-green strategy involves similar steps to implementing canary releases.<\/p>\n\n\n\n<p>Still in the&nbsp;<code>rollouts-demo<\/code>&nbsp;directory, create a new namespace for the rollout. Here, it&#8217;s called&nbsp;<code>blue-green<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl create ns blue-green<\/code><\/pre>\n\n\n\n<p>Run&nbsp;<code>kustomize<\/code>&nbsp;to deploy the rollout in your Kubernetes cluster:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kustomize build examples\/blue-green | kubectl -n blue-green apply -f -<\/code><\/pre>\n\n\n\n<p>Check the rollout:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl argo rollouts list rollouts -n blue-green<\/code><\/pre>\n\n\n\n<p>The output is similar to this:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>NAME            STRATEGY   STATUS        STEP  SET-WEIGHT  READY  DESIRED  UP-TO-DATE  AVAILABLE\nbluegreen-demo  BlueGreen  Healthy        -     -           3\/3    3        3           3<\/code><\/pre>\n\n\n\n<p>To monitor the process, run the command:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl argo rollouts get rollout bluegreen-demo -n blue-green --watch<\/code><\/pre>\n\n\n\n<p>Here&#8217;s what you see if you monitor the rollout:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"423\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-13-1024x423.png\" alt=\"stable versions\" class=\"wp-image-2143\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-13-1024x423.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-13-300x124.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-13-768x317.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-13-1536x635.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-13-2048x846.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>You are at the starting point, and all users use the&nbsp;<code>rollouts-demo:blue<\/code>&nbsp;image.<\/p>\n\n\n\n<p>Begin an update using this command:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl argo rollouts set image bluegreen-demo -n blue-green \"*=argoproj\/rollouts-demo:yellow\"<\/code><\/pre>\n\n\n\n<p>Here&#8217;s the output:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"423\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-15-1024x423.png\" alt=\"6 replicas\" class=\"wp-image-2145\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-15-1024x423.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-15-300x124.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-15-768x317.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-15-1536x635.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-15-2048x846.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>The process is paused; take a moment to review what has happened. When you started the update, Argo created the preview environment. There are now six replicas, but only three are serving users with the current stable version. The other three replicas are waiting for your next action.<\/p>\n\n\n\n<p>Promote the new version (preview) to stable using:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code><code>kubectl argo rollouts promote bluegreen-demo -n blue-green<\/code><\/code><\/pre>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"423\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-14-1024x423.png\" alt=\"3 of 3 replicas\" class=\"wp-image-2144\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-14-1024x423.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-14-300x124.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-14-768x317.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-14-1536x635.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-14-2048x846.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>As you can see, the update proceeded without any problems.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Rolling Back a Blue-Green Deployment<a href=\"https:\/\/github.com\/jain-av\/mq-demo\/new\/main#rolling-back-a-blue-green-deployment\"><\/a><\/h3>\n\n\n\n<p>If you need to roll back to the previous version, you just have to start the process again. To do this, simply run the following:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl argo rollouts set image bluegreen-demo -n blue-green \"*=argoproj\/rollouts-demo:blue\"<\/code><\/pre>\n\n\n\n<p>Now, you have to promote the image, and you will return to the previous version:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"423\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-19-1024x423.png\" alt=\"process starts over\" class=\"wp-image-2150\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-19-1024x423.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-19-300x124.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-19-768x317.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-19-1536x635.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/image-19-2048x846.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>Overall, once you define your rollout and know the main commands, managing any strategy in Argo Rollouts is simple.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Canary vs. Blue-Green Strategies<a href=\"https:\/\/github.com\/jain-av\/mq-demo\/new\/main#canary-vs-blue-green-strategies\"><\/a><\/h2>\n\n\n\n<p>In this tutorial, you learned how to implement both canary and blue-green strategies, so deciding on the optimal approach requires you to find a balance between your specific requirements and constraints and what each strategy has to offer you.<\/p>\n\n\n\n<p>The choice between canary and blue-green implementations in Argo Rollouts depends on several factors, including app traits, available infrastructure, budget, downtime tolerance, and user experience goals. The key takeaway is that no strategy is flawless. Canary deployments mitigate risks by rolling out changes gradually but often require comprehensive monitoring. Blue-green deployments offer instant rollback and minimal downtime but are twice as resource-intensive, impacting costs.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">FAQs<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What is the difference between Argo CD and Argo rollout?<\/h3>\n\n\n\n<p>Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes that manages application deployment using Git repositories as the source of truth. Argo Rollouts, on the other hand, is a Kubernetes controller for managing advanced deployment strategies such as blue-green, canary, and progressive delivery. While Argo CD focuses on syncing app states from Git to the cluster, Argo Rollouts enhances how updates are delivered to ensure minimal disruption.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is rolling updates and rollbacks in Kubernetes?<\/h3>\n\n\n\n<p>Rolling updates and rollbacks in Kubernetes refer to the process of updating applications with zero downtime and reverting to a previous version if necessary. Rolling updates replace pods gradually to ensure availability, while rollbacks allow reverting to a previous stable state if something goes wrong during the update.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is a major limitation of Argo rollouts?<\/h3>\n\n\n\n<p>A major limitation of Argo Rollouts is its limited support with Helm-based applications and lack of deep integration with custom resource definitions (CRDs), which can make it complex to adopt in environments heavily reliant on Helm or other templating tools.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is a rollout in Kubernetes?<\/h3>\n\n\n\n<p>A rollout in Kubernetes is the process of deploying new versions of an application in a controlled and gradual manner to avoid downtime and ensure stability. It involves updating pods managed by a Deployment or similar controller, monitoring their health, and either completing the update or rolling back in case of failure.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Learn how to manage canary, blue-green deployments and rollbacks using Argo Rollouts. These methods can greatly reduce downtime during deployments.<\/p>\n","protected":false},"author":33,"featured_media":4418,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[302],"tags":[97],"class_list":["post-2126","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tooling-integrations"],"blocksy_meta":[],"acf":[],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/05\/argocd-banner.jpg","post_mailing_queue_ids":[],"_links":{"self":[{"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/posts\/2126","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/users\/33"}],"replies":[{"embeddable":true,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/comments?post=2126"}],"version-history":[{"count":13,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/posts\/2126\/revisions"}],"predecessor-version":[{"id":4932,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/posts\/2126\/revisions\/4932"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/media\/4418"}],"wp:attachment":[{"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/media?parent=2126"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/categories?post=2126"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/tags?post=2126"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}