Iac

Предыстория: параллельные миры разработчиков и инфраструктуры

Бермудский треугольник проблем

Проблемы разработчиков

• собрали классную команду;
• за полгода написали удобное и красивое приложение;
• подкрепили торжественный запуск вкусными промоакциями;
• и в первый же день благополучно упали под нагрузкой.

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

Проблемы инфраструктуры

• 60 ролей;
• 102 плейбука;
• обвязка на Python и Bash;
• тесты в Vagrant, запускаемые вручную.

Проблемы бизнеса

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

И что с этим делать?

• механизмы мониторинга приложений и инфраструктуры (спойлер: это мы в 2018 думали, что они хорошие, а сейчас уже всё переписали);
• процессы для дежурств 24/7 on-call;
• практика ведения постмортемов по инцидентам и их анализ;
• нагрузочное тестирование;
• CI/CD-пайплайны для прикладного софта;
• хорошие программисты, которые пишут хороший код;
• евангелист SRE в команде инфраструктуры.

Онбординг SRE-команды

1. Обучить программистов тем знаниям и навыкам, которые необходимы для дежурств и операционной деятельности в команде инфраструктуры.
2. Написать IaC описание всей инфраструктуры в коде. Причём это должен быть полноценный программный продукт с CI/CD, тестами.
3. Пересоздать всю нашу инфраструктуру из этого кода и забыть про ручное накликивание виртуалок мышкой в Azure.

Две составляющие онбординга: обучение и практика

• на чтение статей и книг из списка литературы: Linux, сети, SRE;
• на лекции по конкретным инструментам и технологиям;
• на клубы по технологиям, например, по Linux, где мы разбирали сложные случаи и кейсы.

Практики Extreme Programming в инфраструктуре

Технические и антропогенные проблемы на пути

• Технические: ограничения железного мира, недостаток знаний и сырые инструменты, которыми приходилось пользоваться, потому что других нет. Это привычные любому программисту проблемы.
• Человеческие: взаимодействие людей в команде. Общение, принятие решений, обучение. С этим было хуже, поэтому нужно остановиться подробнее.

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

Итоги онбординга

• Создали полноценный программный продукт, который управляет нашей DEV-инфраструктурой, с собственным CI-пайплайном, с тестами и прочими атрибутами качественного программного продукта.
• Удвоили количество людей, которые готовы дежурить и сняли нагрузку с текущей команды. Спустя ещё полгода эти люди стали полноценными SRE. Теперь они могут потушить пожар на проде, проконсультировать команду программистов по НФТ, или написать свою библиотеку для разработчиков.
• Сместили майндсет в сторону идей SRE. Не только у участников проекта онбординга, но и у тех программистов из продуктовых команд, которые теперь могут разговаривать с нами на одном языке.
• Сильно устали: и те, кто участвовал в онбординге, и те, кто участвовал в дежурствах.

Вместо выводов: инсайты, не наступайте на наши грабли

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

PPS: Эта статья написана по моему выступлению на DevOpsConf осенью 2019 года. С тех пор прошло довольно много времени, и теперь уже точно понятно, что всё было не зря: тойл теперь не съедает бОльшую часть времени инженеров, наша команда теперь может реализовывать крупные долгосрочные проекты по улучшению инфраструктуры в широком смысле, а программисты почти не жалуются на безумных DevOps-инженеров, которые только мешают жить.

PPPS: В этом году конференция, посвящённая DevOps-практикам, будет называться DevOps Live 2020. Изменения коснутся не только названия: в программе будет меньше докладов и больше интерактивных обсуждений, мастер-классов и воркшопов. Рецепты о том, как расти и перестраивать процессы с помощью DevOps-практик. Формат также изменится два блока по два дня и домашние задания между ними.

Чтобы узнать подробнее о том, что будет происходить на DevOps Live и что полезного вынесут инженеры, безопасники, тимлиды и CTO, подписывайтесь на рассылку и следите за публикациями в блоге.

Меня зовут Никита, я системный инженер в компании SEMrush. И в этой статье я расскажу вам, что такое Immutable Infrastructure, какие у этого подхода есть преимущества и недостатки и как мы его используем в компании.

Если вы ни разу не слышали такое словосочетание, то усаживайтесь поудобнее, будет интересно.

Что это такое

Immutable Infrastructure подход к созданию неизменяемой инфраструктуры. Идея его не нова в мире, хоть и не слишком распространена. Мы начали его использовать, когда поняли, что не все можно запустить в Kubernetes, и нам нужны виртуальные машины.

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

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

Мы в компании активно используем облако GCP, поэтому не админим железо, на котором запускаются виртуалки. У GCP есть мощный API и множество SaaS продуктов, использование которых делает возможным применение Immutable подхода. Если у вас KVM-хосты, и вы выкатываете виртуалки скриптиком, то вряд ли вам подойдет такое решение. Но при использовании любого облака (Openstack, AWS, Azure и т.д.), можно имплементировать данный подход. Я опишу его применение совместно со всей мощью облака, где, например, создание виртуалки происходит POST-запросом, а увеличение диска производится на лету.

Преимущества Immutable

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

1. Повторяемое окружение
   Обычно на сервер устанавливается операционная система определенной версии, настраивается окружение для приложения и происходит деплой самого приложения. Но если вы захотите через какое-то время развернуть точно такой же сервер с вашим приложением, то точно такой же у вас никак не получится: какие-то пакеты устарели, на другие пакеты выпущены security патчи, ядро уже тоже обновилось. В итоге вы получаете два похожих сервера. И вот эта разница часто является ключевой и может привести к багам и ошибкам. С Immutable Infrastructure у вас всегда есть образ виртуальной машины, который точно запустится и будет повторять реальное окружение точь-в-точь. В нем уже все предустановлено: все системные пакеты и библиотеки одной версии, а окружение приложения не изменится со временем. Вы можете повторно развернуть или масштабировать сервис спустя годы, лишь бы у вас был образ.
2. Инфраструктура как код
   Immutable infrastructure всегда описана как код, потому что на каждый коммит (релиз) нам нужно создавать новый образ виртуальной машины, а также проводить его через пайплайны CI/CD. Это не получится делать руками.
3. Неизменяемое окружение
   Как и в случае с Docker контейнером, виртуальная машина не может быть изменена. Не придет какой-нибудь configuration management инструмент или unattended upgrades, которые установят новые версии пакетов и все сломают. Там просто нет этих механизмов. Они не нужны и даже специально отключаются, потому что все, что нужно для функционирования приложения, уже установлено в системе. Окружение неизменяемо во времени и всегда одно и то же, пока не произошел релиз новой версии приложения.
4. Отсутствие configuration drift
   Может быть такое, что у вас есть 100 серверов, на которые нужно вылить новый апдейт, и на несколько из них выкладка зафейлилась по какой-то причине. Тогда ваша конфигурация разъезжается, и вы не имеете одинакового окружения на всех машинах в вашей системе. Или у вас работает unattended upgrade, который периодически ставит обновления безопасности, и где-то ему удалось поставить пакет, а где-то нет. Immutable же гарантирует неизменяемость виртуалок во времени, а также то, что на них одна одинаковая версия всех приложений, зависимостей и операционной системы.
5. Независимость от внешних источников
   В ходе настройки окружения приложению необходимы различные зависимости, которые тянутся из внешних источников. Если внешний источник недоступен, то создание новых инстансов может быть зафейлено. С Immutable такого не произойдет. Все зависимости уже установлены в образе, что гарантирует работоспособность приложения после старта. С таким подходом мы выносим failure point на этап билда образа, а не на этап деплоя, когда что-то пошло не так при обновлении на production VM. После того, как образ собран, мы точно знаем, что виртуалка рабочая, и осталось задеплоить ее как обычно.
6. Отсутствие устаревших систем
   С Immutable нет проблемы "старых" серверов с высоким аптаймом, которые страшно не только обновить, но и даже перезагрузить. Любое изменение это новый билд образа и новая виртуалка.
7. Простое масштабирование
   Всегда есть некий срез во времени вашего приложения, поднять новый инстанс которого можно по щелчку пальцев.
8. Все плюсы облака
   В облаке дешево и легко создавать новые ресурсы, запрашивать столько CPU и RAM, сколько необходимо. Кроме того, можно интегрировать виртуалки с другими сервисами GCP: Load balancers, GCS для бэкапов, Autoscaler, Cloud SQL и т.д.
9. Трансформация разработки
   Такой подход к инфраструктуре и осознание того, что инфраструктурная часть неотделима от самого кода и приложения, что минимальная единица это виртуальная машина, заставляет изменить и подход к разработке приложения. Нужно проектировать свое приложение исходя из того, что оно будет immutable. Приложение должно "осознавать" свою эфемерность и быть готовым быть замененным новой версией самого себя. Деплой таких приложений тоже отличается, поэтому нужно предусмотреть нюансы на этапе проектирования.
10. Базовые образы
    Можно создать образы виртуальных машин различных ОС с предустановленным ПО, которые будут являться базовыми. Далее их можно расширять, устанавливая туда конкретные приложения и окружения для них. Все по аналогии с Docker образами.
11. Простые откаты
    Чтобы откатиться на предыдущую версию, достаточно просто поднять виртуалку с предыдущим образом. Как будто бы запускаешь контейнер.
12. Идентичные окружения
    Вы собираете новый образ виртуальной машины и запускаете его в Dev окружении на тестирование. Если тестирование прошло успешно, вы запускаете ТОТ ЖЕ САМЙ ОБРАЗ (только с другим конфигом для provisioner) в Prod окружении.

