Mit csinal vegig egy deploy a NIP-en

A Nortinia Infrastructure Platform (NIP) az a hely, ahol a mernoki commit-bol futo szolgaltatas lesz. Nem egy CI/CD eszkoz, hanem egy infrastruktura-vezerlo: a kubernetes klasztereket, a GitOps allapotot, az image rolloutokat es a notifikaciokat egyutt kezeli. Ez a cikk vegigveszi, mi tortenik egy egyszeru git push-tol addig, amig egy uj pod kiszolgalja a forgalmat.

A nyolc lepes (median ido: 9 perc)

1. Commit — a mernok push-ol egy main branchre (vagy mergeli a PR-t). GitHub Actions workflow indul.
2. CI build — a workflow OCI imaget epit. Cache-bol dolgozunk, ezert egy tipikus backend build 3-4 perc.
3. Push GHCR-be — a kep felmegy a ghcr.io/nortinia-ltd/<repo> repoba, kettos taggel: main-<sha> es main-latest.
4. Webhook a NIP fele — a CI POST-olja a image-built payloadot a NIP /api/v1/deploy/image-built route-jara. A payload tartalmazza a repo nevet, a commit SHA-t, a kep tag-et es a celkornyezetet (staging/prod).
5. NIP deduplikalja — egy idempotency kulccsal (repo+sha+env) leellenorzi, hogy nem dolgozta-e fel mar a webhookot. Ha igen, 200-zal valaszol es nem csinal semmit.
6. Flux reconcile — a NIP frissiti a GitOps repoban a Kustomization image-eit (egy commit, ami a kustomization.yaml-ban a tag-et bumppolja). Flux 60 masodpercen belul eszreveszi, es elinditja a sync-et.
7. kubectl rollout — a Deployment uj ReplicaSetet kap, a readiness probe-ig var minden uj pod, mielott felvenne a forgalmat. Default surge: 25%, max unavailable: 0.
8. Notifikacio — Slack uzenet a #deploys csatornaba a commit szerzojenek tag-elve. Sikeres rollout eseten zold, hiba eseten piros + on-call elerheto.

End-to-end median: 9 perc (commit-tol az elso uj pod readinessig). A leggyakoribb szuk keresztmetszet a CI build (kep meret + Next.js production build).

A rollback negy lepese

Ha valami baj van, a rollback nem git revert — annal gyorsabb ut van:

1. NIP UI-on "Rollback to previous tag" gomb.
2. NIP commit-ol a GitOps repoba a kovetkezo legutobb sikeres tag-et.
3. Flux 60 mp-en belul sync-eli.
4. kubectl rollout uj ReplicaSetet inditja, regi forgalom elhal.

Vegrehajtasi ido: 2-3 perc. A git revert ut 8+ perc lenne (CI build + push + webhook).

A webhook deduplikacio miert kell

A GitHub Actions retry-ozhat, ha a NIP valasza lassu vagy 5xx. A webhook dedup nelkul ket egymast koveto Flux commit lett volna ugyanarra a SHA-ra, ami felesleges reconcile zaja. A dedup kulcs: ${repo}:${sha}:${env}, 24 ora TTL Redisben. Egyszeru, de napi 30+ duplicate-et szur ki.

Mi van, ha a Flux sync elakad

A Flux-nak van egy failureSeverity mezo a HelmRelease/Kustomization status-aban. A NIP polloz minden 30 mp-ben. Ha hiba van (pl. invalid manifest, image pull error), a deploy state-je FAILED-re megy, es az on-call kap Slack DM-et + PagerDuty page-et (Sev2).

A leggyakoribb hibak forrasa az utolso 6 honapban: (1) tul nagy memory request, ami nem fer be a node-ba; (2) titkos kulcs hianya (SealedSecret nem deployolva); (3) ConfigMap mezo-elironas. Mindharomra runbook van.

Mit nem epitettunk meg (es miert nem)

• Canary deployment auto-rollback — terveztuk, de a forgalom nem eleg nagy hozza, hogy a metric-alapu doglas megbizhato legyen. Helyette: 5 perces stabilitasi ablak utan ertekeljuk a Sentry error rate-et, es ember dont.
• Multi-region failover automation — egy regio van (Hetzner FSN1). Ha kell masik, akkor sem auto.
• Sajat container registry — GHCR mukodik, ingyenes, nincs miert valtani.

Szamok az utolso negyedevbol

• 1 247 sikeres deploy
• 23 rollback (1.8%)
• 9.1 perc median end-to-end
• 0 elveszett deploy (a webhook dedup miatt)