⚙️ DevOps‑челлендж «Zero‑Downtime? Серьёзно?»

Вам выдали репозиторий ShopCat (SaaS‑платформа).
Он уже «работает» в Kubernetes‑кластере AWS EKS, собирается GitHub Actions и раскатывается Helm‑чартом.
Менеджеры уверяют, что *«релизы без простоя, всё по‑мажору»* — но пользователи получают 502 при каждом деплое.

Ваша миссия — найти и устранить скрытую причину даунтайма, не внося изменений в само приложение.

📂 Что есть в репо

.
├─ docker/
│  └─ Dockerfile        # двухступенчатая сборка
├─ helm/
│  └─ shopcat/          # Chart.yaml + values.yaml + templates/*
├─ k8s/
│  ├─ namespace.yaml
│  └─ ingress.yaml      # AWS ALB Ingress Controller
├─ .github/workflows/
│  └─ deploy.yml        # CI → CD
└─ terraform/
   ├─ eks.tf
   ├─ rds.tf
   └─ outputs.tf

⚠️ Подвох № 1 (скрытый таймер)
В Dockerfile есть RUN adduser ... с интерактивным sudo‐prompt’ом, который «застревает»,
но только если кеш Docker‑слоёв инвалидирован (например, при обновлении base‑image).

⚠️ Подвох № 2 (невидимая «дырка» в rolling‑update)
В шаблоне Deployment:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
---
readinessProbe:
  httpGet:
    path: /healthz
    port: 8080

* /healthz возвращает 200 даже во время graceful‑shutdown (SIGTERM → 30 с drain).
* terminationGracePeriodSeconds = 60, а Ingress ALB считает Pod «живым», пока тот не закроется.
* В итоге старый Pod уже не принимает новые запросы, но остаётся в EndpointSlice ещё ±60 секунд.

⚠️ Подвох № 3 («сам себе злобный Буратино»)
Helm‑values указывают образ image: shopcat:latest.
GitHub Actions пушит тэгированный :vX.Y.Z, но тэг :latest перезаписывается той же джобой PR‑preview.
В production во время canary‑release может внезапно оказаться незамёрженый код Pull‑Request’а.

## 🏆 Задание

1. Настройте pipeline, чтобы:
* на каждый PR собирался shopcat:<sha> и катил preview‑релиз в namespace pr‑<num>,
* на main пушился shopcat:v<semver>, после чего Helm делал blue/green‑deploy в prod.
2. Измените манифесты так, чтобы во время rolling‑update не было 502/504:
* никакого даунтайма, даже если контейнеру нужно 60 с на graceful‑shutdown;
* сетевой трафик должен _сначала_ уходить от старых Pod’ов, а _потом_ те выключаются.
3. Ограничьте blast‑radius: превратить latest в «immutable image tag» и запретить Helm обновлять release, если image.tag уже был задеплоен (hint: .Chart.AppVersion + `helm.sh/hook`).
4. Найдите и исправьте «застревающий» шаг в Dockerfile, чтобы кэш всегда использовался, а билд не ждал интерактива.
5. ✅ Предоставьте:
* патчи (`.diff`) или PR в репозиторий,
* скриншот успешного kubectl rollout status deployment/shopcat ‑‑watch,
* краткое Post‑mortem (≤ 300 слов): *«Почему был даунтайм и какой фикс вы сделали»*.

## 💣 Неочевидные ограничения

* Нельзя менять исходный код приложения (только инфраструктура).
* Кластер prod имеет 2 ноды t3.medium (4 vCPU, 8 GiB) — бюджету больно от лишних replica‑set’ов.
* CI‑время — ≤ 5 мин на каждый PR.
* Все секреты — только через AWS Secrets Manager; в манифестах не должно быть plaintext.

🔜 Решение

@DevOPSitsec