8.2 Инфраструктура как код и конфигурация

Обзор и мотивация

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

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

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

Ключевые принципы

Предпочитайте декларативные определения, описывающие желаемое состояние, императивным скриптам, описывающим шаги.
Храните все определения инфраструктуры под контролем версий и рецензируйте, как любой другой код.
Воспринимайте инфраструктуру как неизменяемую: заменяйте, а не изменяйте на месте.
Делайте подготовку идемпотентной, так что повторное применение того же определения даёт тот же результат.
Обнаруживайте и согласуйте дрейф, расхождение живой среды с её объявленным определением, непрерывно; источник истины код, а не живая система.
Составляйте инфраструктуру из повторно используемых версионируемых модулей, а не копированием и вставкой.
Кодируйте политику как код, организационные правила, выраженные машинно проверяемым кодом, так что ограждения автоматические, а не рекомендательные.
Держите секреты вне определений; ссылайтесь на них из выделенного менеджера секретов.

Компромиссы: плюсы и минусы

Выбор	Плюсы	Минусы	Лучше всего подходит
Декларативная IaC (Terraform/Pulumi)	Воспроизводимо, рецензируемо, дрейф обнаруживаем	Кривая обучения; сложность управления состоянием	Почти все команды в масштабе
Императивные скрипты	Знакомо; гибко для разовых случаев	Не идемпотентно; трудно проверять и повторять	Узкие переходные случаи
Неизменяемая + золотые образы	Нет дрейфа; тривиальный откат	Накладные расходы конвейера сборки образов	Парки, нуждающиеся в согласованности
Изменяемое управление конфигурацией	Тонкий постоянный контроль	Риск дрейфа; медленнее сходимость	Унаследованные или долгоживущие хосты
GitOps (по вытягиванию)	Сильный след аудита; самолечение	Требует агента в кластере и дисциплины Git	Kubernetes и облачные технологии
Политика как код	Автоматические единообразные ограждения	Усилия по написанию политик заранее	Регулируемые среды

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

Вопросы для обсуждения с командой

