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

мы настоятельно рекомендуем хранить код Terraform для каждой из ваших сред (например, stage, prod, qa) в отдельных наборах шаблонов (и, следовательно, отдельно .tfstate файлы). Это важно для того, чтобы ваши отдельные среды были фактически изолированы друг от друга при внесении изменений. В противном случае, когда вы возитесь с каким-то кодом в staging, его слишком легко взорвать что-то в прод тоже. Смотрите 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 который определяет все таблицы маршрутов, подсети, шлюзы, ACL и т. д. Для одного 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") или, как в примере выше, git URL (см. модуль источники). Преимущество git URL заключается в том, что мы можем указать конкретный git sha1 или тег (ref=v0.0.4). Теперь мы не только определяем нашу инфраструктуру как набор небольших модулей, но и можем верифицировать эти модули и тщательно обновлять или откатывать их по мере необходимости.

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

State

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

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

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

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

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

Update: Полное руководство по Terraform blog post series стало настолько популярным, что мы расширили его в книгу под названием Терраформировать: Работает!

С 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 для сведения.

более подробно освещено @Евгением Брикманом, но конкретно отвечая на вопросы ОП:

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. используйте одну рабочую область и переменные для управления спецификациями среды. Пример: писать свои модули так, чтобы при изменении переменной среды (ВАР.этап популярен) план изменяется в соответствии с вашими требованиями. Как правило, окружающая среда должна изменяться как можно меньше с количеством, экспозицией и емкостью, обычно являющимися переменными конфигурациями. Dev может развернуть 1 виртуальную машину с 1 ядром и 1 ГБ оперативной памяти в частной топологии, но производство может будьте 3 виртуальными машинами с 2 ядрами и 4 ГБ оперативной памяти с дополнительной публичной топологией. Конечно, у вас может быть больше вариантов: dev может запускать процесс базы данных на том же сервере, что и приложение, чтобы сэкономить затраты, но производство может иметь выделенный экземпляр БД. Все это можно управлять путем изменения одной переменной, тернарных операторов и интерполяции.

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

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

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

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

эта стратегия проводит параллели со стратегией мультисчета AWS. Есть читать для большего информация.

CI / CD

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

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