Я работал над многими проектами терраформирования. Для всех этих проектов мне приходилось управлять многими средами и иногда дублировать код или модули для каждой среды.

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

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

Почему именно контейнер?

На сайте docker.com вы можете прочитать: «Контейнер — это стандартная единица программного обеспечения, которая упаковывает код и все его зависимости, чтобы приложение быстро и надежно запускалось из одной вычислительной среды в другую».

Подобно контейнеру, проект terraform представляет собой единицу, которая упаковывает код terraform, объявляющий группу ресурсов.

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

Подобно контейнеру, ваш проект terraform должен быть надежным в разных средах. Эта статья в основном посвящена последнему пункту. Рассмотрите проект терраформирования как единицу упакованных ресурсов, которые вы можете развернуть в среде. Как и контейнер, ваш проект terraform должен быть «независим от среды», и все спецификации должны передаваться через переменные среды.

Действительный стандарт

В книге Terraform: Up & Running: Write Infrastructure as Code, написанной знаменитым Евгением Брикманом, вы можете увидеть такую ​​архитектуру:

Вы можете увидеть три среды. Два из них, stage и prod, почти одинаковы:

  • vpc
  • сервисы: фронтенд-приложение, бэкенд-приложение
  • хранилище данных: mysql, redis

Эти три группы логических ресурсов можно рассматривать как часть стека. Кусок пакетных групповых ресурсов для vpc, бэкэнд для хранения данных. В большинстве случаев между vpc сцены и производства существует только одно основное различие: CIDR и, возможно, имя.

Итак, вы бы сделали то же самое для контейнера? Вы бы создали контейнер для подготовки и один для производства, если единственная разница заключается в параметре?

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

Как развернуть стек в качестве контейнера?

Стек VPC можно рассматривать как контейнер с двумя переменными среды и развертывать путем внедрения:

  • CIDR vpc
  • Имя вкк

а затем мы можем объявить только один стек VPC и развернуть его с двумя файлами переменных среды для каждой целевой среды.

давайте посмотрим на пример структуры:

Вместо того, чтобы разделять терраформы по средам, мы разделяем наши терраформы по проектам и стекам.

VPC представляет собой стек, состоящий из:

  • backends/‹env›.tf : определение бэкенда состояния терраформирования
  • tfvars‹env›.tf : переменные окружения
  • variable.tf : переменные окружения
  • backend.tf : определение структуры бэкенда
  • main.tf : файлы terraform, содержащие определение vpc.
  • провайдеры.tf : определение провайдеров terraform

бэкенды/prod.tf :

backend.tf :

tfvars/prod.tf:

variables.tf :

main.tf :

провайдеры.tf

Теперь вы можете запустить свой проект terraform:

terraform init -backend-config=backends/prod.tfvars

и применить:

terraform apply -var-file=tfvars/prod.tfvars

Теперь, если вы хотите развернуть свой vpc в другой учетной записи, вам нужно добавить всего два файла: backends/‹env›.tf и tfvars/‹env›.tf.

Как может выглядеть ваш проект терраформирования:

Разделить структуру терраформа

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

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

Каждый из ваших стеков должен быть максимально независимым со своим собственным состоянием терраформирования.

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

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

  • Улучшенная изоляция ошибок
  • Устранение привязки к поставщику или технологии
  • Простота понимания
  • Меньшие и более быстрые развертывания
  • Масштабируемость

Например, ваш проект terraform не должен управлять вашими пользователями, группами и ролями iam в вашем кластере kubernetes. Между ними нет логической связи.

Заключение

Между архитектурой микросервисов и структурой проекта terraform есть много общего.

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