Blue Green Deployment Azure Best Practices and Hands-On Example

In Azure, a blue-green deployment allows you to have two identical environments, one for production and one for testing.

The blue environment is typically the current production environment, while the green environment is the new, updated version.

By having two separate environments, you can test the updated version without affecting the current production environment.

This approach ensures minimal downtime and reduces the risk of errors or bugs affecting your users.

Azure provides a range of tools and services to support blue-green deployments, including Azure DevOps and Azure Kubernetes Service.

With Azure DevOps, you can automate the deployment process and easily switch between the two environments.

Azure Kubernetes Service (AKS) also supports blue-green deployments, making it easier to manage and scale your applications.

By following best practices for blue-green deployment in Azure, you can ensure a smooth and efficient deployment process.

Azure App Service is a powerful tool for hosting multiple versions of your web app, essentially creating parallel universes for your app. You can deploy changes to a staging slot first, mirroring your production environment, ensuring everything works perfectly before swapping it with the production slot.

To create a slot for your app service, you'll need to use a YAML file, specifically a second task that handles the deployment. This task should deploy to a staging slot first and then swap it with the production slot.

You can achieve this by initially creating a slot for your app service, which can be done manually or through a GitHub Action workflow file. To set up the necessary secrets in GitHub Actions, you'll need to get the resource Id of your container registry and create a role. This will allow your GitHub Action to push and pull images to your Azure Container Registry.

Azure App Service is a powerful tool for hosting and deploying your web applications. You can host multiple versions of your app in parallel universes, known as slots, which allows for seamless deployment and testing.

One of the key features of Azure App Service is the ability to create slots for your app, which can be used for staging and production environments. For instance, you can deploy changes to a staging slot first, and then swap it with the production slot with just a few clicks.

To create a slot for your app, you can use the Azure CLI or the Azure portal. You can also use YAML pipelines to automate the deployment process. In fact, the YAML pipeline can handle the deployment to a staging slot and then swap it with the production slot.

Azure App Service also supports container deployment, which allows you to deploy your containerized applications with ease. To deploy your container to App Service, you need to create a container registry in Azure and configure the GitHub Action to push images to the registry.

Here are the secrets you need to set up in GitHub Actions for container deployment:

Once you've set up the secrets, you can deploy your image to the Blue slot using the output variable you set as the App name, with the image that you've pushed to your ACR, and explicitly tell the task to deploy the image to your Blue slot.

Application Gateway supports rewriting HTTP headers of requests and responses, allowing you to add conditions to ensure headers are rewritten only when certain conditions are met.

This feature uses server variables to store useful information about the server, connection with the client, and current request on the connection, which can be used to evaluate rewrite conditions and rewrite headers.

To enrich requests coming through canary routing rules with an extra header, you need to select which routing rules you want to associate with the rewrite set.

In my case, I only want to enrich request headers for the canary routing rule, so I select that one.

Next, you configure your rewrite set by adding a new Redirect-To header with value green before Application Gateway forwards the requests to the backend.

There are no conditions needed in this case, and you only need one action called CanaryRewrite to add the new header.

The resulting Application Gateway configuration will be assigned to the canary routing rule.

Creating a deployment in Azure is a straightforward process. You can start by creating a deployment slot in Azure, which allows you to host multiple versions of your web app. Not all app service plans support deployment slots, so you may need to upgrade your plan to S1 or higher.

To create a deployment slot, click on "Deployment Slots" within your App Service, and then click on "Add slot". You can then add a new slot, such as a "STAGING" slot, and give it a name like "staging".

Alternatively, you can create a deployment slot using Bicep, which is a declarative language for defining infrastructure as code. To do this, you'll need to add a webAppSlot resource to your app.bicep file.

Once you've created your deployment slot, you can deploy your app to the slot using GitHub Actions. To do this, you'll need to set up a resource group and a service principal, and then create a secrets file that contains the necessary credentials.

Here's a summary of the steps involved in creating a deployment:

By following these steps, you can create a deployment in Azure that allows you to host multiple versions of your web app. This is a key part of blue-green deployment, which we'll discuss in more detail later.

Configuring Application Gateway is a crucial step in setting up a blue-green deployment in Azure. You'll need to configure multiple listeners, routing rules, and backend pools to achieve this.

To start, you'll need to add an extra listener, which we'll call the "canary" listener, to receive requests from your test host. This listener will be used to route traffic to your new infrastructure slot.

When configuring the routing rules, you'll need to bind the canary listener with the APIM backend pool, also named "canary". This will allow you to test your new infrastructure slot without affecting production traffic.

Here's a summary of the key components you'll need to configure:

With these components in place, you'll be able to test your new infrastructure slot without disrupting production traffic.

Configuring Application Gateway requires attention to several key areas.

You typically need to configure Application Gateway, starting with the basics.

Here is what you need to configure at Application Gateway:

Typically, you need to configure the backend pool, which includes the IP addresses of the servers behind the gateway.

You also need to configure the frontend IP configuration, which includes the public IP address of the gateway.

And, you need to configure the routing rules, which determine how traffic is directed to the backend pool.

This is where you specify the conditions under which traffic is routed to the backend pool, such as based on the URL or headers.

You also need to configure the authentication and authorization settings, which determine who can access the application.

This includes configuring the Active Directory settings, which allow users to access the application using their AD credentials.

Finally, you need to configure the SSL/TLS settings, which determine how the gateway handles secure connections.

Backend Pools are a crucial component of Application Gateway configuration. A backend pool routes requests to backend servers, which serve the request.

In my example, there is one backend called apim pointing to APIM instance. This is a common setup, but you can have multiple backends if needed.

A backend pool can be associated with a routing rule, which determines how to route traffic on the listener. For instance, the default routing rule links the default listener with the apim backend pool.

Here's a summary of backend pools in Application Gateway: