Hogyan juss el a hagyományos szerverektől a Kubernetes clusterig (x)

Címkék

Az előadásból megérted milyen előnyei vannak a kontenirizációnak, miért érdemes elindulni ezen az úton és hogyan segítik az életedet a modern eszközök. További részletek »

Hozzászólások

Aznap, ahogy ez általánosan és kötelezően eljön, megyek el kapálni és megköszönöm az IT-t, úgy örökre.

Másrészt typo van már ebben a szövegben is: "kontenirizációnak".

Ha nem szereted a Kubernetest, ott a HashiCorp Nomad :)

Egyébként a Kubernetesben nem az a lényeg, hogy most milyen API-val írod le a szolgáltatásokat, hanem az, hogy ezt megteszed, és minden komponens működése külön mérhető és menedzselhető egy egységes felületen keresztül. Ez egy ugyanolyan evolúciós lépés, mint a 2 rétegű architektúráról a 3 rétegűre váltás.

Nem csak a Kubernetes-t “nem szeretem”, hanem úgy általában az összes efféle modern buzzword-öt, ami a konténerizációhoz kapcsolódik, ami ma a Szent Grált jelenti. Másrészt pont ez a “mindent a yaml-lel írok le”-típusú megközelítés az egyik legnagyobb problémám az egésszel.

Nem a szent gral, de soha nem latott lehetosegeket biztosit. Amit eddig igy-ugy ossze kellett hekkelni, most egy egyseges platformon lehet managelni. Segit elvalasztani a platform uzemeltetest az alkalmazas uzemeltetestol, es utobbit kozelebb hozza a fejleszteshez.

Szemelyes peldaval tapasztaltam, meg en beszeltem le a tobbieket, hogy mindek ide kubernetes, egy fisfos dolgot kellett deployolni. Neki is ugrottam, es fejlesztes kozben realizaltam, hogy akkor provisionelni kell nodeokat, kellenek load balancerek, meg reverse proxy, meg legyen multitanent, meg nemi network izolacio, aztan monitorozni, deployment, failover, rollback, force tls, lusta vagyok leirni is, hogy mi minden kellett csak egy fejlesztok altal hasznalt 20ad rangu hatterszolgaltatasnak. Ha' hulye vagyok en? Felpattintottunk egy managelt kubernetest (ahol csak a node-ok utan kell fizetni, szoval tobbe se nagyon kerult kb) leirtam egy marek yaml-t es koszi tok jol elvan a cucc. Raadasul pont ugyanazt a yaml-t tudom futtatni a gepemen is meg a lenyegeben akarhol. (nyilvan vannak elteresek kube es kube telepites kozott jelen esetben teljesen standard dolgokat hasznaltunk)

Amugy a yaml csak a jeghegy csucsa, de az igazi power az a kulonbozo controllerek es operatorok, amikkel aztan tetszuleges tortenesekre tetszoleges modokon lehet reagalni, legyen szo network, storage, adatbazis anyamkinja mukodeserol. Csak ezekkel ritkan talalkozik az atlag user, es nem is kell neki elvegre platform as a service

Tök jó, igazán. Ugyanakkor lássuk meg azt a lényeges különbséget, hogy te fejlesztői oldalról nézed/látod ezt, engem meg pl. a másik oldalon mezei Linux üzemeltetőként kényszerítenek valamelyest ezek megismerésére, holott semmi nem áll tőlem távolabb. Szóval maradnak buzzword-ök, és emiatt sajnos a véleményem is.

Hat en uzemeltetek is, sot fejlesztek olyan alkalmazast, ami uzemeltet olyan infrastrukturat, amin manageli az alkalmazas clustert. Azert kenyszeritenek, mert a modern elvarasok hozzak ezt a dolgot: resource izolacio, eroforras hatekonysag, alkalmazas csomagolas, self healing, autoscaling, baromi hosszu a lista, amit kontenerekkel kenyelmesyen lehet csinalni (es persze van egy masik lista, amit meg nem, de szerencsere az sokkal rovidebb)

Es pont mint uzemeltetonek kenyelmes, hogy en adom a kernelt, a fejleszto hozza az appot, es nem kell a hostra feltenni minden dependenciat, es kenyelmesen szabalyozhato mennyi eroforrast kaphat, lenyegeben barmely distron elindul a cucc, nem kell masik playbookot irni centosra meg archra, nem kell apparmor profilokkal megvedeni a tobbi futo processzt, nem kell varni, amig elindul a vm, konnyebben automatizalhato ergo konnyebben tesztelheto (Travison fellovunk egy Kind clustert es tetszoleges teszteket futtatunk percek alatt), stb.

Persze mindenki maga tudja, tavol alljon tolem, hogy megmondjam barkinek mit csinaljon vagy miben higgyen. En komoly potenciat latok benne, es jovobiztosnak erzem a tudasom (mar amannyire lehet ilyet ITban mondani).

Az informatikus olyan mint a capa. Ha nem uszik elore elobb-utobb megfullad.

Linux uzemeltetokent te egy szolgaltato vagy es az ugyfeleid a ceg fejlesztoi es managementje. Ha ok hoznak egy dontest hogy microservices es konternerizacio akkor ez van, es ha nem vagy hajlando kiszolgalni oket akkor ertelemszeruen keresnek majd olyat a helyedre aki igen.

Nalunk kb. 1 eve epitgetik szepen lefele a klasszikus sysops dolgozokat, akinek nem tetszik hogy erre megy a ceg es nem partner a fejlodesben az igy jart.

Nem nagyon érdekel, lásd. az első kommentem, akkor elmegyek kapálni. Vagy kb bármit szívesebben, mint ezeket, nem túlzok, végtelenül visszatetsző számomra ez az összes efféle újdonság. Klasszikusan és a klasszikus infráért felelünk, semmi azon túlmutaóan, ezekkel meg avilágból ki lehetne kergetni, pláne, hogy érintőlegesen kell vel foglalkoznom (szerencsére épphogy, csak annyira, hogy lássam, még egy sor konfigot nem írtam ebben, OpenShift).

És akkor sem tetszik, ha azt mondom, hogy a felhő világnak az egyik velejárója, hogy a fejlesztők sokkal nehezebben adnak szart a kezedbe, hogy üzemeltesd el?

Több oka is van, hogy miért nehéz szart kiadni:

  • Az egyik az, hogy egy felhő app csak és kizárólag a lehető legtisztább üzleti logikát tartalmazza, semmi mást.
  • A másik az, hogy a CI kimenete pár image és helm chart valami repóba, amit a CI meg is próbál vmi kis clusterre felrakni vagy még jobb esetben egy meglévőt upgrade-elni. Pontosan azt csinálja, ami az üzemeltetésen is az első lépés: helm install/upgrade. Aztán tud teszteket is futtatni rajta, tehát nem a unit tesztnél áll meg a CI, hanem az üzemeltetési teszten. Jobb esetben a végfelhasználó / vevő tesztjei is futnak, nem csak a fejlesztők agyszüleményei.

