Tanzu-ról már írtam párszor és az azóta eltelt időben csak egyre jobban megerősödött bennem a szokásos érzés, hogy minél többet tanulok, kísérletezek, annál buttábbnak érzem magam – és sajnos vagyok is. Több ügyfél meg-megkérdezte tőlem mostanság hogy mi az a Tanzu és mit itt a nagy tudomány?
Teljesen igaz a mondás, hogyha nem tudod elmondani egyszerűen, akkor magad sem érted igazán. Szóval általában úgy fejezem ki a mellette szóló érveket és magyarázom a hype-ot, hogy alapvetően egy közös platform a víziója, amelyet a nem konténeres és konténeres alkalmazások használnak, oly módon, hogy a mélyében – amennyi látszik belőle – nem kell megváltoztatni semmit, nem kell túl sok új dolgot megtanulnia senkinek. Arra fejlesztették, hogy VMware admin számára ne legyen túl mély a konténerek adaptációja, a fejlesztők számára meg kis túlzással transzparens legyen mi van alatta.
Természetesen ha a motorháztető alá nézünk, akkor feljsejlik, hogy biztonsági szempontból olyan képességeket tud, amelyeket elég kevesen tud más. Az is kiderülhet, hogy átláthatóság szemponjából a natív Pod-ok futtatása – mikor nincs is worker node OS egy VM formájában – magán az ESXi kiszolgálón elképesztő lehetőségeket ad.
Maga a termék elég gyorsan halad, a vCenter/vSphere frissítésekkel együtt érkeznek az újabbnál újabb image-ek a Tanzu Content Library-jébe. Ezek gyakorta dobnak be olyan funkciókat, amik olyan képességeket tesznek lehetővé, hogy eddig lehetett nélkülük élni, de ezentúl nem.
Jelen bejegyzés arról szól el, hogy a fejlesztők kezét elengedjük, szóval hadd hozzak három példát arra, hogy éppen hol. A zebra előtt vagy a zebra után. Kezdem az utóbbival.
Zebra után
A VMware üzemeltetés feltelepíti a vCenter-t, az ESXi kiszolgálókat, az NSX Data Center-t (aka NSX-T) és végrehajtja a workload management bekapcsolását, melynek végeredménye a Supervisor klaszter és az ESXi kiszolgálók mint worker node-ok.
Létrehozz a VMware terminológia szerinti namespace-t és beállítja a kívánalmaknak megfelelően a:
- jogosultságokat, hogy a vCenter SSO-n keresztül tudjanak authentikálni a fejlesztők.
- a felhasználható kapacitást (CPU,RAM és tárterület)
- a tárterület helyét – melyik datastore-on legyen.
- a VM class-okat – hogy a VM as a Service és a TKG Guest klaszterek mit használhatnak
- a releváns content library-t
Szóval a VMware admin meghatározza a namespace minden beállítását, maximális méretét, hogy milyen VM-eket kérhetnek majd benne, illetve megát a nevét. Ha belép rá, akkor a részleteket már látja is.
Ezen a ponton már a vSphere Pod-ok működnek is, de az vanilla K8s kell, akkor ki is görgethet a fent látható méretekből magának egyet/többet.
A kimenet alján látszik is a négy node állapota (1 control és 3 worker-t kértünk)
Az VMware adminisztrátor ebből kb ennyit lát – elég sokat, ami a Tanzu egyik előnye is.
A „Virtual Machines”-re kattintva látszik a VM class és a konkrét nevük.
Zebra előtt
Minden ami fent látható, de még a namespace-t sem hozza létre a VMware admin, csak egy template-et készít és majd megcsinálják maguknak. Érhetetlen, hogy ez miért klaszter szinten van és nem a workload management rész mögött de mindegy.
Ha átkattinjuk a fentit, akkor egy template létrehozását kell megtennünk. Mennyi CPU/RAM és tárkapacitást kap egy namespace.
Illetve, hogy kinek/kiknek, csoportoknak és felhasználóknak van joga namespace-t létrehozni és abban jogosultsággal bírni.
Sikeres beállítás után meg is jelenik amit beállítottunk és ezen a ponton már dobhatjuk is el a kaszát.
Szóval ha most authenikálunk be a supervisor klaszterbe, akkor egyenesen onnan tudunk létrehozni VMware terminológia szerint namespace-t.
Alább a GUI-n is látszil. Nyilvánvalóan a VMclass-okat és a content library-t is be kell állítani, mert ezeket még sajnos nem lehet kubectl-ből megtenni – egyelőre. Ugyanakkor ha natív vSphere Pod-ban dolgozunk, akkor arra nincs is szükség, azonnal használható ahogy van.
Természetesen VM-eket amelyen nem egy TKG klasztert szolgál hanem akár az alkalmazás olyan részét, amely nem konénerizálható – nem érdemes mindent konténerbe tenni csak azért mert most az a menő.
Korábbi cikkem a VM as a Service-ről.
