Защитите свою инфраструктуру, автоматизируя ее доставку
Terraform - фантастический инструмент для управления вашей облачной инфраструктурой, особенно если ваши активы размещены у нескольких облачных провайдеров.
В зависимости от масштаба вашей организации вы обычно начинаете с запуска этих команд Terraform локально, имея свой код в репозитории Git, а ваше удаленное состояние - в надлежащем общем онлайн-бэкэнде. Все идет хорошо, пока вы не поймете, что наличие центральной кодовой базы - это действительно хорошо, но для запуска этих команд Terraform необходимо использовать ноутбук для разработчиков.
Сейчас разработчики используют CI для разработки кода и приложений. Но как насчет Terraform? Как применить методы непрерывной интеграции и доставки к вашему коду Terraform?
В этой статье мы продемонстрируем, как построить полный конвейер Terraform с помощью GitLab CI.
Реализация конвейера
В этом конвейере мы рассмотрим 3 этапа:
- Проверка выполнит некоторые проверки качества кода.
- План создает и сохраняет план выполнения Terraform для рассмотрения членом команды.
- Применить, когда член команды вручную запускает задание по применению изменений в инфраструктуре, если проверка плана в порядке. Кроме того, этот этап будет происходить только в главной ветке.
Мы также можем рассмотреть дополнительный этап: возврат последнего примененного набора изменений. Но поскольку эти операции могут быть разумными, я лично держу их подальше от CI.
Настраивать
Чтобы реализовать этот конвейер, вам нужно настроить некоторые секреты. Большинство людей используют удаленную корзину для хранения состояния Terraform. Для доступа к этому хранилищу требуются определенные учетные данные в зависимости от вашего облачного провайдера.
Давайте продемонстрируем использование Google Cloud Platform и сегмента хранилища.
- Сначала создайте новую учетную запись службы для GitLab и сохраните файл учетных данных.
- Предоставьте этому сервисному аккаунту соответствующие права в сегменте Terraform (владелец хранилища).
- Настройте учетные данные учетной записи службы как файловую переменную в настройках CI / CD вашего проекта GitLab.
Этот процесс аналогичен, если вы используете AWS: вам нужно настроить AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY переменные среды с учетными данными пользователя с соответствующей областью действия.
Инициализировать конвейер GitLab CI
Создайте .gitlab-ci.yml файл в корне проекта со следующим содержимым:
Это базовое задание будет унаследовано всеми последующими заданиями и введет учетные данные. Мы берем машину за запуск нашего конвейера только в том случае, если файлы Terraform изменяются в контексте запроса на слияние или нажатия на ветку.
Статическая проверка кода Terraform
Первое, что нам нужно, это обеспечить отправляемый код:
- Правильно отформатирован в соответствии с командой форматирования Terraform.
- Нет синтаксических ошибок благодаря команде проверки.
Эти проверки будут первыми работами в нашем конвейере. Они запускаются параллельно, чтобы сэкономить время. Обратите внимание, что команда validate требует инициализации Terraform.
Создать план
Затем мы хотим создать план Terraform. Нам нужно сначала инициализировать Terraform, а затем, если вы используете функцию рабочего пространства, выбрать подходящее рабочее пространство. Наконец, мы вызываем команду плана с необязательными tfvars файлами, если это необходимо.
Здесь происходит несколько интересных вещей:
- Сначала мы сохраняем план в виде файла, чтобы передать его команде применения на следующем этапе. Это единственный способ быть абсолютно уверенным в том, что то, что мы планируем, будет применено к нашей инфраструктуре.
- По той же причине мы сохраняем папку
.terraform, чтобы все модули провайдера были в той же версии, что и та, которая использовалась для создания плана. В Terraform 0.14 файл блокировки зависимостей решит эту проблему более элегантно. - Мы сохраняем файлы с помощью ключевого слова артефактов GitLab CI, чтобы сделать их доступными для заданий на более позднем этапе.
Применение изменений
Последнее, что нужно сделать, - это применить изменения.
Как мы объясняли ранее, мы хотим, чтобы этот шаг выполнялся вручную после проверки плана. Причина в том, что изменения инфраструктуры могут быть критическими или разрушительными, а автоматическая проверка без участия человека может оказаться невозможной.
Мы возвращаем наш сохраненный план и .terraform папку с предыдущего этапа и просто запускаем команду Terraform в неинтерактивном режиме. Это задание создается только для основной ветки.
Идти дальше
Если хотите, вы можете реализовать ключевые метрики из плана Terraform прямо в графическом интерфейсе GitLab с помощью интеграции Terraform MR.
Или вы можете добавить этап тестирования для своей инфраструктуры, реализовав несколько тестовых примеров Terratest, особенно в среде промежуточной инфраструктуры, перед развертыванием в производственной среде.
Заключение
Даже если автоматизация операций Terraform, возможно, менее модна, чем автоматизация развертывания приложений, она необходима для защиты вашего процесса и сохранения репозитория IaaC как уникального источника истины. Поскольку эту автоматизацию можно быстро и легко реализовать, нет оправдания, чтобы не сделать это сейчас!