Ezek megint csak nagyobb részben fejlesztői szempontok, amikre nézve mondtam, hogy totálisan hidegen hagynak. Felhasználói oldalon mondhatnám, hogy mennyivel jobb, de nem igazán használok ilyeneket, kerülöm is. A baj az, viszont, hogy egyre inkább bekerül a teljesen hagyományos infraüzemeltetés látókörébe is (illetve próbálkoznak vele)(valamint lásd a másik kommentet, a hagyományos üzemeltetőket már küldik el, erre inkább nem is reagáltam..), holott ahogy pl. írtam, ilyen tekintetben semmi sem áll tőlem messzebb. Ha nem így lenne és békén hagynának vele, hidd el nem is zavarna, de nem így van, így egyre jobban zavar.

Nagy szervezetben dolgozom, ahol mindenre saját terület van, ami kell: infra, alkalmazásüzem, db, storage, hálózat, stb, így nagyon konkrétan behatárolt feladataim vannak, és azokon semmivel sem kell és nem is szeretnék túlnyúlni, így pl. emiatt sem szempont, hogy alkalmazásoldalon mit hogyan könnyít, illetve mennyivel jobb tesztelni is, normális esetben ezekre egyáltalán nem látok rá.

"emiatt sem szempont, hogy alkalmazásoldalon mit hogyan könnyít" Az van, hogy amikor naponta tobb releaset is ki kell tenni, ami fele a nagy szervezetek is tartanak, akkor eleg nagy szempont, hogy a fejlesztes gordulekenyen menjen, es automatizaltan lehessen tesztelni.

Regen az volt, emlekszem, hogy a dev felrakta a random nyelvet, a *db-t, meg az X valamit a gepere, kiszedte a forrast, elinditotta az alkalmazast es go. De egy mai rendszert osszebindzsiszkedni a gepemen, raadasul frissen lekovetni a fuggosegek verzioszamait, egy remalom. mondhatnam lehetetlenseg. Es az a budos nagy helyzet, ha a fejleszto nem dolgozik (vagy mashol dolgozik, ahol kenyelmesen is tud), neked sincs mit uzemeltetni.

En is dolgoztam nagy szervezetnel, es mindenre megvolt a kulon csapat. Es a hagyomanyos uzemeltetesnek is megvolt a letjogosultsaga. Voltak infras sracok, akik osszedugdostak a gepeket, meg cserelgettek a HW-et. Voltak networkosok, akik felugyeltek a halozatot. Voltak sys opsok, akik felugyeltek a platformot. Eddig a pontig ez teljesen hagyomanyos dolgok. Amit viszont nem csinaltak, hogy tudtak mi fut a gepeken. Mert az a dev csapatok feladata, hogy uzemeltetheto allapotban leszallitsak a termeket. Es aztan jonnek az SRE-k, akik meg kockazatot elemeznek, monitoroznak, belerugnak ha kell, elerhetove teszik a dolgokat.

Nekunk azert volt ez egy kicsit specialis, mert konkretan mi szolgaltattuk a cloudot :) De, es itt jon a de, a cloud az, ami belerondit a szempontodbol a dolgokba, mert sokan kiszervezik pont azt a reszet. Lehetseges megoldas: a cloudba kell dolgozni, ahonnan sose (amig a robotok at nem veszik a hatalmat) kopik ki az a fajta melo, ami neked fekszik. Vagy meg kell tanulni uzemeltetni a Kubernetest, es tudod azt mondani, hogy amig a platform fut rendesen, addig mosod kezeidet :D

"Ezek megint csak nagyobb részben fejlesztői szempontok" ezzel sem ertek teljesen egyet, mert irto sok uzemeltetesi kerdes is atkerult a fejlesztokhoz cserebe. Marmint az uzemeltetesnek mar nem kell reverse proxykat konfiguralgatni, vagy kulcsokat generalni es rotalni. Ahogy nem kell felhasznalokat kezelni vagy a tuzfallal bajlodni, vagy selinux/apparmor. (vagy legalabbis nem olyan mertekben)

A fejleszto az aki tudja mit csinal az alkalmazas. O tudja megmondani, hogy milyen servicekhez beszelhet a cucc, milyen jogok kellenek neki a geprol, kivel es mit akar kozoskodni. Eppen ezert ezek a dolgok atkerultek oda, es ezek a dolgok szinten gyonyoruen tesztelhetok a CI/CD soran. Tudod te mekkora ertek ez a cegeknek, akik a megbizoid?

Tudod te mekkora ertek ez a cegeknek, akik a megbizoid?

Egy darab cég a "megbízóm", szerintem megint nagyon elbeszélünk egymás mellett. Szerintem nehezen dolgozod fel, hogy a "konténerizációs világ" (ahogy lejjebb fogalmaztak) és az én munkám között semmiféle átfedés nincsen, szerencsére, illetve semmiféle fejlesztéshez kapcsolódó szemponttal sem (pl. CI/CD és hasonlók, nem jutnak el felénk).

"semmiféle átfedés nincsen" bocsi, hogy ez nem volt vilagos abbol, hogy "illetve próbálkoznak vele" vagy "engem meg pl. a másik oldalon mezei Linux üzemeltetőként kényszerítenek valamelyest ezek megismerésére". Biztos nem en erteni magyar.

En feldolgoztam, te nem dolgoztad fel, hogy 2-5 ev es elmehetsz kozepiskolaba rendszergazdanak, kkv-ba bohockodni, vagy tenyleg szakmat kell valtanod, mert kevesebb kontener nem lesz egy darabig csak tobb.

Biztos nem en erteni magyar

Kontextusban maradva mondom, úgy látszik tényleg nem, mert azt is leírtam világosan, hogy néznem kell. Szó szerint, néha beültetnek, hogy nézzem, ahogy valaki átír vmi yaml-t, aztán deploy-olja, azt is leírtam, hogy semmi dolgom vele és még csak egy sor hasonló konfigot sem írok. Ennél jobban nem tudom kifejezni, hogy mennyire nincs gyakorlati átfedés.

 

En feldolgoztam, te nem dolgoztad fel, hogy 2-5 ev es elmehetsz kozepiskolaba rendszergazdanak, kkv-ba bohockodni, vagy tenyleg szakmat kell valtanod, mert kevesebb kontener nem lesz egy darabig csak tobb.

Akkor szerintem fusd át a topic legelső kommentjét újra. Igen, előbb elmegyek bárhova, ahol nem kell ezekkel foglalkozni, és ezt nem tegnap döntöttem el.

teljesen hagyományos infraüzemeltetés

Nade ez lassan már nem is IT munka, amiről beszélsz!

