DevOps a automatizace

Co konkrétně děláme

1. 01

   Posouzení nasazování a CI/CD

   Projdeme cestu změny od commitu do provozu a změříme, kde čeká a kolik stojí. Výstupem je seznam úzkých míst a pořadí, v jakém je řešit. Díváme se na:

   • jak dlouho trvá pipeline a které kroky ji nejvíc zdržují
   • kolik stojí runnery a minuty buildu a kolik z toho připadá na čekání a opakování
   • co se při nasazení dělá ručně a co ví jen jeden člověk
   • nestabilní testy, které se pouštějí znovu, dokud neprojdou
   • velikost a stáří image a závislostí
   • jak se dnes vrací předchozí verze a jak dlouho to trvá
2. 02

   Rychlejší a levnější CI/CD

   Pomalá pipeline zdržuje každou změnu a drahé runnery se platí i za čekání. Pipeline zkrátíme tak, aby se sestavovalo a testovalo jen to, co je potřeba. Zavádíme:

   • cache závislostí a vrstev image, aby se nic nestahovalo a nesestavovalo pořád dokola
   • paralelní běh testů a spouštění jen pro části, které se změnily
   • vlastní nebo automaticky škálované runnery místo drahých sdílených minut, kde se to vyplatí
   • jeden build a stejný artefakt pro test i produkci
   • rychlou zpětnou vazbu: kontrola kódu a unit testy před pomalými integračními testy
   • přehled délky a ceny pipeline v čase, aby bylo vidět, když se zase zpomalí
3. 03

   Kontejnery a Kubernetes

   Aplikace zabalíme do kontejnerů, aby běžela stejně u vývojáře, v testu i v produkci. Kubernetes navrhujeme tam, kde přináší jednodušší provoz nebo škálování. Kde stačí méně, zůstaneme u jednoduššího řešení. Zavádíme:

   • Dockerfile s vícefázovým buildem (multi-stage) a malé image bez zbytečností
   • kontrolu zranitelností v image a jejich pravidelnou aktualizaci
   • container registry s verzováním a pravidly pro mazání starých verzí
   • Kubernetes, nebo jednodušší běh kontejnerů (například Cloud Run nebo Docker Compose), podle velikosti a potřeb aplikací
   • popis nasazení aplikací v Helmu nebo Kustomize
   • limity zdrojů, kontroly stavu (health checks) a automatické škálování
   • jednotné logy a metriky aplikací, na které navazuje monitoring
4. 04

   GitOps a přehled nasazených aplikací

   Požadovaný stav všech aplikací je popsaný v Gitu a nástroj jako Argo CD nebo Flux ho průběžně porovnává s tím, co skutečně běží. Na jednom místě vidíte, co kde běží a v jaké verzi. Zavádíme:

   • přehled aplikací: která verze běží v kterém prostředí, kdy a kým byla nasazena
   • nasazení přes merge request se schválením místo ručních příkazů
   • průběžnou synchronizaci a upozornění, když se provoz od Gitu odchýlí (drift)
   • návrat k předchozí verzi vrácením změny v Gitu
   • stav aplikací a historii nasazení na jednom místě
   • přístup do přehledu pro vývojáře, bez nutnosti přístupu do clusteru
5. 05

   Řízené nasazování

   Nová verze nemusí jít naráz ke všem uživatelům. Nasazujeme postupně (například s Argo Rollouts) a podle metrik rozhodujeme, jestli pokračovat. Podle potřeb zavádíme:

   • postupné nasazení na malou část provozu (canary) a jeho rozšiřování podle chybovosti a odezvy
   • blue-green nasazení s přepnutím a rychlým návratem
   • automatický návrat předchozí verze, když metriky nevypadají dobře
   • přepínače funkcí (feature flags), aby šlo novou funkci vypnout bez nového nasazení
   • změny databáze navržené tak, aby fungovaly se starou i novou verzí aplikace
   • schvalovací krok před produkcí tam, kde ho potřebujete
6. 06

   Prostředí a konfigurace

   Vývoj, test a produkce vznikají ze stejného popisu, takže se od sebe nerozcházejí. Infrastrukturu pod aplikacemi popíšeme v IaC (Terraform, Ansible). Zavádíme:

   • oddělená prostředí pro vývoj, test a produkci, která se liší jen hodnotami v konfiguraci
   • dočasná prostředí pro merge requesty, která po sloučení zmizí
   • konfiguraci aplikací v Gitu, oddělenou od kódu a verzovanou
   • lokální prostředí pro vývojáře (Docker Compose, dev containers), které se chová jako produkce
   • infrastrukturu v IaC, takže nové prostředí vznikne z kódu
7. 07

   Hesla, klíče a přístupy

   Hesla, klíče a certifikáty patří do trezoru, ne do kódu ani do proměnných, které vidí každý. Zavádíme:

   • trezor pro hesla a klíče (secrets), například Vault nebo Secret Manager v cloudu, odkud si je aplikace i nasazování berou
   • krátkodobé přihlašovací údaje pro CI/CD místo dlouhodobých klíčů (OIDC, Workload Identity)
   • kontrolu, že se do repozitáře nedostane heslo ani klíč
   • pravidelnou obměnu klíčů a automatické obnovování certifikátů
   • oprávnění pipeline a aplikací jen v nutném rozsahu
   • osobní účty, kterým jde přístup rychle odebrat