Но есть нюансы

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

1. Более сложный деплой
   Immutable подразумевает, что каждый раз при любом изменении вы создаете новый образ, на основе которого запускаете виртуалку. После этого вам может понадобится сконфигурировать приложение (чтобы оно получило свои переменные, конфиги, вступило в кластер и т.д.). Это все необходимо автоматизировать и это может быть достаточно сложно. Пайплайн обновления и его логика могут получаться развесистыми.
2. Даунтайм при обновлениях
   Если есть приложение, которое крутится на виртуалке и использует какие-то данные, хранящиеся локально, то выкладка новой версии приложения подразумевает ряд процессов: выключение текущей виртуалки, отсоединение от нее диска, поднятие нового инстанса, подключение диска к нему. Понятно, что это ведет к даунтайму (по правде сказать, в таком случае перерыв в работе сервиса, но просто более короткий, был бы даже если бы и не использовался Immutable подход). Узкие места: единственный инстанс и локальный storage. Решить это можно через системы динамической конфигурации, несколько инстансов (горячий, холодный резерв или одновременная работа), удаленный storage (но тут уже будет возможный downgrade производительности дисковой подсистемы). Все это зависит от конкретного кейса и архитектуры приложения. Если это Stateless воркеры, то для них данная концепция подходит как никакая другая. А у нас, например, на инфраструктурных сервисах есть SLA, в рамках которого мы иногда можем сделать даунтайм для обновления.
3. Отсутствие постоянных апдейтов
   Как это ни странно, но у Immutable есть обратная сторона своего же преимущества это отсутствие постоянных апдейтов, security патчей и т.д., которые в обычной системе могут быть настроены на автоматическую установку. В образе не обновится ничего, пока вы не соберете и не задеплоите обновленный вами образ.

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

Push и Pull модели

При проектировании нужно учитывать, какой модели будет соответствовать ваше приложение. Существует два основных пути:

Push

Такая модель не подразумевает, что приложение может автоматически масштабироваться, а соответственно, количество виртуалок строго постоянно в течение времени. Это значит, что новая машина запускается по коммиту собирается новый образ, создается новая виртуалка, CI/CD накатывает в нее необходимую конфигурацию, приложение запускается. То есть конфигурация происходит снаружи пушится в виртуалку.

Pull

При таком подходе может работать автоскейлинг, а виртуалки будут в инстанс группе (ну или использовать схожий механизм). Это значит, что создание новой виртуалки будет происходить автоматически, а не по воли оператора или процесса CI. Новосозданная машина должна иметь в себе все необходимое для само конфигурации. То есть конфигурация происходит изнутри пуллится самой виртуалкой (в себя).

В зависимости от модели нужно по-разному подходить к проектированию CI/CD пайплайна и процесса деплоя.

В главных ролях

При работе с неизменяемой инфраструктурой нам помогают эти инструменты:

1. Packer программа от Hashicorp, которая позволяет создавать образы виртуальных машин, на базе разных облачных провайдеров. Packer берет указанный базовый образ, создает из него виртуалку в нужном облачном провайдере, накатывает в нее конфигурацию с помощью любого из множества провижинеров, а в конце создает из ее диска установочный образ, который можно использовать в выбранном облаке.
2. Terraform еще одна утилита от Hashicorp, которая, наверное, уже не нуждается в представлении. Позволяет описать необходимые инфраструктурные ресурсы нужного облачного провайдера и, используя этот манифест, приводит конфигурацию облака к описанному в конфиге.
3. Ansible инструмент, с которым также знакомы почти все. Он нам нужен для того, чтобы делать provision образа и создаваемой виртуалки настраивать окружение.
4. Gitlab CI мы используем Gitlab, поэтому и всю автоматизацию пишем на нем.
5. GCP собственно, облако, которое делает запуск виртуалки легким и простым, а также позволяет создавать множество других ресурсов.

Immutable Images

Образ VM является основным артефактом деплоя. У нас есть собственные базовые образы, которые собираются на основе образов Google, специально заточенных под работу в их облаке, образы приложений с каким-то предустановленным, но не сконфигуренным ПО (nginx, mysql, mongodb и т.д.), и продуктовые образы. Последние содержат в себе все необходимое для работы конкретного продукта или его компонента (это может быть образ с настроенной БД, вэб-сервером, бэкэндом). Как можно понять, каждый образ в иерархии базируется на каком-то родителе и расширяет его. Для конфигурации образов (подготовки окружения) мы используем Ansible отличный инструмент, позволяющий доставлять one-shot конфигурацию.

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

Image Family

У образа в GCP есть имя, метки, статус, а также принадлежность к какой-то Image Family.

Image Family удобный механизм, объединяющий все версии одного образа под одной "семьей". Это упрощает использование базовых образов если вам не нужно точно знать, какую вы используете версию образа, его название, которое включает дату и т.д., вы просто указываете image family, на базе которого вы хотите собраться, и все. Это аналог тега latest в докере.

Однако, если при сборке образа использование Image Family вполне оправдано, то при деплое вам обязательно нужно использовать Image Name и указывать конкретный образ, который вы хотите задеплоить (только что собранный). Как и latest в докере, использование family может привести к дрифту версий или неожиданным изменениям на проде.

Кратко принцип работы с Image Family выглядит так:
У вас есть image-v1 это самая последняя версия образа вашего приложения. my-image-family указывает на данный образ

gcloud compute images create image-v1 \    --source-disk disk-1 \    --source-disk-zone us-central1-f \    --family my-image-familygcloud compute images describe-from-family my-image-familyfamily: my-image-familyid: '50116072863057736'kind: compute#imagename: image-v1

Вы создаете новый образ image-v2, и теперь my-image-family указывает на него.

gcloud compute images create image-v2 \    --source-disk disk-2 \    --source-disk-zone us-central1-f \    --family my-image-familygcloud compute images describe-from-family my-image-familyfamily: my-image-familyid: '50116072863057756'kind: compute#imagename: image-v2

По какой-то причине нужно откатиться на предыдущую версию, и теперь my-image-family снова указывает на image-v1:

gcloud compute images deprecate image-v2 \    --state DEPRECATED \    --replacement image-v1gcloud compute images describe-from-family my-image-familyfamily: my-image-familyid: '50116072863057736'kind: compute#imagename: image-v1

Обновление и ротация базовых образов

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

У образов виртуальных машин в GCP есть текущее состояние:
READY образ готов к использованию
DEPRECATED образ признан deprecated. Такие образы не отображаются в веб-консоли по-умолчанию, но доступны для gcloud и terraform. В случае их использования выдается предупреждение.
OBSOLETE образ в этом статусе уже недоступен для использования.
DELETED образ помечен удаленным, но еще существует физически.
REALLY_DELETED такого статуса в реальности нет, но спустя некоторое время, как образ был помечен DELETED, он будет удален по-настоящему.

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

Для базовых образов мы делаем автообновление. Раз в сутки производится автоматическая проверка наличия обновления пакетов, входящих в состав образа. Если обновления найдены, производится сборка новой версии образа и указатель image-family сдвигается на нее. После этого происходит ротация всех образов, относящихся к данной image-family.

Для автоматизации жизненного цикла мы написали скрипт image-rotator, который в ближайшее время мы выложим в публичный доступ (в статью будет добавлена ссылка). Его принцип работы следующий:

1. Скрипту передаются нужные переменные, главной из которых является --image-family. Так он понимает, с чем ему нужно работать
2. Скрипт находит все образы, принадлежащие данной Image Family, и дальше работает со всеми этими образами КРОМЕ последнего актуального образа, на который указывает Image Family в данный момент
3. Далее среди этих образов он делает следующее:
   
   • Все READY образы делает DEPRECATED и проставляет им дату, когда они должны стать OBSOLETE
   • Все DEPRECATED образы, у которых дата obsolete меньше текущей даты, переводит в состояние OBSOLETE и выставляет дату, когда образ должен стать DELETED
   • Все OBSOLETE образы обрабатывает по аналогии с DEPRECATED
   • То же самое с DELETED. Если у DELETED образа подошла дата удаления, то скрипт удаляет образ навсегда

Схема пайплайна

Итак, теперь, когда мы разобрались с основными моментами, можно рассмотреть общий процесс деплоя.

На рисунке ниже, схематично, представлен данный процесс.

Мы подразумеваем, что сначала деплоим приложение в Dev-среду из Master-ветки (название ветки здесь не принципиально), где оно тестируется. После чего, деплоим тот же самый образ на Prod-окружение из другой ветки stable, посредством синхронизации двух веток через Merge Request.

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

• Интеграция с Hashicorp Vault для получения секретов
• Использование снапшотов дисков с данными Prod-инстанса для создания Dev окружения
• Использование последнего бэкапа CloudSQL (примечание: база данных как сервис от Google (MySQL, PostgreSQL)) Prod-инстанса для создания базы данных в Dev-окружении
• Удаление Dev-окружения в конце тестирования (это же облако, нам не хочется тратить лишние деньги)

Дальше Terraform создает виртуалку с приложением в Dev-окружении, создает диск со свежими данными из образа, сделанного в п.1. Так мы получаем свежие независимые данные, на которых протестируем новую виртуалку. Бонусом случайно проверяем бэкапы Prodа :)

Заключение

