Deploying a multi-container application to Azure Kubernetes Services

Summary: Excellent article for deploying application to AKS. Steps explained are .

Deploy Kubernetes to Azure, using CLI:

 az group create --name akshandsonlab --location <region>

 az aks create --resource-group akshandsonlab --name <unique-aks-cluster-name> --enable-addons monitoring --kubernetes-version $version --generate-ssh-keys --location <region>

az acr create --resource-group akshandsonlab --name <unique-acr-name> --sku Standard --location <region>

Authenticate with Azure Container Registry from Azure Kubernetes Service

az aks update -n $AKS_CLUSTER_NAME -g $AKS_RESOURCE_GROUP --attach-acr $ACR_NAME

In this article micrsoft start up for azure dev ops project used to explain the complete multi stage set up.   Required code and yaml files will be available by the time project created from template . All the azure resource configuraiton like ACR  , web app name should be replaced in the release and build pile line.         

Overview

Azure Kubernetes Service (AKS) is the quickest way to use Kubernetes on Azure. Azure Kubernetes Service (AKS) manages your hosted Kubernetes environment, making it quick and easy to deploy and manage containerized applications without container orchestration expertise. It also eliminates the burden of ongoing operations and maintenance by provisioning, upgrading, and scaling resources on demand, without taking your applications offline. Azure DevOps helps in creating Docker images for faster deployments and reliability using the continuous build option.

One of the biggest advantage to use AKS is that instead of creating resources in cloud you can create resources and infrastructure inside Azure Kubernetes Cluster through Deployments and Services manifest files.

Lab Scenario

This lab uses a Dockerized ASP.NET Core web application - MyHealthClinic (MHC) and is deployed to a Kubernetes cluster running on Azure Kubernetes Service (AKS) using Azure DevOps.

There is a mhc-aks.yaml manifest file which consists of definitions to spin up Deployments and Services such as Load Balancer in the front and Redis Cache in the backend. The MHC application will be running in the mhc-front pod along with the Load Balancer.

The following image will walk you through all the steps explained in this lab

If you are new to Kubernetes, click here for description of terminology used in this lab.

What’s covered in this lab

The following tasks will be performed:

• Create an Azure Container Registry (ACR), AKS and Azure SQL server

• Provision the Azure DevOps Team Project with a .NET Core application using the Azure DevOps Demo Generator tool.

• Configure application and database deployment, using Continuous Deployment (CD) in the Azure DevOps

• Initiate the build to automatically deploy the application

Want additional learning? Check out the Automate multi-container Kubernetes deployments module on Microsoft Learn.

Before you begin

1. Refer the Getting Started page to know the prerequisites for this lab.

2. Click the Azure DevOps Demo Generator link and follow the instructions in Getting Started page to provision the project to your Azure DevOps.

   For this lab the Azure Kubernetes Service template is used which is already selected when you click on the link above. There are some additional extensions required for this lab and can be automatically installed during the process.

   

Setting up the environment

The following azure resources need to be configured for this lab:

Azure resources	Description
Azure Container Registry	Used to store the Docker images privately
AKS	Docker images are deployed to Pods running inside AKS
Azure SQL Server	SQL Server on Azure to host database

1. Launch the Azure Cloud Shell from the Azure portal and choose Bash.

2. Deploy Kubernetes to Azure, using CLI:

   i. Get the latest available Kubernetes version in your preferred region into a bash variable. Replace <region> with the region of your choosing, for example eastus.

     version=$(az aks get-versions -l <region> --query 'orchestrators[-1].orchestratorVersion' -o tsv)
   

   ii. Create a Resource Group

     az group create --name akshandsonlab --location <region>
   

   iii. Create AKS using the latest version available

    az aks create --resource-group akshandsonlab --name <unique-aks-cluster-name> --enable-addons monitoring --kubernetes-version $version --generate-ssh-keys --location <region>
   

    Important: Enter a unique AKS cluster name. AKS name must contain between 3 and 31 characters inclusive. The name can contain only letters, numbers, and hyphens. The name must start with a letter and must end with a letter or a number. The AKS deployment may take 10-15 minutes

