Infrastructure as Code — это подход, который подразумевает описание инфраструктуры в виде коде с его последующим применением для внесения необходимых изменений. Но, как именно писать код, IaC не говорит, только даёт инструменты. Один из таких инструментов — Terraform.

21 мая в Слёрм пройдёт практический интенсив «Terraform Мега». Мы пообщались с его автором Павлом Селиванов, архитектором Yandex.Cloud. Он рассказал, каких принципов нужно придерживаться, когда описываешь инфраструктуру, чтобы на выходе не получить непонятный и плохо поддерживаемый код. 

№1. Читаемость

Инфраструктурный код должен быть читаем. Тогда ваши коллеги смогут легко в нём разобраться, а при необходимости — дописать или протестировать. Это вроде элементарная вещь, но о ней часто забывают, и на выходе появляется «write only code» — код, который можно только написать, но нельзя прочитать. Даже его автор спустя пару дней вряд ли сможет понять, что написал, и разобраться, как это всё работает. 

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

№2. Стиль написания

Нужно придерживаться определённого стиля написания кода. Например, длина строки кода должна быть в пределах 80-120 символов. Если строки очень длинные, редактор начинает их переносить. Переносы рушат общий вид и мешают пониманию кода. Приходится тратить много времени, чтобы просто разобраться, где началась и где закончилась строка. 

Хорошо, когда проверка написания кода автоматизирована. Для этого можно использовать пайплайн CI/CD. Одним из шагов такого пайплайна должен быть Lint — процесс статистического анализа написанного, который помогает выявить потенциальные проблемы ещё до того, как код будет применен. 

№3. Работа с репозиториями

Работайте с репозиториями как разработчик. Важно вести разработку в новых ветках, привязывать ветки к задачам, делать ревью того, что уже было написано, перед внесением изменений отправлять Pull Request и т.д.

С точки зрения специалиста сопровождения перечисленные действия могут показаться лишними — нормальная практика, когда люди просто приходят и начинают коммитить. Если у вас небольшая команда, это ещё может работать. Хотя и в таком случае будет сложно понять, кто, когда, зачем и какие исправления вносил. По мере развития проекта подобные практики будут всё больше усложнять понимание происходящего и мешать работе. Поэтому стоит поучиться тому, как разработка работает с репозиториями. 

№4. Автоматизация

Инструменты Infrastructure as Code так или иначе ассоциируются с DevOps. А DevOps — специалисты, которые не только занимаются сопровождением, но и помогают разработчикам работать: настраивают пайплайны, автоматизируют запуск тестов и т.д. Всё это тоже относится к IaC.

В Infrastructure as Code должна применяться автоматизация: правила Lint, тестирование, автоматические релизы и др. 

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

Когда всё находится в репозитории и контролируется автоматическим CI/CD-пайплайном, мы всегда можем посмотреть, когда был запущен пайплайн и как он отработал. Можем контролировать параллельное выполнение пайплайнов, выявлять причины сбоев, быстро находить ошибки и многое другое. 

№5. Тестирование

Часто от специалистов сопровождения можно слышать, что они никак не тестируют код или просто сначала запускают его где-то на dev. Это не самый удачный вариант тестирования, потому что он не даёт никаких гарантий, что dev соответствует prod. В случае с Ansible или другими инструментами конфигурации стандартное тестирование выглядит примерно так: 

• запустили тест на dev;

• на dev прокатилось, но упало с ошибкой;

• исправили эту ошибку;

• ещё раз тест не запустили, потому что dev уже находится в том состоянии, к которому его пытались привести.

Кажется, что ошибку поправили, и можно катить на prod. Что случится с prod? Это всегда вопрос везения — попали или не попали, угадали или не угадали. Если где-то на середине, что-то снова упадёт, ошибку поправят и всё перезапустят.

Но инфраструктурный код можно и нужно тестировать. При этом часто даже, если специалисты знают о разных способах тестирования, они все равно не могут ими воспользоваться. Причина — роли Ansible или файлы Terraform написаны без изначального фокуса на то, что их нужно будет как-то тестировать. 

Когда разработчик пишет код, он задумывается о том, что его ещё нужно протестировать. И, соответственно, прежде чем начать писать код, планирует, как будет его тестировать. Нетестируемый код — это код низкого качества. 

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

Пара слов про автоматизацию напоследок

Распространённая практика в случае работы с Ansible — даже если что-то и можно протестировать, автоматизации никакой нет. Обычно это история, когда кто-то создаёт виртуалку, берёт какую-то роль, написанную коллегами, и запускает её. Дальше думает: нужно дописать вот это и это. Дописывает и снова запускает на виртуалке. Затем понимает, что нужны ещё какие-то изменения, и что текущая виртуалка уже приведена в какое-то состояние, поэтому её нужно убить, поднять новую виртуалку и прокатить по ней роль. А если что-то не будет работать, этот алгоритм придётся повторять до устранения всех ошибок. 

Обычно срабатывает человеческий фактор, и спустя n-ное количество повторов удалять виртуалку и создавать снова становится лень. Кажется, на этот раз всё точно работает как надо, поэтому можно замёржить изменения и прокатить по prod. Но на деле ошибки все равно могут возникать, поэтому и нужна автоматизация. Она работает на автоматических пайплайнах и сигнализирует о новых Pull Request, помогает быстрее выявлять баги и предупреждать их появление.