- Garmin Forerunner 255 Music - nem csak futóknak
- Motorola Moto G24 Power - hol van az erő?
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Érkezőben a Poco M6 4G
- Google Pixel 8 Pro - mestersége(s) az intelligencia
- Samsung Galaxy S21 FE 5G - utóirat
- Telekom mobilszolgáltatások
- Honor Magic5 Pro - kamerák bűvöletében
- Mobil flották
- Samsung Galaxy A54 - türelemjáték
Hirdetés
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
VR játék lesz az Alien: Rogue Incursion
gp Az év végén érkező program PC-re, Meta Quest 3-ra és PlayStation VR2-re érkezik a tervek szerint.
-
Rossz üzlet az EV-kölcsönzés
it Küszködik az EV-kölcsönzés miatt a Hertz Global, még több EV-t adnak el.
Új hozzászólás Aktív témák
-
Nem ertek egyet mindennel.
A devops nem arrol szol, hogy nincs ops, hanem arrol, hogy a fejlesztes resze az, hogy aktivan gondolkozunk az uzemeltethetosegrol es az uzemeltetesrol is. Pelda: a fejlesztes resze az, hogy megtervezzuk, hogy milyen health checkek lesznek, kell-e circuit breaker, milyen skalazasi problemak varhatoak. Satobbi.
> 2. a fejlesztési ciklus felgyorsítása gyakorlatilag egyet jelent azzal, hogy sokkal hatékonyabban hagyod benne a hibákat.
Nem. Az iteraciok roviditese nem jelenti azt, hogy a fejlesztes abszolutertekben gyorsabb. Azt jelenti, hogy kevesebb hulyeseget csinalunk, mert olyan stabil a delivery pipeline, hogy akar napi otszor is releaselhetunk. Meg azt is jelenti, hogy a sok deployment miatt rutinszeruen tudunk rollbacket csinalni, es nem az van, hogy felevente kitolunk valamit, aztan amikor nem mukodik valami, akkor meg panik van.
Nyilvan csak akkor lehet gyorsan iteralni, ha rendkivul szoros automatizalt tesztlefedettseg van.
> 3. felszínesen belenéztem egy-két fejlesztési módszertanba, van, amelyik arra optimalizál, hogy nem tudjuk mit akar a megrendelő, de elkezdjük legyártani, és milyen szuper csávók vagyunk, hogyha kiderül, hogy nem is ezt akarta, akkor qrva gyorsan tudunk irányt váltani. ja, ezzel nagyjából ki is dobtad az addigi munkát.
Jol latod, pl. agile nem a sebessegrol szol, hanem a kockazatmenedzsmentrol. Ergo felaldozunk nemi sebesseget azert cserebe, hogy ne a vegen deruljon ki, hogy 1) total mast csinaltunk, mint amire a megrendelo gondolt vagy 2) a megrendendelo erre gondolt anno, de mar nem erre gondol. Emiatt inkabb gyakrabban dobunk ki kisebb darabokat, mint ritkabban nagyobbakat.
> 4. a 3.-as pont következménye: a rendes folyamatszervezést szerintem nem lehet megspórolni, még akkor sem, ha mostani módszertanok ezzel kecsegtetnek.
Az agile nem/sem helyettesiti a megfelelo folyamatszervezest, nyilvan.
> és ez tényleg olyan jó nekünk, mint rendszergarázdák?
Az a helyzet, hogy senkit nem erdekel, hogy nektek mi a jo. A megrendelonek kell, hogy jo legyen.
[ Szerkesztve ]
while (!sleep) sheep++;
-
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++;
-
A kontenernek az a lenyeges tulajdonsaga, hogy allapotmentes, nem az, hogy fekete doboz. (Altalaban.)
Az appliance-eknek is megvan a maguk problemaja, es persze erteni is kell hozzajuk, ahogy a kontenereknek is. A kerdes, hogy jobb-e a celjaidra, mint az elozo megoldas.
while (!sleep) sheep++;
-
> .deb natívan van egy csomó oprendszerben, a konténerhez meg kell egy csomó konténer infrastruktúra. tehát ez az állítás nem igaz.
Nem kovetkezik az elso allitasbol a masodik.
> és biztos nincs arany középút, ahol swarm nélkül is automatizálva van az ilyen, és működik rendesen?
Miert jobb a te automatizalasod, mint pl. a Swarm?
> mert akkor csak konténert, swarmot, chefet, meg ansible-t nem kell megtanulnod, telepítened, üzemeltetned, debuggolnod, frissítened
Ebbol a chef meg az ansible nem kell, ha kontenerezel. Szoval ha ezeket nem kellene megtanulnom, akkor megtanulhatnam azt, hogy ezeket a funkciokat hogy csinalom meg sajat magam.
Egyebkent baromi egyszeru: ti azt hiszitek, hogy a vilag hulye, es azert kattant ra kb. mindenki a kontenerekre, mert valaki megvezette oket. Kozben meg a vilag jo resze nem teljesen hulye, es jo oka van ra, hogy ezeket hasznalja. Erre a te valaszod az, hogy azok az okok nem valosak.
Hat, szori.
[ Szerkesztve ]
while (!sleep) sheep++;
-
Mondok egy jo peldat, ami nalunk konkret use case. Kivancsi vagyok, hogy ki hogy oldana meg.
Eleg jo tesztlefedettsegunk van. Peldaul csak ugy kerulhet be a verziokezelo fo agaba kod, ha elotte tobb ezer konkret tesztszkript lefut a teljes rendszeren. Egy tesztszkripthez az kell, hogy a teljes rendszer fusson (mert az automatizalt teszt vegigkattintgatja az UI-on egy teljes feature-t).
Namost. Ugye a teszteknek reprodukalhatonak kell lennie, azaz kezben kell tartani az allapotot. Kontenerekkel eleg egyszeruen meg lehet azt csinalni, hogy minden egyes teszt az eles rendszert elegge megkozelito masolaton fut, es a tesztek kozott egyszeruen eldobjuk az allapotot.
Ezenkivul ha kezd sok lenni egy teszt, akkor bedobunk a clusterbe par uj build hostot, es azokon is megy a teszt. Egyidoben mondjuk 100-150 peldanyban fut a komplett rendszer, es kb. par percenkent felhuzunk egy ujat a nullarol. Ha bekerul egy uj szolgaltatas a rendszerbe, akkor a tesztkornyezeten semmit nem kell ujrakonfiguralni.
Szerintem ez sokkal nehezebb lenne kontenerek es software defined networking nelkul.
[ Szerkesztve ]
while (!sleep) sheep++;
-
> Inkább pont az a bajom vele, hogy az olyan dolgoknak amiknek nagy permanens tároló kell nem az igazi.
Nincs koze a kettonek egymashoz, ortogonalis problemak. Kontenerek ala is lehet tenni barmekkora tarolot, a lenyeg, hogy az adat a konteneren _kivul_ van. k8s eseten valami volume plugint hasznalsz peldaul, ami mogott ott lehet egy S3 is, vagy barmi.
Na befejezem a teritest
[ Szerkesztve ]
while (!sleep) sheep++;
Ú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.
- OLED TV topic
- Internet Rádió építése (hardver), és programozása
- HiFi műszaki szemmel - sztereó hangrendszerek
- Garmin Forerunner 255 Music - nem csak futóknak
- A fociról könnyedén, egy baráti társaságban
- AMD GPU-k jövője - amit tudni vélünk
- Magga: PLEX: multimédia az egész lakásban
- EA Sports WRC '23
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Autós topik
- További aktív témák...