3. Deploy Azure Container Registry(ACR): Run the below command to create your own private container registry using Azure Container Registry (ACR).

    az acr create --resource-group akshandsonlab --name <unique-acr-name> --sku Standard --location <region>
   

    Important: Enter a unique ACR name. ACR name may contain alpha numeric characters only and must be between 5 and 50 characters

4. Authenticate with Azure Container Registry from Azure Kubernetes Service : When you’re using Azure Container Registry (ACR) with Azure Kubernetes Service (AKS), an authentication mechanism needs to be established. You can set up the AKS to ACR integration in a few simple commands with the Azure CLI. This integration assigns the AcrPull role to the managed identity associated to the AKS Cluster. Replace the variables $AKS_RESOURCE_GROUP, $AKS_CLUSTER_NAME, $ACR_NAME with appropriate values below and run the command.

    az aks update -n $AKS_CLUSTER_NAME -g $AKS_RESOURCE_GROUP --attach-acr $ACR_NAME
   

   For more information see document on how to Authenticate with Azure Container Registry from Azure Kubernetes Service

5. Create Azure SQL server and Database: Create an Azure SQL server.

    az sql server create -l <region> -g akshandsonlab -n <unique-sqlserver-name> -u sqladmin -p P2ssw0rd1234
   

   Create a database

    az sql db create -g akshandsonlab -s <unique-sqlserver-name> -n mhcdb --service-objective S0
   

    Important: Enter a unique SQL server name. Since the Azure SQL Server name does not support UPPER / Camel casing naming conventions, use lowercase for the SQL Server Name field value.

6. The following components - Container Registry, Kubernetes Service, SQL Server along with SQL Database are deployed. Access each of these components individually and make a note of the details which will be used in Exercise 1.

   

7. Select the mhcdb SQL database and make a note of the Server name.

   

8. Click on “Set server Firewall” and enable “Allow Azure services …” option.

   

9. Navigate to the resource group, select the created container registry and make a note of the Login server name.

   

Now you have all the required azure components to follow this lab.

Exercise 1: Configure Build and Release pipeline

Make sure that you have created the AKS project in your Azure DevOps organization through Azure DevOps Demo Generator (as mentioned in pre-requisites). We will manually map Azure resources such as AKS and Azure Container Registry to the build and release definitions.

1. Navigate to Pipelines –> Pipelines.

   

2. Select MyHealth.AKS.Build pipeline and click Edit.

   

3. In Run services task, select your Azure subscription from Azure subscription dropdown. Click Authorize.

   

   You will be prompted to authorize this connection with Azure credentials. Disable pop-up blocker in your browser if you see a blank screen after clicking the OK button, and please retry the step.

   This creates an Azure Resource Manager Service Endpoint, which defines and secures a connection to a Microsoft Azure subscription, using Service Principal Authentication (SPA). This endpoint will be used to connect Azure DevOps and Azure.

    Tip: If your subscription is not listed or to specify an existing service principal, follow the Service Principal creation instructions.

4. Following the successful authentication, select appropriate values from the dropdown - Azure subscription and Azure Container Registry as shown.

   Repeat this for the Build services, Push services and Lock services tasks in the pipeline.

   

   Tasks	Usage
   Replace tokens	replace ACR in mhc-aks.yaml and database connection string in appsettings.json
   Run services	prepares suitable environment by pulling required image such as aspnetcore-build:1.0-2.0 and restoring packages mentioned in .csproj
   Build services	builds the docker images specified in a docker-compose.yml file and tags images with $(Build.BuildId) and latest
   Push services	pushes the docker image myhealth.web to Azure Container Registry
   Publish Build Artifacts	publishes mhc-aks.yaml & myhealth.dacpac files to artifact drop location in Azure DevOps so that they can be utilized in Release Definition

   applicationsettings.json file contains details of the database connection string used to connect to Azure database which was created in the beginning of this lab.

   mhc-aks.yaml manifest file contains configuration details of deployments, services and pods which will be deployed in Azure Kubernetes Service. The manifest file will look like as below

   

   For more information on the deployment manifest, see AKS Deployments and YAML manifests

