5 принципов, о которых нельзя забывать, когда описываешь инфраструктуру в виде кода
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, помогает быстрее выявлять баги и предупреждать их появление.
Все эти принципы применительно к Terraform разберём на интенсиве
21–22 мая Слёрм проведёт практический интенсив »Terraform Мега». За два дня активного участия вы узнаете:
зачем использовать IaC;
как работает Terraform и как с его помощью управлять инфраструктурой;
как писать инфраструктурный код, который будет сопровождаемым и тестируемым;
как лучше использовать Terraform в корпоративном масштабе.
По окончанию интенсива вы будете уверенно разбираться в управлении инфраструктурой как кодом, а ещё сможете работать с Terraform на продвинутом уровне.
Посмотреть программу и записаться