A bejárati ajtó, az álpadló, az áram, a klíma, a rackek, a fizikai hw dobozok - ez a teljesen hagyományos infraüzemeltetés területe, és ami ezen felül van, az kb. üresedik ki. Az önálló OS réteg nagyjából a firmware szintjére megy vissza, és minden OS szintű beállítását a gép a hálózatról kapja (lásd RHCOS).

Bocsánat, akkor lehet, hogy nem voltam elég egyértelmű: az a gap, ami a fent leírt hw üzemeltetés és az alkalmazások között van, az egyre inkább át fog menni egy olyan állapotba, hogy lesz egy egyre üresebb OS réteg (full automatizált és lecsupaszított), és lesz egy platformréteg, aminek része pl. a "hogyan futtassunk konténereket" c. funkció. Ha ebből kihagyod ez utóbbit, mert nem akarsz a konténerekhez meg az azokat menedzselő réteghez érteni, akkor a torta maradék része meg egyre jobban szűkülni fog.

De, egyértelmű volt, csak ez nem igaz:

Nade ez lassan már nem is IT munka, amiről beszélsz!

Mert nagyon is intenzív IT munkát végzek, amire rá kívántam világítani. Értettem, amit írtál elsőre is, csak az irány, ahova ez az egész tart, nagyon nem fekszik nekem.

Csak hogy a lényegről is beszéljünk:

 

Sok olyan cápafaj van, ami simán nem fullad meg attól, hogy nem úszik. 

Jonathan Bird "Blue World" sorozatát ajánlom a Youtube-on, abból is a Shark Academyt: https://www.youtube.com/playlist?list=PLJEGLu0_tbrS33VrdO7BGJkDOXa8mE1hQ

Vigyázat! Gyerekbarát tartalom! :)

Sokáig "ellenálltam" én is a dockernek, úgy gondoltam hogy az openvz meg az lxc elég jó lesz nekem. Ansible-el meg pláne.
Aztán csak megnéztem a kubernetes-t, egész pontosan a rancher-t. Valamennyit játszottam vele, és egész jól mentek is a dolgok de rájöttem hogy ha igazán érteni akarom hogy mi történik ahhoz kell a docker.
A dockerben az a tuti egyébként, hogy rengeteg mindent ki lehet próbálni tényleg nulla erőfeszítéssel, másodpercek alatt. Rengeteg lehetőség van. 
És rengeteg jó doksi amiből meg lehet tanulni.

Az alapnál egy picivel is bonyolultabb rendszernél (vagy nagyobbnál) itt is ugyanúgy elválik a developer és az operations. Ops szinten egy csomó olyan problémát kell megoldanod amiről a dev-nek lövése nincs, nem is kell hogy legyen.

Én pl. tök büszke vagyok arra, hogy megoldottam h ZFS-en is baromi gyors legyen a docker build.
De volt olyan példa is, hogy hogyan kell 1.2GB image-ből 50MB-osat csinálni.

De amikor microservice-ekkel elosztott tranzakciókat kell megbízhatóan kezelni (mert valódi pénz utazik benne) az is egy finom kihívás.

 

Gábriel Ákos

Van ket hirem, rossz vagy jo dontsd el te magad.

A kontenerizacio itt van, ez nem csak a jovo, de mar erosen a jelen. Annyi hozzaadott erteke van a hagyomanyos processz vagy vm futtatshoz kepest, amivel szinte mar arra kell indokot talalni miert ne kontenerbe futtassuk.

A kontener orchesztracios csata elso felvonasat pedig kokemenyen behuzta a Kubernetes. Gyakorlatilag kihivo nelkul all mert az egyetlen talpon maradt "alternativa" (Nomad) lenyegeben nem is ugyanazt celozza.

Ez pedig a "devops sap-ja": cégeket és folyamatokat szabnak hozzá :), érdemes legalább az alapokat tudni róla ha másért nem, hogy tudd jelezni mi az amit nagyon nem kellene bele gyötörni mert (jelen formájában) nem oda való..

+1 es az ido elorehaladtaval egyre kevesebb dolgot nem lehet majd rajta futtatni. Ma olyan workloadok futnak, amiket 2 eve meg erosen nem javasoltunk. Akkoriban az volt a mondas, hogy csak stateless vagy by design skalazhato cuccokat toljunk benne. Mara az osszes vezeto adatbazishoz van operator, ami automatizalja az adatbazis koruli muveleteket. De van strong consistent replicated storage read-write-many opcioval, adatkozpontokon ativelo service mesh vagy teljesen heterogen clusterek.

A kontener az uj vm :)

A masik dolog, hogy mindent* (szerver oldali cuccokrol beszelek, de amugy bongeszot meg doomot is lehet futtatni benne) el lehet inditani kontenerben, leven a kontener egy kutya kozonseges processz, ami ugyanugy megorokolhet minden default cuccot (ez egy elmeleti kerdes, hogy /-re chrootolt default namespacekkel cgroupokkal inditott kontener kontener-e? de mivel a kontener egy alkalmazas csomagolasi technika is, azt hiszem megadhatjuk). A kerdes sokkal inkabb az, hogy van-e hozzaadott erteke. Esetleges atalakitasokkal ki lehetne-e hozni tobbet az alkalmazasbol stb.

De azt se felejtsuk el, ha van 1 alkalmazas a 10bol, amit nem lehet kontenerizalni (marmint nincs hozzaadott erteke), erdemes-e annak fenntartani kulon infrastrukturat, vagy belerakni egy fat kontenerbe, odaadni neki mindent ami kell, forszolni, hogy dedikalt nodokon csak az futhasson, es had szoljon ugyanazon a platformon mint a tobbi dolog? En nem tudom ezekre a valaszt, mindenki dontse el maga.

A persze rohadt biztos, hogy nincs ingyen ez a fene nagy kenyelem. Es ha nincs meg a szakertelem teljesen felesleges belevagnia barkinek, mert labon loves lesz a vegeredmeny, es altalaban a technologia tehet rola :) Ez tenyleg az a komplexitas, amit leginkabb erdemes kiszervezni. Fajjon a feje a szolgaltatonak!

Van operator, persze, csak van-e benne köszönet ... uis. az operator nem más mint a stateful cucc körbetákolása scriptekkel. 
Legjobb egy CNCF certified db-t használni (és úgy megírni az alkalmazást hogy azzal jó legyen) 

A konténer az új vm - ezért a hardcore containeresek biztos vasvillára hánynak :) - nagyon nem ugyanúgy kell hozzáállni. 
Lehet, de nem lesz jó.

Azzal egyetértek, hogy lábon lövés lesz a vége, ha nincs hozzá szakértelem. Márpedig nagyon kevés helyen van hozzá valódi szakértelem.

Gábriel Ákos

Nem ismerem a konténeres világot, de ahol fürtözésre van igény, ott azért jó eséllyel nincs már hagyományos szerver, mert (majdnem) minden virtualizált. Ilyen formában a hagyományos szerver alatt talán a hagyományos operációs rendszer környezetet lehet leginkább érteni (?).