5. Click on the Variables tab.

   

   Update ACR and SQLserver values for Pipeline Variables with the details noted earlier while configuring the environment. 

6. Save the changes.

   

7. Navigate to Pipelines | Releases. Select MyHealth.AKS.Release pipeline and click Edit.

   

8. Select Dev stage and click View stage tasks to view the pipeline tasks.

   

9. In the Dev environment, under the DB deployment phase, select Azure Resource Manager from the drop down for Azure Service Connection Type, update the Azure Subscription value from the dropdown for Execute Azure SQL: DacpacTask task.

   

10. In the AKS deployment phase, select Create Deployments & Services in AKS task.

    

    Update the Azure Subscription, Resource Group and Kubernetes cluster from the dropdown. Expand the Secrets section and update the parameters for Azure subscription and Azure container registry from the dropdown.

    Repeat similar steps for Update image in AKS task.

    

    • Create Deployments & Services in AKS will create the deployments and services in AKS as per the configuration specified in mhc-aks.yaml file. The Pod, for the first time will pull up the latest docker image.

    • Update image in AKS will pull up the appropriate image corresponding to the BuildID from the repository specified, and deploys the docker image to the mhc-front pod running in AKS.

    • A secret called mysecretkey is created in AKS cluster through Azure DevOps by using command kubectl create secret in the background. This secret will be used for authorization while pulling myhealth.web image from the Azure Container Registry.

11. Select the Variables section under the release definition, update ACR and SQLserver values for Pipeline Variables with the details noted earlier while configuring the environment. Select the Save button.

     Note: The Database Name is set to mhcdb and the Server Admin Login is sqladmin and Password is P2ssw0rd1234. If you have entered different details while creating Azure SQL server, update the values accordingly

    

Exercise 2: Trigger a Build and deploy application

In this exercise, let us trigger a build manually and upon completion, an automatic deployment of the application will be triggered. Our application is designed to be deployed in the pod with the load balancer in the front-end and Redis cache in the back-end.

1. Select MyHealth.AKS.build pipeline. Click on Run pipeline

   

2. Once the build process starts, select the build job to see the build in progress.

   

3. The build will generate and push the docker image to ACR. After the build is completed, you will see the build summary. To view the generated images navigate to the Azure Portal, select the Azure Container Registry and navigate to the Repositories.

   

4. Switch back to the Azure DevOps portal. Select the Releases tab in the Pipelines section and double-click on the latest release. Select In progress link to see the live logs and release summary.

   

   

5. Once the release is complete, launch the Azure Cloud Shell and run the below commands to see the pods running in AKS:

   1. Type az aks get-credentials --resource-group yourResourceGroup --name yourAKSname in the command prompt to get the access credentials for the Kubernetes cluster. Replace the variables yourResourceGroup and yourAKSname with the actual values.

      

   2. kubectl get pods

      

      The deployed web application is running in the displayed pods.

6. To access the application, run the below command. If you see that External-IP is pending, wait for sometime until an IP is assigned.

   kubectl get service mhc-front --watch

   

7. Copy the External-IP and paste it in the browser and press the Enter button to launch the application.

   

Kubernetes resource view in the Azure portal (preview)

The Azure portal includes a Kubernetes resource viewer (preview) for easy access to the Kubernetes resources in your Azure Kubernetes Service (AKS) cluster. Viewing Kubernetes resources from the Azure portal reduces context switching between the Azure portal and the kubectl command-line tool, streamlining the experience for viewing and editing your Kubernetes resources. The resource viewer currently includes multiple resource types, such as deployments, pods, and replica sets.