На этом с теорией покончено. И к сожалению (или к счастью для тех, кто не любит много буков), на самом интересном я заканчиваю свое изложение, так как статья уже получилась достаточно объемной, и реальный пример сервиса, разворачиваемого с помощью данной концепции, она уже не вместит. Напишите в комментариях, если статья получилась интересной/полезной, и хочется посмотреть, как это сделано на практике: с кодом, реальным CI/CD и пояснениями. Я буду благодарен вам за обратную связь.

Immutable Infrastructure подход, который имеет свои плюсы и минусы. Подход, который подойдет не для каждого сервиса или приложения. И я повторюсь, использовать его надо, понимая и принимая все его плюсы и минусы. И конечно, пусть всегда торжествует здравый смысл. Вы всегда можете взять какую-то его часть и использовать только ее, если это дает вам преимущества.

Сейчас мы в команде работаем над усовершенствованием концепции и нашей реализации, так как через некоторое время использования ее в том виде, в котором она описана здесь, мы поняли, что нам есть над чем работать, и у нас есть идеи как все сделать лучше. И когда все получится, мы напишем еще одну статью, в которой поделимся нашими наработками.

Это расшифровка выступления на TechLeadConf 2020-06-09. Прежде чем начнем, попробуйте ответить для себя на вопрос какие у вас ожидания от взаимодействия с инфраструктурой? Например сколько времени займет:

• Развернуть новое окружение для тестов.
• Обновить версию java и/или ОС внутри контейнера.
• Выдать права доступа на сервер.

А теперь умножьте свои ожидания на двое, и вы получите суровую реальность. Не приятненько как-то, да?

Особенно когда ты тот самый человек со стороны инфраструктуры, который говорит, что всё будет долго. Но так долго не потому, что я такой-сякой чопорный. Для этого, как правило, есть объективные причины. Давайте разбираться почему так происходит и что с этим делать.

Инфраструктура как она есть

Cлучайности + Договоренности + Процессы = Инфраструктура

Прежде чем ответить на вопрос почему так долго? Предлагаю разобраться с тем что такое инфраструктура и как она появляется. Зачастую, процессы появления инфраструктуры изоморфны и похожи между собой. Рассмотрим собирательный образ некого сферического коня, не проводящего в вакуме: появления инфраструктуры для разработки коробочного приложения.

1. Случайность. Есть приложение. Но оно не появляется просто так, его разрабатывают вполне конкретные люди. Со временем или сразу появляется потребность развернуть/запустить приложение где-то(Спасибо Кэп!). В нашем случае лет 10-15 назад было отправлено письмо с просьбой смонтировать сервер в стойку. У кого-то это просьба в телеграмм чате настроить сервер. Суть в том, что инфраструктура это про то, что вас кто-то что-то попросил сделать, развернуть сервис. Изменения не происходят потому что вам так захотелось, за изменениями стоят люди.
2. Договоренности. Со временем, случайные запросы на изменения через jira, email, slack могут перерасти в хаотичный поток запросов. В нашем случае необходимо было разворачивать множество окружений похожих на клиентские. Но бывает можно услышать "если хотите ускорить развёртывание, то не пишите нам в четверг, потому что мы ходим в серверную по средам". Появляются договоренности.
3. Процессы. Апогеем становится преобразование договоренности в процесс. Появляется формальный процесс: заведите таску в jira, заполните необходимые поля и в течение 7 дней первый освободившийся инженер создаст вам новое окружение.

Инфраструктура стремится к хаосу

Как вы понимаете, монтаж серверов в стойку, процесс не быстрый, а разработка должна лететь. Но всё меняется, и приложение было контейнеризировано. Появилась возможность создавать динамически виртуалки на CoreOS и запустив compose файл получить окружение похожее боевое. Этакий k8s на минималках. И тут появился первый звоночек: а кто отвечает за YML файлике в git? Кто описывает инфру? Закономерно, код без присмотра начинает дурно пахнуть и привет групповая безответственность. Растет технический долг за счет быстрых и незаменимых подпорок из велосипедов. Меняется команда с одной стороны, потом с другой. И всё. Приплыли. Наступает ОПА момент когда инфраструктура работает, но никто не видит картинку целиком и не понимает почему она работает именно так. Это ни хорошо и ни плохо. Это данность: Инфраструктура стремится к хаосу, как и наша вселенная стремится к тепловой смерти.

Как бороться с Хаосом?

Бумажки и инструкции на защите от хаоса

Написать инструкции может прийти первым на ум, когда вы захотите бороться с хаосом. У меня тут есть, забавная история, как в одной ооооочень большой организации любили писать бумажки почти на каждый чих. Однажды, там для переезда сервиса согласовали временную схему сети на пару недель и выставили сервис в интернет. Соль в, том что я нашел это спустя пять лет. А на минутку это: нефтебаза в аэропорту с доступом в сеть ЦОД. Не хорошо как-то. Бумажка есть, а реальность показывает другое.

Agreements as Code

Аналогичная ситуация будет с задачами в Jira. Вас попросили, подготовить новое окружение. Вы что-то сделали и забыли как-оно там было настроено. Но если те же договорённости формализовать в виде кода. Пусть даже на своем DSL, или просто кодом на Ansible написали. Итогом у вас есть воспроизводимое решение и единая точка правды. Кто-то то поправил код в репозитории и вот обновленная версия приложения уже в проде. Но стоит ли это все эти договоренности автоматизировать? Стоит ли овчинка выделки?

Agreements as Code внедрять нельзя забить

Для ответа на вопрос автоматизировать или нет процесс/договоренности я выработал матрицу для принятия решений. Она концептуально похожа на матрицу Эйзенхауэра.

• *ОПА степень "проблемности" проблемы. Насколько вы/ваши коллеги/заказчики страдаете.
• Стоимость решения сколько времени/денег стоит решить проблему.

Рассмотрим краевые случаи:

• Проблема огромная, решается дешево надо делать. Инструкция по заведению пользователей из confluence который пользоваться каждый день, замечательно заменяется скриптом, который формализует договоренности.
• Проблема маленькая, решается дешево спорно, делать по остаточному принципу. Разбираться с REST api редкого сервиса, чтобы раз в год обновить DNS может быть не лучшим выбором для инвестиции времени. Но на долгой дистанции может пригодиться.
• Проблема маленькая, решается дорого игнорировать. Как часто вам приходится обновлять подпись к email? раз в год? в три?
• Проблема огромная, решается дорого спорно, необходимо десять раз подумать, т.к. без опыта можно сделать только хуже. Например, скриптики которые автоматизировали процессы и договорённости вдруг стали стандартом, все пользуют и не знают как оно работает. Собственно, та самая *ОПА когда вам надо рефакторить IaC.

Ручной труд -> Механизация -> Автоматизация

Предлагаю взглянуть на проблемы под другим взглядом и чуть шире. Процессы могут быть автоматизированы до различной степени.

• Ручной труд нет автоматизации, вы руками проделываете всё, собираете шишки и понимаете, как выглядит процесс и какие в нем бутылочные горлышки.
• Механизация первые попытки упростить себе жизнь. Статья в confluence с собранными шишками превращается в скрипт автоматизирующий отдельные проявления рутины. Но требующий человека для принятия решений.
• Автоматизация "Слава роботам"(с) Бендер. Человек задействован минимально, появляются различные * as Service и позволяют другим людям автоматизировать их работу.

Когда эволюционировать и переходить на следующий уровень автоматизации, а когда нет?

• Проблема огромная, автоматизируется легко надо делать. Заведение пользователей замечательно заменяется интеграцией, например, с LDAP и решает проблемы на корню. Инструкция -> скрипт -> LDAP.
• Проблема маленькая, автоматизируется легко имеет смыл, т.к. на дальней дистанции можно переиспользовать наработки и не изобретать велосипед по новой, ваше знание сохранено и со временем может перерасти в сервис. Если посмотреть на AWS, то предоставляется множество * as Service на любой вкус, а ведь когда-то оно тоже могло начинаться с простого скрипта. Например, я завел приватный репозиторий, где хранятся такого рода скрипты.
• Проблема маленькая, автоматизируется сложно скорее нет. Но для кого-то даже такое редкое действие как обновление подписи к email может быть актуально, у нас на дружественном проекте такое разрабатывают; говорят, что у одного крупного аутсорсера есть специальный web портал на котором можно получить свою подпись.
• Проблема огромная, автоматизируется сложно скорее да, если ваши договоренности представлены в виде кода, то когда настанет *ОПА(а это неизбежно, т.к. всё стремится к хаосу!), у вас будет возможность отрефакторить код.

По мере развития инфраструктуры, договоренности формализуются в виде кода и стремятся стать * as Service.

Инфраструктуру можно и нужно рефакторить. Но не всегда

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

• Разобраться как оно работает и удовлетворить собственное эго.
• Ускорить внесение изменений.
• Уменьшить количество падений сервисов
• ...

Ansible: Миграция конфигурации 120 VM c Coreos на Centos за 18 месяцев

В моем случае, досталось в наследство самописное configuration management решение. Оно представляло инфраструктуру в виде кода, оно работало, но его поддержка было сложной, т.к. оно было хрупкой, никто не хотел его поддерживать. Планомерным итогом стала замена его на Ansible, подробности можно глянуть тут Ansible: Миграция конфигурации 120 VM c Coreos на Centos за 18 месяцев. Почему 1,5 года заняла миграция? Ответ прост 80% был reverse engineering как оно работает и только 20% непосредственно написание плэйбуков, ролей и миграция. Сам же процесс был прост:

1. Сформировать список серверов.
2. Выбрать сервер из списка не перенесенных.
3. Зафиксировать текущие договоренности.
4. Разобраться как работает.
5. Описать в виде кода.
6. Вернуться на пункт 2.