Nem tudom, kitér-e az előadás a hibrid virtualizált-konténerizált környezetekre, mivel biztosan nem lehet mindent konténerben futtatni és nem feltétlenül éri meg külön hardver csoportot konténereknek, másikat virtuális gépeknek fenntartani.

Lényeg, ami a lényeg: ha van mozgástér a témában, engem ilyen hibrid felállásról is érdekelne néhány gondolat. DR-t miként szokás megoldani konténerekkel (akár VM hibrid, akár nem)?

Az, hogy kontener indulk vagy vm a runtime kerdese. Lehet csinalni hibrid x86/arm, CPU/GPU, kontener/vm clustereket.

Jah es mident lehet kontenerizalni: https://hup.hu/comment/2626501#comment-2626501 mert a kontener egy sima processz, ami nem a default namespace-t kapja, es sajat konyvtarba van chrootolva es nem kap capabilityket

Teljesen igazad van. Es nagyon orulok, hogy nem hiaba szantam az idomet, hogy beszelgessunk valamirol, amihez lovesed sincs sajat bevallasod szerint SE. Ezentul megjobban megfontolom mit irok le, es kitorlom a szotarambol a minden kifejezest, mert a minden az minden, es mindent tenyleg nem lehet kontenerizalni, pl szerelemmel sem tudok megtolteni egy kontenert vagy fennyel pl.

Nem kell megsértődni, csak belegondolni abba, hogy a másik miért kérdezi azt, amit. Te nem beszélgetni akartál, hanem eljátszani a tájékozottat, mintha a másik újszülött lenne. A konténerekhez nem értek, de nagyjából tudom azért, mi fán terem, például azt, amit leírtál már tudtam.

De ha beszélgetni akarsz, elmondhatnád a tapasztalatod VMware HA+DRS vs konténer szintű HA és terhelés elosztásról. Komolyan érdekelne, hogy miként célszerű DR-t megvalósítani, milyen dobozos megoldások vannak, az adatok miként kerülne át egyik helyről a másikra. Milyen adatbázisokat és mikor célszerű konténerbe tenni, mi a helyzet ezek mentésével. Például van-e konténeres elcsendesítős API, ez integrálódik-e az openvmtools-szal? (azaz VM+konténer hibrid esetén mi az, amit VM gondolkodással minden további nélkül meg lehet csinálni, van-e olyan, amit nem, mi az, amit lehet, de nem célszerű, ...)

Szerk: igen, a VMware-nek van Kubernetes integrációja, tudok róla, de ez nem feltétlenül játszik, mert eléggé sok vonzata van.

Vmware szerver oldali termékeiben én sem vagyok szakértő, de már van ilyen termékük: https://tanzu.vmware.com/

 

Egyébként a fentebb, általam félig viccesen írt HashiCorp Nomad azért (is) jópofa, mert hagyományos, nem konténerizálható appokat is tud menedzselni: https://www.nomadproject.io/

Köszi, erre írtam, hogy "a VMware-nek van Kubernetes integrációja". De ahogy olvastam kell hozzá például NSX, ami kisebb infrastruktúra esetén nagyon ágyúval verébre, konkrétan a lé sokkal több, mint a hús. Ezért kérdeztem, hogy van-e tapasztalat "egyszerű" VMware alatti konkténer üzemeltetéssel kapcsolatban, nem hiszem, hogy egyedül én fordulok meg olyan infrastruktúrában, ahol szinte csak VM-ek vannak, ellenben nincs NSX és valószínűleg nem is fogják emiatt meglépni.

A dolog azért is fontos, mert ha valaki alkalmazásokat konténerizál, jó eséllyel nem egy lépésben fogja megugrani az egészet, így kézenfekvőnek tűnik a konténerek VM-ekben történő futtatása. Aztán ha van annyi konténer, hogy megéri alá fizikai vasakat venni, az más kérdés, de addig el kell jutni, közben és utána az üzleti elvárásokat teljesíteni (például DR).

Konkrétan a menedzselt Kubernetes clusterek nagy része így működik: Kubernetes worker node-oknak 1-1 VM van betolva, abban futnak a konténerek. Persze működhet ez dedikált géppel is, de a VM sokkal jellemzőbb.

Tehát csinálhatod azt simán, hogy a VMware infrastruktúrádon elindítasz néhány VM-et, amik a Kubernetes cluster lesznek, ahova lehet már konténerizált alkalmazásokat betolni, a legacy appok meg futnak tovább VM-ben, ahogy eddig. Pl. ilyen esetben én elgondolkoznék a K3OS használatán ezeken a VM-eken: minimál Linux + K3S (egyszerűen deployolható Kubernetes) egy csomagban.

 

Aztán még lehet ezen is csavarni egyet, mert ugye a konténer sem azonos a "Linux konténerrel" úgyis mint cgroups és társai, hanem vannak itt egyéb megoldások is, pl.:

- KATA containers (QEMU-n belül futnak a konténerek)

- GVisor (Go-ban írt Linux system call ABI implementáció, kb. user-mode Linux csak biztonságra kihegyezve, ez van a Google AppEngine alatt)

- Firecracker (Amazon Lambda alatt is ez fut, de Kubernetes konténerek alá is be lehet tenni, eredetileg a ChromeOS VMM-jéből forkolták)

- elég biztos vagyok benne, hogy van olyan OCI runtime, ami Vmware VM-ben futtatja a konténert (passz, hogy ez a Tanzu része, vagy valami külön is használható cucc)

Mentéseket, DR-t miként szoktak csinálni? VM szinten, mintha nem lenne konténer, vagy konténer szintű intelligenciát is használnak?

A HA-t gondolom célszerűbb konténer szintjén kezelni, ha az alkalmazásban nincs erre beépített funkció (kis csomag gyorsabban elindul, mint egy VM, arról nem beszélve, hogy a tartalék biztosan konzisztens, ellenben a VM-nél azért van némi kockázat).

Kétféle konténer van: stateless és stateful. A stateless minden perzisztens adattárolását külső szolgáltatással oldja meg (adatbázis, S3 ... stb.).

Egy stateful konténer a megadott PersistenceVolumeClaim alapján kapott Volume-ba dolgozik, alapvetően azt a Volume-ot kell menteni. Az, hogy ezt hogy érdemes, nagyon függ attól, hogy pontosan hogy van ez a storage megvalósítva.

Tegyük fel, hogy van 3 Vmware szervered, mindegyiken elindítasz 1-1 worker node-ot, rendelsz hozzájuk tárhelyet, és a HA PostgreSQL szolgáltatást nyújtó stateful konténereket úgy állítod be, hogy workerenként 1 fusson, local storage-on, akkor a Postgres intézi az adatok replikációját, és a 3 VM-ben ott vannak redundánsan az adatok.