The Kubernetes resource view from the Azure portal replaces the AKS dashboard add-on, which is set for deprecation.

More information found at: https://docs.microsoft.com/en-us/azure/aks/kubernetes-portal

Summary

Azure Kubernetes Service (AKS) reduces the complexity and operational overhead of managing a Kubernetes cluster by offloading much of that responsibility to the Azure. With Azure DevOps and Azure Container Services (AKS), we can build DevOps for dockerized applications by leveraging docker capabilities enabled on Azure DevOps Hosted Agents.

Reference

Thanks to Mohamed Radwan for making a video on this lab. You can watch the following video that walks you through all the steps explained in this lab

Azure DevOps Multi-Stage Pipelines

Summary :  Very simple article to push docker to ACR and use in web app
1. create resource group 

az group create --name $(APP_NAME)-rg --location $(LOCATION)

2.launches an Azure Container Registry if one doesn’t exist,

az acr create --resource-group $(APP_NAME)-rg --name $(ACR_NAME) --sku Basic --admin-enabled true

3. Push image to ACR

export THETIMEANDDATE=$(date '+%Y-%m-%d-%H%M')

echo "$THETIMEANDDATE will be the point in time tag"

az acr login --name $(ACR_NAME) 

docker image build -t $(IMAGE_NAME) ./

docker image tag $(IMAGE_NAME) $(ACR_NAME).azurecr.io/$(IMAGE_NAME):latest

docker image tag $(IMAGE_NAME) $(ACR_NAME).azurecr.io/$(IMAGE_NAME):$THETIMEANDDATE

docker image push $(ACR_NAME).azurecr.io/$(IMAGE_NAME):latest 

docker image push $(ACR_NAME).azurecr.io/$(IMAGE_NAME):$THETIMEANDDATE

4 configures and launches an App Service Plan, App Service and then configures automatic deployment 

az webapp config container set --resource-group $(APP_NAME)-rg --name $(APP_NAME)

--docker-custom-image-name $(ACR_NAME).azurecr.io/$(IMAGE_NAME):latest

--docker-registry-server-url https://$(ACR_NAME).azurecr.io

az webapp deployment container config

--resource-group $(APP_NAME)-rg

--name $(APP_NAME)

--enable-cd true

 As I move into using Azure DevOps more and more, there is one thing which I really haven’t got on with and that is release pipelines. I didn’t like that I couldn’t easily define it as YAML like I could with build pipelines, even though I don’t like them, there are a few things I do like — like approval gates.

 

Environments

Luckily, there are ways to get around this — the most simple way is to add an Environment and then add an Approval. Adding an Environment is simple enough, just click on Environment in your Pipeline and then add one with None selected under Resource;

Adding an environment {Source: MediaGlasses}

 

Once you have added the Environment you can then add an approval check, to do this click on the Environment you have just created and click on the three dots in the top right-hand side of the page. From the menu select Approvals and checks;

Adding an approval {Source: MediaGlasses}

 

Now we have an Environment and the Approval in place we can move onto the Pipeline.

 

Pipeline

I already had a multi-stage pipeline I have been using to demo a container build, so I decided to adapt that as it made sense to slot in an approval at the stage where our container image is built, tagged and pushed, there are a few stages before that though so lets take a quick look at those.

First up is the stage where the Resource Group is created;

	- stage: "SetupRG"
	displayName: "Resource Group"
	jobs:
	- job: "CreateResourceGroup"
	displayName: "Resource Group - Setup"
	steps:
	- task: AzureCLI@2
	inputs:
	azureSubscription: "$(SUBSCRIPTION_NAME)"
	addSpnToEnvironment: true
	scriptType: "bash"
	scriptLocation: "inlineScript"
	inlineScript: |
	az group create --name $(APP_NAME)-rg --location $(LOCATION)
	displayName: "Resource Group - Use Azure CLI to setup or check"