Как начать тестировать Ansible, отрефакторить проект за год и не слететь с катушек

На дружественном проекте занялись автоматизацией развертывания окружений у заказчиков и делали это через Ansible. Но спустя какое-то врем пришло понимание, что получившиеся плэйбуки страшно запускать на боевых серверах, т.к. нет уверенности что они не свалятся с ошибкой. Ситуацию еще усугубляло то, что до клиентов был air gap(инженеру могло потребоваться прийти на площадку к заказчику где нет интернета). Задача была стабилизировать плэйбуки и наладить процесс выпуска. Как решали можно почитать в Как начать тестировать Ansible, отрефакторить проект за год и не слететь с катушек, но если кратко:

1. Составить список существующих ролей.
2. Выбрать одну роль.
3. Покрыть тестами и зафиксировать текущие договоренности.
4. Внести правки в плэйбуки/роли, исправив причины падения.

Как реализовано тестирование Ansible ролей?

Так исторически сложилось, что использовался репозиторий в котором лежали все роли. Был создан Jenkins Pipeline, который:

1. Вычитвает конфиг из репозитория что тестировать.
2. Генерирует динамически стадии для Jenkins.
3. Запускает lint для всех ролей и плэйбуков.
4. Запускает molecule для всех ролей

Реафаторинг IaC

Мы то с вами помним, что инфраструктура эволюционирует и формализуется в скрипты и/или множество * as Service. А с этим можно работать как с кодом и переиспользовать практики по рефакторингу кода. Из предыдущих сценариев выбивается нечто общее:

1. Определяем измеримую цель.
2. Проверяем наличие нужных знаний и времени на изменения.
3. Выбираем маленький кусочек инфраструктуры.
4. Разбираем что он делает.
5. Формализуем договоренности и покрываем их тестами.
6. Отдыхаем(это важно! иначе сгоришь оставив недоделанным работу).
7. Повторяем.

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

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

Ускоряем ускорение

Со временем, внесение изменений в договоренности, в IaC может замедлиться и это нормально. Долго думал, как формализовать договоренности, и пришла идея изобразить историю развития проекта в цифрах и поискать закономерности. На график изображено:

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

По графику можно увидеть, что:

• Количество кода растет линейно и прогнозируемо.
• Количество тестов отложенное коррелирует с количеством кода и растет по экспоненте.
• Количество инженеров константно.

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

Используй IaC testing pyramid. Не откладывай не потом!

Годом ранее на DevopConf рассказывал Что я узнал, протестировав 200 000 строк инфраструктурного кода и подробно рассмотрел пирамиду тестирования инфраструктуры. Ровно таже идея, что в разработке, но для инфраструктуры: идем от дешевых быстрых тестов, которые проверяют простые вещи, например отступы, к дорогим полноценным тестами разворачивающих цельную инфраструктуру.

• Static Analysis Статистический анализ кода, без запуска. Линтеры, например.
• Unit IaC должна состоять из простых кирпичиков и вот их тестируем. В случае Ansible это роли тестируемые при помощи Molecule.
• Integration Очень похожи на unit, но представляют комбинацию ролей описывающих целевую конфигурацию сервера.
• E2E Цельная инфраструктура, состоящая из множества серверов.

Когда начинать писать тесты?

Ок, договоренности в инфраструктуре можно представить как код. А потом можно рефакторить. А если есть тесты то еще и не закопаться в рефакторинге. Но вот вопрос, когда начинать писать тесты? Рассмотрю пару проектов.

Проект 1

Начали с интеграционных тестов, и оно задалось тяжко т.к. поддерживать сложно, работают медленно. В итоге было принято волевое решение начать с основ, с линтинга и только потом юнит тестов.

Проект 2

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

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

• 2000 линтинг должен быть.
• 4000 пора делать юнит тесты
• 6000 время интеграционных тестов.
• 8000 E2E тесты мерещат на горизонте.

Lessons learned

1. Инфраструктура стремится с хаосу.
2. Agreements as Сode внедрять нельзя забить.
3. Ручной труд -> Механизация -> Автоматизация.
4. Инфраструктуру можно и нужно рефакторить. Но не всегда.
5. Тесты на инфраструктуру удешевляют/ускоряют ее изменения.
6. Используй IaC testing pyramid. Не откладывай не потом!

Links

• Slides
• Video
• English Version
• A list of awesome IaC testing articles, speeches & links
• Что я узнал, протестировав 200 000 строк инфраструктурного кода
• Как начать тестировать Ansible, отрефакторить проект за год и не слететь с катушек
• Ansible: Миграция конфигурации 120 VM c Coreos на Centos за 18 месяцев
• Podcast nsfw.co.in/04 Agreements as Code
• Cross post from personal blog

• как устроен Powershell DSC и чем он отличается от Ansible при управлении инфраструктурой на Windows;
• почему мы перешли на Ansible;
• с какими проблемами столкнулись и как их решали;
• как соотносятся ожидания и реальность после перехода на Ansible;
• кому стоит выбрать Powershell DSC, а кому Ansible.

Почему изначально выбрали PowerShell DSC

Как работает Powershell DSC

Чем DSC отличается от Ansible

Проблемы, которые возникли с DSC

Как планировали перейти с DSC на Ansible

• научиться подключаться к Windows-хостам с помощью Ansible;
• переписать конфигурации DSC с помощью Ansible-модулей;
• удалить DSC pull server, его базу данных и прочие артефакты.

С какими сложностями столкнулись при переходе на Ansible и как их решали

WinRM или SSH

1. Форкнули и переделали под себя роль из Galaxy.
2. Написали плейбук, в котором есть только вызов этой роли. Это единственный плейбук, при котором идет подключение к хостам по WinRM.
3. Стандартными средствами Prometheus Blackbox Exporter сделали мониторинг порта 22/tcp и версии OpenSSH:
   
   - alert: SSHPortDown
expr: probe_success{job=~".*-servers-ssh",instance!~".*domain..ru"} == 0
for: 1d
annotations:
summary: "Cannot reach {{`{{ $labels.instance }}`}} with SSH"
4. Выбрали и настроили LDAP-плагин для инвентаризации, чтобы не вписывать вручную все Windows-серверы из домена в статическую инвентаризацию:
   
   plugin: ldap_inventory
domain: 'ldaps://domain:636'
search_ou: "DC=domain,DC=ru"
ldap_filter: "(&(objectCategory=computer)(operatingSystem=*server*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"
validate_certs: False
exclude_hosts:
- db-
account_age: 15
fqdn_format: True
5. Развернули везде OpenSSH с нужными ключами и убедились, что ни одного алерта о недоступности Windows-серверов по SSH больше нет.
6. Чуть позже интегрировали установку OpenSSH в стандартный образ. Наши образы готовятся с помощью Packer, который также умеет вызывать Ansible:
   
   "type": "shell-local",
"tempfile_extension": ".ps1",
"execute_command": ["powershell.exe", "{{.Vars}} {{.Script}}"],
"env_var_format": "$env:%s=\"%s\"; ",
"environment_vars": [
"packer_directory={{ pwd }}",
"ldap_machine_name={{user `ldap_machine_name`}}",
"ldap_username={{user `ldap_username`}}",
"ldap_password={{user `ldap_password`}}",
"ansible_playbooks={{user `ansible_playbooks`}}",
"github_token={{user `github_token`}}"
],
"script": "./scripts/run-ansiblewithdocker.ps1"


Рефакторинг

Second hop authentication

Сетевой дисконнект

Дрифт инфраструктуры

Баги сбора фактов

Тесты

Как устроена работа с Ansible

1. Инженер пишет код роли и тесты к ней, если это роль для Linux-серверов. Как только инженер решит, что роль готова, он делает pull request в отдельный бранч в GitHub-репозитории, созданном специально для роли.
2. При создании pull request автоматически запускается воркфлоу GitHub Actions, который выполняет синтаксическую проверку и линтинг роли. Если это Linux-роль, то запускаются еще и тесты. Инженер проверяет, что всё хорошо, и при необходимости исправляет.
3. Другой инженер делает ревью кода из pull request. После того как автор роли исправляет все замечания, код вливается в мастер-бранч, а версия роли автоматически повышается.
4. Теперь нужно развернуть новую версию роли. Версии перечислены в специальных файлах requirements.yml, которые лежат в GitHub-репозитории с плейбуками. Для каждого плейбука отдельный такой файл. Автор роли изменяет версию в таком файле. Если нужно развернуть роль на серверы, которых нет в инвентаризации Ansible, автор дополняет инвентаризацию. Потом автор снова создает pull request, но уже в репозиторий с плейбуками.
5. После подтверждения pull request снова запускается GitHub Actions, который создает новый релиз в Octopus Deploy. Роль готова к развертыванию.
6. Инженер заходит в Octopus Deploy и запускает развертывание. Процесс развертывания позволяет инженеру ограничить теги и хосты, а также переопределить переменные аналогично опциям команды ansible-playbook: --tags, --limit и --extra-vars.
7. Процесс развертывания сначала запускает режим проверки, который показывает, какие изменения будут сделаны. Инженер оценивает результат проверки и либо подтверждает развертывание кода на целевую инфраструктуру, либо сначала устраняет обнаруженные недостатки.

Организация работы с Ansible

Что выбрать: DSC или Ansible

Terraform это опенсорс-инструмент IaC (инфраструктура как код), который предоставляет согласованный рабочий процесс в CLI для управления сотнями облачных сервисов. Terraform преобразует облачные API в декларативные файлы конфигурации.

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

