A konténeres alkalmazáshoz megfelelő telepítési modell kell. A Docker Compose egy áttekinthető összetettségű éles szolgáltatáshoz is elegendő lehet. A Kubernetes akkor vizsgálandó, ha az alkalmazásoknak több gépen kell futniuk, és telepítésük összehangolt vezérlést igényel. A döntés az alkalmazás követelményeivel kezdődik.
Az egyik vállalat belső portált üzemeltet webes felülettel, adatbázissal és háttérfeldolgozással. Van karbantartási ablaka, kezelhető terhelése és kijelölt rendszergazdája. Egy másik hetente többször ad ki több szolgáltatáshoz új verziót, és tervezett karbantartáskor is elérhetőnek kell maradnia. Mindkettő konténereket használ, de eltérő modell illhet hozzájuk.
A Docker, a Compose és a Kubernetes más feladatot lát el
A konténer-futtatókörnyezet futtatja a konténereket. Ehhez a Docker Engine elterjedt platformot ad. A Docker Compose YAML-fájlban írja le az alkalmazás szolgáltatásait, egyesítve képfájlokat, hálózatokat, tartós köteteket és konfigurációt. A Compose eszközei azon a Docker-gazdagépen hozzák létre és kezelik az alkalmazást, amelyhez kapcsolódnak.
A Kubernetes a klaszter munkaterheléseinek kívánt állapotát kezeli. Megfelelő csomópontokra ütemezi a Podokat, és pótolhatja vagy fokozatosan frissítheti a kezelt példányokat. Minden csomópontnak továbbra is megfelelő futtatókörnyezet kell. A Compose-fájl és a Kubernetes-erőforrások másként írják le a telepítést, ezért a migráció nem fájlátnevezés.
A vállalat mérete kevéssé döntő. Egy gyakran kiadó kis fejlesztőcsapat profitálhat az orkesztrációból. Egy jóval nagyobb vállalat egyetlen támogatott üzleti szolgáltatásához elegendő lehet egy megfelelően karbantartott gazdagép.
A Docker Compose éles használatra is alkalmas
A Docker kifejezetten dokumentálja a Compose éles használatát, különösen egy szerveren. A fejlesztési és éles konfiguráció elválasztható vagy igény szerint bővíthető. Az újraindítási szabályoknak, publikált portoknak, naplózásnak és frissítési folyamatnak illeszkednie kell az éles környezethez.
Belső dokumentumportálnál ez egyszerű felállás lehet: áttekinthető szolgáltatások, dokumentált verziók, védett adatok és tesztelt helyreállítás. A gazdagép kiesése ettől még külön tervet igényel. Az újraindítási szabály nem költöztet másik gépre. A virtualizációs háttér redundanciája és az alkalmazás mentése szintén külön réteg.
A szoftvergyártó által támogatott telepítési mód is számít. Egy hivatalosan karbantartott Compose-telepítés üzemeltetési szempontból többet érhet, mint egy saját klaszteres megoldás megbízható frissítési út nélkül.
Üzemeltetési döntési mátrix
| Kérdés | Docker Compose egy gazdagépen | Kubernetes |
|---|---|---|
| Mekkora a környezet? | Egyedi alkalmazásokhoz és áttekinthető szolgáltatáscsoporthoz megfelelő. | Több terhelés és csomópont kezelhető közös platformszabályokkal. |
| Mi történik gazdagéphibánál? | A helyreállítás vagy infrastruktúra-redundancia a Compose-on kívül szervezendő. | Más csomóponton pótlás lehetséges, ha az alkalmazás, kapacitás, vezérlősík és adatelérés felkészült rá. |
| Hogyan történik a kiadás? | Az érintett szolgáltatásokat dokumentált, szükség szerint automatizált folyamat cseréli. | A telepítési szabályok ellenőrzött bevezetést támogatnak. Az adatváltozások és funkcionális tesztek külön tervet igényelnek. |
| Hol vannak az üzleti adatok? | Kötetekben vagy külső szolgáltatásokban, saját mentési és visszaállítási eljárással. | Tartós tárolásban vagy külső szolgáltatásban, amelynek hibatűrését és mentését továbbra is értékelni kell. |
| Ki tartja karban a platformot? | A felelősség a gazdagépre, futtatókörnyezetre, képfájlokra és alkalmazásra terjed ki. | Ezenfelül a klaszterre, hálózati és tárolási integrációra, valamint életciklusukra is. |
| Hogyan értékelik a szolgáltatás állapotát? | Felügyelik a gazdagépet, szolgáltatásokat és üzleti folyamatokat. | A klasztert és a platformösszetevők együttműködését is figyelik; egy futó Pod nem elegendő. |
| Mit támogat a gyártó? | A támogatott telepítési mód és frissítési út döntő. | Üzemeltethető Kubernetes-telepítés és megfelelő gyártói támogatás kell. |
Mikor ad konkrét hasznot a Kubernetes?
Jó indok lehet sok hasonló telepítés egységes kezelése vagy a rendelkezésre álló számítási kapacitás megosztása több szolgáltatás között. Gyakori frissítések világos kiadási szabályokkal és elkülönített alkalmazási felelősségekkel szintén mellette szólhatnak. Ehhez több példányban futtatható alkalmazás és a többletfeladatokat kezelni képes emberek kellenek.
Szolgáltatásválasztás előtt tisztázandó, ki kezeli a vezérlősíkot, mit tart karban a vállalat, és milyen hibaelhárítás marad nála. A menedzselt klaszter egyes feladatokat csökkent. Az alkalmazások, jogosultságok, adatok és költségek felelőssége megmarad.
A közös adatokra vonatkozó feltételezések gyakori akadályok. Működik több aktív alkalmazáspéldány? Hová ír fájlokat? Hol vannak a munkamenetek? Ismételhető biztonságosan a háttérfeladat? Ezekre migráció előtt kell válasz. Az elérhető konténer nem bizonyítja a rendelések helyes feldolgozását.
A ráfordítás a teljes életciklusra kiterjed
A szerver- vagy felhődíj nem elég az összehasonlításhoz. Megvalósítás, dokumentáció, frissítés, felügyelet, mentés és incidensidő is számít. A Kuberneteshez platformszakértelem és a klaszter, hálózat, tárolás összehangolása is kell. A szabványos üzemeltetés csökkentheti az ismétlődő munkát, de a szabványt előbb ki kell alakítani és fenn kell tartani.
Három forgatókönyv ad hasznos költségösszevetést: a jelenlegi alkalmazás megfelelő üzemeltetése, Compose-alapú egységesítés vagy Kubernetes-platform bevezetése. Mindegyikre azonos üzleti követelmények vonatkozzanak. Különben könnyű egy egyszerű önálló szervert jóval magasabb rendelkezésreállási céllal összevetni a különbség jelzése nélkül.
Így lesz megalapozott a döntés
- Üzemeltetési igények meghatározása: elfogadható kiesés, karbantartási ablak, adatvesztés és várható változások leírása.
- Az alkalmazás értékelése: támogatott telepítési módok, többpéldányos működés, fájlok, munkamenetek és külső interfészek rögzítése.
- Felelősségek kiosztása: a karbantartás, riasztás, helyreállítás és távolléti helyettesítés felelőseinek kijelölése.
- Egy szolgáltatás tesztelése: frissítés, kiesés és visszaállítás elpróbálása a tervezett környezetben, a ráfordítás dokumentálásával.
- Bővítés ezután: további alkalmazások értékelése azonos feltételekkel.
A DAXS összekapcsolja az alkalmazás és interfészeinek értékelését az infrastruktúra tervezésével és megfelelő üzemeltetési modellel. Egy konkrét szolgáltatás, függőségei és elvárt működési eredményei elegendők az első felméréshez. A személyes egyeztetés ezekkel kezdődik.
Források: Docker: a Compose alkalmazásmodellje · Docker Compose éles használatban · Kubernetes: összetevők és felelősségek · Kubernetes: Deploymentek és fokozatos kiadás · Éles Kubernetes-környezet tervezése