Рекомендации по использованию Terraform

Question

Я сейчас перехожу на нашу инфраструктуру в терраформу. Какова наилучшая практика для управления файлами террароформ и состояния? Я понимаю, что это инфраструктура как код, и я буду передавать свои .tf-файлы в git, но я также могу выполнить tfstate? Должно ли это находиться где-то как S3? Я бы хотел, чтобы в конечном итоге CI справился со всем этим, но это далеко потянуло и требует от меня разобраться в движущихся частях файлов.

Я действительно просто смотрел, как люди там на самом деле использовать этот тип материала в производстве

Answer 1

Я также в состоянии миграции существующей инфраструктуры AWS терраформировать так будет стремиться обновить ответ, как я развиваться.

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

.tfstate файлы

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

Это можно подтвердить, посмотрев на Terraform .gitignore.

управление Разработчиком

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

1. Основание общего ОМИ, которое включает в себя повторно используемые модули, например. кукольный.
2. Основная инфраструктура, предоставляемая DevOps с использованием Terraform.
3. Разработчики меняют конфигурацию Terraform в Git по мере необходимости (количество экземпляров, новый VPC, добавление региона/зоны доступности и т. Д.).
4. Конфигурация Git нажата и запрос на тяну, представленный для проверки, проверен членом команды DevOps.
5. В случае одобрения, вызывает webhook к CI для построения и развертывания (не знаете, как разметить несколько сред в это время)

Edit 1 - Обновленная информация о текущем состоянии

С начала этот ответ у меня есть написал много кода TF и ​​чувствовал себя более комфортно в нашем положении дел. У нас есть проблемы с ошибками и ограничениями, но я согласен, что это характерно для использования нового, быстро меняющегося программного обеспечения.

Layout

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

Модули

Следующий шаг должен был создать единый репозиторий для хранения наших модулей терраформировать. Наша структура высшего уровня реж для модулей выглядит следующим образом:

tree -L 1 . . ├── README.md ├── aws-asg ├── aws-ec2 ├── aws-elb ├── aws-rds ├── aws-sg ├── aws-vpc └── templates

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

Клей

У нас есть второе хранилище с нашей glue, что делает использование модулей, упомянутых выше. Она выложена в соответствии с нашей систематики документа:

. ├── README.md ├── clientA │   ├── eu-west-1 │   │   └── dev │   └── us-east-1 │   └── dev ├── clientB │   ├── eu-west-1 │   │   ├── dev │   │   ├── ec2-keys.tf │   │   ├── prod │   │   └── terraform.tfstate │   ├── iam.tf │   ├── terraform.tfstate │   └── terraform.tfstate.backup └── clientC ├── eu-west-1 │   ├── aws.tf │   ├── dev │   ├── iam-roles.tf │   ├── ec2-keys.tf │   ├── prod │   ├── stg │   └── terraform.tfstate └── iam.tf

Внутри уровня клиента мы имеем AWS счета конкретных .tf файлов, что предоставление глобальных ресурсов (например, IAM ролей); далее - уровень региона с открытыми ключами EC2 SSH; Наконец, в нашей среде (dev, stg, prod и т. Д.) Хранятся наши настройки VPC, создание экземпляров и пиринговые соединения и т. Д.

Боковое примечание: Как вы можете видеть, я иду против собственного совета, поддерживая terraform.tfstate в git. Это временная мера, пока я не перейду на S3, но мне подходит, поскольку я в настоящий момент единственный разработчик.

Следующие шаги

Это по-прежнему ручной процесс, а не в Дженкинс, но пока мы портирование довольно большой, сложной инфраструктуры и до сих пор так хорошо. Как я уже сказал, мало ошибок, но все идет хорошо!

Edit 2 - Изменения

Это было почти год, так как я написал этот первоначальный ответ и состояние как терраформировать и сам существенно изменились. Теперь я нахожусь на новой позиции, используя Terraform для управления кластером Azure, а Terraform теперь - v0.10.7.

государственный

