Terraform is an Infrastructure as Code (IaC) tool that allows you to create, manage, and update infrastructure resources in a declarative way. GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your software development workflow.
By combining Terraform and GitHub Actions, you can create a CI/CD pipeline that will automatically build, test, and deploy your infrastructure changes to production.
Prerequisites
Before you can set up your CI/CD pipeline, you will need to have the following prerequisites:
- A GitHub repository that contains your Terraform configuration files.
- An Azure subscription.
- An Azure managed identity.
- The Azure CLI: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest.
Setting up the Azure Managed Identity
The first step is to create an Azure managed identity. A managed identity is an identity that is managed by Azure and can be used to access Azure resources.
To create a managed identity, you can use the Azure CLI. Run the following command to create a managed identity named terraform-ci
:
az identity create --resource-group my-resource-group --name terraform-ci
This command will create a managed identity in the my-resource-group
resource group. The managed identity will be named terraform-ci
.
Setting up the GitHub Secrets
Next, you need to set up the GitHub secrets for your CI/CD pipeline. GitHub secrets are encrypted values that can be used in your GitHub Actions workflows.
You need to set the following secrets:
-
AZURE_CLIENT_ID
: The client ID of your Azure managed identity. -
AZURE_TENANT_ID
: The tenant ID of your Azure subscription.
You can set these secrets in your GitHub repository settings.
Creating the GitHub Actions Workflow
Now that you have the prerequisites in place, you can create the GitHub Actions workflow. The workflow will be triggered when you push changes to your GitHub repository. The workflow will first run a terraform fmt
command to format your Terraform configuration files. Then, the workflow will run a terraform plan
command to generate a plan for your infrastructure changes. If the plan is successful, the workflow will run a terraform apply
command to deploy your infrastructure changes to production.
The following is an example of a GitHub Actions workflow that you can use:
name: Terraform CI/CD
permissions:
id-token: write
contents: read
checks: write
on:
push:
branches:
- main
env:
ARM_CLIENT_ID: $
ARM_SUBSCRIPTION_ID: $
ARM_TENANT_ID: $
ARM_USE_OIDC: true
terraform_version: 1.5.2
jobs:
terraform:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: hashicorp/setup-terraform@v2
with:
terraform_version: $
- name: Terraform fmt
run: terraform fmt
- name: Terraform plan
run: terraform plan
- name: Terraform apply
if: github.ref == 'refs/heads/main'
run: terraform apply
You’ll notice the permissions object in the workflow, these are needed for a few things:
-
id-token: write
: This scope allows the workflow to read and write the GitHub user’s ID token. The ID token is a JSON Web Token (JWT) that identifies the user who triggered the workflow. -
contents: read
: This scope allows the workflow to read the contents of the repository. This is necessary for the workflow to checkout the repository and run the Terraform commands. -
checks: write
: This scope allows the workflow to create and update GitHub checks. Checks are used to track the progress of a workflow and to identify any errors.
This workflow will trigger when you push changes to your main
branch. The workflow will first run a terraform fmt
command to format your Terraform configuration files. Then, the workflow will run a terraform plan
command to generate a plan for your infrastructure changes. If the plan is successful, the workflow will run a terraform apply
command to deploy your infrastructure changes to production.
Conclusion
In this blog post, we showed you how to set up a Terraform CI/CD pipeline in GitHub Actions using OIDC and an Azure managed identity with federated credentials. This pipeline will automatically build, test, and deploy your infrastructure changes to production. This can help you to improve the quality and reliability of your infrastructure, and to reduce the time it takes to deploy new changes.
I hope this blog post was helpful. Let me know if you have any questions.