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 на продвинутом уровне. 

Посмотреть программу и записаться

Источник: https://habr.com/ru/company/southbridge/blog/665646/

Интересные статьи

Интересные статьи

Кажется, задача вычисления абсолютного значения (или модуля) числа совершенно тривиальна. Если число отрицательно, давайте сменим знак. Иначе оставим как есть. На Java это будет выглядеть примерно так...
Говорить о том, что пандемия коронавируса в 2020 году стимулировала онлайн во всех его проявлениях становится уже немодным. Это свершившийся факт. Тем не менее, цифры упрямая вещь: мо...
Автор статьи, перевод которой мы сегодня публикуем, решил поделиться с читателями семью рекомендациями по JavaScript. Эти рекомендации, как хочется надеяться автору, помогут писать более надёжные...
Получить трафик для интернет-магазина сегодня не проблема. Есть много каналов его привлечения: органическая выдача, контекстная реклама, контент-маркетинг, RTB-сети и т. д. Вопрос в том, как вы распор...
В Испании, где я сейчас живу, довольно много электромобилей — встречаю их практически каждый день, как на дорогах, так и на станциях для зарядки. И каждый год электрокаров становится все бол...