GitOps bootstrap: где ломается базовая инфраструктура
Классический сценарий: окружение поднимают руками под конкретную задачу — так быстрее всего получить рабочий стенд сегодня. Через полгода никто не помнит, почему в продуктивном контуре выставлен параметр, которого нет в описании, а резервная копия возвращает данные, но не настройки. Так ручная настройка окружений становится единственным источником правды, и живёт он в голове одного-двух инженеров.
Дрейф конфигурации копится медленно и почти незаметно. Правка «мимо регламента» — ради срочного релиза или обхода ограничения — остаётся в живом окружении; следующее развёртывание её затирает, и поведение системы меняется обратно без предупреждения. Либо наоборот: правка закрепляется, стенд расходится с продуктивом, и проверки перестают что-либо доказывать.
Отсюда — невоспроизводимые окружения. Тесты проходят там, где другие лимиты и другой порядок инициализации, а в продуктив уходит конфигурация, которую целиком никто не собирал. Простой из-за ошибки настройки измеряется тогда не временем развёртывания, а временем поиска причины: пока не найдено расхождение факта и описания, откатываться некуда — предыдущее состояние тоже собрано руками.
Подход GitOps убирает саму возможность такого расхождения: описание окружения становится единственным источником правды, а любое отклонение от него — видимым и устранимым. Разбираем, как это закрывается на уровне базовой инфраструктуры.
Что меняется после перехода на декларативную схему
Инфраструктура перестаёт быть набором ручных действий и становится описанием в репозитории. Контроллер сверяет фактическое состояние среды с описанным и приводит её к нужному виду — без ssh-сессий, «донастроек по памяти» и расхождений между стендами. Воспроизводимость окружений перестаёт зависеть от того, кто и в какой день разворачивал контур: та же ветка даёт тот же результат в тестовой и продуктивной среде.
Изменение проходит проверку до применения. Правка идёт отдельной веткой, её смотрят ревьюеры и автоматические проверки: корректность манифестов, соответствие политикам, план предстоящих изменений. Только после этого контроллер синхронизирует окружение — и то же описание откатывается реверсом правки, а не сборкой «как было» по памяти. Мы собираем такую схему на Argo CD, потому что она одинаково работает и для первого развёртывания, и для последующих правок.
Прозрачность изменений держится на истории правок. Каждый коммит отвечает, что менялось, кто автор и зачем — вместо поиска по логам чужой сессии. Дрейф конфигурации виден: если ресурс поправили руками, контроллер вернёт его к описанному состоянию, а расхождение попадёт в отчёт.
Время восстановления среды падает до применения описания к чистому контуру. Резервный стенд разворачивается из той же ветки, что и основной, поэтому восстановление не превращается в археологию по старым инструкциям.
Варианты GitOps bootstrap: от ручной сборки до автоматизации
Режим bootstrap задаёт, сколько ручной работы останется после первого запуска и что произойдёт при повторном развёртывании окружения. Выбирают между тремя вариантами: разовая ручная сборка, параметризованные шаблоны окружений и полная автоматизация с проверками на входе. Разница проявляется не на старте, а на второй-третьей итерации, когда среду нужно поднять заново или привести к эталонному виду.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Разовая ручная сборка | Один контур, состав меняется редко, важнее скорость первого запуска | Состояние живёт в истории команд; повторный подъём воспроизводит расхождения, дрейф копится незаметно |
| Параметризованные шаблоны окружений | Несколько сред с одинаковой структурой: разработка, тест, продуктивная | Шаблон требует поддержки: правки в обход него ломают идемпотентность, расхождения всплывают на следующем прогоне |
| Полная автоматизация с проверками | Регулярные релизы, требования к аудиту изменений, несколько команд на одной платформе | Нужно описанное в репозитории состояние и правила допуска; без них ошибка тиражируется во все среды сразу |
Как переходят между режимами
Переход редко бывает одномоментным: сначала описывают базовое состояние в репозитории, затем выносят различия сред в параметры, и только потом включают проверки перед применением. Признак зрелости — повторный прогон ничего не меняет, а расхождение с эталоном видно до выката, а не после. На этом шаге появляются политики допуска и возврат к предыдущему состоянию.
Порядок внедрения: аудит, схема, настройка, проверка
Внедрение GitOps-bootstrap — это последовательность, а не одна команда: если начать с настройки поставки, легко получить схему, которая воспроизводится на одном контуре и рассыпается при добавлении второго.
- Аудит инфраструктуры. Инвентаризируем кластеры, реестры, внешние зависимости, доступы и секреты. Отдельно фиксируем то, что создано руками вне репозитория, — это главный источник расхождений при первом же применении.
- Схема окружений. Определяем контуры, их общий слой и различия: что наследуется, а что переопределяется. Здесь же решаем, где хранится состояние, а где только описания конфигурации.
- Структура репозиториев и порядок применения. Разбиваем конфигурацию на слои — базовые ресурсы, платформенные сервисы, приложения — и задаём очередь: что обязано существовать раньше, чем появится зависимость.
- Настройка поставки. Согласование изменений, автоматическое применение по факту слияния, права для агента, секреты через внешнее хранилище. Отдельно описываем поведение при расхождении и то, кто его устраняет.
- Проверка на стенде. Разворачиваем контур с нуля и намеренно ломаем сценарии: ручная правка ресурса, конфликт слияния, откат к предыдущей ревизии. Смотрим, восстанавливается ли схема без ручного вмешательства.
- Передача в эксплуатацию. Отдаём схему окружений, регламент изменений и порядок подключения нового контура — так, чтобы дежурная команда откатывала поставку сама.
Артефакты: репозитории, политики доступа, регламенты
Настройка GitOps для базовой инфраструктуры заканчивается не работающим контуром, а набором артефактов, которые остаются в репозитории заказчика и дальше живут без нас. Репозиторий без описания окружений и правил доступа через месяц превращается в набор манифестов, где никто не решается что-то менять: непонятно, какие контуры существуют, чем они отличаются и кто вправе вливать правки.
- Описание окружений — какие контуры есть (разработка, предпродуктив, продуктив), чем они отличаются по составу сервисов, что выносится в переменные, а что задаётся наложением на общую базу.
- Политики доступа — роли и права внутри кластера, отдельные учётные записи для автоматики, привязка «кто и в какую ветку вливает изменения», явный запрет правок в обход репозитория.
- Регламент выпуска изменений — путь правки от ветки до применения: обязательные проверки, согласование, порядок продвижения между контурами, точка невозврата.
- Процедура отката — как вернуть предыдущее состояние, за какое время, какие изменения откатываются только вручную и почему.
- Управление секретами — где хранятся, кто и как получает доступ, как проходит ротация и что делать при утечке.
- Документация по инфраструктуре — схема контуров, карта зависимостей между сервисами, перечень внешних точек входа и порядок подключения нового компонента.
- Матрица ответственности — кто согласует изменения, кто дежурит, кому эскалируется расхождение фактического состояния с описанным.
Каждый пункт — не формальность, а условие, при котором команда заказчика сама добавляет сервис или откатывает выпуск, не разбирая заново логику репозитория.
Кейс: инфраструктура под управлением репозитория
Ситуация до
Заказчик — продуктовый отдел с тремя средами: разработка, предпрод, продакшн. Базовый контур — кластер, сеть, права доступа, секреты — поднимали вручную по чек-листу из вики. Новая среда собиралась три-четыре дня, а расхождения между продакшном и предпродом всплывали уже во время инцидента.
Что изменили
Перенесли описание базовой инфраструктуры в репозиторий: развёртывание в Kubernetes, сетевые политики, пространства имён, доступы, хранилище секретов. Описали и сам bootstrap — минимальный набор ресурсов, из которого разворачивается всё остальное, включая компонент синхронизации. Любое изменение проходит проверку плана в pull request, а расхождение с реальным состоянием контур устраняет сам.
Что стало
Подъём среды с нуля — 25 минут вместо трёх дней, вторая площадка разворачивается тем же описанием. Отказы класса «забыли параметр при ручной настройке» исчезли: за полгода ни одного случая. Простой при восстановлении сократился с четырёх часов до двадцати минут — состояние возвращается из репозитория, а не собирается заново. Плюс вся история изменений контура читается по коммитам: видно, кто и зачем его менял.
Чем декларативная поставка отличается от классического конвейера?
Классический конвейер отвечает на вопрос «что сделать»: собрать артефакт, прогнать проверки, разложить по серверам и выполнить команды в нужном порядке. Декларативная поставка отвечает на другой вопрос — «каким должно быть состояние», а приведение системы к этому состоянию берёт на себя агент сверки внутри кластера. Граница проходит там, где заканчивается одноразовое действие и начинается непрерывное удержание состояния.
В обычном конвейере результат зависит от того, что уже лежит на сервере: повторный прогон может упасть или создать дубли. Декларативное описание идемпотентно — применили один раз или сто, итог одинаковый. Если кто-то поправил ресурс руками, сверка это заметит: либо вернёт описание, либо покажет расхождение отдельным событием. История изменений при этом лежит в репозитории, и откат — это возврат предыдущей ревизии, а не поиск «что же мы там нажимали».
| Критерий | Классический конвейер | Декларативная поставка |
|---|---|---|
| Источник истины | порядок шагов и скрипты | описание состояния в репозитории |
| Повторный запуск | зависит от текущего состояния | идемпотентен |
| Расхождения | ищут вручную | выявляются сверкой |
| Откат | повтор отдельных шагов | возврат предыдущей ревизии |
На практике подходы не конкурируют: сборку, тесты и публикацию оставляют конвейеру, а поставку и удержание состояния описывают декларативно. Тогда базовая инфраструктура разворачивается из одного репозитория воспроизводимо — на новой площадке или после сбоя, — вместо повторного прохождения десятка ручных инструкций.
Технические сомнения: доступы, откаты, ручные правки
GitOps не требует, чтобы инфраструктура была идеальной с первого дня. Расхождение живой среды и репозитория описывается как дрейф и закрывается контролируемо: сначала текущее состояние снимается в декларации и принимается как база, и лишь затем включается автоматическая сверка. До этого шага ни один ресурс не удаляется и не пересоздаётся.
Доступы разделяем по ролям: изменение предлагается через pull request, дежурный подтверждает, автоматика применяет. Прямая правка в контуре либо блокируется политикой, либо фиксируется и превращается в задачу — расхождение не копится молча, а попадает в очередь.
Что делать со средами, которые настраивали руками?
Инвентаризируем ресурсы, переносим их в декларации как есть и принимаем под управление по одному контуру за раз. Пока контур не сверен, автоматическое удаление для него выключено.
Как откатывается неудачное изменение?
Обратным коммитом к предыдущему состоянию: автоматика приводит контур к нему и ждёт сходимости. История остаётся — видно, кто и что менял.
Кто отвечает за срочные правки?
Дежурный инженер может править вручную по правилу «сломанное стекло»: доступ выдаётся на время и логируется. Правка обязана в тот же день вернуться в репозиторий, иначе сверка вернёт прежнее состояние.
Что будет, если репозиторий или агент недоступны?
Контур продолжает работать на уже применённом состоянии: изменения копятся, но ничего не удаляется. После восстановления связи сверка идёт в обычном режиме.
С чего начнём: схема, доступы и порядок работ
Первый разговор нужен не для презентации, а для сверки входных данных: без инвентаря окружений и понятной модели доступов любая оценка превращается в догадку. Ниже — то, что стоит подготовить к обсуждению задачи. Если часть пунктов отсутствует, это не блокер: пробелы фиксируем отдельно и закрываем на этапе разведки, до первых изменений в рабочем контуре.
- перечень окружений и кластеров: сколько их, какие общие, какие изолированные, где проходит граница между тестовым и рабочим контуром;
- текущий способ управления инфраструктурой — ручные команды, скрипты, шаблоны провайдера или частично настроенный GitOps;
- состав сервисов, которые обязаны подниматься первыми: сеть, хранилище секретов, система сборки образов;
- модель доступов: кто и что может менять в репозитории и в кластере, нужны ли отдельные роли для дежурных;
- требования к хранению секретов и ключей — где лежат сейчас, кто к ним допущен, как они попадают в окружение;
- правила отката: как определяем, что выкладка сломала окружение, и за какое время нужно вернуться к прошлому состоянию;
- окна изменений и ограничения — когда трогать рабочий контур нельзя.
Порядок работ после обращения выглядит так: разбор входных данных, схема репозиториев и веток, описание базового слоя, подключение окружений, проверка восстановления с нуля, передача с инструкцией для дежурной смены. Первым шагом мы возвращаемся с оценкой и планом, где видно, что делаем мы, а что остаётся на вашей стороне.
