Ответ
В современных DevOps-практиках код приложения и код инфраструктуры (IaC) проходят единый автоматизированный конвейер CI/CD, который обеспечивает их согласованное и надежное развертывание.
Типичный пайплайн для микросервиса в Kubernetes:
# .gitlab-ci.yml (или Jenkinsfile, GitHub Actions)
stages:
- validate # Валидация кода инфраструктуры
- test # Тесты приложения
- build # Сборка артефакта
- scan # Сканирование безопасности
- deploy-infra # Деплой инфраструктуры (если нужно)
- deploy-app # Деплой приложения
- smoke-test # Дымовое тестирование
variables:
K8S_NAMESPACE: "staging"
APP_IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
# 1. ВАЛИДАЦИЯ: Проверяем корректность манифестов Kubernetes и Terraform
validate_k8s:
stage: validate
script:
- kubectl apply --dry-run=client -f k8s/manifests/
- terraform -chdir=infra/ init -backend=false
- terraform -chdir=infra/ validate
# 2. ТЕСТЫ и СБОРКА: Тестируем и собираем Docker-образ
unit_test:
stage: test
script:
- npm run test:ci
build_image:
stage: build
script:
- docker build --pull -t $APP_IMAGE .
- docker push $APP_IMAGE
# 3. ДЕПЛОЙ: Обновляем инфраструктуру и приложение
deploy_to_staging:
stage: deploy-app
script:
# Используем Kustomize или Helm для подстановки тега образа
- sed -i "s|__IMAGE_TAG__|$CI_COMMIT_SHA|g" k8s/manifests/deployment.yaml
- kubectl apply -f k8s/manifests/ -n $K8S_NAMESPACE
- kubectl rollout status deployment/my-app -n $K8S_NAMESPACE --timeout=120s
environment:
name: staging
url: https://staging.myapp.com
# 4. ДЕПЛОЙ В PROD (ручное подтверждение)
deploy_to_prod:
stage: deploy-app
script:
- kubectl apply -f k8s/manifests/ -n production
- kubectl rollout status deployment/my-app -n production --timeout=180s
environment:
name: production
url: https://myapp.com
when: manual
only:
- mainКлючевые принципы:
- Everything as Code: Манифесты K8s, конфигурации Terraform/Ansible, пайплайны — все хранится в Git.
- Идемпотентность: Деплой инфраструктуры через Terraform и приложения через
kubectl applyможно запускать многократно с одинаковым результатом. - Неизменяемые артефакты: Собирается один Docker-образ с уникальным тегом (например, хэш коммита), который промоутится по всем средам. Конфигурация инжектируется через переменные окружения или ConfigMaps/Secrets.
- Стратегии деплоя: Для минимизации downtime в K8s используем стратегию
RollingUpdate, а для более сложных сценариев — blue-green или canary-деплой, настраиваемые через сервис-меши (Istio) или инструменты вроде Flagger. - Деплой инфраструктуры: Изменения в инфраструктуре (добавление ноды, изменение Security Group) также проходят через CI/CD: план (
terraform plan) проверяется, а применение (terraform apply) часто требует мануального подтверждения для production.
Ответ 18+ 🔞
Слушай, а ведь реально, когда вдумаешься — ёперный театр! Раньше же админы всё руками делали, скрипты какие-то кривые писали, а сейчас, блядь, всё как по маслу. Весь этот цирк с конями — и приложение, и сервера — гонится по одной трубе, и доверия к этому процессу, блядь, ноль, пока сам не увидишь, что всё завелось.
Вот смотри на этот пайплайн, обычный такой. Сначала, чувак, валидация. Это как проверка, не забыл ли ты штаны надеть перед выходом. kubectl с флагом --dry-run тыкается в манифесты, terraform validate смотрит, не накосячил ли ты в коде инфраструктуры. Просто чтобы не было потом: "ой, а у меня запятая лишняя" — и всё, пиздец, пол-кластера накрылось медным тазом. Элементарно, но овердохуища как важно.
Потом — тесты и сборка. Ну тут понятно, npm run test:ci гоняет юнит-тесты. Если они сдохли — дальше даже не суйся, чих-пых тебя в сраку, иди фикси баги. Потом docker build и push. Главный принцип — неизменяемый артефакт. Собрал один образ с хэшем коммита и таскаешь его по всем средам, от staging до production. Никакого "а давайте на проде соберём заново". Хуй с горы! Один бинарник на всех — и волнение, блядь, меньше, потому что на staging он уже работал.
А вот самый сок — деплой. В staging он автоматом после сборки. Подставляем в манифест тег образа и — хуяк — kubectl apply. И сразу rollout status с таймаутом, чтобы не зависнуть, если поды не встанут. Это и есть идемпотентность — можешь применять этот apply хоть сто раз, хуй с винтом, результат будет один и тот же: в кластере будет ровно то, что в манифестах.
И отдельная песня — деплой в прод. Смотри, какой хитрожопый подход: when: manual. То есть пайплайн встанет и будет ждать, пока какой-нибудь ответственный пездабол не нажмёт кнопку. И only: main — значит, эта работа запустится только если мерж сделали в главную ветку. Страховка от пиздопроёбины. Нажал кнопку — поехали те же манифесты, но уже в неймспейс production. И снова ждём rollout status. Всё, жирный маркер "деплой завершён" можно ставить.
Ключевые принципы, блядь, они не с потолка:
- Everything as Code. Всё в гите: и манифесты кубера, и терраформ, и сам этот пайплайн. Если чего-то нет в гите — этого, блядь, не существует. История изменений, ревью кода — красота.
- Идемпотентность. Я уже говорил, но повторюсь, потому что это пиздец как важно.
terraform applyиkubectl apply— твои лучшие друзья. Запустил — получил предсказуемый результат. Запустил ещё раз — ничего не сломалось. - Неизменяемые артефакты. Образ с тегом
:abc123— это закон. На staging'еabc123, на проде — тот жеabc123. Конфиги отдельно, через ConfigMap или переменные окружения. Никакой магии. - Стратегии деплоя. В K8s из коробки идёт
RollingUpdate— он потихоньку новые поды поднимает, старые убивает, без даунтайма. А если хочешь изощрённости — blue-green или canary через Istio/Flagger. Но это уже для параноиков, у которых терпения, блядь, ноль, и они хотят на 2% трафика новую версию погонять. - Деплой инфраструктуры. А вот это, чувак, вообще высший пилотаж. Ты меняешь не код приложения, а, например, размер инстанса в терраформе. Так этот план тоже через CI/CD прогоняешь! Сначала
terraform plan— смотришь, что он там собрался менять. Потом, если не напугался, —apply. И часто для прода этотapplyтоже ручной, с подтверждением. Чтобы какой-нибудь инженер, не глядя, всю базу не вырубил.
Вот и вся магия. Выглядит сложно, но когда настроил — жить становится проще. Одна команда git push — и через полчаса твой код уже работает на проде. Главное — не накосячить в манифестах, а то будет тебе хиросима, а не деплой.