Terraform: инфраструктура на уровне кода

1. Написать код Terraform, чтобы создать бакет S3 и таблицу DynamoDB, а затем развернуть этот код с использованием локального хранилища.

2. Вернуться к коду Terraform, добавить в него конфигурацию для удаленного хранилища, чтобы применить свежесозданные бакет S3 и таблицу DynamoDB, и выполнить команду terraforminit, чтобы скопировать ваше локальное состояние в S3.

Если вы когда-нибудь захотите удалить бакет S3 и таблицу DynamoDB, придется выполнить обратные действия.

1. Перейти к коду Terraform, удалить конфигурацию backend и снова выполнить команду terraforminit, чтобы скопировать состояние Terraform обратно на локальный диск.

2. Выполнить terraformdestroy, чтобы удалить бакет S3 и таблицу DynamoDB.

Этот двухступенчатый процесс довольно непростой, зато вы можете использовать во всем своем коде Terraform одни и те же бакет S3 и таблицу DynamoDB, поэтому нужно выполнить его лишь раз (или единожды для каждой учетной записи AWS, если у вас их несколько). Если у вас уже есть бакет S3, вы можете сразу указывать конфигурацию backend в своем коде Terraform без дополнительных действий.

Второе ограничение более болезненное: в разделе backend в Terraform нельзя применять никакие переменные или ссылки. Следующий код не будет работать.

# Это НЕ будет работать. В конфигурации хранилища нельзя использовать переменные.

terraform {

  backend "s3" {

    bucket         = var.bucket

    region         = var.region

    dynamodb_table = var.dynamodb_table

    key            = "example/terraform.tfstate"

    encrypt        = true

  }

}

Значит, необходимо вручную копировать и вставлять имя и регион бакета S3, а также название таблицы DynamoDB в каждый ваш модуль Terraform. Вы подробно познакомитесь с модулями Terraform в главах 4 и 6. Пока достаточно понимать, что модули — это способ организации и повторного использования кода Terraform и что настоящий код Terraform обычно состоит из множества мелких модулей. Что еще хуже, вам нужно быть очень осторожными, чтобы не скопировать значение key. Чтобы разные модули случайно не перезаписывали состояние друг друга, это значение должно быть уникальным для каждого из них! Частое копирование и ручное редактирование чреваты ошибками, особенно если нужно развертывать и администрировать множество модулей Terraform во многих средах.

По состоянию на май 2019 года единственным решением является использование частичной конфигурации, в которой можно опустить определенные параметры раздела backend и передавать их вместо этого в аргументе командной строки -backend-config при вызове terraforminit. Например, вы можете вынести повторяющиеся параметры хранилища, такие как bucket и region, в отдельный файл под названием backend.hcl:

# backend.hcl

bucket         = "terraform-up-and-running-state"

region         = "us-east-2"

dynamodb_table = "terraform-up-and-running-locks"

encrypt        = true

В коде Terraform останется только параметр key, поскольку вам все равно нужно устанавливать ему разные значения в разных модулях:

# Частичная конфигурация. Другие параметры (такие как bucket, region) будут

# переданы команде 'terraform init' в виде файла с использованием

# аргументов -backend-config

terraform {

  backend "s3" {

    key = "example/terraform.tfstate"

  }

}

Чтобы собрать воедино все фрагменты вашей конфигурации, выполните команду terraforminit с аргументом -backend-config:

$ terraform init -backend-config=backend.hcl

Terraform объединит частичную конфигурацию из файла backend.hcl и вашего кода Terraform, чтобы получить полный набор параметров для вашего модуля.

Еще один вариант заключается в применении Terragrunt, инструмента с открытым исходным кодом, который пытается компенсировать то, чего не хватает в Terraform. Terragrunt может помочь избежать дублирования базовых параметров хранилища (имя и регион бакета, имя таблицы DynamoDB) за счет определения их в едином файле и автоматического применения относительного файлового пути модуля в качестве значения key. Пример с Terragrunt будет показан в главе 8.

Изоляция файлов состояния

Благодаря удаленным хранилищам и блокированию совместная работа больше не проблема. Но одна проблема у нас все же остается: изоляция. Когда вы начинаете использовать Terraform, может появиться соблазн описать всю свою инфраструктуру в одном файле или едином наборе файлов в одной папке. Недостаток этого подхода в том, что в одном файле хранится не только код, но и состояние Terraform и, чтобы все сломать, достаточно одной ошибки в любом месте.

Например, при попытке развертывания новой версии своего приложения в среде финального тестирования вы можете нарушить его работу в промышленных ­условиях. Или еще хуже, вы можете повредить весь файл состояния (скажем, из-за отсутствия блокирования либо из-за редкой программной ошибки в Terraform), в результате чего ваша инфраструктура выйдет из строя во всех средах38.