Terraform: 5 важных рекомендаций по настройке

Terraform — одна из лучших утилит, в которой удобно управлять конфигурациями облачной инфраструктуры. Этот инструмент только набирает популярность: Salt, Ansible и Puppet используют чаще, но это скоро поменяется. Ловите список важных рекомендаций по настройке Terraform.

У Terraform открытый исходный код, поэтому его развивает большое сообщество разработчиков. Конечно, эта утилита полностью не заменит Salt, Ansible или Puppet,  но она займёт своё место в инструментарии DevOps-инженера.

Два основных преимущества Terraform:

  • Портативность. Одна утилита и один язык применяется для описания облачной инфраструктуры с любым поставщиком услуг. Будь-то Google Cloud, AWS или OpenStack. Смена поставщика облачного хостинга больше не проблема.
  • Простота полноценного запуска приложений. Например, на ваших серверах Amazon запущены Docker контейнеры под управлением Kubernetes, в которых работает много приложений. Всем этим с легкостью можно управлять с помощью одного инструмента.

Наши рекомендации помогут логично и удобно настроить Terraform. Советы подойдут всем вне зависимости от размера команды или характера проекта. 

1. Определите состав команды

При организации кода Terraform, важно понимать: 

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

Подобные вопросы и ответы на них влияют на несколько моментов. В идеале вы должны иметь удалённый доступ (Remote State) и возможность блокировки (State Locking) независимо от размера команды сейчас или в будущем. Remote State — гарантирует, что ваш ноутбук — не единственное место, где сможет работать ваш Terraform. State Locking гарантирует, что только один человек за раз может изменить инфраструктуру.

2. Разделите модули Terraform на частые и одноразовые

Модуль Terraform позволяет вам создавать логическую абстракцию поверх некоторого набора ресурсов. Другими словами, модуль позволяет вам группировать ресурсы вместе и повторно использовать эту группу позже, возможно, много раз.

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

Разделите модули в зависимости от частоты их использования или изменения. Например, группы автомасштабирования, целевые группы, балансировщики нагрузки и другие. Все они могут изменяться при каждом развертывании. Поэтому отделение их от одноразовых шаблонов упростит проверку кода и ускорит настройку.

3. Определение версий Terraform

Команды часто думают, что версия Terraform (которую они используют для написания кода сегодня) никогда не изменится. Или предполагают, что внешние модули не изменятся. Это приводит к проблемам, которые можно будет увидеть только через несколько недель. Что делать?

Убедитесь, что вы определили версии везде, где это возможно: 

  • в основном блоке Terraform, 
  • в блоке поставщика, 
  • в блоке модуля и подобное. 

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

4. Автоматизация всего

Автоматизация на каждом этапе процесса развёртывания позволяет избежать проблем ещё до того, как они возникнут. Используйте хуки предварительной фиксации git, чтобы запустить terraform fmt и terraform validate перед фиксацией кода. Они гарантируют, что перед фиксацией код буде правильно отформатирован и синтаксически верен. Залейте этот файл предварительной фиксации в репозиторий, и все в вашей команде смогут воспользоваться такой же автоматизацией. Этот важный момент контроля качества, что может существенно сэкономить время на протяжении развития проекта.

Все современные инструменты развёртывания имеют процессы CI. Вы можете использовать их для запуска SAST и инструментов модульного тестирования при отправке кода в источник. Checkov может тестировать код Terraform на безопасность и соответствие. Он также может создавать пользовательские проверки для конкретных соглашений организации. Добавьте эти инструменты модульного тестирования в свой CI, чтобы улучшить качество и надёжность кода.

5. Сделайте README

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

Как минимум, ваш README должен: 

  • содержать шаги по инициализации правильной среды Terraform на ваших рабочих станциях (Linux, Windows, Mac и других), включая версию Terraform для установки. 
  • указывать необходимые зависимости (Checkov, TerraGrunt и другие) с версиями и любыми удобными псевдонимами Linux, которые использует ваша команда (некоторые люди любят определять их tff как сокращенные terraform fmt). 
  • содержать стратегию и процесс проверки ветвления и PR, соглашения об именах и стандарты маркировки ресурсов.

Есть проверочный вопрос на этот счёт. Если завтра к вашей команде присоединится новый сотрудник, достаточно ли README, чтобы он понял что и как делать? 

Надеемся, эти советы помогут вам не совершать распространённых ошибок. Не стесняйтесь делиться своими мыслями по этому поводу и вы. Ждём ваших комментариев.

Какие навыки кроме Terraform нужны, чтобы стать DevOps-инженером?
Чтобы узнать, жмите сюда.

Добавить комментарий

Спасибо, что поделились