Konténer vagy virtuális gép: az egymondatos különbség és négy következménye

Valami új indul a Proxmoxon, és két lehetőség kínálkozik. Mindkettő Linuxot futtat, mindkettő egymás mellett ül a panelen, és mindkettő ugyanazt a munkát látszik végezni.

A választás rendszerint az erőforrásokhoz kötődő megszokásból történik: a konténer könnyebb. Ez igaz, csak nem ez az, aminek döntenie kellene.

A különbség egyetlen mondatban áll: a virtuális gép saját kernelt hoz magával, a konténer a szerverét használja. Minden tudnivaló ebből a mondatból következik.

Első következmény: hol húzódik a határ

A virtuális gép határát a hardver rajzolja meg. A konténer határát a szerver kernelje rajzolja meg.

Ez nem azt jelenti, hogy a konténer gyenge, hanem azt, hogy hol húzódik a határ. Ha egy konténeren belüli szoftverhiba el akar jutni a szerverig, a szerver saját kerneljén kell átjutnia. Virtuális gép esetén hardverszintű falon kell átjutnia.

A gyakorlati kérdés a következő: mennyire megbízható az, ami futni fog? Egy saját fejlesztésű vagy évek óta használt szolgáltatáshoz a konténer tökéletesen megfelel. Egy letöltött és nem teljesen átlátott dologhoz a virtuális gép a jobb hely.

Második következmény: nem minden fut konténerben

Semmi nem fut konténerben, aminek saját kernelre van szüksége. Az eltérő kernelverziót igénylő szoftver, a kernelbe modulokat betöltő eszköz, a nem Linux operációs rendszer: mindegyikhez virtuális gép kell.

Ez nem ízlés kérdése, hanem a fenti mondat közvetlen következménye. Ha a konténer a szerver kerneljét használja, nem kérhető tőle, hogy ezt a kernelt lecserélje.

Harmadik következmény: a karbantartás máshogy érinti őket

Ez a legkevésbé ismert, és ez fáj a legnagyobb eséllyel.

A virtuálisgép-motor frissítése a futó gépeket nem érinti. Az új motor a frissítés után indított gépekre vonatkozik. Egy karbantartási éjszaka így csendben elmehet a futó gépek fölött.

A konténer futtatórétegének frissítése viszont érintheti a futó konténereket, mert mindegyikük osztozik ezen a rétegen. A frissítés közben a megosztott fájlrendszerréteg újracsatolásra kerülhet, és a konténereken belül rövid hozzáférési hibák jelenhetnek meg.

Ez nem a termék véleménye, hanem ugyanannak az egyetlen mondatnak a közvetlen következménye: ha egy megosztott dolog frissül, azt mindenki megérzi, aki osztozik rajta.

Negyedik következmény: a mozgás szabadsága

A virtuális gép futás közben áthelyezhető másik csomópontra. A konténer nem: leáll, átkerül, majd újraindul.

Ha tehát megszakítást nem tűrő munka ül egy konténerben, az a munka a karbantartási éjszakákon megáll. Ezt érdemes mérlegelni az elhelyezés eldöntésekor.

A gyakorlati szabály

Konténer választása akkor indokolt, ha a futtatott dolog olyan hétköznapi Linux szolgáltatás, amely a szerveren magán is elfutna, ha megbízható, és ha elvisel egy rövid megszakítást.

Virtuális gép választása akkor indokolt, ha saját kernelre van szükség, ha a karbantartás alatt nem szakadhat meg, vagy ha a futtatott dolog nem teljesen megbízható.

Az erőforrásbeli különbség e három próba után jön. Igaz, hogy a konténer kevesebb memóriát használ, de a rossz helyen ülő konténer ára sokszorosa ennek a megtakarításnak.

Mit csinál az Atlas

Az Atlas ezt a megkülönböztetést nem jelmondatként, hanem viselkedésként hordozza.

A frissítések értékelésében a virtuálisgép-motor és a konténer futtatórétege külön kezelésre kerül. A virtuálisgép-motor frissítésekor a futó gépekre adott válasz tájékoztató szintű: nem érintettek, az új motor a később indítottakra vonatkozik. A konténerréteg frissítésekor a szint figyelmeztetésre emelkedik, és az indoklás is kiíródik: a megosztott réteg újracsatolásra kerülhet, érdemes megfontolni a kritikus konténerek rövid leállítását.

Ugyanez a megkülönböztetés jelenik meg a költöztetés tervezésénél: konténereknél a futás közbeni költöztetés nem jelenik meg lehetőségként, helyette a leállítás, áthelyezés, indítás lánc szerepel.

A termék tehát nem úgy mutatja be a kettőt, mint ugyanannak a dolognak a két változatát. Máshogy viselkednek, ezért máshogy is kerülnek leírásra.