Terraform is used as declarative code for infrastructure deployments on multiple cloud platforms including Azure. Azure DevOps provides capability to execute Infrastructure as code (IaC), with CI/CD pipelines, by using tasks added with the extension by Microsoft DevLabs (https://marketplace.visualstudio.com/items?itemName=ms-devlabs.custom-terraform-tasks) available in the marketplace. The terraform task to plan or apply a terraform plan demands to have reources in Azure such as a resource group, storage account, container and a key (terraform state file path). Similar demands are there for even AWS and GCP for when using the task.
Why I do not like it?
The Terraform commands allowing plan or applying a plan relies on a state file. To cater this need, Terraform task by Microsoft DevLabs demands to create Azure resource group, storage account, container and a key (terraform state file path). Which is to create a new env in Azure subscription the task demands to pre create few Azure resources manually.
When using Azure CLI based IaC for creating Azure resources only requirement was to have a service connection from the team project based on an SPN created in Azure in subscription level, to authenticate and authorize creating resources in Azure, which is reasonable prerequisite. However, keeping the terraform state in Azure storage account demands for every new subscription to have manual Azure resource creation work other than the SPN and service connection creation in Azure DevOps if the task by Microsoft DevLabs is used.
Couple of other Marketplace extensions evaluated as below and they seem to be not fixing the issue described above.
Terraform by Peter Groenewegen
This one still keeps state in Azure blob so demands to create Azure resources manually as a prerequisite.
Only allows installing Terraform.
Relies on terraform state in an Azure blob storage demanding for pre-created Azure resources manually.
Not sure how terraform maintained with the tasks in this extension. Need an evaluation to confirm which we can do in another post.
What is the alternative?
As alternatives Terraform by Charles Zipp seems to have multiple approaches to store Terraform status, which can be used as a solution.
Out of options available with this task local option is not feasible to be used with hosted agent as keeping the terraform state locally in a hosted agent would not help in the subsequent runs. The azurerm options relies on Azure blob storage so it is not a solution. However, keeping self-configured and using state file as a secure file in Azure DevOps seems to be a possible solution which we can explore in a next post.
My own solution
As an alternative to using any of extension tasks I could come up with a solution described briefly below.
· Use Terraform Install task by Microsoft DevLabs to get terraform installed in the agent.
· Use PowerShell commands to create a plan and apply the terraform plan
· Store the terraform state and plans in Azure git repo via pushing the file to git repo with command line within PowerShell tasks.
· After executing plan the plan is stored in a git repo and manual intervention step with agentless phase to be introduced to verify plan and approve for applying.
· Add an apply plan agent phase utilizing state plan stored in Azure git repo.
With this solution an approval flow can be introduced as well utilizing the usage of terraform plan to find the changes getting applied to infrastructure and control it with an approval, so that better control on changes to infrastructure in an environment can be maintained. Let’s discuss this solution in detail in the next post.
No comments:
Post a Comment