Immutable Deployment: гарантована відтворюваність релізів

Immutable Deployment: гарантована відтворюваність релізів

«Працює на staging, не працює на prod» — класика, яка майже завжди пояснюється одним: сервери прода накопичили стан. Хтось вручну поставив пакет без фіксації. Хтось поправив конфіг напряму. Накопичилися артефакти старих деплоїв. Immutable Deployment прибирає цю категорію проблем повністю: сервер не змінюється — він замінюється. Концепція описана в статті про Immutable infrastructure. Ми впроваджуємо цю стратегію під ключ, від аудиту до налаштування GitOps, і гарантуємо передбачуваність кожного релізу. Наш досвід — понад 6 років у DevOps, більше 40 успішних проектів з впровадження GitOps. Річна економія від усунення дрейфу конфігурації може бути значною, а середній час усунення інциденту скорочується до 5–10 хвилин — у 6–8 разів швидше порівняно з mutable-підходом.

Чому Immutable Deployment кращий за змінні сервери?

Змінні сервери схожі на снігову кулю — кожна ручна дія залишає слід. З часом відмінності між dev і prod стають катастрофічними: різняться версії бібліотек, конфіги, права доступу. Immutable підхід виключає це: одні й ті самі інструкції збірки дають один і той самий образ на будь-якій машині в будь-який час. Образ збирається один раз, тегується хешем коміту або семантичною версією, і цей самий образ проходить через усі середовища — від dev до prod. Жодних apt-get upgrade в production, жодних sed -i по живих конфігах. Це знижує час на відкат з 20-30 хвилин до 2-3 хвилин, а кількість інцидентів, пов'язаних з дрейфом конфігурації, зменшується на 95%. Навіть частота деплоїв може зрости з одного разу на тиждень до кількох разів на день — без втрати стабільності.

У Docker це виглядає жорстко: базовий образ повинен бути з точною версією, не latest:

FROM python:3.11.9-slim-bookworm
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
USER nonroot
ENTRYPOINT ["gunicorn", "app:wsgi"]

Тег образу в Kubernetes Deployment — завжди конкретний, ніколи :latest:

spec: containers: - name: api image: registry.example.com/api:a3f8c21d imagePullPolicy: IfNotPresent 

imagePullPolicy: IfNotPresent — якщо образ з таким тегом вже є на ноді, не тягнути знову. При immutable тегах це безпечно.

Як версіонувати конфігурацію?

Незмінність образу означає, що конфігурація середовища — secrets, URLs, feature flags — не може бути частиною образу. Вона передається через environment variables або монтовані ConfigMap/Secret. Важливо: ConfigMap і Secret теж повинні бути versioned. api-config-v3 — це нова версія конфігу, api-config-v2 залишається і використовується старими подами під час rolling update. Після повного переходу стара версія видаляється.

External Secrets Operator + Vault вирішує це чистіше: секрети зберігаються у Vault, ESO синхронізує їх у Kubernetes Secrets, перестворюючи при зміні у Vault.

Деплой через заміну, не оновлення

Стандартний kubectl set image робить rolling update: старі поди йдуть, нові приходять. Це immutable на рівні подів, але Deployment залишається змінним об'єктом. Більш чистий підхід — GitOps: будь-яка зміна тільки через PR у Git, ArgoCD синхронізує кластер з репозиторієм.

---
# argocd/application.yaml
spec:
  source:
    repoURL: https://github.com/company/k8s-manifests
    targetRevision: HEAD
    path: apps/api
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

selfHeal: true — якщо хтось руками зробив kubectl edit deployment, ArgoCD поверне назад до того, що в Git. Це і є immutability на рівні кластерного стану.

Rollback — це деплой попереднього образу

При immutable стратегії rollback — просто деплой старого тегу. Жодної магії kubectl rollout undo, яка відновлює попередній ReplicaSet. Просто змінюється тег у маніфесті (через Git revert) і ArgoCD синхронізує.

git revert HEAD # відкочуємо останній коміт з новим тегом
git push origin main # ArgoCD побачить зміну і задеплоїть старий образ

Це займає 2-3 хвилини. Передбачувано і відтворювано. Середня вартість одного інциденту з дрейфом конфігурації може сягати суттєвих витрат, тому швидкий rollback окупається одразу.

Процес впровадження: покрокове керівництво

1. Аудит інфраструктури: перевіряємо Dockerfile на точні версії, CI/CD на mutable теги, кластери Kubernetes на стан.
2. Налаштування pipeline: збірка → тегування (SHA + середовище) → push → деплой. Всі теги immutable.
3. Налаштування GitOps: розгортаємо ArgoCD або FluxCD з політиками self-heal і prune.
4. Версіонування ConfigMap і Secret: кожен конфіг отримує версію, при зміні створюється нова, стара видаляється після переходу.
5. Тестування rollback: перевіряємо, що відкат працює через Git revert.
6. Документація та навчання: пишемо runbook і проводимо воркшоп для команди.

---
stages:
  - build
  - push
  - deploy
variables:
  IMAGE_TAG: ${CI_COMMIT_SHORT_SHA}
build:
  stage: build
  script:
    - docker build -t registry.example.com/app:${IMAGE_TAG} .
    - docker tag registry.example.com/app:${IMAGE_TAG} registry.example.com/app:latest-production
push:
  stage: push
  script:
    - docker push registry.example.com/app:${IMAGE_TAG}
deploy:
  stage: deploy
  script:
    - sed -i "s|image:.*|image: registry.example.com/app:${IMAGE_TAG}|g" k8s/deployment.yaml
    - git commit -m "Update image tag to ${IMAGE_TAG}"
    - git push

Що входить в роботу

• Аудит інфраструктури: Dockerfile, CI/CD, кластери Kubernetes
• Перехід на immutable теги з хешами комітів
• Налаштування GitOps (ArgoCD/Flux) з політикою self-heal
• Версіонування ConfigMap і Secret з підтримкою rolling update
• Документація runbook та навчання команди
• Пост-релізна підтримка протягом 2 тижнів

Вартість розраховується індивідуально після аудиту. Отримайте консультацію — оцінимо ваш проект за 1 день. Замовте аудит інфраструктури сьогодні, щоб уникнути проблем з дрейфом конфігурації. Послуги DevOps-інженерів з налаштування безшовного деплою допоможуть вам налагодити CI/CD pipeline.