В статье рассмотрим несколько способов подготовки инфраструктуры в разных окружениях. У каждого из них есть свои преимущества и недостатки.

Введение

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

Раз Terraform это инструмент IaC, мы прописываем инфраструктуру в коде, поэтому ее можно приспособить для разных окружений с помощью модульного подхода.
Рассмотрим способы создания инфраструктуры в нескольких окружениях.

Предварительные требования

Если у вас еще нет опыта работы с Terraform, сначала лучше почитать эту статью.

Используем папки метод 1

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

Папка представляет отдельное окружение. У вас может быть бэкэнд в каждой папке, а может не быть ничего общего между папками. В каждой папке могут находиться файлы outputs.tf, providers.tf, variables.tf и т. д. При выполнении команд terraform приходится переходить в соответствующую папку и выполнять три команды: init, plan, apply.

Использование папок (метод 1)

Преимущества:

• для каждого окружения можно легко добавлять или удалять ресурсы,
• изменения в одном окружении не влияют на другие окружения.

Недостатки:

• дублирование кода;
• если нужно изменить ресурс, приходится делать это во всех окружениях.

Используем папки метод 2

Здесь у нас одна и та же инфраструктура в общих файлах, но для каждого окружения есть отдельный файл terraform.tfvars. Это не идеальный вариант, если у вас разные инфраструктуры во всех окружениях.

Раз файлы main.tf и variables.tf у нас одинаковые, при выполнении команд terraform мы передаем разные переменные в зависимости от окружения. Например, если у нас три окружения, для создания инфраструктуры мы должны выполнить следующие три команды:

// Dev Environmentterraform plan --var-file="tfvars/environment/dev.tfvars"// QA Environmentterraform plan --var-file="tfvars/environment/qa.tfvars"// Prod Environmentterraform plan --var-file="tfvars/environment/prod.tfvars"

Использование папок (метод 2)

Преимущества:

• код не дублируется;
• если нужно изменить ресурс, не приходится делать это во всех окружениях.

Недостатки:

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

Воркспейсы

Terraform начинается с одного воркспейса с именем default. Это дефолтный воркспейс, который, в отличие от остальных, невозможно удалить. Если вы никогда явно не использовали воркспейсы, значит, вы работали только в воркспейсе default.
Воркспейсы управляются командами terraform workspace. Существует целый набор таких команд. Например, terraform workspace new создает воркспейс.

Модули

Модуль это контейнер для нескольких ресурсов, которые используются вместе. В каждой конфигурации Terraform есть хотя бы один модуль root-модуль. Root-модуль обычно состоит из ресурсов, определенных в файлах с расширением .tf в главном рабочем каталоге.

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

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

Несколько окружений

Terragrunt

Terragrunt это тонкая обертка, которая предоставляет дополнительные инструменты для соблюдения принципа DRY в конфигурациях, работы с несколькими модулями Terraform и управления удаленным стейтом.

Подробнее об этом на их официальном сайте.

Итоги

• Terraform это опенсорс-инструмент IaC, который предоставляет согласованный рабочий процесс в CLI для управления сотнями облачных сервисов.
• Обычно мы деплоим инфраструктуру в нескольких окружениях, которые мы используем для разработки, стейджинга, тестирования и продакшена.
• Есть пять способов написать многоразовый код для разных окружений в Terraform.
• Самый популярный из них папки. Работать с папками можно двумя методами.
• Terraform начинается с одного воркспейса с именем default. Это дефолтный воркспейс, который, в отличие от остальных, невозможно удалить.
• Модуль это контейнер для нескольких ресурсов, которые используются вместе. Использование модулей можно настроить таким образом, чтобы один и тот же модуль подходил для разных окружений без изменения кода.
• Terragrunt это тонкая обертка, которая предоставляет дополнительные инструменты для соблюдения принципа DRY в конфигурациях, работы с несколькими модулями Terraform и управления удаленным стейтом.

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

Для будущих студентов курса Infrastructure as a code in Ansible и всех интересующихся подготовили перевод полезного материала.

Также приглашаем записаться на открытый урок по теме Управление Kubernetes при помощи Kubespray.

• Контроль качества кода terraform fmt -check и terraform validate.
• Предварительный просмотр terraform plan.
• Построение TFLOG=debug terraform apply для дотошной проверки.

Средства статического анализа кода Terraform

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

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

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

• Поддержка сообщества важна, когда дело касается программного обеспечения с открытым исходным кодом. Ну и самое последнее, любые выбранные платформы должны быть написаны на распространенном языке программирования, таком как Go или Python. Если понадобится углубиться в платформу и написать собственные методы, найти инженера с опытом работы с одним языком будет, пожалуй, проще, чем с двумя. Любой предыдущий опыт работы с подобными инструментами, который может быть у имеющихся сотрудников группы и организации в целом, также будет полезен. Итак, теперь я готов отправиться на поиски правильного средства тестирования и платформ для выполнения этой работы.

• tflint github.com/terraform-linters
• terrafirma github.com/wayfair/terrafirma
• tfsec github.com/liamg/tfsec
• terrascan github.com/cesar-rodriguez/terrascan (на данный момент отсутствует поддержка TF 0.13)
• checkov github.com/bridgecrewio/checkov
• conftest github.com/instrumenta/conftest

Выбранные средства тестирования

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

Модульное тестирование Checkov от BridgeCrew

Checkov это инструмент статического анализа кода для инфраструктуры как кода.

Он сканирует облачную инфраструктуру, подготовленную с помощью Terraform, Cloudformation, Kubernetes, Serverless или шаблонов ARM, и выявляет неправильную конфигурацию с точки зрения безопасности и соблюдения нормативных требований.

• Установите двоичный файл.
• Инициализируйте каталог terraform командой terraform init.
• Запустите chechov для этого каталога.

Вывод после работы checkov с указанием пройденных и непройденных проверок.

Terraform-compliance

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

Предыстория

Тестирование с помощью Terraform-Compliance

• Шаг 1. Инициализируйте каталог terraform:# terraform init
• Шаг 2. Можно быстро сформировать terraform plan следующей командой: #terraform plan -out=plan.out
• Шаг 3. Напишите несколько тестов. Дело нехитрое уже есть папка с примерами. Давайте пройдемся по моим собственным примерам тестов, приведенным ниже, написанным на основе моего вывода terraform plan.

• Шаг 4. Давайте заставим terraform-compliance оценить плат с использованием тестовых сценариев: #terraform-compliance -p plan.out -f ./<test-cases-folder>

Выполнение тестов

Результаты тестов

Итоги

Узнать подробнее о курсе Infrastructure as a code in Ansible.

Записаться на открытый урок по теме Управление Kubernetes при помощи Kubespray.

Вспомним классику.

Разработчики с трудом выкатывают фичи раз в год. Зато админы довольны и радостны им больше не нужно уходить с работы, они теперь работают круглосуточно, и руководство их ласково называет нянечки для разрабов. Технологии начинают откатываться. Отладка требует сотни передач из отдела в отдел все с огромным энтузиазмом перекидывают друг другу дохлую свинью через забор. Даже свинья улыбается. Долгое ожидание сервера под проект запросил сервер, получил посмертно, за заслуги перед компанией. Баги в продакшене с полной уверенностью рассчитывают увидеть XXII век. SLA 50% и седые до прозрачной белизны владельцы бизнеса. Упал сервис не проблема, подождём часок или два, пока поднимется. Универсальные инженеры на грани психоза на столе у каждого по две полупустых баночки бензодиазепиновых транквилизаторов и пачка SSRI-антидепрессантов.

Вздрогнули? И с лёгким сердцем обратно в нормальный мир, где есть DevOps-философия и DevOps-инструменты, как часть неё.

19-21 августа пройдёт онлайн-интенсив Слёрм DevOps: Tools&Cheats. Мы покажем IDDQD из мира DevOps.

Да есть книги и мануалы одни дают теорию, другие информацию. Но только на конференциях и интенсивах можно получить практику из первых рук. Именно практику, а не пересказ тех самых мануалов.

Слёрм DevOps: Tools&Cheats:

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

С программой курса и спикерами вы можете ознакомиться и познакомиться на странице интенсива.

Поговорим откровенно? Почему мы создали этот курс? Потому что нас тоже бесит:

• что курсы для практиков ведут теоретики;
• что решением проблем считают не подход, а должность;
• что 80% курсов по девопсу рассказывают о концепции и философии. А инструменты где? Чем гвозди забивать, микроскопом или лучше Macbook Pro?
• бесит, когда к концу обучения забыл, что было в начале, а результатов надо ждать от 6 до 8 месяцев.

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

За эти три дня вы научитесь основным DevOps-практикам, которые позволят:

• организовать командную работу с Git;
• автоматизировать рутинные операции;
• настроить мониторинг и интегрировать его с мессенджерами;
• развернуть серверы, используя подход Infrastructure as Code;
• обеспечить процесс CI;
• И ещё немного практических читов из реальной работы.

Слёрм DevOps пройдет с 19 по 21 августа 2020. Каждый день начинаем в 10:00 и заканчиваем в 19:00, с перерывами на чай и обед.

Инструменты DevOps + IDDQD + IDKFA и за работу. И пусть кто-то только попробует помешать.

Привет, Хабр! Меня зовут Саша Козлов, я занимаюсь разработкой инфраструктуры и системным администрированием вАвито последние три споловиной года. Я расскажу, как мы масштабировали и модернизировали современем нашу работу синфраструктурным кодом и вывели её накачественно новый уровень.