Ha van egy külső storage (pl. NAS vagy egy Ceph Cluster), amihez meg van írva a Kubernetes támogatás (szerintem kb. minden ilyenhez megvan, amihez nincs, attól én tartanék), akkor be lehet állítani, hogy a Kubernetes ha kap egy PersistenceVolumeClaim-et, akkor csináljon a NAS-on egy volume-ot, és azt mountolja fel a konténerbe. 

A poén ebben az, hogy az alkalmazásfejlesztőnek nem kell tudnia, hogy a Kubernetes cluster hogy van összerakva. Azt kell tudnia beállítani, hogy ha egy stateful HA szolgáltatást akar csinálni, akkor az egység, amivel dolgozik, az a konténer + a hozzá tartozó PersistentVolumeClaim, és ezeket kell többszöröznie lehetőleg különálló availability zone-okba (amikre ad a Kubernetes API támogatást).

A mentéseket lehet csinálni központilag is (pl. a node storage-et, NAS-t menteni), vagy alkalmazásszinten is, ez az adott környezettől függ. Azt is el tudom képzelni, hogy egy Ops csapat azt mondja, hogy mi azt biztosítjuk, hogy ami a mi S3 kompatibilis szolgáltatásunkba bemegy, az ott is marad. Ezen kívül persze adunk block storage-et is, ami RAID, de azokat nem mentjük külön, és a kedves alkalmazásfejlesztő lesz szíves összerakni a mentését, hogy amit meg akar őrizni az utókornak az felkerüljön az S3 kompatibilis storage-ba az alkalmazásnak megfelelő ütemezéssel, illetve az alkalmazás szintű disaster recovery úgy néz ki, hogy a konténer induláskor (ha a korábbi volume nincs meg és újat kapott), akkor lehúzza az S3-ról a mentést és abból állítja fel magát.

Köszi az infót.

Olyan API akkor nincs, mint Windows alatt a VSS? Azaz be lehet szólni az alkalmazásnak, hogy most rövid ideig kerüljön konzisztens állapotba az lementett adat. PostgreSQL példánál maradva kívülről nem tudni, hogy adott adattábla változásainak a kiírása éppen hol tart.

Ez a technológia egy OS virtualizációs technológia. Arra való, hogy több linuxos alkalmazást tudjál úgy futtatni egyetlen OS alatt (egyetlen VM-ben), hogy az alkalmazásoknak nem kell tudniuk egymásról.

Ergó amilyen feature nincs Linuxra az OS szintjén, azt a funkciót nem is tudja virtualizálni a konténertechnológia. Márpediglen ez a VSS egy Windows-only cucc. Ha ezt a funkciót konténerek nélkül meg tudod valahogy oldani Linuxon, akkor konténereken keresztül is meg lehet találni a módját.

A konkrét problémáról annyit, hogy egy adatbázis alatti terület konténeresdiben mindig konténeren kívüli terület lesz (hacsak nem egy eldobható tesztadatbázisról beszélünk), tehát a problémát (a döglött lovat) áttoltuk a szomszéd telkére: ahonnan az a diszk jön, ott lehet pl. snapshotokat meg mentést csinálni. Adatbázismentéshez erre a VSS-es mókolásra annyira nincs szükség, egy adatbáziskezelőtől ugyanis azt várjuk, hogy ha én bármikor nyomok neki egy kill -9-et, akkor újraindítás után menjen tovább. Amelyik ezt nem tudja, ott a HA meg a DR szavak használatának nincs létjogosultsága, mert egy sima áramszünetet/crasht sem biztos, hogy túlélne a cucc. Amelyik meg tudja, az sima snapshotból menthető.

Attól, hogy valami nincs Linux OS szintjén, attól még lehetne. Például az indítást is egy API funkciónak lehetne nevezni.

Nem konkrétan VSS-t várnék, de egy cache ürítés lehet éppen jogos elvárás egy futó processztől.

Adatbázismentéshez erre a VSS-es mókolásra annyira nincs szükség, egy adatbáziskezelőtől ugyanis azt várjuk, hogy ha én bármikor nyomok neki egy kill -9-et, akkor újraindítás után menjen tovább. Amelyik ezt nem tudja, ott a HA meg a DR szavak használatának nincs létjogosultsága, mert egy sima áramszünetet/crasht sem biztos, hogy túlélne a cucc. Amelyik meg tudja, az sima snapshotból menthető.

Akkor szerintem menj el néhány megoldás és DR szállítónak előadást tartani, biztosan örülnének, ha sok fejlesztési költséget megspórolhatnának.

Annyit hozzátennék, hogy áramszünet egy adatközpontban meglehetősen ritkább esemény, mint egy mentés vagy replikáció miatti konzisztencia pont létrehozása.

Abban én is biztos vagyok, hogy az Azure-ben nem 1-1 ugyanaz fut, ami helyben, például Exchange sem lenne gazdaságos sem erőforrás, sem üzemeltetés szempontjából.

Ha nem is konténer, akkor valami "Super-AD", leegyszerűsítve minden (vagy gyökér) értékhez van egy többlet paraméter, hogy melyik bérlőhöz tartozik.

Van windowsos konténerizáció is

Hát, hunyorítva, messziről nézve, akár azt is hihetnénk, hogy az is ugyanez. De valójában nem az. Helyesebben pont azt nem tudja csak, ami a linuxos konténerek lényege lenne (kicsi, egyszerű, hordozható). De ez nagyjából technológiai adottság, és a Windowság következménye. Szar élmény lehet látni a windowsos júzereknek,  hogy a Linux architektúrája mennyivel jobb lehetőségeket ad ezen a téren...

én nem gondolnám hogy az Azure-ben futó AD-k monolitikusak lennének

Pedig de. Az egy sima, mezei windowsos AD bebaszva egy VM-be. Olyannyira, hogy nem is létezik hozzá cloud API, cloud menedzsment, meg hasonlók. Tehát nem tudod a webes Azure portálról baszogatni, nem tudsz pl. júzereket a linuxos 'az' CLI-ből vagy HTTP REST API-n keresztül létrehozni, meg hasonlók.

Az a "recommended" megoldás a menedzselésére, hogy joinold egy meglevő, kialakított (vélhetően on-prem) Active Directory fába, és majd akkor onnan lehet szinkronizáltatni meg menedzselni - a standard windowsos toolokkal.

Az Azure mögötti, AAD-nak nevezett valami sem egy windows AD, a séma is egészen jól láthatóan más, és nem is lehet Windows munkaállomásoknak ezt a valamit AD szerverként megadni.

A Windows user-space, mint mozgatható fogalom nem létezik, mivel kernel-függő részek vannak a system .dll-ekben. Kernel interface (personality) versioning sincs. Ergó ha Windows 10 1903 + 2020 október 12-i Windows Update-et használó hoston futó konténert csinálsz, abban benne lesznek a host dlljei, amik csak ugyanezen OS verzió ugyanezen Update-jével garantált működésüek (és csak ilyen hoston támogatottak). Ha Updatelsz a hoston, akkor új Windows konténer image-et kell gyártanod az új system .dll-ekkel... Ja, és egy nagyon lecsupaszított konténer image is a GB nagyságrendjében mozog (ami hatalmas előrelépés volt nekik a kezdeti, 5GB+-os image-ekhez képest).

