Blue-Green Deployment is a software release strategy that aims to minimize downtime and reduce the risk associated with deploying new versions of an application. In a blue-green deployment, two identical environments, referred to as "blue" and "green," are set up. One environment (blue) is running the current application version and one environment (green) is running the new application version.
Once the green environment is tested, the live traffic is directed to it, and the blue environment is used to deploy a new application version during next deployment cycle.
Revision | Description |
---|---|
Blue revision | The revision labeled as blue is the currently running and stable version of the application. This revision is the one that users interact with, and it's the target of production traffic. |
Green revision | The revision labeled as green is a copy of the blue revision except it uses a newer version of the app code and possibly new set of environment variables. It doesn't receive any production traffic initially but is accessible via a labeled fully qualified domain name (FQDN). |
After you test and verify the new revision, you can then point production traffic to the new revision. If you encounter issues, you can easily roll back to the previous version.
Actions | Description |
---|---|
Testing and verification | The green revision is thoroughly tested and verified to ensure that the new version of the application functions as expected. This testing might involve various tasks, including functional tests, performance tests, and compatibility checks. |
Traffic switch | Once the green revision is tested and verified, you can switch the traffic from the blue revision to the green revision. |
Rollback | If you encounter issues with the green revision, you can easily roll back to the blue revision. |
Role Change | The roles of the blue and green revisions change after a successful deployment to the green revision. During the next release cycle, the green revision represents the stable production environment while the new version of the application code is deployed and tested in the blue revision. |
The code snippets demonstrate the process of setting up a Blue-Green deployment using Azure ContainerApps and GitHub Actions. Make sure to follow the instructions carefully and set the required secrets and environment variables in your GitHub repository. Once everything is set up, you can make changes to the sample app, create a pull request, and merge it to the main branch to trigger the deployment process.
The equivalent replica of this repo in AzureDevops can be found here
Fork the repository to your GitHub account.
Set your own GitHub handle as the owner:
Now you will have the repository locally on your machine.
Open the local folder on your machine in Visual Studio Code.
Check you can access the Azure subscription via the portal CloudTechLearningArea Sandbox
Go to Access control (IAM) and check on the "Check Access" tab you have the following roles assigned:
- Reader - SC LZ CloudTechLearningArea Sandbox Reader (needed in order to view the portal)
- Writer - SC LZ CloudTechLearningArea Sandbox LandingZone Writer (needed to create the container apps resource - needs to be activated first)
On the same page/tab activate the writer role by clicking "Activate" (in the "Action" column - Check Access tab) on the "SC LZ CloudTechLearningArea Sandbox LandingZone Writer" row. Next fill in the reason text box (required) e.g. "Container Apps Session" and then activate - the activation should take a few minutes
Before we can do anything, first you'll need to login to the subscription via az cli.
az login --tenant aa81b43f-3969-4fd4-80c9-84c411508d82
A list of subscriptions will be displayed, look for the following: CloudTechLearningArea Sandbox 545d127a-0109-4129-b384-693504b5753f aa81b43f-3969-4fd4-80c9-84c411508d82
and type the number of the subscription for the above.
Once in you can use the below command to make sure you're in the correct subscription
az account show --query name
It should return CloudTechLearningArea Sandbox
, which means you're in the correct subscription
Create a resource group for the environment. The following will create a new resource group in the swedencentral
region.
az group create --name <name-of-resource-group> --location swedencentral
Then use the following to create a new Azure ContainerApps environment as well as a new Azure Container Registry. It will also deploy an initial version of the sample app to the environment.
az deployment group create --resource-group <name-of-resource-group> --template-file ".\infrastructure\bicep\deploy-infra.bicep"
The values from the az deployment group create
command can be retrieved from the Azure portal or CLI and added.
To set environment variables in GitHub, go to your repository, click on Settings
, then Secrets and variables
, and finally Actions
. Select Variables
and click on New repository variable
.
Add the following environment variables to your GitHub repository:
AZURE_ENVIRONMENT_NAME
- the short name of the existing Azure Container Apps environment where the sample app will be deployed to, for examplemycontainerappenv
. Do not use the full environment ARM resource id. You can use this command to get it:
az containerapp env list -g <name-of-resource-group> --query [].name
AZURE_ACR_NAME
- the short name of the existing Azure Container Registry where the sample app will be deployed from, for examplemycontainerregistry
. Do not use the full registry ARM resource id. You can use this command to get it:
az acr list -g <name-of-resource-group> --query [].name
AZURE_RG
- the name of the existing Azure resource group where the sample app will be deployed to.AZURE_APP_NAME
- the name of the containerapp where the sample app will be deployed to. You can use this command to get it:
az containerapp list -g <name-of-resource-group> --query [].name
AZURE_APP_DNSSUFFIX
- the default domain of the containerapp environment where the sample app will be deployed to, for examplewhitedesert-078f44c6.<region>.azurecontainerapps.io
. You can use this command to get it:
az containerapp env show -g <name-of-resource-group> -n <name-of-containerapps-environment> --query properties.defaultDomain
OpenID Connect in Azure OpenID Connect (OIDC) allows your GitHub Actions workflows to access resources in Azure, without needing to store the Azure credentials as long-lived GitHub secrets. This is achieved by using a short-lived token that is generated by Azure when the workflow runs.
For this setup, we will use a user-assigned managed identity to authenticate the GitHub Actions workflow with Azure. The managed identity will be granted the required permissions to access the Azure resources.
After the bidep deployment is done, there will be a user-assigned managed identity created in the resource group. You can find it in the Azure portal under Resource groups
> <name-of-resource-group>
> Identity
.
Click on the managed identity and copy the Client ID
and the Subscription ID
. You will need these values to set up the GitHub secrets.
Use the following values as GitHub secrets from your Microsoft Entra managed identity for your GitHub workflow. To set GitHub secrets, go to your repository, click on Settings
, then Secrets and variables
, and finally Actions
. Select New repository secret
.
AZURE_CLIENT_ID
the managed identity Client ID.
AZURE_SUBSCRIPTION_ID
the Subscription ID.
AZURE_TENANT_ID
the Tenant ID.
The following screenshot demonstrates how to copy the managed identity ID and subscription ID.
AZURE_TENANT_ID the Directory (tenant) ID. Learn how to find your Microsoft Entra tenant ID.
To allow GitHub Actions to use the managed identity, you need to set up federated credentials. This allows GitHub Actions to authenticate with Azure using the managed identity.
- Go to the Azure portal and navigate to the managed identity you created earlier.
- Under
Settings
, selectFederated credentials
. - Click on
Add
to create a new federated credential. - In the
Add federated credential
pane, selectGitHub Actions
as the identity provider. - In the
Repository
field, enter the name of your GitHub repository in the format<owner>/<repo>
, for examplembn-ms-dk/BlueGreen
. - In the
Entity
field, selectPull request
as the entity type. - Provide a name for the federated credential, for example
GitHubActions
. - Click on
Add
to create the federated credential.
Give the managed identity the following permissions: owner role on the resource group where the Azure Container Apps environment is deployed.
Open the Azure portal and navigate to the resource group where the Azure Container Apps environment is deployed.
- Under
Overview
, selectAccess control (IAM)
. - Click on
Add role assignment
. - In the
Privileged administrator roles
field, selectOwner
. - In the
Assign access to
field, selectManaged Identity
. - In the
Select
field, search for the managed identity you created earlier and select it. - Click on
Save
to assign the role.
This script id called from the GitHub action.
The script .\infrastructure\set-params.sh
is used to set the blue and green deployments.
Run
git update-index --chmod=+x .\infrastructure\set-params.sh
locally to make the bash script executable. Once you commit and push the change to your GitHub repository the script will be allowed to run in your GitHub action.
Make changes to the sample app and push the code. When you create a PR an merge it to main branch the GitHub action will run and deploy the sample app to the Azure ContainerApps environment.
In Visual Studio Code create a new branch and make changes to the sample app. When you are done, create a pull request and merge it to the main branch.
This is done by comitting your changes and pushing the code to your GitHub repository. Visual Studio Code will prompt you to create a pull request.