Ответ
Я организую деплой через полностью автоматизированный GitOps-пайплайн с использованием ArgoCD для Kubernetes и стратегией постепенного развертывания.
Архитектура пайплайна:
- Сборка и тестирование (CI): При пуше в ветку
mainJenkins/GitLab CI запускает сборку Docker-образа, прогоняет юнит- и интеграционные тесты, а затем пушит образ с тегом (например,git-sha) в Container Registry (Harbor). - Проверка образа: Запускается сканирование уязвимостей образа (Trivy) и проверка политик (OPA).
- Синхронизация конфигурации (GitOps): ArgoCD постоянно мониторит Git-репозиторий с манифестами Kubernetes. Как только в манифесте обновляется тег образа (например, через PR или автоматически после успешного CI), ArgoCD начинает процесс деплоя.
Стратегия деплоя в production:
- Canary-развертывание: Использую сервисную сеть (Istio) для управления трафиком. Сначала новый релиз (canary) получает 5% трафика.
# Пример VirtualService для Istio (упрощенно) apiVersion: networking.istio.io/v1beta1 kind: VirtualService spec: hosts: - myapp.prod.svc.cluster.local http: - route: - destination: host: myapp.prod.svc.cluster.local subset: stable weight: 95 - destination: host: myapp.prod.svc.cluster.local subset: canary weight: 5 - Анализ и продвижение: Мониторинг (Prometheus/Grafana) и система алертинга (Alertmanager) отслеживают ключевые метрики canary-пода: latency, error rate, throughput. Если в течение заданного времени (например, 15 минут) метрики в норме, я автоматически (или вручную) увеличиваю вес канарейки до 50%, затем до 100%.
- Автоматический откат: Если error rate превышает порог, пайплайн автоматически возвращает 100% трафика на стабильную версию и создает инцидент для анализа.
Практики:
- Все изменения инфраструктуры и конфигурации хранятся в Git (Infrastructure as Code с Terraform).
- Для критичных обновлений требуется ручное подтверждение через PR или интерфейс ArgoCD.
- Обязательно настроены pre- и post-deployment хуки для задач вроде миграций БД.