Кто владеет общей библиотекой модулей и как улучшение в модуле достигает каждой команды, которая его использует? Модули окупаются, только если исправления и укреплённые умолчания распространяются, а это требует ясного владения и настоящего версионирования, а не папки, из которой все копируют. Решите, кто сопровождает модули соответствующей сети и укреплённой базы данных, как вы их версионируете (семантическое версионирование с журналом изменений) и как команды вытягивают обновления без аврала. В масштабе это разница между однократным исправлением неверной настройки и погоней за ней по тысяче вручную правленых ресурсов. Принесите свидетельства: сколько различных копий одного шаблона существует сегодня, сколько времени исправление безопасности идёт до каждой среды и закрепляют ли команды версии модулей или плавают. Если критичное исправление не может достичь всего хозяйства за дни, ваша модульность косметическая.
Каков ваш ритм обнаружения дрейфа и что на самом деле происходит, когда дрейф найден? Дрейф это тихое расхождение живой среды с объявленным состоянием, обычно из-за аварийного изменения в консоли, и терпимость к нему превращает ваш код в вымысел. Решите, как часто вы сравниваете реальное состояние с объявленным (ночью разумное умолчание), и, что важнее, решите реакцию: согласуйте обновлением кода и повторным применением, никогда не оставляя ручное изменение на месте. В регулируемых условиях это требование контроля, потому что аудиторам нужно, чтобы объявленное состояние совпадало с реальностью непрерывно. Принесите ваши текущие числа: сколько ресурсов дрейфует за неделю, как долго они остаются дрейфовавшими и отвечает ли кто-либо за их закрытие. Воспринимайте каждый дрейф как дефект с владельцем, иначе гарантия источника истины разъедается, пока никто не доверяет коду.
Перешли ли вы на GitOps и согласование по вытягиванию или внешняя система по-прежнему держит постоянные учётные данные для изменения производства? В модели вытягивания агент внутри целевой среды непрерывно согласует живую систему с Git, что снимает необходимость любой внешней системе держать доступ на запись, и он вновь утверждает желаемое состояние, так что дрейф самоисправляется. Это сильная позиция безопасности и аудита, поскольку каждое изменение коммит, а ни одному оператору не нужны постоянные производственные учётные данные. Цена реальна: агент в кластере для эксплуатации и строгая дисциплина Git, поэтому взвесьте это против вашей нынешней автоматизации проталкивания. Принесите список того, кто и что может прямо менять производство сейчас, и какой след аудита оставляют эти изменения. Для Kubernetes и анклавов высокой гарантии этот сдвиг обычно стоит того; для горстки статических ресурсов он может быть излишним.
Как хранится, блокируется и контролируется по доступу состояние вашей инфраструктуры и что происходит в день, когда оно испорчено или потеряно? Состояние это карта между вашим кодом и реальными ресурсами, поэтому потерянный или повреждённый файл состояния может оставить инструмент слепым к созданным им ресурсам и соблазнить кого-то на разрушительное повторное применение. Для большой команды риск умножается, потому что многим инженерам, применяющим против общего состояния, нужен удалённый зашифрованный блокируемый бэкенд, чтобы параллельные запуски не затирали друг друга. Взвесьте удобство одного большого состояния против радиуса поражения, который оно создаёт, и рассмотрите разделение состояния по средам или областям, чтобы одна ошибка не могла уронить всё. Принесите факты: где состояние живёт сегодня, принуждается ли блокировка, кто может его читать (оно может содержать секреты) и репетировали ли вы когда-нибудь восстановление. В корпоративной и государственной среде воспринимайте бэкенд состояния как чувствительный контролируемый по доступу актив с собственной резервной копией, журналом аудита и ранбуком восстановления, потому что его потеря это потеря вашей записи о том, что существует.
Когда настоящая авария требует ручного изменения, каков санкционированный путь «разбить стекло» и как это изменение возвращается в код? Каждая зрелая практика IaC рано или поздно встречает инцидент в три часа ночи, когда ожидание конвейера неприемлемо, и честный вопрос не в том, случаются ли ручные изменения, а в том, как вы их сдерживаете. Решите заранее, кто может обойти конвейер, чего ему разрешено касаться, как действие журналируется и каков срок, к которому изменение должно быть согласовано в код или отменено. Без этого соглашения аварийное исключение тихо становится повседневной привычкой, и ClickOps возвращается через чёрный ход. Принесите свидетельства: сколько внеполосных изменений было в прошлом квартале, как долго каждое оставалось несогласованным и поймало ли их обнаружение дрейфа. Для регулируемых и государственных органов документированная процедура «разбить стекло» с автоматическим журналированием нередко требование контроля, потому что аудиторы ожидают и что аварии возможны, и что каждая оставляет след и возвращает систему к объявленному состоянию.
Какая часть вашей базы безопасности и соответствия выражена как политика, автоматически блокирующая плохое изменение, против правил, живущих в документе и полагающихся на то, что кто-то их помнит? Ограждения, написанные прозой в вики, нарушаются регулярно, потому что зависят от того, что каждый инженер читает и применяет их под давлением сроков, тогда как те же правила, выраженные политикой как кодом, отклоняют несоответствующее изменение до подготовки. Для большой организации это единственный способ масштабировать намерение команды безопасности на тысячи изменений, не став узким местом рецензии. Взвесьте цену написания и сопровождения политик заранее против повторяющейся цены ручной рецензии и исправления постфактум и решите, какие средства контроля (шифрование, утверждённые регионы, обязательные теги, отсутствие публичного раскрытия) достаточно непреложны для принуждения как жёстких барьеров. Принесите список ваших нынешних правил базы и отметьте, какие автоматизированы против рекомендательных, плюс как часто каждое нарушается на практике. В корпоративном и государственном контекстах автоматизированная политика превращает аудит из недель ручного сбора свидетельств в запрос к принуждаемым средствам контроля и переводит соответствие от обнаружения к предотвращению.

Взгляд по секторам

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

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

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

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

Примеры

