GitOps / IaC

Что такое IaC

IaC (Infrastructure as Code, инфраструктура как код) — подход, при котором серверы, сети, кластеры и их конфигурация описываются текстовыми файлами и создаются автоматически, а не настраиваются руками через панель или SSH.

Что это меняет: инфраструктура становится обычным кодом. Она лежит в Git, проходит code review, имеет историю изменений и воспроизводится с нуля одной командой. Ответ на вопрос «почему на проде не так, как на staging» перестаёт быть археологией — достаточно сравнить два файла.

Главная проблема, которую IaC лечит, — дрейф конфигурации: сервер, который полгода правили вручную, становится уникальным снежинкой. Его нельзя воспроизвести, его страшно трогать, а после отказа диска восстановление превращается в расследование.

# Terraform: три идентичных сервера вместо трёх заявок и кликов
resource "example_server" "web" {
  count  = 3
  name   = "web-0${count.index + 1}"
  cpu    = 4
  memory = 8192
  image  = "ubuntu-24.04"
}

Декларативно и императивно

Ключевое свойство декларативного подхода — идемпотентность: применяете конфиг десять раз — состояние не меняется после первого. Именно поэтому IaC-инструменты вытеснили самописные скрипты развёртывания. Ansible формально описывает шаги, но его модули идемпотентны и приводят систему к заданному состоянию.

Инструменты

Типовая связка: Terraform создаёт облачные серверы → cloud-init делает первичную настройку → Ansible доводит до рабочего состояния → приложение выкатывает CI/CD.

Что такое GitOps

GitOps — способ применения IaC, в котором Git является единственным источником истины о состоянии системы, а специальный агент внутри кластера непрерывно сводит фактическое состояние к описанному в репозитории.

Отличие от обычного CI/CD принципиальное и называется push vs pull:

• Push (классический CI/CD): пайплайн снаружи ходит в кластер и выполняет kubectl apply. Значит, у CI-сервера есть учётные данные с правами на production.
• Pull (GitOps): агент (Argo CD, Flux) живёт внутри кластера, сам следит за репозиторием и применяет изменения. Наружу доступ не нужен, ключей от кластера у CI нет.

Второе свойство — непрерывная сверка. Если кто-то поправит replicas вручную через kubectl, агент увидит расхождение с Git и вернёт как было (или подсветит дрейф). Ручные правки на проде становятся физически бессмысленными.

Отсюда практические следствия: откат — это git revert, аудит — git log, а окружение восстанавливается на пустом кластере из репозитория.

Разработчик → PR в infra-repo → review → merge в main
                                            ↓
                              Argo CD (внутри кластера) видит коммит
                                            ↓
                              применяет манифесты, сверяет состояние

Как это устроено на практике

Репозитории обычно разделяют: код приложения отдельно, манифесты инфраструктуры отдельно. Пайплайн приложения собирает образ, кладёт его в registry и делает один коммит в infra-репозиторий — меняет тег образа. Дальше работает GitOps-агент.

# infra-repo/apps/api/deployment.yaml — единственная строка, которую меняет CI
spec:
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/api:2f1a9c4   # ← новый тег

Секреты

Главный вопрос к GitOps: пароли в Git класть нельзя, а состояние должно быть полным. Рабочие ответы: шифрование в репозитории (SOPS, Sealed Secrets — в Git лежит только шифротекст) или внешнее хранилище (HashiCorp Vault), из которого агент подтягивает значения при применении. Что нельзя — коммитить открытый .env: попавший в историю секрет скомпрометирован навсегда.

Чего IaC не даёт бесплатно

Состояние (Terraform state) нужно где-то хранить и блокировать, иначе два инженера одновременно снесут друг другу инфраструктуру. Ошибка в декларации применяется так же быстро и надёжно, как правильная конфигурация, — поэтому terraform plan и review обязательны. И порог входа реален: для одного сервера IaC избыточен, окупается он на десятках.

Связанные термины

• Ansible — конфигурация серверов как код
• Kubernetes — декларативная платформа, где GitOps раскрывается полностью
• Git — источник истины в GitOps
• CI/CD — как GitOps соотносится с классическим пайплайном
• cloud-init — первичная настройка машин при создании
• DevOps — культура, частью которой является IaC