Код инфраструктуры: 5 уроков из 300 000 строк

Краткий мастер-класс о том, как писать код инфраструктуры

В октябре этого года я выступил с докладом на HashiConf 2018, где поделился пятью главными уроками, которые мы усвоили в Gruntwork при создании и поддержке библиотеки объемом более 300 000 строк кода инфраструктуры, используемой в продакшене сотнями компаний. В этом посте я поделюсь видео и слайдами выступления, а также сокращенной текстовой версией пяти ключевых выводов.

Видео и слайды

Уроки, извлеченные из написания более 300 000 строк кода инфраструктуры, от Евгения Брикмена

Введение: DevOps находится в каменном веке

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

Для меня DevOps выглядит скорее так:

Создание инфраструктуры продакшн-уровня — это сложно. И стрессово. И отнимает много времени. Очень много времени.

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

Урок 1: Чек-лист инфраструктуры продакшн-уровня

Проекты DevOps всегда занимают гораздо больше времени, чем вы ожидаете. Всегда. Почему так происходит?

Что ж, первая причина — это бритье яка, как отлично проиллюстрировано в этом отрывке из сериала «Малкольм в центре внимания»:

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

Чтобы избежать этой проблемы, каждый раз, когда вы приступаете к работе над новым элементом инфраструктуры, сверяйтесь со следующим чек-листом:

Чек-лист инфраструктуры продакшн-уровня

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

Зона приземления (landing zone) применяет этот же чек-лист на уровень выше — к учетным записям, средствам контроля и конвейеру предоставления ресурсов, внутри которых работает вся остальная инфраструктура. О том, как описанные выше элементы соотносятся с этим уровнем, читайте в статье «Как построить правильно спроектированную зону приземления AWS с помощью OpenTofu/Terraform».

Урок 2: набор инструментов

По состоянию на 2018 год вот основные инструменты, которые мы используем в Gruntwork для создания и управления инфраструктурой:

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

• Packer: мы используем Packer для определения и сборки образов виртуальных машин, которые запускаются поверх наших серверов.

• Docker: некоторые из наших серверов образуют кластеры, в которых мы запускаем приложения в виде контейнеров Docker. Основными инструментами кластеризации Docker, которые мы используем, являются Kubernetes, ECS и Fargate.

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

В частности, лучшие инструменты в мире ни капли не помогут вашей команде, если она не заинтересована в их использовании или у нее недостаточно времени, чтобы научиться ими пользоваться. Следовательно, главный вывод заключается в том, что использование кода инфраструктуры — это инвестиция: на старте требуются первоначальные затраты, но если инвестировать с умом, в долгосрочной перспективе вы получите большие дивиденды.

Урок 3: крупные модули — это зло

Новички в написании кода инфраструктуры часто описывают всю инфраструктуру для всех сред (dev, stage, prod и т. д.) в одном файле или в одном наборе файлов, которые развертываются как единое целое. Это плохая идея.

Вот лишь некоторые из негативных последствий:

• Медленно: если вся ваша инфраструктура описана в одном месте, выполнение любой команды займет много времени. Мы видели компании, где выполнение terraform plan занимает 5–6 минут!

• Небезопасно: если вся ваша инфраструктура управляется совместно, то для изменения чего-либо вам нужны права доступа ко всему. Это означает, что почти каждый пользователь должен быть администратором, что является еще одной плохой идеей.

• Рискованно: если все яйца сложены в одну корзину, ошибка в любом месте может сломать все. Вы можете вносить незначительные изменения во фронтенд-приложение в среде разработки, но из-за опечатки или выполнения не той команды удалить продакшн-базу данных.

• Трудно понять: чем больше кода находится в одном месте, тем труднее кому-то одному понять его целиком. Но если все это объединено в пакет, те части, которые вы не понимаете, могут навредить вам.

• Трудно тестировать: тестирование кода инфраструктуры — сложная задача; тестировать большой объем кода инфраструктуры практически невозможно. Мы вернемся к этому вопросу позже.