Стартап. Стартап из пяти человек определяет всю свою установку AWS, то есть VPC, базу данных и сервис контейнеров, в единственном репозитории Terraform с состоянием в зашифрованном бэкенде S3 и блокировкой через DynamoDB. Каждое изменение идёт через запрос на слияние, так что даже единственный дежурный инженер видит, что именно изменится, перед запуском apply. Когда им нужна свежая промежуточная среда для большой демонстрации, они копируют небольшой модуль и поднимают её за минуты и сносят так же быстро, чтобы держать облачный счёт низким.

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

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

Бизнес-обоснование: мотивы, ROI и TCO

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

В книге TCO цены принятия включают инструменты, обучение, построение библиотеки модулей и политик и дисциплину прекращения ручных изменений. Цена непринятия круче и накапливается со временем: инфраструктура-«снежинка», которую никто не может перестроить, медленная и подверженная ошибкам подготовка, неверные настройки безопасности, ведущие ко взломам, и аудиты, съедающие недели ручных усилий. Для руководства формулируйте IaC как превращение инфраструктуры из неуправляемого обязательства в управляемый воспроизводимый актив и как механизм, делающий безопасность и соответствие автоматическими, а не желаемыми.

Антипаттерны и ловушки

ClickOps в производстве. Внесение изменений вручную в консоли гарантирует дрейф и разрушает воспроизводимость.
Секреты в коде. Жёсткое кодирование учётных данных в файлах определений утекает их в историю версий и состояние.
Монолитные немодуляризованные определения. Одна огромная конфигурация, которую никто не смеет менять, становится столь же хрупкой, как ручная установка, которую она заменила.
Неуправляемое состояние. Локальные или не блокируемые файлы состояния ведут к порче и потерянной инфраструктуре.
Терпимость к дрейфу. Оставление ручных изменений на месте разъедает гарантию источника истины, пока код не станет вымыслом.
Политика как документация. Правила, живущие в вики вместо автоматической проверки, регулярно нарушаются.
Размножение копированием. Дублирование конфигурации между командами означает, что исправления и улучшения никогда не распространяются.

Модель зрелости

Уровень 1: Начальный. Инфраструктура подготавливается вручную через консоль и стихийные скрипты. Среды несогласованны, недокументированы и не могут быть надёжно воспроизведены, а восстановление после отказа медленно и неопределённо.

Уровень 2: Развитие. Часть инфраструктуры кодифицирована, но практики различаются по командам. Управление состоянием непоследовательно, дрейф распространён, секреты порой утекают в определения, а политика принуждается, если вообще, ручной рецензией.

Уровень 3: Стандартизация. Декларативная IaC документированный стандарт по организации, построенный из общих версионируемых модулей с управляемым удалённым блокируемым состоянием. Политика как код принуждает ограждения в конвейере, секреты берутся по ссылке из выделенного менеджера, а обнаружение дрейфа работает с регулярным ритмом.

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

Уровень 5: Оркестрация. Инфраструктура неизменяема и управляется GitOps, самолечится от дрейфа, а свидетельства соответствия производятся автоматически. Библиотека модулей и политик непрерывно улучшается по реальному использованию и инцидентам, а инфраструктурная практика интегрирована с планированием безопасности, цены и поставки, так что всё хозяйство адаптируется по мере сдвигов требований.

Идеи для обсуждения

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

Главные выводы

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

Источники и дополнительное чтение

Kief Morris, Infrastructure as Code: Dynamic Systems for the Cloud Age.
Yevgeniy Brikman, Terraform: Up & Running.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering.
Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
Weaveworks, “GitOps” foundational writings (Alexis Richardson et al.).
Open Policy Agent documentation and the Rego policy language.
NIST Special Publication 800-53, security and privacy controls (configuration management family).

8.2 Инфраструктура как код и конфигурация

Обзор и мотивация

Ключевые принципы

Рекомендации

Выбирайте декларативные инструменты и структурируйте их вокруг модулей

Управляйте состоянием намеренно

Стройте неизменяемую инфраструктуру с золотыми образами

Обнаруживайте и согласуйте дрейф конфигурации

Принимайте GitOps и развёртывание по вытягиванию

Принуждайте ограждения политикой как кодом