view raw01.yml hosted with  by GitHub

As you can see, I am using the Azure CLI and variables which are defined in the header of the Pipeline.

Once the Resource Group has been created the next stage launches an Azure Container Registry if one doesn’t exist, if there is already one there then nothing happens;

	- stage: "SetupACR"
	displayName: "Azure Container Registry"
	dependsOn:
	- "SetupRG"
	jobs:
	- job: "SetupCheckAzureContainerRegistry"
	displayName: "Azure Container Registry - Setup"
	variables:
	- name: "DECODE_PERCENTS"
	value: true
	steps:
	- task: AzureCLI@2
	inputs:
	azureSubscription: "$(SUBSCRIPTION_NAME)"
	addSpnToEnvironment: true
	scriptType: "bash"
	scriptLocation: "inlineScript"
	inlineScript: |
	ACR_ID=$(az acr show --resource-group $APP_NAME-rg --name $ACR_NAME --query "id" -o tsv)
	if [ -z "$ACR_ID" ]; then
	echo "There is no Azure Container Registry, we should sort that"
	az acr create --resource-group $(APP_NAME)-rg --name $(ACR_NAME) --sku Basic --admin-enabled true
	else
	echo "There is already an Azure Container Registry, we don't need to do anything else here"
	fi
	displayName: "Azure Container Registry - Use Azure CLI check or setup"

view raw02.yml hosted with  by GitHub

Now that we have a container registry to push our image to we can build and the push the container, this is the stage where we will be getting approval before building;

	- stage: "BuildContainer"
	displayName: "Build, Tag and Push the container image"
	dependsOn:
	- "SetupACR"
	jobs:
	- deployment: BuildPushImage
	displayName: "Build, tag and push the image"
	environment: "production"
	pool:
	vmImage: "Ubuntu-20.04"
	strategy:
	runOnce:
	deploy:
	steps:
	- checkout: self
	- task: AzureCLI@2
	inputs:
	azureSubscription: "$(SUBSCRIPTION_NAME)"
	addSpnToEnvironment: true
	scriptType: "bash"
	scriptLocation: "inlineScript"
	inlineScript: |
	export THETIMEANDDATE=$(date '+%Y-%m-%d-%H%M')
	echo "$THETIMEANDDATE will be the point in time tag"
	az acr login --name $(ACR_NAME)
	docker image build -t $(IMAGE_NAME) ./
	docker image tag $(IMAGE_NAME) $(ACR_NAME).azurecr.io/$(IMAGE_NAME):latest
	docker image tag $(IMAGE_NAME) $(ACR_NAME).azurecr.io/$(IMAGE_NAME):$THETIMEANDDATE
	docker image push $(ACR_NAME).azurecr.io/$(IMAGE_NAME):latest
	docker image push $(ACR_NAME).azurecr.io/$(IMAGE_NAME):$THETIMEANDDATE
	displayName: "Use Azure CLI to build and push the container image"

view raw03.yml hosted with  by GitHub

As you can see, rather than defining a job we are using a deployment this means we can then use the environment we created and because the environment is what our approval is attached to the deployment won’t progress until approved.

One thing to note here is that there are two steps, the first checkout step downloads a copy of the repo which our azure-pipelines.yml and Dockerfile are in, without this step the build would fail.

The second step builds, tags and then pushes the image to the Azure Container Registry launched in the previous stage.

