Один бинарник вместо платформы
Установка — одна команда, обновление — замена файла, удаление — удаление файла. У платформы, которую надо разворачивать, чтобы разворачивать инфраструктуру, есть проблема курицы и яйца.
Инструмент — один исполняемый файл. Устанавливается одной командой или скачивается сборкой под платформу. Не требует агента в кластере, панели управления, базы данных на стороне и подписки на сервис.
Это архитектурное решение, а не аскетизм.
Проблема курицы и яйца
У платформы, которую надо развернуть, чтобы разворачивать инфраструктуру, есть неприятный первый шаг. Панель управления должна где-то работать — значит, нужна инфраструктура для инфраструктуры.
Обычно эту проблему решают, размещая панель у поставщика. Тогда появляется другая: ваша способность управлять своей инфраструктурой зависит от доступности чужого сервиса, а описание вашей инфраструктуры лежит у него.
Бинарник эту рекурсию обрывает. Он работает на ноутбуке, на виртуальной машине, на runner-е непрерывной интеграции — везде, где есть файловая система и git.
Что из этого следует практически
Обновление — замена файла. Не миграция схемы базы, не согласование версий агента и сервера, не окно обслуживания.
Откат на прежнюю версию — тоже замена файла. Это важнее, чем кажется: инструмент, который нельзя быстро откатить, страшно обновлять, поэтому его обновляют редко, поэтому разрыв версий растёт.
Работа без сети до внешнего сервиса. Инструменту нужен доступ к целевому облаку и к вашему репозиторию. Больше ничего.
Одинаковое поведение локально и в непрерывной интеграции. Тот же файл, те же команды, тот же вывод.
Чего у бинарника нет
Многопользовательской панели с ролями. Централизованного журнала для всей организации. Постоянного цикла сверки — на простом треке его нет вообще, а на производственном сверку ведёт ArgoCD в вашем кластере, а не наш сервис.
Это реальные ограничения, и в ряде организаций они окажутся решающими. Мы предпочитаем назвать их, а не описывать как «упрощённую модель».
Где живёт состояние
Раз нет сервера, состояние живёт в проекте: конфигурация в корне репозитория, локальное состояние в отдельном каталоге, желаемое состояние приложений — в GitOps-репозитории.
Локальный GitOps-запуск устроен так, что внешний Git-сервер не обязателен: если указанная папка пуста, инструмент сам создаёт рабочее дерево, локальный удалённый репозиторий, файл источника, коммит и отправку.
Это не обход GitOps и не запасной вариант. Это локальный канонический источник для того, у кого пока нет своего Git-сервера — с тем же поведением, что и с внешним.
Кому это подходит
Небольшой команде, которая не хочет платформенного отдела. Организации, у которой требование к суверенности данных сильнее требования к удобству централизованного управления. Проекту, который должен продолжать разворачиваться, если поставщик инструмента исчезнет.
Последний пункт — самая честная причина выбирать один файл. Бинарник, который у вас уже скачан, продолжит работать.