Implementing Blue/Green Deployments with Azure Web Apps for Containers

Application uptime is critical for our cloud applications. Using Azure App Service slots, we can implement the Blue/Green deployment pattern to validate that new versions of our application will perform as expected in a production environment, without causing downtime to our existing version of our application. With App Service slots, we can deploy new versions of our container images to our Green slot, run tests against that slot to ensure that everything is working, and then direct incoming traffic to our updated container image. In this article, I'll explain what Blue/Green Deployments are and show you how can implement Blue/Green deployments for your App Services that host your containers. This includes: Creating our Azure resources with Bicep. Deploying our resources with GitHub Actions. Pushing our container image to Azure Container Registry. Pulling our container image into our App Service Blue Slot. Swapping from the Blue slot into our Green Slot. Throughout this article, I'll be referring to code that you can find in this GitHub . If you want to follow along, or use that repo as a base for experimenting with Blue/Green deployments with App Service, please feel free to fork it and have a play around with it! If you see something wrong or want to make an improvement to it, PRs are welcome! 😊 repo What are Blue/Green Deployments? As I mentioned, ensuring that our applications are highly available is critical for applications running in the cloud. There are a couple of strategies that we can implement to ensure HA for our apps, such as spinning up our application in a different region in case of a regional disaster affecting the datacenter where our app is hosted or using high availability configurations. With both of these options, there are time and cost implications that we would need to consider. We can ensure high availability when deploying our application. With Blue/Green deployments, we can deploy a new version of our application next to the existing one. Imagine you're working on an application and you build a container image that packages the new version of your app. With Blue/Green deployments, we can deploy the new image to the Blue slot alongside our Green slot. Production traffic is still being routed to the Green slot, but now that our new version has been deployed to the Blue slot, we can run tests against the Blue slot in a production environment to ensure that the new image works as expected. If everything works, we can swap the image from the blue slot to the green slot, redirecting our production traffic to our new image, which happens with no visible downtime for our users. Should anything not work as expected, we can abandon the deployment of our new container image without affecting our users, since traffic will be redirected to our green slot containing our exiting image. In Azure App Service, we can set up staging environments using deployment slots. By using Blue/Green deployments, we can warm up instances in a slot before we swap slots to production traffic, eliminating downtime for our application. Please note, that your App Service Plan must be either at the , or tier. Standard Premium, Isolated Preparing our infrastructure Let's start off by setting up our infrastructure pipeline. Here, I want to create my App Service that has both a blue and green slot, an Azure Container Registry to store my images, then I want to be able to deploy my Bicep template using GitHub Actions. Creating our Azure Resources First, let's create the Azure Container Registry that we need to store our container images. We can do this in Bicep like so: param registryName string param registryLocation string param registrySku string resource containerRegistry 'Microsoft.ContainerRegistry/registries@2021-09-01' = { name: registryName location: registryLocation sku: { name: registrySku } identity: { type: 'SystemAssigned' } } Here, we're giving our container registry a name, location, and SKU which we will pass through as parameters. The important thing to note here is that we're creating a . So rather than enabling admin access on this Container Registry, we'll be using a managed identity for our ACR which will allow us to assign permissions and roles for the ACR without having to supply registry credentials. System Assigned Managed Identity for our Container Registry There are a number of ways that we can authenticate with Azure Container Registry, so I'd encourage you to check out to see what options are best for your scenario. this guide Next up. we'll create our App Service Plan. To do this, we can write the following Bicep code: param appServicePlanName string param appServicePlanLocation string param appServicePlanSkuName string param appServicePlanCapacity int resource appServicePlan 'Microsoft.Web/serverfarms@2021-02-01' = { name: appServicePlanName location: appServicePlanLocation sku: { name: appServicePlanSkuName capacity: appServicePlanCapacity } kind: 'linux' properties: { reserved: true } } output appServicePlanId string = appServicePlan.id We're running our containers on Linux, so we'll need to provision a Linux App Service Plan. I've parameterized the App Plan SKU name, but as I mentioned before, deployment slots are only available at or above plan. Since we're provisioning a Linux plan, we'll need to set the property to true. Standard reserved To see the full Bicep reference template for App Service Plans, check out this . page With our App Plan template complete, we can start to create our Bicep template for our App Service with both Blue and Green slots. Here is our full Bicep file for our App Service. Don't worry! we will break this down: @description('Name of the app service plan') param appServiceName string @description('Location of the app service plan') param appServiceLocation string @description('Name of the slot that we want to create in our App Service') param appServiceSlotName string @description('The Server Farm Id for our App Plan') param serverFarmId string @description('Name of the Azure Container Registry that this App will pull images from') param acrName string @description('The docker image and tag') param dockerImageAndTag string = '/hellobluegreenwebapp:latest' // This is the ACR Pull Role Definition Id: https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#acrpull var acrPullRoleDefinitionId = subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '7f951dda-4ed3-4680-a7ca-43fe172d538d') var appSettings = [ { name: 'WEBSITES_ENABLE_APP_SERVICE_STORAGE' value: 'false' } { name: 'WEBSITES_PORT' value: '80' } { name: 'DOCKER_REGISTRY_SERVER_URL' value: 'https://${containerRegistry.properties.loginServer}' } ] resource containerRegistry 'Microsoft.ContainerRegistry/registries@2021-09-01' existing = { name: acrName } resource appService 'Microsoft.Web/sites@2021-02-01' = { name: appServiceName location: appServiceLocation kind: 'app,linux,container' properties: { serverFarmId: serverFarmId siteConfig: { appSettings: appSettings acrUseManagedIdentityCreds: true linuxFxVersion: 'DOCKER|${containerRegistry.properties.loginServer}/${dockerImageAndTag}' } } identity: { type: 'SystemAssigned' } resource blueSlot 'slots' = { name: appServiceSlotName location: appServiceLocation kind: 'app,linux,container' properties: { serverFarmId: serverFarmId siteConfig: { acrUseManagedIdentityCreds: true appSettings: appSettings } } identity: { type: 'SystemAssigned' } } } resource appServiceAcrPullRoleAssignment 'Microsoft.Authorization/roleAssignments@2020-08-01-preview' = { scope: containerRegistry name: guid(containerRegistry.id, appService.id, acrPullRoleDefinitionId) properties: { principalId: appService.identity.principalId roleDefinitionId: acrPullRoleDefinitionId principalType: 'ServicePrincipal' } } resource appServiceSlotAcrPullRoleAssignment 'Microsoft.Authorization/roleAssignments@2020-08-01-preview' = { scope: containerRegistry name: guid(containerRegistry.id, appService::blueSlot.id, acrPullRoleDefinitionId) properties: { principalId: appService::blueSlot.identity.principalId roleDefinitionId: acrPullRoleDefinitionId principalType: 'ServicePrincipal' } } Let's start with our parameters. We'll need to import both the App Service Plan and the Docker Registry into this Bicep file, so I've added some parameters that we can use in the template. This may be scope creep for this tutorial, but say we have Container Registries across our different environments (DEV, UAT, Prod) and different app service plans, we can provision new App Services that use our different resources across our different environments taking this approach. We then create a variable for our role definition. We do this by getting the unique identifier for a resource using the . AcrPull subscriptionResourceId function We create another variable for our App Settings. For our example, both our Blue and Green slots will need to have the same app settings. We could use different app settings for our slots if we needed/wanted to, but for simplicity, I've created a variable and applied them to both slots just so I don't have to repeat myself. Our Container Registry needs to be imported so I can reference it in our App Service. All we need to do here is to create a resource block for our Container Registry and use the keyword . We reference the name of our registry using a parameter. existing For our App Service, we give it a name and location. We also need to provide the following information: First, we set the property to . This tells the App Service that we want to host Linux Containers. kind app,linux,container In the properties section, we set the to the Id of our Server Farm. We're setting this as a parameter, so if we wanted to use this module for other App Services, we could deploy it to another App Service Plan. serverFarmId For our site config section, we set the to the App Settings we defined earlier, the property tells the App Service that we want to use the managed identity credentials to pull images from our container registry. We finally set the to . This sets the Linux App Framework and version. appSettings acrUseManagedIdentityCreds linuxFxVersion DOCKER|${containerRegistry.properties.loginServer}/${dockerImageAndTag} We finally create a System Managed Identity for this App Service and the Blue slot. We'll need this for our role assignments. We then create two role assignments that allow our App Service Blue and Green slot to pull images from our container registry. The uses the role definition we defined in our variable at the start and the property assigns this role to the App Service over our Azure Container Registry. roleDefinitionId AcrPull scope To learn more about how we can create role assignments using Bicep, check out this . article With our modules created, we can now write up our file like so: main.bicep param webAppName string = uniqueString(resourceGroup().id) param acrName string = toLower('acr${webAppName}') param acrSku string param appServicePlanName string = toLower('asp-${webAppName}') param appServiceName string = toLower('asp-${webAppName}') param appServicePlanSkuName string param appServicePlanInstanceCount int var appServiceSlotName = 'blue' param location string = resourceGroup().location module containerRegistry 'containerRegistry.bicep' = { name: 'containerRegistry' params: { registryLocation: location registryName: acrName registrySku: acrSku } } module appServicePlan 'appServicePlan.bicep' = { name: 'appServicePlan' params: { appServicePlanLocation: location appServicePlanName: appServicePlanName appServicePlanSkuName: appServicePlanSkuName appServicePlanCapacity: appServicePlanInstanceCount } } module appService 'appService.bicep' = { name: 'appService' params: { appServiceLocation: location appServiceName: appServiceName serverFarmId: appServicePlan.outputs.appServicePlanId appServiceSlotName: appServiceSlotName acrName: acrName } } We'll also need a parameters file. We can create a file like so: parameters.json { "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": { "acrSku":{ "value": "Basic" }, "appServicePlanSkuName": { "value": "S1" }, "appServicePlanInstanceCount": { "value": 1 } } } Deploying our resources with GitHub Actions Now that our Bicep code has been written, we can deploy it using GitHub Actions. Before we can do this, we'll need to set up a couple of things. First, let's set up a resource group that we'll deploy our resources to. We can do this by running the following AZ CLI command: az group create -n -l With our resource group created, we'll need to generate a Service Principal that will allow our GitHub Action workflow to deploy resources to Azure. We can do so by running the following: az ad sp create-for-rbac --name yourApp --role owner --scopes /subscriptions/{subscription-id}/resourceGroups/exampleRG --sdk-auth Use your resource group name and subscription Id in the command. The output of this command will generate a JSON object that you'll need to copy. It should look similar to this: { "clientId": " ", "clientSecret": " ", "subscriptionId": " ", "tenantId": " ", } We need to save this JSON output as a in our GitHub repo. You can do this by selecting then and clicking on to create the secret. We'll need to create the following secrets: Secret Settings Secrets New Secret Value RESOURCE_GROUP Name of the resource group that we're deploying resources to AZURE_CREDENTIALS The entire JSON output that was generated as part of the service principal creation step Now that we have our secrets, we can create the following workflow file that will deploy our resources: name: Deploy Azure Infrastructure on: push: paths: - 'deploy/*' workflow_dispatch: jobs: lint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Run Bicep Linter run: az bicep build --file ./deploy/main.bicep validate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: azure/login@v1 name: Sign in to Azure with: creds: ${{ secrets.AZURE_CREDENTIALS }} - uses: azure/arm-deploy@v1 name: Run preflight validation with: deploymentName: ${{ github.run_number }} resourceGroupName: ${{ secrets.AZURE_RG }} template: ./deploy/main.bicep parameters: ./deploy/parameters.json deploymentMode: Validate preview: runs-on: ubuntu-latest needs: [lint, validate] steps: - uses: actions/checkout@v2 - uses: azure/login@v1 name: Sign in to Azure with: creds: ${{ secrets.AZURE_CREDENTIALS }} - uses: Azure/cli@v1 name: Run what-if with: inlineScript: | az deployment group what-if --resource-group ${{ secrets.AZURE_RG }} --template-file ./deploy/main.bicep --parameters ./deploy/parameters.json deploy: runs-on: ubuntu-latest environment: Dev needs: preview steps: - uses: actions/checkout@v2 - uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} - name: Deploy Bicep File uses: azure/arm-deploy@v1 with: subscriptionId: ${{ secrets.AZURE_SUBSCRIPTION }} resourceGroupName: ${{ secrets.AZURE_RG }} template: ./deploy/main.bicep parameters: ./deploy/parameters.json failOnStdErr: false This file does the following: We first validate our file to ensure that it's a valid Bicep template. We then run a preview job on our Bicep template to see what will be deployed as part of our workflow. We then run a deploy stage that uses a manual approval step. This is done by putting the parameter in this stage. When we approve this deployment, the stage deploys our Bicep template using the parameters file to deploy our resources to Azure. environment If we head into Azure, we can see that our resources have been created: Deploying our container to App Service We have our Container Registry and App Service ready to go in Azure! We just need to allow our GitHub Action to push and push images to our Azure Container Registry. First, we need to get the resource Id of our container registry. We can do this by running the following command (Replace with the name of your Azure Container Registry): registryId=$(az acr show --name --query id --output tsv) Now that we have our resource Id, we can use the following AZ CLI command to assign the AcrPush role (Replace with the client ID of your service principal): az role assignment create --assignee --scope $registryId --role AcrPush Once our role has been created, we can set up the following secrets in GitHub Actions that we'll need to use in our GitHub Action workflow file: Secret Value REGISTRY_LOGIN_SERVER The login server name of your registry (all lowercase). Example: myregistry.azurecr.io REGISTRY_USERNAME The from the JSON output from the service principal creation clientId REGISTRY_PASSWORD The from the JSON output from the service principal creation clientSecret Pushing our container image to Azure Container Registry We can now create our workflow file. This file will do quite a bit so let's focus on pushing our Container Image to Azure Container Registry, to begin with. name: Build and Deploy Container Image to App Service on: workflow_dispatch: defaults: run: working-directory: ./src # Note: The use of :latest for the container image is not recommeded for production environments. jobs: build-container-image: runs-on: ubuntu-latest steps: - name: 'Checkout GitHub Action' uses: actions/checkout@main - name: 'Login via Azure CLI' uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} - name: 'Build and Push Image to ACR' uses: azure/docker-login@v1 with: login-server: ${{ secrets.REGISTRY_LOGIN_SERVER }} username: ${{ secrets.REGISTRY_USERNAME }} password: ${{ secrets.REGISTRY_PASSWORD }} - run: | docker build . -t ${{ secrets.REGISTRY_LOGIN_SERVER }}/hellobluegreenwebapp:latest docker push ${{ secrets.REGISTRY_LOGIN_SERVER }}/hellobluegreenwebapp:latest We log in to Azure using our Service Principal connection and then log into our Azure Container Registry. Once that's successful, we build and push our container image to our ACR. You can view the Dockerfile that I'm using . here One thing to note here is the image tag that we're using. This is a basic demo, so I'm just using . For your container images, make sure you follow . latest best practices Once this has been built and pushed to our Azure Container Registry, we should be able to see our container image by navigating to our ACR, and searching for the image under Repositories Deploying our App to the Blue slot Once our image has been pushed to Azure Container Registry, we can deploy it to our Blue slot. In the snippet below, we log into Azure, then retrieve our Application name using an inline script and set it to a output variable that we can use in a later step in this stage. We then deploy our image to our Blue slot using the output variable we set as the App name, with the image that we've pushed to our ACR, and explicitly tell the task to deploy the image to our slot: blue deploy-to-blue-slot: needs: build-container-image runs-on: ubuntu-latest steps: - name: 'Checkout GitHub Action' uses: actions/checkout@main - name: 'Login via Azure CLI' uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} - name: 'Get App Name' id: getwebappname run: | a=$(az webapp list -g ${{ secrets.AZURE_RG }} --query '[].{Name:name}' -o tsv) echo "::set-output name=appName::$a" - name: 'Deploy to Blue Slot' uses: azure/webapps-deploy@v2 with: app-name: ${{ steps.getwebappname.outputs.appName }} images: ${{ secrets.REGISTRY_LOGIN_SERVER }}/hellobluegreenwebapp:latest slot-name: 'blue' Verify that the blue slot works In this sample, we can verify whether or not our deployment to the blue slot was successful by simply navigating to the blue slot of our App Service. The URL for our blue slot will take the following format: https:// - .azurewebsites.net In this sample, we're just deploying to our blue slot and manually verifying whether or not our container image deployed successfully. In production scenarios, we'll need to include tasks, such as automation tests, to ensure that our deployed container image works as expected before we deploy to our production slot. In our GitHub actions, we should see the URL to our blue slot like so: We can use this URL to navigate to the blue slot and see that our image has been successfully deployed: If we navigate to our green slot, we see that nothing has been deployed yet! Let's swap the slots now. Swap to Green slot Once we have verified that our deployment to the blue slot has been successful, we can deploy our container image to the green slot. We can do this using the following job in our GitHub Actions workflow: swap-to-green-slot: runs-on: ubuntu-latest environment: Dev needs: deploy-to-blue-slot steps: - name: 'Checkout GitHub Action' uses: actions/checkout@main - name: 'Login via Azure CLI' uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} - name: 'Get App Name' id: getwebappname run: | a=$(az webapp list -g ${{ secrets.AZURE_RG }} --query '[].{Name:name}' -o tsv) echo "::set-output name=appName::$a" - name: 'Swap to green slot' uses: Azure/cli@v1 with: inlineScript: | az webapp deployment slot swap --slot 'blue' --resource-group ${{ secrets.AZURE_RG }} --name ${{ steps.getwebappname.outputs.appName }} In this job, we use environments to manually approve the deployment to our production slot provided that our deployment to the blue slot was successful. We can assign a user or users that need to approve the deployment before this job runs. In this sample, we just use this as a manual approval step. In production scenarios, it's a good idea to run automation tests to ensure that your new container image works as expected before deploying to your production slots. To learn more about how environments work in GitHub Actions, check out the following . documentation Finally, we initiate the swap to the production slot by using the AZ CLI. Here are just swapping from our blue slot into our green slot. To learn more about how we can work with slots using the AZ CLI, please review the following . documentation Without the green slot, we should get a URL. Since this is our production slot, our URL won't have a slot name within its URL. Navigate to the URL and you can see that we've successfully swapped to our green slot! Conclusion If you're deploying containers to Azure App Service, hopefully, this has helped you see that you can use Blue/Green deployments to achieve zero-downtime deployments for your container images. This was a basic example, so in your production scenarios, you'll want to run comprehensive automation tests against your blue slot before swapping to the green slot. If you have any questions, feel free to reach out to me on Twitter @willvelida Until next time, Happy coding! 🤓🖥️ Also Published Here