When you read the title you may think that this article can be a clickbait. That’s the reason you should continue reading until this end to figure out that deploying k8s application with Azure DevOps and terraform can be very easy when you create everything through infrastructure as code.
In this example we will utilize Azure DevOps pipelines and terraform to deploy a yaml definition on an AKS cluster that runs on Azure. For this output we will need three steps.
The first step is to create an AKS cluster on Azure. When we have the infrastructure ready we can then continue and bind Azure DevOps pipelines with the AKS resource so that we can deploy on the cluster. The last step is to have the yaml definition of the application that we need to deploy and run the application deployment process inside azure devops.
The project is structure as shown in the below picture.
The code folder contains the yaml k8s definition file.
The iac_aks creates the AKS cluster inside Azure
The iac_devops creates the Azure Devops resources needed (Service connection with AKS)
And finally the azure-pipeline and application-pipeline are the pipelines that will run the automation and do the job.
In order to try out the example the first think that you need to do is to create a variable group inside azure devops and store two values. The first value will be the secret Personal access token that will be used to create the Azure DevOps resources. The second one is the URL of your Azure DevOps organization.
When those are set you will need to change the tfvars files and add the names that you prefer for the resources creation. Finally you can have your deployment ready with just two clicks. One for the infra pipelines and one for the application pipeline.
In this article I will demonstrate how one can deploy app service code on Azure through Azure DevOps. App service is a hosting provider for your applications (web app) that can be created with multiple hosting options and application specific settings.
When creating an app service you can choose from many available options like different code frameworks or even container deployments.
For my demo I wanted to deploy an asp .net core web api using .net 6 version hosted on windows app service.
My repository structure is shown below. The app service that I want to deploy is the one located under Front folder.
The pipeline code can be found below:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In more detail there are three necessary steps for the deployment.
The first task will build the .NET app using VSbuild task. The build will use as parameters the deployonBuild and the webpublishmethod as filesystem in order to specify the path on which the build output will be stored.
The second task will bundle this build output to a zip file and then the third task will upload this .zip file in the app service using a service connection with the subscription. The two parameters that should be changed are azureSubscription and WebAppName which should be the app service name.
When running the pipeline, a build folder will be created as shown in the below screenshot that will host the build output.
This output will be then zipped to a file that will be uploaded to the app service.
Its a common thing for DevOps engineers to define some agent pools that hold agents and organize their deployments through those pools. I have worked with this approach as well by defining Uat and Prod pools that are used from build and release pipelines.
In this article I will explain how to use the environment resources that are located under Pipelines section.
Environments are a collection of resources on Azure DevOps through which you can define your deployment strategy, approvals and conditions. An environment could be a custom one, or a predefined like a virtual machine or Kubernetes cluster.
It is important to understand the difference between an agent pool and an environment as you have the option to run a deployment job with an environment that has no resources.
This is possible because environments are the scope at which you define pre-deployment checks (approvals, gates, etc). Deploying to resources defined in an environment is an option, not a requirement.
As an example, if you have a serverless Azure web app, you use an environment to define the approvals and gates required to deploy to that environment, but then actual deployment activities occur on an agent from an agent pool because an Azure Web App doesn’t have any physical machines to deploy to.
Lets now examine how you could create your own environments to define your strategies. From environments select add new environment
In my case I will select windows virtual machines as I will use common windows servers as deployment machines.
Then the registration script will be provided to register your machine as an Azure DevOps agent so that jobs can run on those environments. If you use empty environments just for approvals you will not have to run scripts or install an azure devops agent.
Azure DevOps will automatically create a Personal Access Token for the agent registration. You can either create a new one, or use the created one. Keep in mind that the life timespan of this token will be three hours. If you want to have the agent alive, you can extend the expiration time of the token.
You will have to save the script as .ps1 on your target machine and run it as administrator.
$ErrorActionPreference="Stop";If(-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent() ).IsInRole( [Security.Principal.WindowsBuiltInRole] "Administrator")){ throw "Run command in an administrator PowerShell prompt"};If($PSVersionTable.PSVersion -lt (New-Object System.Version("3.0"))){ throw "The minimum version of Windows PowerShell that is required by the script (3.0) does not match the currently running version of Windows PowerShell." };If(-NOT (Test-Path $env:SystemDrive\'azagent')){mkdir $env:SystemDrive\'azagent'}; cd $env:SystemDrive\'azagent'; for($i=1; $i -lt 100; $i++).....
During the configuration I proceeded with the default values. (just press enter)
When you finish with the configuration of your agents you will have the recources listed under your environment. In my case those are two virtual machines, test-qa and test-dev
Lets now define a deployment strategy. You can choose between the rolling, runOnce, canary deployments. Each of them are explained on the documentation article that I have included on the bottom of the page.
runOnce is the simplest deployment strategy and most steps are executed once. (preDeploy, deploy, routeTraffic)
A rolling deployment replaces instances of the previous version of an application with instances of the new version of the application on a fixed set of virtual machines (rolling set) in each iteration
Canary deployment strategy is an advanced deployment strategy that helps mitigate the risk involved in rolling out new versions of applications. By using this strategy, you can roll out the changes to a small subset of servers first. As you gain more confidence in the new version, you can release it to more servers in your infrastructure and route more traffic to it.
In the below pipeline I added a rolling strategy. The max parallel execution percentage is 50% this means that the deployment will be executed first on my dev server and then on my qa server after all tasks of the dev are finished. The deployment test task will create a file and paste some text on it.
trigger:
- none
pool:
vmImage: ubuntu-latest
stages:
- stage: deployment
displayName: Deploy on Environment
jobs:
- deployment: VMDeploy
displayName: Deploy to VM
environment:
name: azure-test-dev
resourceType: VirtualMachine
strategy:
rolling:
maxParallel: 50%
preDeploy:
steps:
- script: echo running pre deployment steps
deploy:
steps:
- script: echo running rolling strategy on windows servers > C:\output
Strategy sequence:
Dev server -> predeploy step
Dev server -> deploy step
When the deployment for the dev server is completed then the qa server deployment will start.
QA server -> predeploy step
QA server -> deploy step
You can also define approvals and checks for your stages on the deployments. For example you could define a stage to be deployed only during working hours or from a specific branch.
Lastly you should give access to the environment from the pipeline that you created.
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy