general_config¶

All 'shared' configuration that applies to all sites.

environment - (Required) environment Identifier for the environment. For example development, test or production.
Is used to set the environment variable of any Terraform component
terraform_config - (Required) terraform_config block
cloud - Either azure or aws
azure - Azure block
sentry - Sentry block
contentful - Contentful block

terraform_config¶

Terraform configuration block.

Can be used to configure the state backend and Terraform provider versions.

azure_remote_state - Azure remote state configuration
aws_remote_state - AWS remote state configuration
providers - Providers configuration block

azure_remote_state¶

An Azure state backend can be defined as:

terraform_config:
  azure_remote_state:
    resource_group: <your resource group>
    storage_account: <storage account name>
    container_name: <container name>
    state_folder: <state folder>

A good convention is to give the state_folder the same name as environment

aws_remote_state¶

An AWS S3 state backend can be defined as:

terraform_config:
  aws_remote_state:
    bucket: mach-statefiles
    key_prefix: test-statefiles
    role_arn: arn:aws:iam::1234567890:roldeploy

bucket - (Required) S3 bucket name
key_prefix - (Required) Key prefix for each individual Terraform state
role_arn - Role ARN to access S3 bucket with
lock_table - DynamoDB lock table
encrypt - Enable server side encryption of the state file. Defaults to True

providers¶

Can be used to overwrite the MACH defaults for the Terraform provider versions.

Example:

terraform_config:
  providers:
    aws: 3.21.0

aws aws provider version overwrite
azure azurerm provider version overwrite
commercetools commercetools provider version overwrite
sentry sentry provider version overwrite
contentful contentful provider version overwrite

Cache your providers

If you're overwriting the provider versions, make sure you mount the plugins cache

sentry¶

Defines a Sentry configuration.

This could be a predefined DSN to be used in the components, or MACH can manage the keys for you and pass the correct DSN to the components to be used.

Example (managed)

sentry:
  auth_token: <your-sentry-auth-token>
  organization: <organization-name>
  project: <project-name>

predefined DSN

sentry:
  dsn: https://LhNrqROZRIl2c5ciidkN82DObJfgtiLd@sentry.io/123456

dsn - DSN to use in the components

or

auth_token - Auth token to manage keys with
organization - Organization name
project - Project to create the key for
rate_limit_window - The rate limit window that applies to a generated key
rate_limit_count - The rate limit count that applies to a generated key

When defined, a sentry integration can be used in the components to expose a Sentry DSN value.

The Sentry settings can be overwritten on site and component level

azure¶

General Azure settings. Values can be overwritten per site.

Example:

azure:
  tenant_id: f2e03b8b-fe10-4fbc-9f5c-76dad9ac52e2
  subscription_id: a5b51c09-a2da-45b8-918a-67cf42456ab3
  region: westeurope
  resources_prefix: my-
  service_object_ids:
    gitlab-sp: d1114ea6-88f9-45b2-9de4-031291090380 # gitlab-sp
    developers: 3d280212-934f-4d32-876d-1b541a7697ba # developers tst group

tenant_id - (Required)
subscription_id - (Required)
region - (Required)
resources_prefix - Prefix to be used for all Azure resources, for example my-
frontdoor - Front-door settings
service_object_ids - Map of objects IDs that should have access to things like KeyVaults created for components

Don't lock yourself out

Make sure that, as a minimum, you set the service_object_ids to the objects IDs of the users or groups that perform the mach apply

frontdoor¶

Example:

frontdoor:
  resource_group: my-shared-rg

resource_group - (Required)

contentful¶

Defines global Contentful credentials to manage the spaces

cma_token - (Required)
organization_id - (Required)

amplience¶

Defines global Amplience credentials to manage hubs

client_id - (Required)
client_secret - (Required)