Automated DB migrations

10 October 2025

Автоматизация миграций БД

Миграции — критическая часть деплоя: их нужно запускать аккуратно, атомарно и предсказуемо. Лучшие практики:

Миграции — отдельный шаг в CI/CD pipeline (до обновления сервиса)
Запускать миграции с помощью контейнера, который содержит код и мигратор (Flyway, Liquibase, Alembic, Django migrations, Doctrine и т.д.)
Идempotent-миграции: писать миграции так, чтобы повторный запуск не ломал БД
В production включать таймауты и резервный план (rollback / backup)

Пример GitLab job для миграций (PHP + Doctrine)

migrate:
  stage: deploy
  image: registry.gitlab.com///php-base:latest
  script:
    - apk add --no-cache mysql-client    # если нужен клиент
    - export DATABASE_URL="mysql://root:${DB_PASS}@${DB_HOST}:3306/${DB_NAME}"
    - php vendor/bin/doctrine-migrations migrate --no-interaction
  only:
    - main
  when: manual     # можно сделать ручным для безопасного запуска

Пример с Flyway (контейнер)

# Запуск миграций в CI через официальный flyway образ
docker run --rm \
  -v $(pwd)/sql:/flyway/sql \
  -e FLYWAY_URL=jdbc:mysql://$DB_HOST:3306/$DB_NAME \
  -e FLYWAY_USER=root \
  -e FLYWAY_PASSWORD=$DB_PASS \
  flyway/flyway migrate

Совет: Всегда делай dump/backup перед критическими миграциями и тестируй миграции в staging с данными, близкими к prod.

13. ?? Blue-Green и Canary деплой

Стратегии безопасного выката для уменьшения риска:

Blue-Green — держим две среды (blue / green). Выкатим новую версию в inactive окружение, прогоняем smoke tests, меняем маршрутизацию (Ingress / LoadBalancer).
Canary — новой версии даём маленький процент трафика, затем постепенно увеличиваем.

Blue-Green (пример, упрощённо)

# 1) Деплой новой версии как отдельный Deployment (e.g. app-green)
kubectl apply -f deployment-app-green.yaml

# 2) Проверки (smoke tests)
# 3) Сменить Service/Ingress чтобы указывать на app-green
kubectl patch svc app -p '{"spec":{"selector":{"version":"green"}}}'

# 4) Если всё ок — удалить старый (app-blue) или оставить для быстрой откатки

Плюс: мгновенный свитч; минус — двойной ресурс.

Canary с Nginx/Ingress (ручной подход)

# Пример: два Deployment (app-v1, app-v2) и Ingress с weight (если Ingress поддерживает)
# Некоторые ingress controllers (traefik, nginx plus, istio) поддерживают traffic-splitting
# Для nginx-ingress можно использовать annotations в nginx-plus или external tools

Лучше решение — Argo Rollouts

Argo Rollouts добавляет CRD для управляемых стратегий (canary, blue-green) с автоматическими анализами/метриками.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: example-rollout
spec:
  replicas: 4
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 1m }
        - setWeight: 50
        - pause: { duration: 1m }
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
        - name: example
          image: registry.gitlab.com///example:TAG

Argo Rollouts можно подключить к Prometheus / Datadog для автоматического промо/роллбека по метрикам.

14. ?️ Helm Charts — шаблонизация манифестов

Helm позволяет пакетировать Kubernetes-ресурсы, параметризовать их и версионировать. Полезно для повторяемости деплоя и совместной настройки.

Быстрый skeleton Helm chart

helm create myapp
# Создаст структуру charts/myapp/ с templates/, values.yaml и т.д.

# values.yaml (упрощённо)
replicaCount: 2

image:
  repository: registry.gitlab.com///php-app
  tag: "latest"

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: true
  hosts:
    - host: example.devopz.tech
      paths: ["/"]

# templates/deployment.yaml (вырезка)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myapp.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ include "myapp.name" . }}
  template:
    metadata:
      labels:
        app: {{ include "myapp.name" . }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: 80

Helm в CI/CD

В pipeline генерируем/пакуем chart и делаем helm upgrade --install:

# В job CI
helm repo add mycharts https://charts.example.com
helm dependency update ./chart
helm upgrade --install myapp ./chart --namespace prod --set image.tag=$CI_COMMIT_SHA

Рекомендуется подписывать чарты и хранить chart-repo (ChartMuseum, OCI registry).

15. ? ArgoCD — GitOps для Kubernetes

ArgoCD позволяет: держать desired state в Git и автоматически синхронизировать кластер с репозиторием (GitOps).

Установка (кратко)

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Простой ArgoCD Application (под Helm chart или k8s-manifests)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: This email address is being protected from spambots. You need JavaScript enabled to view it.:/.git'
    targetRevision: main
    path: charts/myapp   # или path: k8s/
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

ArgoCD будет отслеживать git и автоматически синхронизировать кластер, либо делать это вручную через UI/CLI.

ArgoCD + Helm + Vault

Используй HelmRelease или ArgoCD с Helm chart
Для секретов — интеграция через External Secrets (ExternalSecretsOperator) или использование Vault Secret Agent Injector
Argo CD может использовать pull secrets/credentials, но секреты лучше подтягивать динамически из Vault

16. ? Пример полного GitOps workflow

Dev -> Push в GitLab
CI: собирает образ, пушит в Registry, создаёт тег/обновляет Helm values (image.tag)
CI делает commit в git-repo (например, обновляет values.yaml с новым тегом) или открывает MR
ArgoCD видит изменение в Git и автоматически применяет обновления в кластере
При включённом Argo Rollouts — контрольованное продвижение (canary) с авто-анализом метрик

17. ✅ Best Practices и чеклист

? Автоматизируй миграции, но делай их отдельно и с бэкапом
? Тестируй стратегии деплоя в staging (blue/green, canary) перед prod
? Храни манифесты в Git — это single source of truth
? Секреты — в Vault / External Secrets → не в git
? Интегрируй мониторинг и автоматические проверки (smoke tests, SLO/SLIs)
? Используй Helm + ArgoCD/Flux для GitOps и повторяемых деплоев
? Вводи rollback-планы и health checks (readiness/liveness probes)

Вывод ?

Сочетая CI (GitLab), Helm, ArgoCD и Vault можно построить безопасный, автоматический и auditable pipeline: от коммита до постепенного, контролируемого выпуска в продакшен. Blue-Green и Canary дают контроль над риском, Argo Rollouts автоматизирует промо/роллбэки по метрикам, а Helm делает деплой параметризованным и переносимым.

Хочешь, я сгенерирую конкретный готовый pipeline (.gitlab-ci.yml) + Helm chart + ArgoCD Application, под твой проект (заменю плейсхолдеры на твои имена сервисов и Registry)? ?

Read 14 times Last modified on 19 October 2025

Tagged under