- Microsoft Office és Office 365 topic
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- ASUS routerek
- Milyen switch-et vegyek?
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Mikrotik routerek
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- XPEnology
- Az USA nem akarja visszafogni Kína növekedését
- 1000 kilométert mehetnek az EV-k az új CATL-akkuval
Ú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++;
-
ZnVjaw0K
tag
Első bekezdéseddel tökéletesen egyetértek, a számból vetted ki a szót.
A dev és az ops rettenetesen más terület és egészen más érdeklődési körbe tartozó és egészen máshogy gondolkozó embereket vonz (a masszívan eltérő szaktudás igényen kívül).Tapasztalatból beszélek, jelenleg épp ezt a devops hype-ot erőltetik ránk. Melósok szintjén kb mindenki egyetért nálunk azzal, hogy mindenkinek jobb lenne, ha mindent hozzáértő ember csinálna (1-2 kivételtől eltekintve, akik jellemzően magukat hackernek képzelő amatőr kis perverzek, akik a terméken maszturbálnak ahelyett, hogy otthon élnék ki a vágyaikat valami proof of concept-en). Én fejleszteni szeretek, ahhoz értek. Persze, bele lehet tanulni az ops részbe is (valamennyire kénytelen is voltam), de az nagyon nem az én világom. Főleg amikor x terméken az azóta már az új filozófia miatt felszántott ops csapat zseniálisan túlbarokkosított taknyolását kell hegeszteni...
Ráadásul (nem rosszbol írom, de) az ops/platform területnek egész más a fejlettségi szintje. A fejlesztésben megszokott rogyásig optimalizált best practice-ek, módszertanok, eszközök és legfőképp a többszintű automatizált tesztelés írmagja se található meg ops oldalon, ilyen szempontból évtizedekkel van lemaradva. És ez a környezet természetesen egészen más hozzáállást, más filozófiát követel meg az embertől. Egy agyrém ezeket ugyanarra az emberre bízni. Mi lesz a következő? Összevonjuk a fejlesztést pl. a mozdonyvezetéssel? DevRail? Vicc. -
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++;
-
> .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++;
-
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
-
oszi666
őstag
A folyamat szervezéssel teljesen egyetértek. Nemrég kezdtem dolgozni egy olyan cégnél, ahol a reáltudományok összes szegletéből vannak dolgozók (a szaktudásuk miattt nem azért mert így kukázták össze őket) és hát a vegyész-biológus-informatikus-fizikus-matematikus emberkék néha úgy elbeszélnek egymás mellett hogy bődület (én is néha) mindenkinek más a fontos, és szó szerint kurzusokat tart a cég, hogy értsék egymást a népek.
És mégis flottul megy a dolog eléggé, mert a "managgák" ahogy itt hívták őket pöpecül összeszervezik az egészet valahogy mégis. Én eddig nem dolgoztam ilyen helyen és őszintén szólva most érzem, hogy a project management mennyire fontos.It is not birth, marriage, or death, but gastrulation, which is truly the most important time in your life.
-
JoinR
senior tag
Ú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.
- exHWSW - Értünk mindenhez IS
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Xbox Series X|S
- Témázgatunk, témázgatunk!? ... avagy mutasd az Android homescreened!
- Autós topik
- Gurulunk, WAZE?!
- Miskolc és környéke adok-veszek-beszélgetek
- Kerékpársportok
- Fejhallgató erősítő és DAC topik
- Androidos fejegységek
- További aktív témák...