Мы отвечаем заполный цикл управления оборудованием: отзакупки и монтажа вДЦ додоставки доконечного потребителя. Речь пойдёт обуроках, которые мы вынесли запоследние несколько лет, работая стысячей единиц оборудования и несколькими тысячами единиц конфигурирования.

Речь пойдёт обинструментах первого поколения IaC, таких как Ansible, Chef, Salt, Puppet. Если вы имеете дело сon-premises инфраструктурой, и увас нет своего облака навиртуализации, то, скорее всего, вы уже используете один изэтих инструментов.

Исторически вАвито используется Puppet. Вкакой-то момент мы столкнулись снеобходимостью обновить его, поскольку использовали очень старую версию, которую Puppetlabs давно перестали поддерживать. Но мы поняли, что сделать это невозможно, поскольку кодовую базу, которая натот момент у нас была, невозможно было просто перенести напоследнюю версию. Это заставило нас критически подойти ктому, как мы разрабатываем инфраструктурный код и вообще правильный ли инструмент мы используем.

Хорошие практики важнее выбора правильного инструмента

Напервый взгляд, инструменты управления инфраструктурой очень разные. Некоторые требуют, чтобы нанодах был запущен специальный агент. Где-то используется push-модель, где-то pull, но впринципе ничего не мешает запускать ansible накаждой машине покрону и получить pull-конфигурации. Содной стороны Python, Jinja-шаблоны и YAML-программирование, сдругой DSL и Ruby. Многие инструменты включают всвою экосистему дополнительные компоненты: дашборды, хранилище конфигурации вроде PuppetDB, централизованный компонент, который хранит и распространяет навсе ноды ваш инфраструктурный код.

Слюбым инструментом подобного рода не получится работать синфраструктурным кодом ровно так же, как работает скодом разработчик сервиса. Далеко не все изменения откатываются через git revert, сама выкатка этих изменений не происходит одновременно навсей инфраструктуре, а применяется постепенно. Конфигурация влюбом случае остаётся мутабельной, а это значит, что всё равно придётся держать вголове текущее состояние машины. А А не то же самое, что 0 А. Многие такие особенности приходится учитывать.

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

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

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

Определите границы применимости инструмента

Любой инструмент имеет свои сильные и слабые стороны. Поэтому важно понимать границы его применимости: где его следует использовать и, что не менее важно, где не следует.

Puppet очень гибок, местами даже слишком. Он впостоянном цикле приводит состояние инфраструктуры кописанному в коде виду, т.к. использует pull-модель. Как следствие этого недостаточно хорошую обратную связь и задержку при применении изменений. По умолчанию конфигурация применяется раз в 30минут, поэтому длязадач, требующих более динамичного управления, Puppet не подходит. Кроме этого, внём нет event-driven автоматизации, как вSalt, что также ограничивает область его применения.

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

Для себя мы определили границы так: применяем Puppet дляконфигурирования железных нод и stateful-контейнеров, но не используем его длядеплоя сервисов, конфигурации рантайма инфраструктурных сервисов и других быстро меняющихся вещей. Например, мы постепенно отходим отуправления DNS-записями через Puppet, который сложился унас исторически. Мы хотим, чтобы управление было более динамическим, поэтому этим занимается инфраструктурный сервис, предоставляющий свой API.

Правильный выбор структуры кода и уменьшение связанности кода

Мы долго складывали весь инфраструктурный код водной репе, но помере увеличения команды это стало проблемой. Стало сложнее договариваться отом, как лучше писать код. Появились сабрепозитории длятех частей кода, которыми владеют инженеры издругих команд, а работать ссабмодулями вgit не очень удобно. Приэтом изменения восновных частях кода выкатывались сразу навсю огромную инфраструктуру Авито. Цена ошибки стала очень велика.

Поэтому мы выделили основные сущности: control repo и модули. Каждая находится вотдельном git-репозитории. Сами тут ничего особенно не придумали, просто обратились клучшим практикам дляPuppet-кода, которые описаны встатье "The roles and profiles method".

Control repo это репозиторий синфраструктурным кодом. Внём находится тот код, который выкатывается через CI-систему напаппет-сервер и применяется намашинах. Роль это некоторая типовая конфигурация, способ сгруппировать машины содинаковыми настройками. Это самый высокоуровневый слой абстракции условно, ответ навопрос чем занимается эта машина?. Примеры ролей: k8s-нода кластера Х, нода Kafka встейджинг окружении дляшины данных, ClickHouse-нода и т.п.

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

Роли и профили описываются вcontrol repo, а модули подключаются внеё как внешние зависимости и применяются внутри профилей или ролей.

Модуль это подключаемая библиотека, код, который занимается настройкой определённого инфраструктурного компонента, как правило переиспользуемый. Модули релизятся отдельно отcontrol repo, версионируются поsemver и подключаются как зависимости. Унас сейчас порядка 50 модулей: модуль дляработы ссекретами, настройки различных БД, конфигурирования кластеров Kubernetes и другие.

Вопрос, как структурировать код, насамом деле не очень прост в случае сPuppet. Единственно правильного ответа нанего нет. Далеко не всегда ясно, что должно считаться одной ролью, а вкаких случаях профиль нужно пилить нанесколько. Нужно ли сразу делить код намодули, или можно допоры довремени складывать всё вcontrol repo?

Здесь всё зависит отразмера инфраструктуры, её разнородности и количества инженеров, которые занимаются разработкой инфракода. Дляначала вполне подойдёт просто иметь control repo и весь код писать вней, организуя его впрофили. Унас вАвито инфраструктурой занимается несколько команд, длякаждой важны разные вещи. Одним важнее стабильность, а не скорость внесения изменений, поэтому они обложили код кучей тестов. Другим не подошла стандартная схема тестирования вDocker, и пришлось настроить свою. Поэтому унас несколько control repo, поодной натакую команду. А чтобы можно было переиспользовать решения и не дублировать код, мы пишем модули.

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

• Building a Functional Puppet Workflow Part 2: Roles and Profiles
• Roles and Profiles in a Control Repo?
• Workflows Evolved: Even Besterer Practices
• Profiles and the Path to Hiera Data
• Puppetlabs Best Practices Docs

А ещё на своём Гитхаб-аккаунте мы поделились шаблоном модуля и control repo, который используем усебя. Вшаблонах можно посмотреть пример того, как организовать код, а ещё там есть инструменты, которые нужны длязапуска всех видов тестов:

• puppet-controlrepo-template
• puppet-module-template

Используйте External Node Classifier вместо регулярных выражений

Ну хорошо, есть роли, профили и модули но как именно определяется то, какой код накакой машине выполнять?

Достаточно долго мы использовали node definitions и регулярные выражения, чтобы определять то, какие машины каким кодом настраиваем. Такой подход нормально работает нанебольшой инфраструктуре, но помере её роста вы скорее всего получите что-то похожее на это:

node /^avi-ceph(2[1-9]|3[0-9]|4[0-9]|5[0-9]|6[0-9]|7[0-9]|8[0-9]|9[0-9])/ {...}

Одна неправильно закрытая скобка тут может привести кполному краху. Поиск потакому коду не работает невозможно быстро разобраться, какой код выполняется наотдельно взятой машине. Вобщем, такой подход казался разумным вначале, но современем оказался неудачным. Дляпривязки машин кнаписанным ролям Puppetlabs предлагает использовать External Node Classifier.

External Node Classifier это компонент, который хранит всебе то, какую роль следует применить ккаждой ноде. Он даёт возможность винфракоде описывать только роли, а логику привязки ролей кконкретным машинам вынести вовнешнюю систему. Навход ENC принимает имя ноды и отдаёт некий набор параметров, которые вкоде становятся доступны как top-scope variables. Вкаждой control repo есть примерно такой код, который обеспечивает привязку ноды кроли, и это единственное место, где используется node definition:

