Terraform

Terraform is an open-source Infrastructure as Code tool that provides a consistent workflow and human-readable configuration language to manage infrastructure and configurations across several different cloud services.

At Gjensidige, we use Terraform to manage resources for Azure, GitHub and Splunk, among others. We use a multi-repo architecture which enables teams to self-service and compose configurations based on shared building blocks.

Learn more

Get Started - Azure | Terraform - HashiCorp Learn

Repository templates

Repository templates for Terraform are available, which include common boilerplate code, workflows and a directory structure that can be used as a starting point for your repository.

Use the /platform-github repo create-from-template-command in #github-at-gjensidige to create a new repository using one of these templates:

• terraform-root-module-template
• terraform-library-module-template

Reusable modules

The following reusable modules are available for internal use at Gjensidige:

• terraform-azurerm-storage-account
• terraform-azurerm-postgresql-flexible-server
• terraform-azurerm-mssql-server
• terraform-azurerm-redis-cache
• terraform-azurerm-key-vault
• terraform-azurerm-monitor-diagnostic-setting
• terraform-azurerm-linux-virtual-machine
• terraform-azurerm-windows-virtual-machine
• terraform-constants

CI/CD with GitHub Actions

Changes should always be applied using a GitHub Actions workflow.

Reusable workflows

Reusable workflows are used to avoid duplication and increase consistency across repositories.

We have two centrally maintained, reusable workflows for Terraform:

• Apply: terraform-plan-and-apply-azure.yml

• Destroy: terraform-plan-and-destroy-azure.yml

  Destroy workflows are often only needed in specific cases, and can therefore usually be disabled in GitHub Actions.

Both workflows use self-hosted runners and contain two jobs: one for generating a plan and one for applying the planned changes. The generated plan should always be reviewed before applying any changes.

Environments

Environments are used to describe deployment targets like prod or test, and should be configured with protection rules:

• Manual approval

  All environments should have specified one or more teams that can approve workflow runs for the repository.

  caution

  This protection rule must be added before running the workflow. Otherwise, unreviewed changes can accidentally be applied.

• Deployment Branch

  Deployment branches can be used to limit which branches can deploy to an environment. This can f.ex. be used to only allow changes in production from the main branch.

Required secrets

• Service Principal Client ID - We use OpenID Connect for authentication to Azure, so no password is required. This secret is managed in the following repository: gjensidige/terraform-github-repo-credentials.

• GitHub access token - If your configuration uses any of Gjensidige's reusable modules, an access token is required to fetch the modules from GitHub. See Global secrets (Confluence).