Poznatky z praxe

Docker Compose, nebo Kubernetes: jaký způsob nasazení vyhovuje vaší aplikaci?

Jeden kontejnerový hostitel, nebo distribuovaná platforma? Rozhodovací matice pro aktualizace, výpadky, data a provozní náročnost.

Kontejnery a KubernetesInfrastrukturaTechnické podrobnosti
Dva lidé probírají architekturu aplikace pomocí náčrtu na stole.

Kontejnerová aplikace potřebuje vhodný způsob nasazení. Pro produkční službu s přehlednou složitostí může stačit Docker Compose. Kubernetes stojí za zvážení, pokud mají aplikace běžet na více strojích a jejich nasazování vyžaduje koordinované řízení. Rozhodnutí začíná u požadavků aplikace.

Jedna firma provozuje interní portál s webovým rozhraním, databází a zpracováním na pozadí. Má servisní okno, přehledný objem práce a určeného správce. Jiná firma vydává nové verze několika služeb vícekrát týdně a potřebuje zůstat dostupná i při plánované údržbě. Obě používají kontejnery, ale může jim vyhovovat jiný způsob nasazení.

Docker, Compose a Kubernetes plní různé úlohy

Kontejnerové běhové prostředí spouští kontejnery. Docker Engine pro to poskytuje rozšířenou platformu. Docker Compose popisuje služby tvořící aplikaci v souboru YAML. Lze tak propojit obrazy, sítě, trvalé svazky a konfiguraci. Nástroje Compose vytvářejí a spravují aplikaci na hostiteli Dockeru, ke kterému se připojují.

Kubernetes spravuje požadovaný stav úloh v clusteru. Plánuje pody na vhodné uzly a může nahrazovat spravované instance nebo je postupně aktualizovat. Každý uzel stále potřebuje vhodné kontejnerové běhové prostředí. Soubor Compose a prostředky Kubernetes popisují nasazení odlišně, migrace proto vyžaduje více než přejmenování souboru.

Velikost firmy o tomto rozhodnutí říká málo. Malému vývojovému týmu s častými releasy může orchestrace prospět. Mnohem větší firmě může pro jedinou podporovanou podnikovou aplikaci dobře sloužit jeden řádně udržovaný hostitel.

Docker Compose je určen i pro produkci

Docker výslovně dokumentuje použití Compose v produkci, zejména na jednom serveru. Vývojovou a produkční konfiguraci lze oddělit nebo rozšířit podle konkrétních potřeb. Zásady restartování, publikované porty, logování a proces aktualizací musí odpovídat produkčnímu prostředí.

Pro interní dokumentový portál to může být přehledné řešení: zvládnutelný počet služeb, zdokumentované verze, chráněná data a vyzkoušená obnova. Selhání hostitele přesto vyžaduje vlastní plán. Zásada restartování nepřesune aplikaci na jiný stroj. Také redundance podkladové virtualizační platformy a zálohy aplikace jsou samostatné vrstvy.

Důležitý je i způsob instalace podporovaný výrobcem softwaru. Oficiálně udržované nasazení Compose může být v provozu hodnotnější než vlastní instalace clusteru bez spolehlivé cesty aktualizací.

Rozhodovací matice pro provoz

