GitOps: управление инфраструктурой из Git

Коротко: Желаемое состояние приложений и инфраструктуры хранится в репозитории Git, а инструмент автоматически согласует с ним работающие системы.

Подробнее: В GitOps Git — единственный источник истины. Изменения вносятся не ручными командами на сервере, а как коммит или pull request. Агент в кластере (например, Argo CD или Flux) постоянно сравнивает желаемое состояние в репозитории с фактическим и исправляет отклонения.

Подробности

Принципы

• Декларативность: файлы описывают, что должно работать (YAML для Kubernetes), а не шаги для этого.
• Версионирование: у каждого изменения есть автор, время и причина, и его можно отменить (git revert).
• Автоматическое применение: агент принимает одобренные изменения.
• Самовосстановление: если что-то изменено вручную, агент сбрасывает это (обнаружение дрейфа).

Pull вместо push

Классические конвейеры отправляют (push) изменения в кластер со своими учётными данными. В GitOps агент в кластере забирает (pull) изменения из репозитория. Кластеру не нужно выдавать учётные данные конвейеру, что повышает безопасность, а состояние прослеживается в любой момент.

Типичный поток

1. Разработчики меняют файл манифеста (например, новый тег образа) в ветке.
2. Pull request с ревью и автоматическими проверками.
3. После слияния агент обнаруживает изменение.
4. Агент применяет его и сообщает статус.

Откат означает: отменить коммит.

Подводные камни

Секреты (пароли) не должны попадать в репозиторий открытым текстом; для этого существуют инструменты вроде Sealed Secrets или SOPS. Разделяйте код приложения и конфигурацию окружения, иначе каждое изменение кода запускает сборку конфигурации. GitOps наиболее эффективен вместе с инфраструктурой как кодом.

См. также: Инфраструктура как код, Основы Kubernetes, Git, Конвейер CI/CD