Infrastructure as Code — это подход, который подразумевает описание инфраструктуры в виде коде с его последующим применением для внесения необходимых изменений. Но, как именно писать код, IaC не говорит, только даёт инструменты. Один из таких инструментов — Terraform. 21 мая в Слёрм пройдёт практический интенсив «Terraform Мега». Мы пообщались с его автором Павлом Селиванов, архитектором Yandex.Cloud. Он рассказал, каких принципов нужно придерживаться, когда описываешь инфраструктуру, чтобы на выходе не получить непонятный и плохо поддерживаемый код.  Инфраструктурный код должен быть читаем. Тогда ваши коллеги смогут легко в нём разобраться, а при необходимости — дописать или протестировать. Это вроде элементарная вещь, но о ней часто забывают, и на выходе появляется «write only code» — код, который можно только написать, но нельзя прочитать. Даже его автор спустя пару дней вряд ли сможет понять, что написал, и разобраться, как это всё работает.  Пример хорошей практики — выносить все переменные в отдельный файл. Это удобно, потому что их не приходится искать по всему коду. Вы просто открываете файл и сразу находите то, что нужно.  Нужно придерживаться определённого стиля написания кода. Например, длина строки кода должна быть в пределах 80-120 символов. Если строки очень длинные, редактор начинает их переносить. Переносы рушат общий вид и мешают пониманию кода. Приходится тратить много времени, чтобы просто разобраться, где началась и где закончилась строка.  Хорошо, когда проверка написания кода автоматизирована. Для этого можно использовать пайплайн CI/CD. Одним из шагов такого пайплайна должен быть Lint — процесс статистического анализа написанного, который помогает выявить потенциальные проблемы ещё до того, как код будет применен.  Работайте с репозиториями как разработчик. Важно вести разработку в новых ветках, привязывать ветки к задачам, делать ревью того, что уже было написано, перед внесением изменений отправлять Pull Request и т.д. С точки зрения специалиста сопровождения перечисленные действия могут показаться лишними — нормальная практика, когда люди просто приходят и начинают коммитить. Если у вас небольшая команда, это ещё может работать. Хотя и в таком случае будет сложно понять, кто, когда, зачем и какие исправления вносил. По мере развития проекта подобные практики будут всё больше усложнять понимание происходящего и мешать работе. Поэтому стоит поучиться тому, как разработка работает с репозиториями.  Инструменты Infrastructure as Code так или иначе ассоциируются с DevOps. А DevOps — специалисты, которые не только занимаются сопровождением, но и помогают разработчикам работать: настраивают пайплайны, автоматизируют запуск тестов и т.д. Всё это тоже относится к IaC. В Infrastructure as Code должна применяться автоматизация: правила Lint, тестирование, автоматические релизы и др.  Когда у нас есть репозитории с тем же Ansible или Terraform, но выкатываются они вручную — просто приходит инженер и запускает задачу, это не очень хорошо. Во-первых, сложно отследить, кто, зачем и в какой момент её запустил. Во-вторых, нельзя понять, как она работала, и сделать выводы.  Когда всё находится в репозитории и контролируется автоматическим CI/CD-пайплайном, мы всегда можем посмотреть, когда был запущен пайплайн и как он отработал. Можем контролировать параллельное выполнение пайплайнов, выявлять причины сбоев, быстро находить ошибки и многое другое.  Часто от специалистов сопровождения можно слышать, что они никак не тестируют код или просто сначала запускают его где-то на dev. Это не самый удачный вариант тестирования, потому что он не даёт никаких гарантий, что dev соответствует prod. В случае с Ansible или другими инструментами конфигурации стандартное тестирование выглядит примерно так:  запустили тест на dev; на dev прокатилось, но упало с ошибкой; исправили эту ошибку; ещё раз тест не запустили, потому что dev уже находится в том состоянии, к которому его пытались привести. Кажется, что ошибку поправили, и можно катить на prod. Что случится с prod? Это всегда вопрос везения — попали или не попали, угадали или не угадали. Если где-то на середине, что-то снова упадёт, ошибку поправят и всё перезапустят. Но инфраструктурный код можно и нужно тестировать. При этом часто даже, если специалисты знают о разных способах тестирования, они все равно не могут ими воспользоваться. Причина — роли Ansible или файлы Terraform написаны без изначального фокуса на то, что их нужно будет как-то тестировать.  Когда разработчик пишет код, он задумывается о том, что его ещё нужно протестировать. И, соответственно, прежде чем начать писать код, планирует, как будет его тестировать. Нетестируемый код — это код низкого качества.  То же относится и к инфраструктурному коду: после написания вы должны суметь протестировать его. Тесты позволяют уменьшить число ошибок и облегчить работу коллег, которые будут дорабатывать ваши роли на Ansible или файлы Terraform. Распространённая практика в случае работы с Ansible — даже если что-то и можно протестировать, автоматизации никакой нет. Обычно это история, когда кто-то создаёт виртуалку, берёт какую-то роль, написанную коллегами, и запускает её. Дальше думает: нужно дописать вот это и это. Дописывает и снова запускает на виртуалке. Затем понимает, что нужны ещё какие-то изменения, и что текущая виртуалка уже приведена в какое-то состояние, поэтому её нужно убить, поднять новую виртуалку и прокатить по ней роль. А если что-то не будет работать, этот алгоритм придётся повторять до устранения всех ошибок.  Обычно срабатывает человеческий фактор, и спустя n-ное количество повторов удалять виртуалку и создавать снова становится лень. Кажется, на этот раз всё точно работает как надо, поэтому можно замёржить изменения и прокатить по prod. Но на деле ошибки все равно могут возникать, поэтому и нужна автоматизация. Она работает на автоматических пайплайнах и сигнализирует о новых Pull Request, помогает быстрее выявлять баги и предупреждать их появление.  21-22 мая Слёрм проведёт практический интенсив «Terraform Мега». За два дня активного участия вы узнаете: зачем использовать IaC; как работает Terraform и как с его помощью управлять инфраструктурой; как писать инфраструктурный код, который будет сопровождаемым и тестируемым; как лучше использовать Terraform в корпоративном масштабе. По окончанию интенсива вы будете уверенно разбираться в управлении инфраструктурой как кодом, а ещё сможете работать с Terraform на продвинутом уровне.  Посмотреть программу и записаться   Редактор в MobileUp