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

•Изоляция файлов состояния. При изменении инфраструктуры рекомендуется изолировать разные окружения. Например, при правке состояния в среде предварительного или финального тестирования следует убедиться, что это никак не навредит промышленной системе. Но как изолировать изменения, если вся инфраструктура описана в одном и том же файле состояния Terraform?

В следующих разделах мы подробно исследуем все эти проблемы и посмотрим, как их решить.

Общее хранилище для файлов состояния

Самый распространенный метод, который позволяет нескольким членам команды работать с общим набором файлов, заключается в использовании системы управления версиями (например, Git). Хотя ваш код Terraform точно должен храниться именно таким образом, применение того же подхода к состоянию Terraform — плохая идея по нескольким причинам.

•Человеческий фактор. Вы можете легко забыть загрузить последние изменения из системы управления версиями перед запуском Terraform или сохранить свои собственные обновления постфактум. Рано или поздно кто-то в вашей команде случайно запустит Terraform с устаревшими файлами состояния, что приведет к откату или дублированию уже развернутых ресурсов.

• Блокирование. Большинство систем управления версиями не предоставляют никаких средств блокирования, которые могли бы предотвратить одновременное выполнение terraformapply двумя разными членами команды.

•Наличие конфиденциальных данных. Все данные в файлах состояния Terraform хранятся в виде обычного текста. Это чревато проблемами, поскольку некоторым ресурсам Terraform необходимо хранить чувствительные данные. Например, если вы создаете базу данных с помощью ресурса aws_db_instance, Terraform сохранит имя пользователя и пароль к ней в файле состояния в открытом виде. Открытое хранение конфиденциальных данных где бы то ни было, включая систему управления версиями, — плохая идея. По состоянию на май 2019 года сообщество Terraform обсуждает открытую заявку (http://bit.ly/33gqaVe), созданную по этому поводу, хотя для решения данной проблемы есть обходные пути, которые мы вскоре обсудим.

Вместо системы управления версиями для совместного управления файлами состоя­ния лучше использовать удаленные хранилища, поддержка которых встроена в Terraform. Хранилище определяет то, как Terraform загружает и сохраняет свое состояние. По умолчанию для этого применяется локальное хранилище, с которым вы работали все это время. Оно хранит файлы состояния на вашем локальном диске. Но поддерживаются также удаленные хранилища с возможностью совместного доступа. Среди них можно выделить Amazon S3, Azure Storage, Google Cloud Storage и такие продукты, как Terraform Cloud, Terraform Pro и Terraform Enterprise от HashiCorp.

Удаленные хранилища решают все три проблемы, перечисленные выше.

•Человеческий фактор. После конфигурации удаленного хранилища Terraform будет автоматически загружать из него файл состояния при каждом выполнении команд plan и apply и аналогично сохранять его туда после выполнения apply. Таким образом, возможность ручной ошибки исключается.

• Блокирование. Большинство удаленных хранилищ имеют встроенную поддержку блокирования. При выполнении terraformapply Terraform автоматически устанавливает блокировку. Если в этот момент данную команду выполняет кто-то другой, блокировка уже установлена и вам придется подождать. Команду apply можно ввести с параметром -lock-timeout=. Так Terraform будет знать, сколько времени нужно ждать снятия блокировки (например, если указать -lock-timeout=10m, ожидание будет продолжаться десять минут).

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

Если вы используете Terraform в связке с AWS, лучшим выбором в качестве удаленного хранилища будет S3, управляемый сервис хранения файлов от Amazon. Этому есть несколько причин.

• Это управляемый сервис, поэтому для его использования не нужно развертывать и обслуживать дополнительную инфраструктуру.