Új hozzászólás Aktív témák
-
A kontenerezes nem feltetlen arrol szol, hogy szazmillio node-ra deployolsz. Mondok par dolgot. Kontenereket egyszerubb deployolni, mint .deb fajlokat peldaul. Ennel is fontosabb, hogy a kontenerek korul sokkal jobb a tooling.
Peldaul lassuk a kovetkezo, rendkivul egyszeru problemat:
Szeretnek egy olyan rendszert, ahol van egy adatbazis, egy backend meg valami nginx frontend. Azt szeretnem, hogy a frontend es az adatbazis ne legyen kozos halozaton, hogy ezzel is noveljuk a biztonsagot (defense in depth, ugye). Azt is szeretnem, hogy a kommunikacio a szolgaltatasok kozott TLS-en keresztul menjen. Plusz azt is szeretnem, hogy a backendet es az nginxet ugy lehessen deployolni, hogy blue/green jelleggel, folyamatos rendelkezesre allassal tortenjen a deploy (ergo ha frissitem a backendet, akkor eloszor is lojunk fel egy uj peldanyt, load balance-errel tereljuk ra at a forgalom egy reszet, aztan ha ez mukodik, akkor a regit lojuk le, ha nem, akkor vissza az egesz, automatikusan).
Amit fent leirtam, kontenerekkel es pl. Docker Swarm-mal kb. 5 perc beallitani, es atombiztosan mukodik. Ha 'kezzel' akarod megcsinalni, akkor
- be kell loni a VLAN-okat (rendszergazda egy napig fog rajta ulni)
- be kell loni a TLS certeket (= halal)
- fel kell konfiguralni a haproxy-kat
- valoszinuleg kell irni kezzel egy szkriptet, ami megcsinalja a deploymentet (igen, a Chef vagy Ansible szkript sem lesz trivialis erre)Most miert lenne jo nekem, ha nem kontenerrel csinalnam?
Ja, es ha kell egy uj V(X)LAN, akkor Swarm-mal az 2 uj sor a deployment descriptorban, nem pedig ot napos varakozas a rendszergazdara.
[ Szerkesztve ]
while (!sleep) sheep++;
-
frescho
addikt
Ha kritizálni akarod, akkor ismerd meg jobban az ellenséged:
ha megcsináltam mondjuk a .deb-et, egy utasítás, felrakom, jónapot.
ha konténert (pl. docker image-t) csináltam belőle, akkor kell konténer szoftver, meg annak a vezérléséhez nagy kosár más cucc is, pl. puppetet meg chef-t hallottam sokat emlegetni. azoknak a technológiáknak egy része, amit a konténerhez használsz, megvolt előtte is, pl. redundáns, storage alapú tároló volt régen is, ebből is látszik, hogy a konténer dili csak egy marketing buzzword.A deb csomag helyett sokkal közelebb lenne a chroot jail vagy template virtuális géphez.
A puppet és chef jellemzően nem a konténerhez való. Nagy mennyiségű gépnél konfiguráció managelésre viszont jók. Mi is puppetet használunk a bőven 1000 fölötti géphez.
A konténerhez a storage hogy jön? Pont az benne a buli, hogy eldobható konténerek vannak. ha elhal egy host, akkor így járt, majd indul valahol máshol konténer. Inkább pont az a bajom vele, hogy az olyan dolgoknak amiknek nagy permanens tároló kell nem az igazi. Kis webszervereknek meg hasonlónak OK, de 100G fölötti DB-hez értelmetlen.Irónia ON
A többit is nézd más szemszögből szemszögből:
Az outsource nem halott, csak átnevezték cloud-ra. Így már nincs szüksége emberre aki ért a vashoz, képes méretezni vagy érti, hogy mi az IOPs és mi a különbség a bolti HDD, SATA SSD és egy szerverbe való NVMe között. Teljesen felesleges is lenne, mert a cloudban lehet másik instance-ot indítani, ha kell. Az, hogy ez mennyibe kerül legyen a megrendelő baja, úgyis vele fizettetjük ki.
A konténer is a devops szemléletet támogatja. Valaki már írta, hogy az ops-nak kell körbe gányolnia a leszállított kódot cron jobokkal meg log darálóval. Fölösleges, ha konténereket használ az ember. Meghal az app? Automatikusan lelövi a rendszer. Ha lassú, akkor meg indít belőle 10-et. Hogy ez mibe kerül az nem érdekes, mert legyen a megrendelő baja, úgyis vele fizettetjük ki.
Az új módszertan, a gyors deploy is csak előnyére válik. Az új konténerek újraindítást is jelentenek. ezzel ha memory leak vagy bármi más idővel előjövő problémád van, akkor azt is megoldottad egy csapásra. A legjobb, ha mindent felépítesz a fejlesztői gépen, aztán csinálsz egy környezetet a teszteknek, egy másikat stagingnek, meg az élest. Az egészet dinamikusan fel lehet húzni, ne is nézd ez mennyi erőforrás, a cloud a korlátlan erőforrások hazája.
A skálázhatóság is fontos, mert csak akkor jön ki a konténer előnye. Meg ugye a "scale up" úgyis utálatos dolog, mert gyorsabb CPU-ra bárki tud gyors programot írni. Az sokkal szebb, ha 8 gyors helyett 64 lassú maggal szolgáljuk ki a felhasználókat. Amúgyis ilyenkor ha elveszítünk 8 vagy 16-ot, akkor majd indítunk helyettük másikat. Na ezért végre nem kell fizetni, mert idő alapú a számlázás és így a redundanciát is megoldottuk, ha 2-3 különböző helyre telepítettük az alkalmazást, így villanthatunk a megrendelőnek, aki fizeti az egészet.
irónia OFF
Azért ha rendesen csinálják vannak benne jó dolgok. Csak kell hozzá egy ops csapat is aki támogatja a devopsos csapatokat más szemlélettel és tudással.
[ Szerkesztve ]
https://frescho.hu
Új hozzászólás Aktív témák
ph A japán vállalat felmérése szerint alig van olyan nagyvállalat, amelyik nem tervezi a címben említett modell bevezetését.
- Retro teló rajongók OFF topicja
- Milyen okostelefont vegyek?
- Politika
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- BestBuy topik
- Luck Dragon: Asszociációs játék. :)
- Suzuki topik
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Milyen cserélhető objektíves gépet?
- További aktív témák...