The remaining stage, assuming the previous three stages have all completed, configures and launches an App Service Plan, App Service and then configures automatic deployment of any subsequent images which are pushed to our Azure Container Registry, as you can see the code below the steps are only executed if the App Service Plan has not been configured, if our Application is already running then these steps are skipped;

	- stage: "SetupAppServices"
	displayName: "Azure App Services"
	dependsOn:
	- "SetupRG"
	- "SetupACR"
	- "BuildContainer"
	jobs:
	- job: "CheckForAppServicePlan"
	displayName: "App Service Plan - Check if App Service Plan exists"
	steps:
	- task: AzureCLI@2
	inputs:
	azureSubscription: "$(SUBSCRIPTION_NAME)"
	addSpnToEnvironment: true
	scriptType: "bash"
	scriptLocation: "inlineScript"
	inlineScript: |
	APP_SERVICE_PLAN_ID=$(az appservice plan show --resource-group $APP_NAME-rg --name $APP_NAME-asp --query "id" -o tsv)
	if [ -z "$APP_SERVICE_PLAN_ID" ]; then
	echo "There is no App Service Plan, we should sort that"
	echo "##vso[task.setvariable variable=appServiceExist;isOutput=true]No" # there is no app service plan so we should do stuff
	else
	echo "There is an App Service Plan, we don't need to do anything else here"
	echo "##vso[task.setvariable variable=appServiceExist;isOutput=true]Yes" # nothing to do lets move on
	fi
	name: "DetermineResult"
	displayName: "App Service Plan - Check to see if there App Service Plan exists"
	- job: "CreateAppServicePlan"
	displayName: "App Service Plan - Setup"
	dependsOn:
	- "CheckForAppServicePlan"
	condition: "eq(dependencies.CheckForAppServicePlan.outputs['DetermineResult.appServiceExist'], 'No')"
	steps:
	- task: AzureCLI@2
	inputs:
	azureSubscription: "$(SUBSCRIPTION_NAME)"
	addSpnToEnvironment: true
	scriptType: "bash"
	scriptLocation: "inlineScript"
	inlineScript: |
	az appservice plan create --resource-group $(APP_NAME)-rg --name $(APP_NAME)-asp --is-linux
	displayName: "App Service Plan - Use Azure CLI to setup"
	- job: "CreateAppService"
	displayName: "Web App - Setup"
	dependsOn:
	- "CheckForAppServicePlan"
	- "CreateAppServicePlan"
	condition: "eq(dependencies.CheckForAppServicePlan.outputs['DetermineResult.appServiceExist'], 'No')"
	steps:
	- task: AzureCLI@2
	inputs:
	azureSubscription: "$(SUBSCRIPTION_NAME)"
	addSpnToEnvironment: true
	scriptType: "bash"
	scriptLocation: "inlineScript"
	inlineScript: |
	az webapp create --resource-group $(APP_NAME)-rg --plan $(APP_NAME)-asp --name $(APP_NAME) --deployment-container-image-name $(ACR_NAME).azurecr.io/$(IMAGE_NAME):latest
	displayName: "Web App - Use Azure CLI to setup"
	- job: "CreateAppServiceSettings"
	displayName: "Web App - Configure Settings"
	dependsOn:
	- "CheckForAppServicePlan"
	- "CreateAppServicePlan"
	- "CreateAppService"
	condition: "eq(dependencies.CheckForAppServicePlan.outputs['DetermineResult.appServiceExist'], 'No')"
	steps:
	- task: AzureCLI@2
	inputs:
	azureSubscription: "$(SUBSCRIPTION_NAME)"
	addSpnToEnvironment: true
	scriptType: "bash"
	scriptLocation: "inlineScript"
	inlineScript: |
	az webapp config appsettings set --resource-group $(APP_NAME)-rg --name $(APP_NAME) --settings $(APP_SETTINGS)
	displayName: "Web App - Use Azure CLI to configure the settings"
	- job: "CreateAppServiceID"
	displayName: "Web App - Configure & Assign Managed Identity"
	dependsOn:
	- "CheckForAppServicePlan"
	- "CreateAppServicePlan"
	- "CreateAppService"
	- "CreateAppServiceSettings"
	condition: "eq(dependencies.CheckForAppServicePlan.outputs['DetermineResult.appServiceExist'], 'No')"
	steps:
	- task: AzureCLI@2
	inputs:
	azureSubscription: "$(SUBSCRIPTION_NAME)"
	addSpnToEnvironment: true
	scriptType: "bash"
	scriptLocation: "inlineScript"
	inlineScript: |
	az webapp identity assign --resource-group $(APP_NAME)-rg --name $(APP_NAME)
	displayName: "Web App - Use Azure CLI to assign an identity"
	- task: AzureCLI@2
	inputs:
	azureSubscription: "$(SUBSCRIPTION_NAME)"
	addSpnToEnvironment: true
	scriptType: "bash"
	scriptLocation: "inlineScript"
	inlineScript: |
	az role assignment create --assignee $(az webapp identity show --resource-group $(APP_NAME)-rg --name $(APP_NAME) --query principalId --output tsv) --scope /subscriptions/$(az account show --query id --output tsv)/resourceGroups/$(APP_NAME)-rg/providers/Microsoft.ContainerRegistry/registries/$(ACR_NAME) --role "AcrPull"
	displayName: "Web App - Use Azure CLI to assign an identity"
	- job: "EnableCD"
	displayName: "Web App - Configure Azure Container Registry connedction and enable continuous deployment"
	dependsOn:
	- "CheckForAppServicePlan"
	- "CreateAppServicePlan"
	- "CreateAppService"
	- "CreateAppServiceSettings"
	- "CreateAppServiceID"
	condition: "eq(dependencies.CheckForAppServicePlan.outputs['DetermineResult.appServiceExist'], 'No')"
	steps:
	- task: AzureCLI@2
	inputs:
	azureSubscription: "$(SUBSCRIPTION_NAME)"
	addSpnToEnvironment: true
	scriptType: "bash"
	scriptLocation: "inlineScript"
	inlineScript: |
	az webapp config container set --resource-group $(APP_NAME)-rg --name $(APP_NAME) --docker-custom-image-name $(ACR_NAME).azurecr.io/$(IMAGE_NAME):latest --docker-registry-server-url https://$(ACR_NAME).azurecr.io
	displayName: "Web App - Configure the App Serivce to use Azure Container Registry"
	- task: AzureCLI@2
	inputs:
	azureSubscription: "$(SUBSCRIPTION_NAME)"
	addSpnToEnvironment: true
	scriptType: "bash"
	scriptLocation: "inlineScript"
	inlineScript: |
	az webapp deployment container config --resource-group $(APP_NAME)-rg --name $(APP_NAME) --enable-cd true
	displayName: "Web App - Enable continuous deployment whenever the image is updated on the WebApp"
	- task: AzureCLI@2
	inputs:
	azureSubscription: "$(SUBSCRIPTION_NAME)"
	addSpnToEnvironment: true
	scriptType: "bash"
	scriptLocation: "inlineScript"
	inlineScript: |
	az acr webhook create --name $(ACR_NAME)webhook --registry $(ACR_NAME) --scope $(IMAGE_NAME):latest --actions push --uri $(az webapp deployment container show-cd-url --resource-group $(APP_NAME)-rg --name $(APP_NAME) --query "CI_CD_URL" -o tsv)
	displayName: "Azure Container Registry - Add the web hook created in the last task to the Azure Container Registry"

view raw04.yml hosted with  by GitHub

A full copy of the azure-pipelines.yml file can be found in the following repo https://github.com/russmckendrick/docker-python-web-app.

 

Running the Pipeline

Now that we know what the pipeline looks like this what happened when it executed for the first time, first off, you (or whoever your approver is) will get an email;

The approval email {Source: MediaGlasses}

 

Once you click through to approve the deployment you should see something which looks like the following;

The full pipeline run {Source: MediaGlasses} 

When the pipeline is next triggered you should see something like the following;

A second pipeline run {Source: MediaGlasses}

 

This time, other than checking to see if the application has already been deployed everything else in the fourth stage has been skipped.