node default {  include base # применяем базовый слой конфигурации, общий для всех control repo  if $::role != '' {    notify{ "Node ${::fqdn} has role ${::role}": loglevel => info }    include "role::${role}"  } else {    notify{ "Node ${::fqdn} has no role": loglevel => warning }  }}

Вкачестве ENC может выступать любая система, ведь логику получения и формирования ответа вы пишете сами. Такой системой внашем случае стала CMDB, внутренняя система учёта оборудования и его комплектующих. Наш CMDB основан наnetbox отDigital Ocean, сильно доработанном поднаши нужды. Он плотно интегрирован сrazor, системой провижнинга железа, и умеет собирать всевозможные данные ожелезе, которое установлено вдата-центре.

Дляподготовки сервера кработе винтерфейсе CMDB мы указываем нужный паппет-сервер и роль, отправляем сервер напереналивку и через 15-20минут получаем готовый кработе сервер, ккоторому уже применена конфигурация, описанная вроли.

Упростите процесс предварительной настройки серверов

Почему так важно иметь простой способ получить чистую конфигурацию? Длятого, чтобы уменьшить влияние Configuration Drift, который современем будет неизбежно накапливаться. Configuration Drift это неконсистентность конфигурации машины, описанной вкоде, поотношению кеё фактическому состоянию. Его источники это ручные изменения намашинах, тестирование гипотез, ресурсы, которые приизменении вышли из-подуправления Puppet.

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

В идеале нужно иметь возможность получить чистое состояние, отправив машину впереналивку простым API-вызовом. Мы делаем это через netboxAPI, который расширили подсвои нужды. Подкапотом там загрузка поPXE и netboot-образ Debian, шаблонизация preseed'ов наоснове параметров, переданных вAPI, много низкоуровневой настройки и взаимодействия поIPMI черезRedfish API. И, конечно же, болей, связанных сразной его реализацией уразных вендоров.

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

Настройте инструменты тестирования инфраструктурного кода

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

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

Когда мы перешли с3.7 на6 версию Puppet, то поняли, что появилась куча крутых инструментов длятестирования. Последовательность тестирования инфраструктурного кода выглядит так:

1. Запуск линтера.
2. Юнит-тесты.
3. Приёмочные тесты

Наэтих трёх шагах мы делаем следующее:

1. Проверяем валидность синтаксиса, соответствие стайлгайдам и т.п.
2. Проверяем, что код компилируется вкаталог, отлавливаем ошибки duplicate resource declaration. Вэтих тестах можем зафиксировать определённый контракт: например, код должен содержать ресурс сервис, который должен рестартовать приизменениях вопределённых файлах.
3. На стадии приёмочных тестов применяем код вDocker-контейнере, проверяем, что сервис работает припомощи inspec.

  context 'application deployment' do    it 'can deploy an application into a namespace and expose it' do      shell('systemctl restart kubelet')      shell('count=0;        while [[ $(kubectl get pods -n tiller -l name=tiller -o \'jsonpath={..status.conditions[?(@.type=="Ready")].status}\') != "True" ]];          do            if [[ count -gt 180 ]]; then              break;            fi;            sleep 1 && ((count++));          done')      shell('kubectl create -f /tmp/nginx.yaml', acceptable_exit_codes: [0]) do |r|        expect(r.stdout).to match(%r{namespace/nginx created\nconfigmap/my-nginx-config created\ndeployment.apps/my-nginx created\nservice/my-nginx created\n})      end    end    it 'can access the deployed service' do      shell('count=0;        while [[ $(kubectl get pods -n nginx -l run=my-nginx -o \'jsonpath={..status.conditions[?(@.type=="Ready")].status}\') != "True" ]];          do            if [[ count -gt 180 ]]; then              break;            fi;            sleep 1 && ((count++));          done')      shell('curl --connect-timeout 1 --retry-delay 1 --retry-max-time 300 --retry 150 -s --retry-connrefused 10.100.10.5', acceptable_exit_codes: [0]) do |r|        expect(r.stdout).to match %r{Welcome to nginx!}      end    end end

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

Вот список инструментов, которые помогут помочь настроить тестирование инфракода:

• puppet-syntax
  
• puppet-lint
• rspec-puppet
• puppetlabs-spec-helper
• test-kitchen, и пример его использования для Puppet: kitchen-docker-puppet-example
• beaker

И неплохая статья про юнит-тестирование:

• Unit testing with rspec-puppet for beginners

Development kit для инфраструктурного кода

Если хотите, чтобы разработчики инфракода использовали CI/CD или проверяли свой код допуша врепу снабдите их инструментом, который поумолчанию поддерживает необходимый workflow.

В паппет-экосистеме есть отличный инструмент PDK, который активно используется всообществе. Но его мы использовать не стали, потому что он был несовместим снашим инструментарием, и пришлось бы многое дорабатывать. ВPDK впервую очередь не хватило возможности работать сcontrol repo и тестирования сиспользованием Kitchen и Docker. Длятестирования PDK использует Beaker, укоторого довольно высокий порог входа.

Поэтому мы написали свой инструмент, который позволяет:

• Создать изшаблона пустой проект, готовый кработе: тесты, CI пайплайны и прочее.
• Сгенерировать заготовки дляманифестов, тестов, паппет-функций.
• Запускать статические валидаторы кода, юнит-тесты, приёмочные тесты.
• Разрешить зависимости вcontrol repo, показать, есть ли более новые версии зависимостей.
• Сгенерировать документацию вмаркдауне издокстрингов.
• Собрать модуль и запушить вовнутренний репозиторий.

Когда разработчик инфракода создаёт новый модуль припомощи development tool, он сразу получает репозиторий снастроенными сборками наCI длястатического анализа, запуска тестов и релиза модуля.

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

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

Об управлении зависимостями в инфраструктурном коде

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

В управлении зависимостями вPuppet есть много странных и неочевидных вещей. Например, зависимости вмодулях можно указывать двумя разными способами: metadata.json и Puppetfile. Они немного отличаются посвоим возможностям, и разные инструменты по-разному их обрабатывают. Официально поддерживаемого инструмента поразрешению зависимостей нет. Есть librarian-puppet, который, вотличие отофициального r10k, умеет резолвить зависимости второго и высших порядков. Но проект давно не развивается и не имеет нормальной документации, хотя задачу свою вцелом выполняет. За неимением лучшего инструмента взяли его он применяется везде, где требуется резолв зависимостей: вacceptance-тестах и придеплое кода напаппет-сервер.

Достаточно долго мы искали подходящий путь. Сначала подключали модули как гит репу, а версионировали git-тегами, вот так:

mod 'dba-clickhouse',  :git => 'ssh://git@github.com/iac/dba-clickhouse.git',  :ref => '1.2.2'mod 'dba-kafka',  :git => 'ssh://git@github.com/iac/dba-kafka.git',  :ref => '1.2.0'

Такой способ работает, но требует явно указывать версию модуля, и не даёт завязаться намажорную или минорную версию. Дляболее гибкого версионирования придётся поднять собственный локальный Puppet Forge, загружать модули внего, а зависимости резолвить черезlibrarian-puppet.

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

# Puppetfilemod 'arch-puppetserver', '0.20.5' # подключаем строго указанную версию модуляmod 'arch-vault', '~> 2.1' # подключаем модуль в пределах мажорной версииmod 'si-lxc' # используем самую последниюю версию

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

[22:39:43] in dba-control on  production via  ruby-2.5.1 at   unstable $ iack dep show[] Collecting modules metadataFULL NAME            | CURRENT VERSION | LATEST VERSION | OUT OF DATE?  ---------------------|-----------------|----------------|---------------si-lxc               | latest          | 0.3.2          | N/A           si-base              | latest          | 1.3.1          | N/A           petems-hiera_vault   | v0.4.1          |                | Majorarch-vault           | 2.1.0           | 2.1.0          | No   dba-postgresql       | 0.1.2           | 0.1.3          | Tiny dba-pgbouncer        | 0.4.0           | 0.5.1          | Minorsi-grub              | 0.1.0           | 0.1.0          | No   si-collectd          | 0.2.3           | 0.2.4          | Tiny si-confluent         | 0.3.0           | 0.3.0          | No   dba-redis            | 0.2.3           | 0.2.3          | No   dba-collectd_plugins | latest          | 0.2.0          | N/A           dba-mongodb          | 0.2.1           | 0.2.1          | No   dba-patroni          | 0.1.4           | 0.2.4          | Minordba-cruise_control   | 0.1.1           | 0.1.2          | Tiny dba-lxd              | 0.7.0           | 0.7.0          | No   dba-clickhouse       | 1.2.1           | 1.2.2          | Tiny dba-zookeeper        | 2.0.0           | 2.0.0          | No   si-td_agent          | 0.1.0           | 0.1.0          | No   dba-kafka            | 1.1.6           | 1.2.1          | Minorarch-puppetserver    | 0.20.1          | 0.20.2         | Tiny pcfens-filebeat      | 4.1.0           | 4.4.1          | MinorKyleAnderson-consul  | 5.0.3           | 6.0.1          | Majorpuppetlabs-apt       | 6.3.0           | 7.4.2          | Majorpuppetlabs-stdlib    | 5.2.0           | 6.3.0          | Major

Вот несколько полезных ссылок потеме:

• Managing environment content with a Puppetfile
• puppet-forge-server сервер на ruby Sinatra, который может работать как внутренний репозиторий модулей и зеркало внешнего Puppet Forge
• librarian-puppet

О важности code style и документации дляинфраструктурного кода

Почему так важно иметь code style вразработке инфраструктурного кода? Всё как и слюбым другим кодом инфраструктурный код пишется один раз, а читается потом десятками людей напротяжении лет. Поэтому нужен некий стандарт, описывающий лучшие практики, который облегчит чтение кода и его поддержку, адаптацию новых инженеров. Он также упрощает и процесс review кода проще урегулировать спорные моменты, кинув ссылкой наподходящий пункт издокумента.

В Puppet сэтим всё отлично. The puppet language style guide содержит все основные рекомендации понаписанию кода. Puppet-lint, который мы запускаем наCI, проверяет соблюдение этих рекомендаций и позволяет добавлять внего собственные проверки.

Внутри Авито мы его немного расширили и дополнили его своими, более высокоуровневыми правилами и рекомендациями. Их мы выложили вместе с шаблонами модулей и control repo:

• Avito Module Coding Standards
• Avito Control Repo Coding Standards

Поскольку мы используем свой development kit, важно облегчить процесс онбординга новых инженеров и адаптации старых:

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

Удобное управление секретами это важно

Управление секретами дляинфракода должно быть удобным и простым, иначе секреты начинают коммитить вкод. ВPuppet управление секретами удобно делать черезинтеграцию Hiera и Vault. На Гитхабе есть hiera-backend, который позволяет получать их значения прямо изvault черезhiera_lookup.

Для работы ссекретами вАвито есть модуль-обёртка, который позволяет либо получить секрет впеременную, либо положить файл-секрет вопределённое место всистеме. Первый способ работает через функцию, которая вызывается вкоде вот так:

$token_data = vault::secret_field('tokens.csv', 'data')

В этом примере впеременную token_data получаем значение поля 'data' изсекрета tokens.csv, который находится вVault. Всамом Vault секреты хранятся иерархически, также, как вHiera:

$ vault-util ls puppet/arch/      common/nodes/roles/

Таким образом, если мы хотим иметь общее значение секрета длявсех машин, достаточно положить его вcommon. Если оно разное длякаждой роли или ноды вroles/ или nodes/.

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

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

• avito-vault

Canary релизы инфраструктурного кода

В Puppet есть интересный механизм, который позволяет выкатить код изветки control repo. Все ветки репозитория control repo отображаются наокружении, а каждая нода принадлежит кодному из них. Информация обэтом отдаётся изENC вместе сименем роли.

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

Это ещё один, финальный, способ протестировать свои изменения, и не уронить систему.

О достоинствах и недостатках Puppet

Если говорить одостоинствах Puppet, я бы назвал отличную документацию, развитый тулинг вокруг, очень большую гибкость и расширяемость инструмента. Если не хватает возможностей DSL его можно расширять наRuby. Hiera отличное решение дляхранения параметров, которые передаются вроли. Можно обеспечить максимальную стандартизацию инфраструктуры, приэтом сохранить возможность внести изменения сгранулярностью доконкретной машины. Данные вHiera можно выносить вразличные бэкенды, а если не хватает подходящего, можно написать свой.

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

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

Ещё один недостаток плохая обратная связь привнесении изменений. Он впринципе присущ всем инструментам, работающим поpull-модели. Неизвестно, вкакой момент времени применятся изменения, которые попали вмастер. Длянекоторых задач это становится критичным, и приходится изобретать велосипеды, чтобы pull превратить вpush. Bolt, который Puppetlabs предлагает дляподобных задач, выглядит странно, сложно интегрируется сPuppetDB, и отего использования мы пока отказались.

Суммируя

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

1. Вместо безупречного инструмента концентрируемся наулучшении тулинга и практик, которые применяем приразработке.
2. Определяем границы применимости каждого инструмента и фиксируем их.
3. Стараемся уменьшать связанность инфраструктурного кода и более контролируемое применение изменений засчёт версионирования его частей.
4. Тестируем код и обеспечиваем быструю обратную связь привнесении изменений.
5. Обеспечиваем запуск тестов наCI и вывод их результатов приревью кода.
6. Используем пайплайны и инструменты, которые поддерживают необходимый workflow дляинфраструктурного кода.
7. Используем External Node Classifier вместо регулярок.
8. Упрощаем процессы предварительной настройки серверов.
9. Обеспечиваем безопасное и удобное получение секретов винфраструктуру.

Отвечая на вопросы, которые я получил после этой публикации, сегодня хотел бы разрешить бесконечный спор о структуре репозитория, а так же затронуть некоторые проблемы и их решения. Здесь я буду пользоваться своим IaC, основанным на Terraform, но по большей части всё будет применимо и к другим технологиям.

Если говорить о репозиториях инфраструктуры есть два устоявшихся варианта:

• Monorepo. Один репозиторий для управления всем. Содержит всю вашу IaC, модули и любую вспомогательную автоматизацию;
• Распределенные, автономные репозитории. Содержат компоненты, необходимые для решения, которое вы предоставляете. Они могут ссылаться на другие репозитории для повторно используемых компонентов или переменных данных.

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

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

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

• Возможность ссылаться на общий стек или базовые настройки. Обычно такое получается, если у вас есть рабочее пространство terraform или отдельный файл состояния для вашего основного VPC или сети, обеспечивающих вашим подсетям основное подключение. Обычно они идут в виде выходных данных, вместо использования ресурсов позже в других частях кода.
• Простота продвижения изменений из окружения А в окружение А + 1. Нужно наличие возможности быстрого сравнения окружений и безопасного продвижения изменений, сохранив при этом читаемость кодовой базы. В растущем окружении вы возможно захотите быстро найти что изменилось или в чем разница.
• Гармония программных продуктов. Никто не использует отдельно Terraform, точно так же как не используется Ansible, Puppet или Kubernetes для запуска всего в вашей компании. Структура репозитория должна включать в себя различные, используемые вами инструменты, и предлагать инженерам интуитивное или, по крайней мере, хорошо задокументированное руководство по использованию или внесению изменений.
• Оставаться простым, но не слишком простым. Согласно твиту от Jaana, простота не всегда легка, или достижима в большинстве случаев. Чрезмерное упрощение или оптимизация приведут к положению, препятствующему любой значимой скорости. Проектируйте, обеспечивая скорость изменений и простоту тестирования изменений. Сохраняйте гибкость, поскольку новые требования и запросы всегда а я в этом уже уверен придут оттуда, где их не ждешь.
• Гладкая кривая обучения. Не все будут с одинаковым опытом и уровнем навыков. Нужно проектировать и документировать для интуитивного использования и простого вовлечения новых инженеров. Чрезмерно сложное решение, красивое на первый взгляд, потребует много времени вашей команды по вовлечению, обучению и устранению неполадок.

Простое решение.

Начиналось вроде как просто X vs Y, но теперь выглядит примерно так:

Какой лепесток не дернете придете к компромиссу, поскольку в его основе инженерное дело.

Чего не надо делать

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

Избегайте (слишком большой) вложенности модулей

Сложить матрешкой git submodules или модули terraform заманчиво, но можно легко попасть впросак, пытаясь найти комбинацию репозитория\ветки\каталога, где размещен модуль, а также молиться, чтобы не было другого модуля где-нибудь еще, на который этот ссылается. Модуль вне кодовой базы редко обновляется. А когда все-таки обновится в лучшем случае вы потратите время, а в худшем что-то отломается.

Избегайте симлинков

Я как-то видел реализацию, модули которой были в виде каталогов символических ссылок в окружении, где они запускались. Если от такого заранее не трясутся поджилки попытка найти модуль по ссылке может стать ужасом, особенно зная, что ваши изменения обязательно к этому приведут. В конце концов эта реализация была прошита файлами provider-module.tf, связанными с многими экземплярами модулей\окружений. Если не хотите слететь с катушек просто используйте инструменты Terragrunt и подобные.

Займите полосу

Выберите стратегию контроля версий и держитесь ее.

Желаете использовать ветки, чтобы разделять стабильные модули и находящиеся в разработке? Действуйте! Хотите применять метки git для проверки, что версии модуля уже пригодна к тестированию и предварительному внедрению? Шикарно! Захотелось использовать папки в репозитории, чтобы собрать все модули в одном репозитории вместо того, чтобы каждый модуль держать в отдельном репозитории? Так тому и быть, раз оно работает в вашем конкретном случае, если оно соотвествует вашей операционной модели.

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

Что же делать?

Работайте командой, с вашими пользователями, для ваших заказчиков

Неважно, руководите вы платформой в ветке\канале\организационном подразделении или отделом DevOps\SRE\платформы\инфраструктуры\сети\<подставьте свое имя здесь>, обслуживающим боооольшое предприятие, ваши пользователи (читай разработчики, тестировщики, бизнес-аналитики, ...) это те, кто будет использовать вашу платформу для обеспечения ценности ваших клиентов. И то, что они запрашивают будет прямо или косвенно способствовать счастью ваших клиентов. Слушайте их, собирайте требования (Я хочу легко и непринужденно настраивать этот неломаемый параметр в среде для проверки производительности, не проходя каждый раз эти десять шагов) и адаптироваться к ним или вместе с ними. Счастливые пользователи, соотвественно, будут лучше работать и делать ваших клиентов счастливее.

Помечайте со смыслом

Если используете метки git для своих модулей, убедитесь, что у вас они адекватно стандартизированы. Всякий раз, как вы видите метку вида 1.0.234, полностью несовместимую с предыдущими версиями поправьте ее и сделайте лучше.

Не раздавайте бездумно права на ветки и PR

Добавьте контроль там, где он будет наиболее уместен. Не забывайте, что люди с инженерным складом ума всегда будут искать более простой и удобный способ выполнения своей работы. А если вы поставите слишком много препятствий перед ними они найдут способы обхода. Защитите ключевые части вашей инфраструктуры, добавьте мосты в виде review и approval там, где, по вашему мнению, расположены точки принятия решений по продвижению.

Оптимизируйте репозитории

Клонирование занимает слишком много времени? Теряете кучу времени, пролистывая и заходя в каталоги в одном и том же репозитории, чтобы найти то, что, как вы знаете, где-то там лежит? Значит, крайне вероятно пришло время разбить репозиторий на части, сделать их более полезными и простыми в использовании.

Не раздувайте модули сверх нужного

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

На практике это звучит так: если вы тратите больше времени, чтобы понять, что делает модуль, чем обычно вам нужно для прочтения документации по ресурсам в Terraform Docs этот модуль вам скорее всего не нужен.

Что мне нравится делать

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

Решение 1: Инфраструктурный репозиторий + репозитории модулей на каждое организационное подразделение

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

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

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

module "ecr_<repo_name>" {   source      = "git::ssh://<repository/terraform-modules.git//ecr?ref=stable"   environment = var.environment   name        = "<repo_name>"}

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

Решение 2: Monorepo с логическими компонентами

Для мелких подразделений\компаний\проектов мне больше нравится подход с ветками master и develop, которыми разделены prod и non-prod окружения. При таком подходе, совмещенном с рядом расположенными модулями, права на ветки и автоматические применения предоставляют более быстрое внесение изменений и упрощение работы за счет некоторого разделения обязанностей.

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

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

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