Люди неоднократно говорили мне государство должно не идти в Git - и они правильны. Мы использовали это как временную меру с командой из двух человек, которая полагалась на коммуникацию и дисциплину разработчика. С более крупной распределенной командой мы теперь полностью задействуем дистанционное состояние в S3 с locking, предоставляемое DynamoDB. В идеале это будет перенесено в консул, теперь это v1.0, чтобы сократить поставщиков перекрестных облаков.

Модули

Ранее мы создали и использовали внутренние модули. Это все еще так, но с появлением и ростом Terraform registry мы стараемся использовать их как минимум как базу.

Файловая структура

Новое положение имеет гораздо более простую таксономию с только две infx среды - dev и prod. Каждый из них имеет свои собственные переменные и выходы, повторно используя наши модули, созданные выше. Поставщик remote_state также помогает распределять ресурсы созданных ресурсов между средами. Наш сценарий - это субдомены в разных группах ресурсов Azure для глобального домена TLD.

├── main.tf ├── dev │   ├── main.tf │   ├── output.tf │   └── variables.tf └── prod ├── main.tf ├── output.tf └── variables.tf

Планирование

Опять с дополнительными проблемами распределенной команды, теперь мы всегда сохранять наш вывод команды terraform plan. Мы можем проверять и знать, что будет работать без риска каких-либо изменений между стадиями plan и apply (хотя блокировка помогает в этом). Не забудьте удалить этот файл плана, поскольку он потенциально может содержать текстовые «секретные» переменные.

В целом мы очень довольны Terraform и продолжаем учиться и совершенствовать новые функции.

Answer 2

С 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 для деталей.

Answer 3

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

расположение файла

Мы рекомендуем хранить код терраформировать для каждого из сред (например, стадии, прод, Qa) в отдельных наборах шаблоны (и, следовательно, отдельные файлы .tfstate). Это важно, так что ваши отдельные среды на самом деле изолированы друг от друга при внесении изменений. В противном случае, в то время как возиться с некоторым кодом в стадии постановки, слишком легко взорвать что-то в prod тоже. См. Terraform, VPC, and why you want a tfstate file per 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, весь код для прода VPC идет в папку prod, и все код, который живет за пределами VPC (например, пользователи IAM, темы SNS, ведра S3), входит в папку global.

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

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

Модули

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

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

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

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

Затем мы можем использовать этот модуль в infrastructure-live/stage и infrastructure-live/prod создать сценические и prod VPC. Например, вот что 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 (см. module sources). Преимущество URL Git заключается в том, что мы можем указать конкретный git sha1 или тег (ref=v0.0.4). Теперь мы не только определяем нашу инфраструктуру как кучу небольших модулей, но и можем модифицировать эти модули и тщательно обновлять или откатываться по мере необходимости.

Мы создали несколько многоразовых, протестированных и задокументированных Infrastructure Packages для создания VPC, кластеров докеров, баз данных и т. Д., А под капотом большинство из них - только версии версий Terraform.

государственный

При использовании терраформировать создавать ресурсы (например, EC2 экземпляры, базы данных, VPCs), он записывает информацию о том, что он создал в .tfstate файле. Чтобы внести изменения в эти ресурсы, всем в вашей команде нужен доступ к этому же файлу .tfstate, но вы НЕ должны его проверять в Git (см. here for an explanation why).

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

Для решения этой проблемы мы создали инструмент с открытым исходным кодом Terragrunt, который представляет собой тонкую оболочку для Terraform, которая использует Amazon DynamoDB для обеспечения блокировки (которая должна быть полностью бесплатной для большинства команд). За дополнительной информацией обращайтесь к Add Automatic Remote State Locking and Configuration to Terraform with Terragrunt.

Дальнейшее чтение

Мы только начали серию постов в блоге под названием A Comprehensive Guide to Terraform, который подробно описывает все лучшие практики, мы узнали для использования терраформировать в реальном мире.

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

Answer 4

Покрытые более углубленно @Yevgeny Брикман но конкретно отвечая на вопросы Op в:

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

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

but do I commit tfstate as well? 

No.

Should that reside somewhere like S3? 

Да