Что такое инфраструктура как код?

Инфраструктура как код (IaC) — это подход к созданию и настройке инфраструктуры аналогичный процессу разработки ПО. То есть продумывается архитектура, прописываются процессы, устанавливается взаимодействие инфраструктурных элементов между собой. Всё это описывается в специальных форматах, предназначенных для описания иерархических систем: yaml, json, xml и аналогичные им форматы.

Философия IaC основывается на принципах «единого источника правды», согласно которому — исполнение одного и тот же кода формирует одну и ту же исполняемую среду. Благодаря такому подходу достигается единообразие элементов инфраструктуры и их ожидаемое поведение, а также идемпотентность, как свойство системы принимать одно и то же состояние при одинаковых условиях вызова.

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

Из главных преимуществ использования IaC можно отметить следующие:

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

Сейчас IaC — это одна из доминирующих концепций в DevOps. Она стала так популярна в первую очередь благодаря повышению скорости разработки, тестирования и возможности внедрения непрерывного развертывания (CI/CD). Сама концепция IaC проста и прозрачна, а многие инструменты работы с ней имеют невысокий порог вхождения, например — Ansible (Linux) или Octopus deploy (Windows).

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

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

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

Два подхода как вы можете конфигурировать сервера:

руками — если вы конфигурируете их руками, у вас соответственно может получиться такая ситуация, что у вас production настроен одним образом, тест другим, на тесте все зеленое, тесты зеленые. Вы деплоите на production, а там не стоит какой-то фреймворк — у вас ничего не работает.
Другой пример: три Application сервера настроены руками. Один Application сервер настроили одним образом, другой Application сервер другим образом. Сервера могут работать по-разному.
Еще пример: была ситуация, когда у нас один Stage сервер полностью перестал работать. Запустили создание нового сервера используя и через 30 сервер был готов.
Еще пример: сервер просто перестал работать. Если настраивали руками, то нужно искать человека, который знает как его настраивать, нужно поднимать документацию. Как мы знаем, документация вряд ли бывает актуальной. Это большие проблемы.
И, самое главное, — это аудит, то есть грубо говоря, у вас есть десять администраторов, каждый из них что-то руками настраивает, то не особо понятно корректно они это настроили или некорректно, и как вообще понять, нужно ли делать какие-то настройки, могли что-то лишнее поставить, открыть какие-то ненужные порты.
Есть альтернативный вариант — это как раз то, про что мы сегодня говорим — это конфигурирование из кода. То есть у нас есть git репозиторий, в котором вся инфраструктура хранится. Там хранятся все скрипты, с помощью которых мы будем это настраивать. Поскольку это все в git, мы получаем все преимущества от управления кодом, как в разработке, то есть мы можем делать ревью, аудит, историю изменений, кто сделал, почему сделал, комментарии, можем откатываться. Чтобы работать с кодом нужно использовать конвейер непрерывной сборки — конвейер развертывания. Чтобы какая-то система именно вносила изменения в сервера, то есть не человек что-то руками делал, а исключительно делала это система.

В качестве системы, которая вносит изменения, мы используем Ansible. Поскольку у нас нет огромного количества серверов, он нам вполне подходит.

Если у вас там 100-200 серверов, то у вас будут небольшие проблемы, потому что он (т.е. Ansible) все-таки соединяется с каждым и по очереди их настраивает — это проблема. Лучше другие средства использовать, которые не пушат (push), а пулят (pull). Но для нашей истории, когда у нас много проектов, но серверов не больше 20 — нам это вполне подходит.

Очень важный момент — если вы катите инфраструктуру через какие-то скрипты, через код, то если у вас все же остаются ручные манипуляции серверами, то это потенциальная уязвимость. Потому что допустим, вы на тестовый сервер поставили java, написали роль ELK, накатили ее. Деплой в тест прошел успешно. Деплоите в production, а там java нет. А java в скрипте вы не указали — деплой в production упал. Поэтому нужно забрать права со всех серверов у администраторов, чтобы они руками туда не залезали и все изменения вносили через git. Весь этот конвейер мы сами проходили. Здесь есть одно но — не надо сильно закручивать гайки. То есть нужно внедрять такой процесс постепенно. Потому что он все еще необкатанный. В нашем случае мы оставили доступ до всех систем у самого главного руководителя администраторов на случай непредвиденных инцидентов. Доступ выдан с условием, что он не будет ничего руками настраивать.

Выводы

Во-первых, мы получили документацию, то есть когда приходит менеджер и меня спрашивает: на каком порту у нас слушает база данных, я открываю Ansible скрипт в git репозитории, говорю: “Вот смотри, вот на таком-то порту”. Какие у нас здесь настройки? Все это видно в git репозитории. Это можно аудировать, показывать менеджерам и так далее. Это 100% достоверная информация. Документация устаревает. А в данном случае ничего не устаревает.

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

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

Быстрое восстановление после аварии. Если вы упали, вам нужно искать человека, который может эту машину настроить, который знает, как ее настроить, который помнит, как ее настроить. В данном случае все настройки и скрипты развертывания находятся в git. Даже если человек уволился, перешел в другой проект — все находится в git, все в комментариях, все видно: почему он открывал такой порт, почему ставил такие-то настройки и так далее. Вы все можете легко восстановить.

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