Aplikace funguje na lokálu. Docker-compose up, všechno zelené, testy procházejí. A pak ji nasadíte do OpenShiftu a začnou problémy. Pod se restartuje v nekonečné smyčce. Service neodpovídá. Konfigurace je špatně. Health check selhává. Zní vám to povědomě?
Většina těchto problémů nemá kořen v kódu. Má kořen v tom, že vývojář nerozumí prostředí, kde jeho aplikace běží. A přesně tohle je mezera, kterou je potřeba zavřít.
Začněme od základu. Kontejner je proces běžící v kernelových namespaces s vlastním filesystémem postaveným na UnionFS vrstvách. Ne virtuální stroj. Ne sandbox. Proces. Tohle pochopení je klíčové, protože z něj vyplývá všechno ostatní – proč kontejner nemá init systém, proč by měl běžet jeden hlavní proces, proč ephemeral storage zmizí po restartu.
A z toho vyplývá i to, jak stavět Dockerfile. Každá instrukce, která zapisuje na filesystem, vytváří novou vrstvu. Čím víc vrstev, tím větší image, pomalejší pull, víc místa v registry. Optimalizace Dockerfile – správné pořadí instrukcí pro cache, sloučení RUN příkazů, multi-stage buildy – to jsou dovednosti, které vývojáři často přeskočí. A pak se diví, proč jejich image má 2 GB a pull trvá minutu.
V enterprise prostředí navíc pracujete s Podmanem místo Dockeru. Žádný démon, rootless mód, lepší bezpečnostní model. Příkazy jsou prakticky totožné, takže přechod je okamžitý – ale vědět proč a v čem se liší, je důležité.
Health checks jsou pravděpodobně nejdůležitější věc, kterou vývojář v OpenShiftu nastavuje. A zároveň věc, kterou většina vývojářů dělá špatně.
Tři typy probes, tři účely. Liveness probe kontroluje, jestli je kontejner živý. Pokud selže, OpenShift kontejner restartuje. Readiness probe kontroluje, jestli je aplikace připravená přijímat traffic. Pokud selže, Service na ni přestane směrovat požadavky. Startup probe dává aplikaci čas na rozjezd – důležité pro aplikace, které potřebují načíst cache, navázat databázové spojení nebo provést migraci.
Nejčastější chyba: příliš agresivní liveness probe. Timeout 5 sekund, interval 10 sekund, failure threshold 1. Aplikace je pod zátěží, nestihne odpovědět za 5 sekund, liveness probe selže, OpenShift ji restartuje. Po restartu je zátěž ještě vyšší, protože ostatní instance přebraly traffic. Další restart. A máte restart smyčku.
Druhá nejčastější chyba: liveness a readiness probe na stejný endpoint se stejnými parametry. To nedává smysl – liveness by měla kontrolovat, jestli je proces živý (jednoduchý health endpoint), readiness by měla kontrolovat, jestli je aplikace funkční (připojená k databázi, cache nahraná, závislosti dostupné).
Třetí chyba: žádná startup probe u aplikací s dlouhým startem. Java aplikace, která startuje 30 sekund? Bez startup probe ji liveness probe zabije dřív, než naběhne.
Jeden image, víc prostředí – development, staging, produkce. Co se mezi nimi liší? Konfigurace. Connection string na databázi, API klíče, feature flagy, log level. A tohle všechno nepatří do image. Patří to do ConfigMap a Secrets.
Obojí se do kontejneru dostane buď jako proměnná prostředí, nebo jako mountovaný soubor. Vývojář tím oddělí kód od konfigurace a získá možnost měnit nastavení bez rebuildu image.
Tohle není jen best practice, je to předpoklad pro fungující CI/CD pipeline. Jeden image projde celým pipeline od buildu přes testy až do produkce. Mění se jen konfigurace. A pokud to tak nemáte, máte problém, který se bude zvětšovat s každou další službou.
Kubectl apply a oc apply fungují. Pro jednu službu, jednoho vývojáře, jedno prostředí. Ale jakmile máte desítky služeb, víc prostředí a tým lidí, potřebujete systém.
Helm Charts vám dají šablonovací systém pro Kubernetes manifesty. Jeden chart, víc values souborů pro různá prostředí. Templates, hooks, dependencies. Je to mocný nástroj – a proto je důležité vědět, kdy ho použít a kdy ne. Pro jednoduchou službu s pár manifesty je Helm overhead. Pro komplexní aplikaci s desítkami resources je to záchrana.
Kustomize je alternativa, která funguje na principu overlays – base manifesty plus patche pro jednotlivá prostředí. Jednodušší než Helm, ale méně flexibilní. Pro jednoduché případy je to často lepší volba.
A pak je tu ArgoCD – GitOps controller, který zajistí, že stav clusteru odpovídá tomu, co je v Git repository. Pushněte změnu do Gitu, ArgoCD ji automaticky (nebo po manuálním schválení) aplikuje do clusteru. Git jako single source of truth.
Ale pozor – GitOps není stříbrná kulka. Špatně strukturovaný repozitář, špatně nastavená synchronizace, chybějící RBAC v ArgoCD – to všechno jsou problémy, které jsem v praxi viděl. Nástroj je tak dobrý, jak dobře ho nastavíte.
Kód je jen začátek. Dockerfile, image, kontejner, Deployment, Service, ConfigMap, health checks, Helm chart, ArgoCD – to je celá cesta od repozitáře do produkce. A vývojář, který rozumí celé té cestě, je vývojář, který dodává software, který funguje. Ne jen na lokálu, ale v reálném provozu.
Pokud chcete tuhle cestu projít systematicky a hands-on, v Pumpedu máme na to připraven vzdělávací program.
Vývojáři jsou často samouci – a funguje to i u OpenShiftu. Jenže to většinou trvá výrazně déle. Narážíte na slepé uličky, opakujete chyby, které už někdo dávno vyřešil, a chybí vám zpětná vazba od někoho, kdo má zkušenosti z reálného provozu.
Nejrychlejší cesta? Praxe
Klíčem je hands-on přístup. Ne přednášky plné slidů. Ale prostředí, kde si všechno sami vyzkoušíte:
Kurzy Úvod do kontejnerů a Pokročilé kontejnery obsahuje základy Podman, Dockerfile, image, storage. Půldenní školení Úvod do OpenShiftu je o pochopení konceptů a terminologie openshiftu. Při třídenním kurzu OpenShift pro vývojáře si vysvětlíme Deploymenty, ConfigMapy, health checks, multi-container aplikace a Kustomize. Dalším kurzem je Helm a ArgoCD.
Všechno na reálném clusteru, s best practices z praxe.
| Název | Kód | Jazyk | Délka | Forma | Termín konání | Cena |
|---|---|---|---|---|---|---|
| OpenShift pro vývojáře |
PU21180012-0005
|
|
3 dny
|
virtuální učebna
Kurz probíhá online přes počítač a ve stanoveném termínu, lektor je připojen vzdáleně.
virtuální učebna
|
otevřený termín | 28 900 Kč |
