мы используем Terraform сильно, и наша рекомендуемая настройка выглядит следующим образом:

мы настоятельно рекомендуем хранить код Terraform для каждой из ваших сред (например, stage, prod, qa) в отдельных наборах шаблонов (и, следовательно, отдельно .tfstate файлы). Это важно для того, чтобы ваши отдельные среды были фактически изолированы друг от друга при внесении изменений. В противном случае, возясь с каким-то кодом в постановке, слишком легко взорвать что-то прод тоже. См.Terraform, VPC, и почему вы хотите файл tfstate на env для красочного обсуждения почему.

поэтому наш типичный макет файла выглядит следующим образом:

stage
  └ main.tf
  └ vars.tf
  └ outputs.tf
prod
  └ main.tf
  └ vars.tf
  └ outputs.tf
global
  └ main.tf
  └ vars.tf
  └ outputs.tf

весь код Terraform для этапа VPC идет в stage папка, весь код для prod VPC переходит в prod папка, и весь код, который живет за пределами VPC (например, пользователи IAM, темы SNS, ведра S3), входит в global папка.

обратите внимание, что по соглашению мы обычно разбиваем наш код Terraform на 3 файла:

• vars.tf: входных переменных.
• outputs.tf: выходных переменных.
• main.tf: фактические ресурсы.

модули

как правило, мы определяем нашу инфраструктуру в двух папках:

1. infrastructure-modules: эта папка содержит небольшие, многоразовые, версионные модули. Думайте о каждом модуле как схема создания отдельного элемента инфраструктуры, например VPC или базы данных.
2. infrastructure-live: эта папка содержит фактическую живую, работающую инфраструктуру, которую она создает путем объединения модулей в infrastructure-modules. Подумайте о коде в этой папке как о реальных домах, которые вы построили из своих чертежей.

A модуль терраформировать - это просто любой набор шаблонов Terraform в папке. Например, у нас может быть папка с именем vpc в infrastructure-modules это определяет все таблицы маршрутов, подсети, шлюзы, ACLs и т. д. Для одного VPC:

infrastructure-modules
  └ vpc
    └ main.tf
    └ vars.tf
    └ outputs.tf

затем мы можем использовать этот модуль в infrastructure-live/stage и infrastructure-live/prod создать этап и prod VPCs. Например, вот что infrastructure-live/stage/main.tf может выглядеть так:

module "stage_vpc" {
  source = "git::git@github.com:gruntwork-io/module-vpc.git//modules/vpc-app?ref=v0.0.4"

  vpc_name = "stage"
  aws_region = "us-east-1"
  num_nat_gateways = 3
  cidr_block = "10.2.0.0/18"
}

чтобы использовать модуль, вы используете module ресурс и точка его source поле для локального пути на жестком диске (например,source = "../infrastructure-modules/vpc") или, как в приведенном выше примере, URL-адрес Git (см. модуль источники). Преимущество URL git заключается в том, что мы можем указать конкретный git sha1 или тег (ref=v0.0.4). Теперь мы не только определяем нашу инфраструктуру как набор небольших модулей, но и можем модифицировать эти модули и тщательно обновлять или откатывать их по мере необходимости.

мы создали ряд многоразовых, протестированных и документированных Пакеты Инфраструктуры для создания VPCs, Docker кластеров, баз данных и так далее, и под капотом, большинство из них просто версионные Модули терраформировать.

государство

когда вы используете Terraform для создания ресурсов (например, экземпляров EC2, баз данных, VPCs), он записывает информацию о том, что он создал в . Чтобы внести изменения в эти ресурсы, всем в вашей команде нужен доступ к этому же .tfstate файл, но вы не должны проверять его в Git (см. вот объяснение, почему).

вместо этого мы рекомендуем хранить .tfstate файлы в S3, включив терраформировать Удаленное Состояние, который будет автоматически нажимать / тянуть последние файлы каждый раз, когда вы запускаете Terraform. Убедитесь, что включить версионирование в вашем ведре S3, чтобы вы могли откатиться к старшему .tfstate файлы на случай, если вы каким-то образом испортите последнюю версию. Однако, важное замечание: Terraform не обеспечивает блокировку. Итак, если два члена команды работают terraform apply в то же время на том же .tfstate файл, они могут в конечном итоге перезаписывать изменения друг друга.

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

