Почему ручные правки в консоли ломают Pulumi-инфраструктуру
Pulumi хранит файл состояния, где зафиксировано фактическое положение ресурсов, и сравнивает его с описанием в коде. Консоль об этом файле не знает: инженер вручную расширяет диск, открывает порт или переименовывает базу, а состояние молча уходит в сторону от кода. Следующий запуск либо откатывает эту правку, либо приносит расхождение в план изменений — и оба варианта подрывают доверие к процессу.
Так работает дрейф конфигурации: любое вмешательство руками живёт вне кода и вне истории. Оно не проходит проверку, не попадает в ревью и не воспроизводится при пересоздании окружения. Через месяц уже никто не помнит, зачем появилось правило и можно ли снять его без последствий.
Дальше расходятся среды: тестовый контур после нескольких таких правок перестаёт быть копией продуктивного, и разница всплывает на релизе, а не на проверках. Откат тоже перестаёт работать — предыдущую версию не развернуть, потому что фактическое состояние уже никто не описывал. Перед каждым выпуском инвентарь приходится собирать руками, сверяя консоль с кодом и надеясь, что ничего не пропустили.
Закрывается это управлением инфраструктурой как код: изменения только через ревью и применение из кода, импорт уже существующих ресурсов, регулярная сверка фактического состояния с описанным. Ниже — как мы выстраиваем такой контур, чтобы дрейф ловился до релиза, а окружение поднималось из кода без ручной сборки.
Измеримые эффекты: скорость выката, восстановление сред, дрейф
Перевод инфраструктуры в описание в коде на Pulumi меняет не только способ правок, но и то, как часто команда решается их делать. Когда состояние контуров собирается из одного описания, а не воспроизводится вручную, стоимость изменения падает: правка проходит ревью как обычный код, а не как операция в консоли облака.
Что фиксируем как измеримый результат:
- Скорость выката изменений — типовое изменение проходит путь от коммита до применения на всех контурах за минуты; ручные шаги по консолям из процесса уходят.
- Воспроизводимость окружений — тестовый и продуктивный контуры различаются только параметрами: одинаковые сетевые правила, роли доступа, версии образов.
- Восстановление среды — окружение поднимается из описания с нуля, поэтому результат не зависит от того, помнит ли кто-то последовательность действий.
- Дрейф — расхождение между описанием и реальным состоянием видно на плановом прогоне; ручная правка либо попадает в описание, либо откатывается.
- Частота изменений — мелкие правки перестают требовать окна обслуживания, откат на предыдущее описание занимает одну операцию.
Ограничение снимается не с инфраструктуры, а с команды: инженеры перестают бояться трогать рабочий контур, потому что у каждого изменения есть проверяемое описание и путь назад. Дальше показываем, как такой контур заводят и что остаётся у заказчика после передачи.
Pulumi против шаблонов провайдера и ручных правок
Выбор подхода к инфраструктуре — это не про синтаксис, а про то, кто и чем будет платить за изменения дальше. Ниже — четыре варианта, между которыми реально выбирают команды.
Первый стенд быстрее всего собирается руками, и на одном окружении это терпимо. Когда окружений три-четыре и они отличаются парой параметров, поддержка превращается в ручную сверку: расхождение всплывает уже во время сбоя.
| Подход | Когда подходит | Ограничение | Что держать своей команде |
|---|---|---|---|
| Правки в консоли провайдера | прототип, одно окружение | состояние нигде не зафиксировано, повтор стенда — вручную | инструкции и сверку стендов |
| Шаблоны провайдера | типовые ресурсы без сложной логики | нет циклов и ветвлений, блоки копируются | ветки шаблона под каждое окружение |
| Декларативный язык с файлом состояния | единый слепок инфраструктуры, много провайдеров | нужен свой слой абстракций и знание языка описания | модули и порядок применения изменений |
| Код на общем языке | команда пишет на Python, TypeScript или Go, логика важна | код требует тестов, проверки и правил именования | библиотеки модулей и тесты |
Общий язык убирает главную боль шаблонов: параметризация делается функциями и циклами вместо копирования блоков, а декларативное описание ресурсов и их состояния сохраняется — на этом построен Pulumi. Подход выбирают по составу команды и сложности логики, а не по модности инструмента.
Как мы внедряем управление инфраструктурой из кода
Управляемая инфраструктура начинается не с кода, а с честной инвентаризации: пока не выписан каждый ресурс с зависимостями и владельцем, любое описание среды воспроизводит накопленный дрейф. Поэтому порядок этапов у нас фиксирован — каждый следующий опирается на результат предыдущего.
- Инвентаризация ресурсов — обходим аккаунты и проекты, собираем реальные сущности, их связи, теги и ответственных. На выходе — реестр, с которым сверяем каждое последующее изменение.
- Схема ресурсов и зависимостей — раскладываем реестр по слоям: сеть, данные, вычисления, доступы. Определяем порядок создания, чтобы связи не превращались в замкнутые циклы.
- Описание окружений — разделяем среды параметрами и отдельными наборами значений, а не копиями конфигураций. Шаблон один, отличия сред задаются переменными, поэтому среда поднимается воспроизводимо.
- Настройка состояния и секретов — состояние выносим в общее хранилище с блокировкой, чтобы параллельные запуски не перетирали чужие изменения; секреты — в шифрованное хранилище, в репозитории остаются только ссылки на них.
- Проверка плана изменений — каждая правка сначала показывает, что будет создано, изменено и удалено. Удаление ресурсов с данными допускается только после явного ревью и подтверждения.
- Передача команде — регламент ревью, инструкция по локальному запуску, разграничение доступов и порядок отката к предыдущему состоянию.
Работу на Pulumi мы ведём в этой же последовательности — язык описания выбирается под команду заказчика. Критерий готовности один: окружение разворачивается с нуля одной командой за минуты, а не за дни, и результат совпадает у разработчика, тестировщика и в продуктивной среде.
Артефакты и регламенты: описание, состояние, доступы
Передаём мы не набор скриптов, а комплект, по которому команда заказчика ведёт инфраструктуру сама. Каждый артефакт закрывает свой класс вопросов: что развёрнуто, кто и как может это менять, как вернуть предыдущее состояние, если изменение оказалось неудачным. Всё лежит в репозитории заказчика и версионируется вместе с кодом — без устных договорённостей и «знания в голове одного инженера».
- Структура описания ресурсов. Единый шаблон на каждый стек: назначение, владелец, окружение, внешние зависимости. Новый инженер понимает состав по описанию, не читая всю конфигурацию целиком.
- Схема ресурсов. Карта связей между компонентами: что от чего зависит, где общие сети и хранилища, что удалится вместе с родительским ресурсом.
- Политики доступа. Разграничение ролей на чтение, предварительный план и применение; отдельные права на тестовый и рабочий контуры; ручные правки в панели облака закрыты.
- Управление секретами. Ключи и пароли не хранятся в репозитории — только ссылки на защищённое хранилище, выдача по ролям и регламент ротации.
- Регламент изменений. Любое изменение идёт через запрос на слияние с обязательным просмотром плана до применения: видно, что добавится, изменится или будет удалено.
- Правила откатов. История версий описания и порядок возврата к предыдущему состоянию, включая случаи, когда откат требует ручных шагов.
- Документация окружений. Как поднять копию контура для проверки, какие проверки прогоняются автоматически перед применением.
Плюс короткая инструкция по локальному запуску и обзорная запись разбора — команда повторяет типовое изменение по ней, не обращаясь к нам.
Кейс: дрейф трёх сред до и после перевода в код
До: три контура, которые жили своей жизнью
Инфраструктура из трёх сред — разработки, предпродакшна и продакшна — росла вместе с продуктом, но управлялась руками. Инженер заходил в панель облачного провайдера, добавлял правило балансировщика, поднимал базу, менял лимиты — и фиксировал это разве что в переписке. За несколько месяцев контуры разошлись: часть сетевых настроек и прав доступа отличалась, а воспроизвести продакшн в тестовой среде было уже нельзя.
Цена расхождения оказалась не косметической. Инцидент в продакшне разбирали дольше, потому что причина обнаруживалась в ручной правке месячной давности, а восстановление среды после сбоя занимало до шести часов. Выпуск сопровождали более сорока ручных операций — и любая из них могла уехать не в тот контур.
После: одно описание на все три среды
Инфраструктуру перенесли в код на Pulumi: топология описана один раз, а различия контуров вынесены в параметры — размер узлов, число реплик, уровень доступа. Изменения проходят проверку как обычный код и остаются в истории, поэтому вопрос «кто и когда поменял правило» закрывается за минуту, а новая среда поднимается копией описания, без ручной сборки по памяти.
Через два месяца эксплуатации в новом режиме картина такая: время восстановления среды после сбоя сократилось с шести часов до 25 минут, ручных операций при выпуске осталось три вместо сорока с лишним, а расхождения между контурами выявляет автоматическая сверка в течение часа вместо разбора на глаз. Откат к предыдущему состоянию — одна операция с предсказуемым результатом, без «верни как было».
Что делать, если инфраструктура уже развёрнута вне Pulumi
Если инфраструктура уже развёрнута — вручную или другим инструментом — пересоздавать её не нужно: Pulumi принимает существующие объекты под управление. Импорт ресурсов в описание привязывает реальный объект к коду: идентификатор попадает в файл состояния, сам объект остаётся на месте. Тонкость в том, что переносится только ссылка — фактические параметры нужно описать в коде ровно такими, какие они сейчас.
Иначе первый же прогон попытается догнать описание: изменит настройки, пересоздаст ресурс или уронит его. Поэтому перенос существующих ресурсов начинается со снятия фактического состояния — оно попадает в код без правок, а изменения делаются отдельным шагом и отдельным прогоном.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Полный импорт | Один контур, простые зависимости, есть актуальная схема ресурсов | Долгая инвентаризация; ошибка в параметре приводит к пересозданию объекта |
| Постепенный перенос по контурам | Несколько сред, критичный прод, важен контролируемый темп | Дольше живут два источника правды, нужен регламент владения |
| Параллельное ведение | Крупная унаследованная часть, которую нельзя останавливать | Риск конфликта за один и тот же объект, требуется жёсткое разделение |
Состояние описания — точка правды, и у каждого объекта должен быть один владелец: если два описания ссылаются на тот же ресурс, они начинают перетягивать его настройки. Параллельное ведение оправдано только как временная мера — с разделением по типам ресурсов и сроком, после которого остаётся одно описание.
Технические сомнения: состояние, секреты, откат
Перед тем как согласовывать работы, технические заказчики задают одни и те же вопросы: где лежит состояние инфраструктуры, что случится при потере доступа, как разделены среды и насколько безопасно откатывать изменения. Ниже — короткие ответы, которые обычно снимают сомнения на этапе оценки.
Состояние — не деталь реализации, а часть контура безопасности. Поэтому его размещение, шифрование секретов и права команды мы проектируем вместе с самой инфраструктурой, а не «донастраиваем» после первого инцидента.
Где хранится состояние и что будет при потере доступа?
Состояние выносим в удалённый бэкенд с блокировками — параллельные применения не перетирают друг друга. Версии снапшотов сохраняются, поэтому доступ можно восстановить по предыдущей ревизии, а не собирать состояние заново.
Как изолируются среды?
Каждая среда — отдельный стек со своим набором параметров и своим облачным аккаунтом или проектом. Кросс-ссылки между тестовым и промышленным контуром запрещены, поэтому ошибка в тесте физически не может изменить продуктив.
Что делать, если изменение сломало инфраструктуру?
Каждое применение пишет историю. Откат — это повторный запуск предыдущей ревизии описания либо возврат к более раннему снапшоту состояния с последующей сверкой с реальными ресурсами. Целевое время восстановления — минуты, а не часы ручных правок.
Как разграничиваются доступы команды?
Права выдаём ролями: чтение состояния, планирование изменений и применение — разные уровни. Секреты расшифровываются только тем, у кого есть ключ, а все запуски попадают в журнал с автором и временем.
Кто сопровождает описание после сдачи?
Описание остаётся в вашем репозитории с документацией по структуре стеков и порядку выпуска. Дальше его ведёт ваша команда — или мы, по отдельному соглашению о сопровождении.
Обсудим задачу и вернёмся с оценкой и планом
Для старта достаточно описать, как инфраструктура живёт сейчас: что уже заведено кодом, что настраивалось руками через панель управления, какие окружения обслуживаются и у кого есть к ним доступ. Участки, которые держатся на текстовых инструкциях и памяти одного инженера, тоже стоит назвать — мы закладываем их в план переноса отдельно, а не находим в середине работ.
- оценка объёма по этапам: сколько работы в каждом и где сосредоточены риски;
- план работ с порядком старта: с чего начинаем, что идёт параллельно, когда появится первое окружение, поднятое кодом;
- схема разделения окружений и правила продвижения изменений между ними;
- перечень доступов и исходных данных, которые нужны от вас для старта;
- критерии готовности на каждом этапе — по ним вы принимаете результат;
- формат отчётности: что и как часто вы видите в процессе работ.
Руководитель направления, чью инфраструктуру мы переводили на Pulumi, описывает результат так: «Правка окружения перестала быть событием с ручной проверкой — теперь это обычное изменение, которое проходит проверку и откатывается одной командой».
Опишите задачу в свободной форме: что развёрнуто, что болит, какие сроки давят. Мы вернёмся с оценкой объёма и планом работ — с порядком старта и тем, что потребуется от вашей команды.