Я работал над многими проектами терраформирования. Для всех этих проектов мне приходилось управлять многими средами и иногда дублировать код или модули для каждой среды.
Конечно, вы можете факторизовать модули 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 есть много общего.
Ваша инфраструктура должна быть разделена на небольшие группы ресурсов и максимально изолирована от других групп ресурсов. Каждая из вашей группы ресурсов должна иметь возможность быть развернутой в каждой среде, а не жестко запрограммирована в каждой среде.