biztosan nem lehet mindent konténerben futtatni

Azokat nem rakjuk konténerplatformra. Maradnak ott, ahol a legacy dolgok. Némelyik véleménnyel ellentétben: nem, egyáltalán nem evidens, hogy meglevő legacy cuccokat be akarjunk rakni konténerekbe. Ahhoz, hogy ennek bármi értelme legyen, az alkalmazás architektúrájának értelmesen felhőkompatibilisnek kell lennie, és meglévő enterprise alkalmazások esetén ez ritka, mint a fehér holló. Néha meghágható az alkalmazás, vagy a vendor maga hajlandó a szükséges változtatásokat megcsinálni. De inkább nem...

és nem feltétlenül éri meg külön hardver csoportot konténereknek, másikat virtuális gépeknek fenntartani

Lehet így csinálni, és sokan is csinálják így, de amennyiben szabad szemmel is jól látható kapacitásigény van a konténerizált cuccoknak, ott általában a workloadnál előbb-utóbb felmerül, hogy mi a francnak alája aranyáron VM réteg, és inkább legyen külön hw kupac, amin bare metal OS-en futnak a konténerek. Tegyük hozzá, hogy a control plane-t még ilyen esetekben is rendszeresen VM-ekbe pakolják az egyszerűbb (erőforrás)menedzselhetőség és upgradelhetőség miatt.

De, konténerizált. Illetve ha nagyon akarom, lehetne akár konténereken kívül is futtatni, mert ezek a konténerek jellemzően egy szál statikus binárist tartalmaznak. A Kubernetesnek van egy olyan tulajdonsága, hogy rengeteg dologra van benne egy default működés/megoldás, de nem kötelező azt feltételenül úgy csinálni. Sokszor értelmesen lehet választani több opció közül is - persze a választásnak vannak következményei (mondjuk egyik-másik megoldás lehet, hogy nem production-ready, azaz senki nem vállal rá még elvi szinten sem garanciát, hogy nem lesz vele gond, de ettől még dev környezetben, vagy a saját laptopodon teljesen jó lehet az úgy is).

A control plane elég szépen meg van álmodva, egyetlen stateful komponens van benne, ami egy shared-nothing szinkron replikált adatbázis. Minden más komponens vagy full redundáns stateless cucc (annyit futtatsz belőle, amennyit akarsz), vagy az alkalmazásrétegben van a failover megoldva (azaz futtatsz belőle n példányt, és ők majd egymás között megbeszélik, hogy most épp ki dolgozik). És a komponensek alapvetően az adatbázison keresztül kommunikálnak egymással.

ezek a cuccok hogy oldjak meg ha egyes dolgoknak "specialis" igenyuk van? pl mongo/elastic/redisnek soksok ram kell hogy az adat a memoriaban legyen, de a php kodnak meg sok-sok cpu meg szamolja a vilagegyenletet, a mysqlnek meg bitanggyors ssd, a wowzanak meg 100T tarhely.

most ne egy multit vegyunk ahol vegtelen penz van es megveszik a 1024 cpus, csillio gigaramos vasat, hanem valami kozepes ceget (legyen 50fo) . "hagyomanyos" vilagban mindenki megkapja ami kell neki, "szemelyre szabott" hw-vel.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A CPU/memóriára tudsz ilyet mondani, hogy https://kubernetes.io/docs/concepts/configuration/manage-resources-cont…

A storage meg egy külön kérdés, amennyire tudom, mert a skálázható, több gépről elérhető HA világban ez nem annyira egyszerű - vagy tudsz podokat nodera pinelni, s akkor azon a nodeon fixen adni neki valamit. 

De tldr, a memória/cpu vonalon imho tökéletesen megoldja ezt a kubernetes, akár dinamikusan átscheduleolva appokat ha valahol kevés cpu vagy kevés memória lenne. 

A storage-nál elvileg a konténerhez PersistentVolumeClaim-et kell csak megadni, és onnan már a cluster ügyintézi. Persze hogy milyen lesz az a storage (milyen IOPS-t bír, egy adott hosthoz köt vagy valami hálózatos okosság), az már a cluster beállításaitól függ.

VMware fürtben mi a hatékonyabb például egy memória intenzív alkalmazás esetén: konténer szinten elosztani a terhelést vagy ESXi szinten? A terhelés miként van elosztva: lényegében újraindul máshol vagy van beépített intelligencia átvinni az alkalmazás állapotát?

Biztos hogy alkalmazás szinten osztanám el (ami amúgy még a konténer szint felett-előtt van).

Az alkalmazások akkor jól skálázhatóak ha (relatíve) állapotmentesek. Azaz megfelelően pici darabokra kell szabdalni a terhelést és azt szétdobni úgy, hogy ne legyen para ha egy-egy darab menet közben elpusztul.

Amikor végzett akkor valami megbízható helyre perzisztálja az eredményt és ennyi.

Gábriel Ákos

Köszi.

Ez akkor megerősíti bennem azt, hogy a konténeresdi sokkal inkább egy fejlesztői evolúció, mintsem üzemeltetési evolúció. Azaz az előadással ellentétben a konténeresedés nem a virtuális gépek utáni lépés, hanem azzal párhuzamos dimenzió, hiszen nem az üzemeltetés dönti el, hogy miként szeretne egy alkalmazást futtatni, hanem a szerződött szállító biztosít valamit, aminek hátteret kell adni (legyen az akár helyszíni, akár felhő infrastruktúra).

sokkal inkább egy fejlesztői evolúció, mintsem üzemeltetési evolúció

Leginkább sw deployment evolúció, azaz ahol a kettő összeér egymással.

nem a virtuális gépek utáni lépés

Ez egy réteggel feljebb van.

hanem a szerződött szállító biztosít valamit, aminek hátteret kell adni

Azt a problémát képzeld el, hogy a VM-es világban a sw vendor (a fejlesztők) adják a VM image-et, te meg próbálod futtatni. Ugye érzed, hogy ez miért baromi kényelmetlen? Nem is tipikus, de láttunk már ilyet.

Na ezt a problémát oldjuk meg azzal, hogy máshová húzzuk az interfészt, amit az üzemeltetés ad a fejlesztők által biztosított izének. A VM megoldásokkal az a fő gond, hogy az emulált valami (az x86-os hw) nagyjából meghatározza, hogy mi van az interfész két oldalán, attól lényegileg nem lehet eltérni. Viszont ez sajnos olyan dolgokat rak az alkalmazás oldalára, amiknek az üzemeltetés oldalán kéne lenniük. Hasonlóan az OS package-ek interfésze meg olyan dolgokat tol az üzemeltetés oldalára, amiknek ideális esetben a fejlesztők problémáinak kéne lenniük. Ezér t szívás a VM image szintű terjesztés is, de a klasszikus OS package terjesztés se ideális.

