Z dvoch VM na HA Kubernetes — CI/CD pre feature vetvy a deploye bez výpadku

Problém

Webová platforma bežala na dvoch samostatných linuxových VM — jeden aplikačný server, jeden databázový. Každý release znamenal výpadok, pretože jediné webové VM bolo produkciou. Viacerí vývojári nemohli pracovať na rôznych funkciách paralelne: existovalo jedno zdieľané staging prostredie a fronta naň. Lokálny vývoj používal iný stack než produkcia, takže časť chýb sa ukázala až po deployi. Obidve VM boli single point of failure.

Riešenie

Desaťtýždňová spolupráca: kontajnerizácia, Kubernetes platforma, CI/CD pipeline, presun databázy a observabilita.

Kontajnerizácia a parita s lokálnym vývojom

• Pripravené produkčné Docker image pre aplikáciu: rovnaký základ, rovnaké runtime verzie, rovnaký tvar konfigurácie ako v produkcii
• Tie isté image bežia lokálne cez docker-compose — vývojár na notebooku vidí rovnaký runtime, aký posiela do produkcie
• Sessions, uploady súborov a iný zdieľaný stav presunuté z aplikačného kontajnera do backing services, takže každý pod je zameniteľný

Kubernetes platforma

• HA klaster s rolling-update Deploymentmi za Ingressom, PodDisruptionBudgetmi a HPA na aplikačnej vrstve
• Workloady dimenzované podľa reálnych dát z pôvodných VM, nie odhadom
• Pôvodné VM bežali paralelne dva týždne pred dekomisáciou

Databáza

• MariaDB Galera multi-master nahradila jediné DB VM
• Logické aj binlog zálohy na úrovni databázy, replication-lag a slow-query alerty zapojené od prvého dňa
• Releasy so schémovými zmenami ostávajú v plánovanom okne — sú to jediné releasy, ktoré majú výpadok — pretože online schema change s Galerou je samostatná disciplína a do tejto spolupráce sa nevošla

CI/CD s feature branchami

• GitLab CI buildne image raz pre každý commit; ten istý artefakt beží v každom prostredí
• GitLab Agent (KAS) sťahuje Kustomize overlays pre jednotlivé prostredia z repozitára — prod, staging a dočasné prostredia pre feature vetvy — a pri každej zmene ich aplikuje do klastra; vývojár dodáva mergom do repozitára
• Každá feature vetva dostane pri pushi dočasný namespace a DNS subdoménu — dvaja vývojári môžu pracovať na dvoch vetvách naraz bez toho, aby si liezli do cesty
• Merge-request pipeline spúšťa integračné testy voči reálne buildnutému image, nie voči vývojárskemu hostu

Observability

• Prometheus, Grafana, Loki v klastri pre metriky a aplikačné logy
• Aplikačné metriky + golden signals + metriky DB vrstvy (replication lag, slow queries, connection saturation)
• Access logy z webu a ingressu idú do Elasticsearch a sú vizualizované v pripravených Kibana dashboardoch — podľa statusu, endpointu, histogramov latencie a top klientov
• SLO alerting s runbookami priamo z každého alertu — žiadny spam, žiadne alerty bez vlastníka

Výsledok

• Rolling deploy bez výpadku pre aplikačné zmeny — bežný release prejde nepovšimnuto
• Releasy s DB migráciou ostávajú v plánovanom okne, otvorene zaznamenané v release runbooku
• Dva single-VM SPOF preč — webová vrstva škáluje horizontálne, databáza je Galera klaster
• Paralelná práca na feature vetvách: každý merge request má vlastné preview prostredie; čakanie na frontu a bolesť z merge konfliktov výrazne klesli
• Lokálny stack zhodný s produkciou: docker-compose dev prostredie odhalí chyby v konfigurácii a runtime skôr, než sa dostanú do reálneho prostredia

Čoho som sa zámerne nedotkol

Existujúci zdroj pravdy (GitLab) a identity stack ostali na mieste — spolupráca bola o presune aplikácie na HA kontajnerovú platformu, nie o prestavbe všetkého okolo nej.