• Трудно проверять: результат выполнения таких команд, как terraform plan, становится бесполезным, так как никто не утруждает себя просмотром тысяч строк вывода. Более того, код-ревью становятся бесполезными:‍

10 строк кода = 10 проблем. 500 строк кода = "выглядит нормально." Ревью кода.— Я разработчик (@iamdevloper) 5 ноября 2013 г.

10 строк кода = 10 проблем.

500 строк кода = "выглядит нормально."

Ревью кода.

— Я разработчик (@iamdevloper) 5 ноября 2013 г.

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

«Делай одну вещь и делай ее хорошо» — философия Unix

«Первое правило функций заключается в том, что они должны быть маленькими. Второе правило функций заключается в том, что они должны быть еще меньше». — Чистый код

Урок 4: код инфраструктуры без автоматических тестов не работает

Если в вашем коде инфраструктуры нет автоматических тестов, он не работает. Вы просто еще об этом не знаете. Тем не менее, тестировать код инфраструктуры сложно. У вас нет «localhost» (например, вы не можете развернуть AWS VPC на своем ноутбуке) и у вас нет «юнит-тестов» (например, вы не можете изолировать свой код Terraform от «внешнего» мира, так как все, что делает Terraform, — это взаимодействует с внешним миром).

Поэтому для правильного тестирования кода инфраструктуры обычно приходится развертывать его в реальной среде, запускать реальную инфраструктуру, проверять, что она делает то, что должна, а затем все это удалять (для такого стиля тестирования используйте Terratest — библиотеку с открытым исходным кодом, которая включает в себя инструменты для тестирования кода Terraform, Packer и Docker, работы с API AWS, GCP и Kubernetes, выполнения команд оболочки локально и на удаленных серверах по SSH и многое другое). Это означает, что при тестировании инфраструктуры вам придется немного переопределить термины:

• Модульные (юнит) тесты развертывают и тестируют один или небольшое количество тесно связанных модулей одного типа инфраструктуры (например, тестируют модули для одной базы данных).

• Интеграционные тесты развертывают и тестируют несколько модулей из разных типов инфраструктуры, чтобы убедиться, что они работают вместе правильно (например, тестируют модули базы данных с модулями веб-сервиса).

• Сквозные (e2e) тесты развертывают и тестируют всю вашу архитектуру целиком.

Обратите внимание, что диаграмма представляет собой пирамиду, где у нас много модульных тестов, меньше интеграционных тестов и совсем мало сквозных (e2e) тестов. Почему? Из-за времени выполнения каждого типа тестов:

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

• Создавать небольшие, простые, автономные модули (помните Урок 3?) и писать для них множество модульных тестов, чтобы обрести уверенность в их корректной работе.

• Комбинировать эти небольшие, простые, проверенные в боях строительные блоки для создания более сложной инфраструктуры, которую вы будете тестировать с помощью меньшего количества интеграционных и сквозных тестов.

Урок 5: процесс выпуска

Давайте теперь объединим все сказанное в этом докладе. Вот как вы будете создавать инфраструктуру и управлять ею с этого момента:

• Изучите контрольный список инфраструктуры производственного уровня (Production-Grade Infrastructure Checklist), чтобы убедиться, что вы создаете то, что нужно.

• Определяйте свою инфраструктуру как код с помощью таких инструментов, как Terraform, Packer и Docker. Убедитесь, что у вашей команды есть время на освоение этих инструментов (см. Ресурсы по DevOps).

• Создавайте свой код из небольших, автономных, комбинируемых модулей (или используйте готовые модули из библиотеки Infrastructure as Code Library).

• Пишите автоматизированные тесты для своих модулей с помощью Terratest.

• Отправьте пулл-реквест (pull request), чтобы ваш код прошёл проверку.

• Выпустите новую версию своего кода.

• Продвигайте эту новую версию своего кода из одного окружения в другое.

Получите свои суперспособности DevOps на Gruntwork.io.