Ответ
Мой стандартный пайплайн деплоя сервисов строился вокруг контейнеризации (Docker) и оркестрации (Kubernetes), с полной автоматизацией через CI/CD.
Процесс:
- CI (Continuous Integration): При пуше кода в Git (например, в ветку
main) запускался пайплайн в GitLab CI/CD или GitHub Actions. Он выполнял:- Сборку Docker-образа.
- Запуск юнит- и интеграционных тестов.
- Загрузку образа в приватный registry (Harbor, ECR, GCR).
- CD (Continuous Deployment): После успешной сборки автоматически или по approval обновлялся манифест в Kubernetes.
Пример Deployment манифеста для Kubernetes:
apiVersion: apps/v1
kind: Deployment
metadata:
name: backend-service
spec:
replicas: 3
selector:
matchLabels:
app: backend-service
template:
metadata:
labels:
app: backend-service
spec:
containers:
- name: app
image: my-registry/backend:${COMMIT_SHA}
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
resources:
requests:
memory: "128Mi"
cpu: "100m"Сопутствующая инфраструктура:
- Конфигурация: Использовал Helm charts или Kustomize для управления конфигами разных сред (dev/staging/prod).
- Инфраструктура: Виртуальные машины, сети, балансировщики создавались через Terraform.
- Наблюдаемость: На каждый сервис настраивал метрики (Prometheus), логи (Loki) и трейсинг (Jaeger). Всегда добавлял
readiness/livenessпробы. - Стратегия деплоя: Применял rolling updates по умолчанию, для критичных сервисов тестировал blue-green или canary-деплой с помощью Istio или Flagger.
Ответ 18+ 🔞
Да ты посмотри, какой у меня был пайплайн деплоя, просто песня, а не работа! Всё по канону, как у взрослых дядек: Docker, Kubernetes, полная автоматизация — красота.
Как это всё, блядь, крутилось:
-
CI (Continuous Integration): Ты только в
mainветку код закинул — тут же, ёпта, как по маслу, запускается пайплайн в GitLab CI/CD. Он делает три дела, проще пареной репы:- Собирает Docker-образ.
- Гоняет все тесты, юниты там, интеграционные — чтобы никакой хуйни в продакшн не просочилось.
- Запихивает готовый образ в приватный registry (типа Harbor). Всё, образ готов, лежит, ждёт своего часа.
-
CD (Continuous Deployment): А вот тут уже начинается магия. Как только сборка прошла успешно — либо автоматом, либо после лёгкого пинка (approval), в Kubernetes летит обновлённый манифест. И сервис, сука, обновляется, даже не моргнув глазом. Красота!
Вот, смотри, как примерно выглядел мой манифест для Kubernetes. Ничего лишнего, всё по делу:
apiVersion: apps/v1
kind: Deployment
metadata:
name: backend-service
spec:
replicas: 3
selector:
matchLabels:
app: backend-service
template:
metadata:
labels:
app: backend-service
spec:
containers:
- name: app
image: my-registry/backend:${COMMIT_SHA}
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
resources:
requests:
memory: "128Mi"
cpu: "100m"А вокруг этого, ядрёна вошь, ещё целая куча инфраструктуры вертелась:
- Конфигурация: Чтобы не ебаться с кучей файлов, использовал Helm charts или Kustomize. Один базовый конфиг, а для dev, staging и prod — свои настройки поверх. Удобно, блядь, как.
- Инфраструктура: Все эти виртуалки, сети и балансировщики я на Terraform поднимал. Написал код раз — и потом хоть сто раз воспроизводи. Доверия ебать ноль к ручному созданию.
- Наблюдаемость: А это, чувак, святое! Без этого ты как слепой кот. На каждый сервис цеплял метрики в Prometheus, логи в Loki гнал, трейсинг через Jaeger настраивал. И обязательно пробы
readiness/livenessставил, чтобы кубер понимал, когда поднять или прибить pod. - Стратегия деплоя: Rolling update — это по умолчанию, скучно, но надёжно. А для сервисов, от которых всё зависит, уже баловался: blue-green или canary-деплой через Istio настраивал. Чтобы новую версию на 5% трафика пустить, посмотреть, не сломает ли она всё к хуям, и только потом всем выкатывать. Хитрая жопа, но безопасно.