Které požadavky podporují který přístup?
Otázka Docker Compose na jednom hostiteli Kubernetes
Jak rozsáhlé je prostředí? Vhodné pro jednotlivé aplikace s přehledným počtem služeb. Více úloh a uzlů lze spravovat pomocí společných pravidel platformy.
Co se stane při selhání hostitele? Obnova nebo redundance infrastruktury se řeší mimo Compose. Nahrazení na jiných uzlech je možné, pokud jsou na něj připraveny aplikace, kapacita, řídicí rovina i přístup k datům.
Jak se nasazují nové verze? Dotčené služby se nahrazují zdokumentovaným a podle potřeby automatizovaným postupem. Pravidla nasazení podporují řízené rollouty. Změny dat a funkční testy stále potřebují vlastní plán.
Kde jsou uložena firemní data? Ve svazcích nebo externích službách s vlastními postupy zálohování a obnovy. V trvalém úložišti nebo externích službách, jejichž odolnost a zálohování je stále nutné posoudit.
Kdo platformu udržuje? Odpovědnost zahrnuje hostitele, běhové prostředí, obrazy a aplikaci. Navíc zahrnuje cluster, síťovou a úložnou integraci a jejich životní cykly.
Jak se posuzuje stav služby? Sledují se hostitel, služby a firemní procesy. Navíc se sledují cluster a interakce součástí platformy; samotný běžící pod nestačí.
Co podporuje výrobce? Rozhoduje podporovaný způsob instalace a jeho cesta aktualizací. Musí existovat provozovatelné nasazení Kubernetes a vhodná podpora výrobce.

Kdy Kubernetes přináší konkrétní užitek

Dobrým důvodem může být potřeba jednotně spravovat mnoho podobných nasazení nebo sdílet dostupnou výpočetní kapacitu mezi více službami. Pro Kubernetes mohou mluvit i časté aktualizace s jasnými pravidly rolloutů a oddělenou odpovědností za aplikační oblasti. Předpokladem je aplikace schopná běžet ve více instancích a lidé, kteří zvládnou dodatečnou práci s platformou.

Před výběrem služby je nutné zjistit, zda poskytovatel spravuje řídicí rovinu, které součásti udržujete sami a jaké úkoly při incidentech vám zůstávají. Spravovaný cluster omezuje některé úkoly platformy. Odpovědnost za aplikace, přístupová práva, data a náklady zůstává.

Častým problémem jsou předpoklady o sdílených datech. Dokáže podniková aplikace pracovat s více aktivními instancemi? Kam zapisuje soubory? Kde ukládá relace? Lze úlohu na pozadí bezpečně spustit znovu? Tyto otázky je nutné zodpovědět před migrací. Dostupný kontejner nedokládá správné zpracování objednávek.

Náročnost zahrnuje celý životní cyklus

K porovnání nestačí cena serveru či cloudu. Počítají se i zavedení, dokumentace, aktualizace, monitoring, zálohy a čas věnovaný incidentům. Kubernetes navíc vyžaduje znalost platformy a koordinaci clusteru, sítě a úložiště. Standardizovaný provoz může opakovanou práci omezit, standard je ale nejprve nutné vytvořit a udržovat.

Užitečné porovnání nákladů pracuje se třemi scénáři: dál řádně provozovat stávající aplikaci, standardizovat ji na Compose nebo zavést platformu Kubernetes. Pro všechny platí stejné firemní požadavky. Jinak lze snadno porovnávat jednoduchý samostatný server s výrazně vyšším cílem dostupnosti, aniž by byl rozdíl zřejmý.

Jak dojít k podloženému rozhodnutí

  1. Definovat provozní požadavky: popsat přijatelnou nedostupnost, servisní okna, ztrátu dat a očekávané změny.
  2. Posoudit aplikaci: zaznamenat podporované instalace, provoz více instancí, soubory, relace a externí rozhraní.
  3. Přidělit odpovědnost: určit, kdo zajišťuje údržbu, alarmy, obnovu a zastupování při nepřítomnosti.
  4. Otestovat jednu službu: nacvičit v navrženém prostředí aktualizaci, výpadek i obnovu a zdokumentovat náročnost.
  5. Poté rozšiřovat: posoudit další aplikace podle stejných kritérií.

DAXS propojuje posouzení aplikace a jejích rozhraní s plánováním infrastruktury a vhodným provozním modelem. Pro úvodní posouzení stačí konkrétní služba, její závislosti a požadované provozní výsledky. Zde začíná osobní konzultace .

Zdroje: Docker: aplikační model Compose · Docker Compose v produkci · Kubernetes: součásti a odpovědnosti · Kubernetes: Deployment a rollouty · Plánování produkčního prostředí Kubernetes