In a follow up to my recent blog post and video on Deploying infrastructure via Azure DevOps pipelines using Github and Terraform, I thought I would write a brief article on exploring the YAML file that should be used in preference to any ‘classic’ editor in the Azure DevOps environment.
In this blog article, I aim to guide you through the components needed in order to successfully deploy Azure Infrastructure using Terraform via an Azure DevOps Pipeline. The idea here is to help understand how you may be able to automate the deployment and updating of your cloud infrastructure hosted in Azure. Follow along with …
My main reason for wanting to look into the YAML schema and syntax is predominantly based on the point that, if defined in YAML code, your pipeline can live within your Git Repository, and in that sense it becomes an auditable and controlled piece of code along with your actual build artefacts and existing code base.
What this then means is that in theory, within your Git Repo, you contain not just the controlled code to define your application / your IaC declaration or whatever else you may have, but you can also define ‘how’ this code is handled in a CI/CD pipeline. You are able to modify and change your pipeline in the same way that you are able to change your application code etc. If you think about this for a second it should become clear how powerful this scenario actually is……. think Disaster recovery, or Business continuity. No longer do you need hot or warm standby kit, or a 50 page config guide….. a well crafted YAML file can act as your CI/CD automation effort for your code, but it can also act as your BCDR plan and goto strategy!
Ok, so having said that, I wanted to use the example that I posted in the above blog, which is effectively a simple Terraform deployment script that sets up my landing zone environment in Azure, and it enables me to ‘tweak’, ‘change’ or ‘remove parts of my infrastructure via this Terraform.
Export YAML from Azure DevOps Pipeline
If we log onto our Azure DevOps Organisation, select our project and browse to our Build Pipline.
If we select ‘View YAML’ we can export a copy of the YAML that is behind the current build pipeline that we may have use the Classic editor to configure.
steps: - task: charleszipp.azure-pipelines-tasks-terraform.azure-pipelines-tasks-terraform-installer.TerraformInstaller@0 displayName: 'Use Terraform latest' - task: ms-devlabs.custom-terraform-tasks.custom-terraform-release-task.TerraformTaskV1@0 displayName: 'Terraform : INIT' inputs: backendServiceArm: 'Jonnychipz-TFSPN' backendAzureRmResourceGroupName: 'jonnychipz-infra' backendAzureRmStorageAccountName: jonnychipztstate backendAzureRmContainerName: tstate backendAzureRmKey: '77Q4LUB5o9wRdbPYDt+0kGZP+L8Sj9E/FNXg7lZBQS5z3mLod5cyan4wA19CR1SmlqIRUFQfhuQrPVaGzNhjGw==' - task: ms-devlabs.custom-terraform-tasks.custom-terraform-release-task.TerraformTaskV1@0 displayName: 'Terraform : PLAN' inputs: command: plan environmentServiceNameAzureRM: 'Jonnychipz-TFSPN' - task: ms-devlabs.custom-terraform-tasks.custom-terraform-release-task.TerraformTaskV1@0 displayName: 'Terraform : VAL & APPLY' inputs: command: apply environmentServiceNameAzureRM: 'Jonnychipz-TFSPN'
We can see that this YAML is split into a pool and some steps, which reflect the actions we took when we built this pipeline in the previous post.
We can now take this YAML file and modify it slightly to ensure it has an appropriate ‘Trigger’ and Agent Pool and ‘Label’, so we need to copy the following lines to the top of our YAML file:
trigger: - main pool: name: Azure Pipelines vmImage: 'vs2017-win2016'
Ok so now we have extracted and modified our pipeline as YAML code. We can save this off as a YAML file in our file system with a file called buildpipeline.yaml:
Creating a New Build Pipeline from YAML file
Within our Azure DevOps project we can now create a new pipeline:
I will select GitHub as the location for my source code (terraform main.tf and yaml pipeline code).
Next I will select the Repo:
Then I will select ‘Existing Azure Pipelines YAML file’:
Finally I will select the buildpipeline.yaml file that we have just created:
Now we can select Save or Run:
And there we have it, our Azure DevOps Pipeline running our tasks that were defined in a YAML file:
To summarise what we have just covered here.
If we look to declare our Build Pipelines in YAML formatted files, this gives us the ability to keep our pipeline definitions within the same repositories as our source code with whatever this may be producing.
The benefits of this outline the ability to not only save our Development project or Infrastructure as Code definitions in a Git Repo, but we can also store the definition for hoe that code is continuously integrated or delivered/deployed. All in all, this opens up a hugely powerful scenario to offer alternative and innovative BCDR planning and practical implementations!
I hope you have found this posting useful!