Ezért jött létre ez a konténeresdi. Úgy húzzuk meg az interfészt, amit a konténer kap, hogy azok a dolgok legyenek a fejlesztők reszortjai, amiket ők tudnak jobban, és azok a dolgok, amiknek nem a fejlesztőknél van a helyük, azok meg kívül legyenek. És a konténer így a sw terjesztési megoldást is kezeli: ami bent van, az a fejlesztők feladata, oldják meg otthon, és csá. Ami kint van, azzal meg ne foglalkozzanak, az a környezetet biztosítók feladata. Ezzel rengeteg dolgot, ami hagyományosan egy install guide-ban humán fogyasztásra lenne leírva, azt itt a számítógép megcsinálja helyettünk (ergó scriptben kell valakinek megírnia). Illetve a favágás helyett egy-két szinttel feljebb levő, értelmesebb dolgokkal kell csak az embernek foglalkoznia (jellemzően a "hogyan illeszkedjen az alkalmazás a mi környezetünkbe" kategóriában).

Én ezt teljesen értem, csak az első előadás gondolatiságára akartam reflektálni a megjegyzéssel.

A virtualizáció nem a lyukkártya és a konténer között van. A virtualizáció teljesen más, a virtualizáció egy megoldásra arra, mikor a szoftvereknek teljes operációs rendszer környezetre van szükségük. A lyuk kártya és a konténer között a teljes operációs rendszer van, a második előadás nagyon szépen megfogalmazta felhő operációs rendszerként.

Tehát ha az üzlet kitalálja, hogy kell neki valamilyen szoftver, körülnéz a piacon, oda lehet tenni az elvárások közé, hogy konténerizált legyen, de ez a sor kb legvégén lesz, ami akkor lesz valós választási szempont, ha minden feljebb levőben két vagy több szoftver fej-fej mellett van. Ha olyan szoftver jobb az üzlet számára, ami nem konténerizált, akkor legfeljebb egyezkedni lehet a szállítóval, hogy konténerizálja, de az üzemeltetésnek nem biztos, hogy van ehhez kompetenciája (például nem futhat belőle több példány nemcsak licenc okokból, de technikai okokból sem), illetve nem biztos, hogy megéri erre bármennyi időt is rááldozni.

Ezzel szemben a virtualizáció arra ad válasz, ha egy szoftvernek operációs rendszer környezetre van szüksége, akkor felosztja a hardvert, hogy ne kelljen annyi vasat venni. Jártam szerver teremben 10+ éve is, amikor több száz szerver volt, mindegyiken egyetlen vacak alkalmazás futott.

Lehet, hogy rossz a hasonlatom, de a konténerek talán a Java EE-hez hasonlíthatók valamennyire azzal a különbséggel, hogy itt nemcsak Java alkalmazások lehetnek.

Visszakanyarodva a cég szoftver igényére: ha ez a szoftver nem piacról megvásárolható, hanem saját fejlesztés, ott már nyilván bele lehet (kell) tenni, hogy konténerizált legyen.

Ha virtualizációhoz akarjuk hasonlítani, akkor a virtual appliance-okat lehetne említeni, mert az hasonló dobozos szemlélet (VM Image alatt gondolom erre gondolsz, bár szerintem az kényelmetlennek nem kényelmetlen, hiszen next-next-finish-sel felmegy egy OVA).

Ugyanakkor amire kíváncsi vagyok, az az első előadás "register globals" jellegű megjegyzése. A konténerekkel nagy mértékben nő a szoftver kiadó felelőssége, hogy az, amit becsomagol, az biztonsági elvárásoknak is megfeleljen nemcsak a saját fejlesztését illetően, hanem a becsomagolt környezetet illetően is. Azaz konténeres alkalmazást nemcsak akkor kell kiadni, amikor ő funkcionálisan fejlesztett valamit, hanem ha a felhasznált komponensekhez is van frissítés. Mert lássuk be, egy  fejlesztő sokszor nem foglalkozik hasonló "apróságokkal", csak odahány valamit, mert ő üzleti logikát valósít meg. Kérdés, hogy a sok fejlesztő cég fel van-e készülve arra, hogy ezt megugorja, ez erőforrást igényel.

Hasonló a helyzet a virtual appliance-ekkel is: ki lettek kiáltva biztonságosnak stb. Csak kérdem, mitől biztonságosabb egy olyan VM, amibe a szoftver fejlesztő pakolta be a bugos HTTP szervert és nem frissíti? A felelősség kitolása nem oldja meg a rendszer biztonságát.

Nem láttam az előadást úgyhogy csak a komment alapján próbálok válaszolni.

Legelőször is: fel tudsz rakni egy komplett ubuntu-t minden szolgáltatással együtt, egy konténerbe és még menni is fog. Gusztustalan nagy konténer lesz belőle, de menni fog. Van Oracle 12c is konténerben.

Szerintem alapvetően kétféle konténerizáció van:

- bármit be lehet rakni egy konténerbe aminek linux kernel kell, akármilyen kicsit vagy akármilyen nagyot
- írhatsz úgy szoftvert, hogy direkt konténerbe tervezed rakni

Adminként gondolkozhatsz úgy is a konténerekről mint egy új csomagolási módszer.

Óriási előnye, hogy a külön konténereknek semmiféle fejlesztő által enforce-olt dependencyje nem lehet. Egyik motyó fut egyik libc-vel, másik motyó másik libc-vel. Vagy akár másik linux disztribbel.

A storage-ot, a networköt úgy rakod össze ahogy akarod.

A kért dependencyket (pl a cms-nek kell egy db) te konfigurálod alá, ahogy akarod. Gitbe belerakhatod az egész konfigot, ott verziókezelheted.

Az egész motyót lokálban letesztelheted mielőtt komplett ugyanazt kirakod a szerverre élesbe, akár egy pull requestből. Élesben pont ugyanaz fog futni mint bárhol máshol, és ez igen jó.

Aztán vannak azok a szoftverek amik direkt konténeres szemlélettel készültek.

Itt érvényesül a SOLID principle, minden komponens a saját dolgát csinálja és csak azt.
Adminként rád van bízva hogy milyen megoldást raksz össze. 

(
Kubernetesbe való belebonyolódás (és kínlódás) előtt mindenkinek ajánlom a docker-compose docker stack út végigjárását.

Kevésbé komplex de pont olyan jól megmutatja mit és hogyan csinál a kubernetes, mert az egész kubernetes amúgy scriptekkel jól televarrt (docker) konténerek összessége.

)

A “konténeres app fejlesztője” átadhatja neked a cuccot forrásban is, sőt úgy kéne átvenni csak.

Azaz a biznisz logikát tarthatja jar-ban, executable-ben titokban ha nagyon akarja, de a körítést adja ide Dockerfile-ban.

