Ответ
Мы строим end-to-end пайплайн, который от коммита до продакшена управляется кодом. Вот как это выглядит на практике с использованием GitLab CI и Kubernetes.
1. Этап сборки (Build) и тестирования (Test):
- Пайплайн запускается при пуше в любую ветку. Для
main/masterон полный, для feature-веток — обычно ограничен сборкой и unit-тестами. -
Пример (GitLab CI):
build:container: stage: build image: docker:latest services: - docker:dind script: - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA . - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA only: - branches unit-tests: stage: test image: node:18-alpine script: - npm ci - npm run test:unit integration-tests: stage: test image: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA services: - postgres:latest script: - npm run test:integration
2. Этап деплоя (Deploy):
- Мы используем GitOps-подход с ArgoCD или Flux для Kubernetes. Образ, собранный на этапе
build, помечается тегом$CI_COMMIT_SHAи пушится в registry. - Деплой в staging/production: Вместо прямого вызова
kubectlиз CI, пайплайн обновляет манифесты в отдельном Git-репозитории инфраструктуры (например, меняет tag образа вdeployment.yaml). ArgoCD, отслеживая этот репозиторий, автоматически применяет изменения в кластере.deploy:staging: stage: deploy image: alpine/helm:latest script: # Обновляем values.yaml в инфра-репо - sed -i "s/tag:.*/tag: $CI_COMMIT_SHA/" ./infra-repo/apps/my-app/values-staging.yaml - cd ./infra-repo - git add . && git commit -m "Deploy $CI_COMMIT_SHA to staging" - git push origin main only: - main
3. Стратегии деплоя и безопасность:
- Стратегии: Для продакшена настраиваем Blue-Green (с помощью Istio/Ingress контроллеров) или Canary-деплой через ArgoCD Rollouts.
- Secrets: Конфиденциальные данные (пароли БД, API-ключи) никогда не попадают в образ или репозиторий. Они управляются через внешние системы (HashiCorp Vault, AWS Secrets Manager) и подгружаются в поды при запуске через CSI драйверы или sidecar-контейнеры.