более дальнеишее чтение

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

Update: всестороннее руководство по Terraform блог серии сообщений стало настолько популярным, что мы расширили его в книгу под названием Terraform: Up & Running!

С remote config, теперь это стало намного проще:

terraform remote config -backend-config="bucket=<s3_bucket_to_store_tfstate>" -backend-config="key=terraform.tfstate" -backend=s3
terraform remote pull
terraform apply
terraform remote push

посмотреть docs для сведения.

более подробно освещено @Yevgeny Brikman, но конкретно отвечает на вопросы OP:

What's the best practice for actually managing the terraform files and state?

используйте git для файлов TF. Но не проверяйте файлы состояния (т. е. tfstate). Вместо этого используйте Terragrunt для синхронизации / блокировки файлов состояния в S3.

but do I commit tfstate as well? 

нет.

Should that reside somewhere like S3?

да

Я знаю, что здесь много ответов, но мой подход совсем другой.

⁃   Modules
⁃   Environment management 
⁃   Separation of duties

модули

1. создание модулей для логических коллекций ресурсов. Пример: Если ваша цель-развернуть API, который требует DB, Ha VMs, autoscaling, DNS, PubSub и object storage, то все эти ресурсы должны быть шаблонированы в одном модуле.
2. избегайте создания модулей, использующих один ресурс. Это может и было сделано и многие модули в реестре делают это, но это практика, которая помогает с доступностью ресурсов, а не с оркестровкой инфраструктуры. Пример: модуль для AWS EC2 помогает пользователю получить доступ к EC2, делая сложные конфигурации более простыми для вызова, но модуль, как пример в 1. помогает пользователю при организации инфраструктуры приложения, компонента или службы.
   1. избегайте объявлений ресурсов в рабочей области. Это больше о сохранении кода аккуратный и организованный. Поскольку модули легко версируются, у вас больше контроля над выпусками.

управления окружающей средой

IaC сделал процесс SDLC актуальным для управления инфраструктурой, и это не нормально ожидать, чтобы иметь инфраструктуру разработки, а также среды разработки приложений.

1. не используйте папки для управления средами IaC. Это приводит к дрейфу, поскольку нет общего шаблон для вашей инфраструктуры.
2. используйте одно рабочее пространство и переменные для управления спецификациями среды. Пример: Напишите свои модули так, чтобы при изменении переменной среды (var.этап популярен) план изменяет для приспособления ваших требований. Как правило, среды должны меняться как можно меньше с количеством, экспозицией и емкостью, как правило, являются переменными конфигурациями. Dev может развернуть 1 VM с 1 ядром и 1GB RAM в частной топологии, но производство может будьте 3 VMs с 2 ядрами и 4GB RAM с дополнительной публичной топологией. Конечно, у вас может быть больше вариантов: dev может запускать процесс базы данных на том же сервере, что и приложение, для экономии затрат, но производство может иметь выделенный экземпляр БД. Все это можно управлять путем изменения одной переменной, троичных операторов и интерполяции.

разделение обязанностей

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

1. Разбейте свою инфраструктуру по обязанностям, обязанностям или командам. Пример: централизованный ИТ-контроль базовых общих служб(виртуальных сетей, подсетей, общедоступных IP-адресов, групп журналов, ресурсов управления, нескольких арендованных DBs, общих ключей и т.д.) в то время как команда API контролирует только ресурсы, необходимые для их службы (VMs, LBs, PubSub и т. д.), и потребляет центральные свои службы Через Источник данных и удаленное состояние поиски.
   1. управление доступом команды. Пример: Central он может иметь права администратора, но команда API имеет доступ только к ограниченному набору общедоступных облачных API.

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

эта стратегия проводит параллели со стратегией нескольких аккаунтов AWS. Have a read for more информация.

CI / CD

Это отдельная тема, но Terraform работает очень хорошо в хорошем конвейере. Самая распространенная ошибка здесь-рассматривать CI как серебряную пулю. Технически Terraform должен предоставлять инфраструктуру только на этапах сборочного конвейера. Это будет отдельно от того, что происходит на этапах CI, где обычно проверяются и тестируются шаблоны.

N. B. написано на мобильном телефоне, поэтому, пожалуйста, извините за любые ошибки.