Abból én megépítem a “trusted image-et” és pontosan látom hogy milyen verziójú webserver, db, nodejs, akármi van előtte-körülötte. És nem hozott be vírust se trójait.

Gábriel Ákos

A virtualizáció nem a lyukkártya és a konténer között van.

Bevallom, nem néztem az előadást, de a lyukkártya felemlegetése nálam értelmezési tartományon kívülre esik ebben a témában, egyszerűen nem értem, hogy hova jön ide a lyukkártya.

A hw virtualizáció és a konténertechnológia ugyanazt csinálják (virtualizálnak erőforrásokat), csak eltérő rétegben teszik ezt. Emiatt a kettő teljesen ortogonális, mind a két rétegben lehet értelme virtualizálni, nyilván más okokból mást virtualizálunk, így az eredmény is más lesz.

Ha csak annyi az igény, hogy egy fizikai vason több alkalmazást tudjunk futtatni, arra mind a kettő alkalmas lehet (úgy kb. az alkalmazások 99.9%-ánál), de nyilván vannak olyan kivételes alkalmazások, amelyeknek egyik vagy másik nem felel meg, mert vagy a hw-rel kapcsolatban, vagy az OS réteggel kapcsolatban határozott elképzelésük van, amit sehogy  sem lehet teljesíteni alternatív megoldásokkal. De ez valójában ritka, mint a fehér holló.

Lehet, hogy rossz a hasonlatom, de a konténerek talán a Java EE-hez hasonlíthatók valamennyire azzal a különbséggel, hogy itt nemcsak Java alkalmazások lehetnek.

Éppenhogy tökéletes. Mind a kettő ún. Platform-as-a-Service (PaaS) technológia.

Ha olyan szoftver jobb az üzlet számára, ami nem konténerizált, akkor legfeljebb egyezkedni lehet a szállítóval, hogy konténerizálja, de az üzemeltetésnek nem biztos, hogy van ehhez kompetenciája, illetve nem biztos, hogy megéri erre bármennyi időt is rááldozni.

Nem "nem biztos, hogy", hanem "biztos, hogy nem". Vendor által támogatott sw-ek esetén ez az út csak elméletben létezik, a gyakorlatban nem járható. Ahol járható lehet, az a már támogatáson kívüli, best effort alapon üzemeltetett régi szarok, illetve a közösségi támogatással üzemeltetett open-source cuccok esete, de leginkább ez utóbbi.

A vendor által támogatott esetben csak az működik, hogy a vendor gondoskodik róla, hogy konténerizált legyen a cucc - és a valóságban ez is szokott történni. De nem az a tipikus felállás, hogy az ügyfelek egyezkednek a vendorral, hogy "lécci, konténerizált verziót kérünk", hanem pont fordítva: a vendor saját jól felfogott érdekében már évek óta konténerekben fejleszt, és már baromira unja a legacy módon üzemeltető ügyfeleket, sőt, ő kérleli az ügyfeleit, hogy legyenek szívesek végre a konténerizált verziót futtatni, mert azzal sokkal kevesebb a szívás (mindkettejüknek). Sőt, olyan projektet is láttunk már, ahol a vendor még azt is felvállalta, hogy maga telepít egy Kubernetest az ügyfelénél, meg segít üzemeltetni is, csak legyen hol futtatni a szarjait.

bár szerintem az kényelmetlennek nem kényelmetlen

Akkor lesz kényelmetlen, ha ugyanarra akarod használni, mint amire a konténeresdi alkalmas. Azaz limitált funkcionalitással jól használható, a konténeresdi szintjén viszont kezelhetetlen kezd lenni. Ezért is van az, hogy a virtual appliance-eket ott használják, ahol limitált, egyszerű az alkalmazás architektúrája (mondjuk az egész alkalmazás egy szál VM-ben fut, beindítod, #osztkész). Ha az van, hogy van 6-8 alkalmazáskomponens, azokhoz külön-külön image, és akkor indíts mindegyikből annyit, amennyi szükséges az architektúrához (mondjuk szigorúan 1-et, ha failover a komponens, és nem futhat belőle több egyszerre, 2-t, ha simán redundáns, 3-at, ha mondjuk quorum-alapú replikált adatbázisról van szó), aztán ahol egynél több elem van, oda tegyél kívül egy load balancert, tegyél melléjük DNS-t, ahová írd be a szükséges entryket, a konfig fájloknak, közös adatterületeknek csinálj egy külső NFS-t, azokat mountold be a VM-ekbe, hogy a többpéldányos komponenseknek közös lehessen a konfigja, meg hasonlók. És amikor azt mondják, hogy jön az új verzió, akkor csinálj az egész mindenségből még egyet, hogy legyen hol tesztelni az új verziót... Na erre mondtam, hogy ez így egyáltalán nem kényelmes. Vagy "oldja meg a vendor", írja meg hozzá a scripteket, ha már ilyen elcseszett architektúrát álmodott.

A konténerekkel nagy mértékben nő a szoftver kiadó felelőssége

Kicsit precízebben: innentől konkrétan a vendor felelőssége a biztonság az alkalmazásában, csak ő felelős érte. Nem kenheti rá a problémát az üzemeltetésre. Ennek amúgy van egy előnye: van kin számonkérni. A klasszikus felállásban az ügyfél egyéni szoc. problémája, hogy hogyan oldja meg ezeket a dolgokat.

Kérdés, hogy a sok fejlesztő cég fel van-e készülve arra, hogy ezt megugorja, ez erőforrást igényel.

A fejlesztőcégek jellemzően eljutnak oda, hogy ezzel nekik feladatuk van. Nekünk konkrétan van ilyen ügyfelünk, akik érezték, hogy ehhez a részéhez nem értenek eléggé, és kértek segítséget, hogy hogyan kéne ezt jól csinálni. Van azért ezzel a résszel kapcsolatban már egész sok best practice, van honnan tanulni. Az kétségtelen, hogy aki a saját reszortját (fejlesztés) rosszul csinálta/ja, annak nincs silver bullet, amivel varázslatos módon kompenzálni tudná a hibás gyakorlatát. Pl. értelmes mennyiségű automatikus tesztelés nélkül az életben nem fognak ezek a dolgok jól működni.

Csak kérdem, mitől biztonságosabb egy olyan VM, amibe a szoftver fejlesztő pakolta be a bugos HTTP szervert és nem frissíti?

Hát ugye a konténeresdiben az a koncepció, hogy legyen olyan hatékony módszer, amivel relatíve sűrűn lehet új verziót előállítani és eljuttatni a végső futási helyére, közben kezelve azokat a problémákat, amik ilyenkor tipikusan előfordulhatnak (pl. regression, vagy amikor dev-test-prod rendszerek divergálnak). Na ez a VM-es világban annyira nem triviális. Ezért is van az, hogy a virtual appliance-jellegű megoldások nem tekinthetőek annyira tipikus megoldásnak prod környezetben.