Hirdetés

Új hozzászólás Aktív témák

  • bambano

    titán

    LOGOUT blog

    mire 5 év múlva bevezetné, addigra lecseng ez a marhaság, és más buzzword lesz népszerű.

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • #45997568

    törölt tag

    válasz bambano #1 üzenetére

    Egyelore eleg sokan elnek ezzel a "marhasaggal" es erdekes modon ez a "marhasag" szamottevo elorelepest jelentett a fejlesztesi ciklus felgyorsitasaban, automatizalasaban :U

    Miert is marhasag :F

  • nofene

    aktív tag

    Erdekes modon az egeszbol (marmint a bejegyzesbol) kimaradtak a Site Reliabilty Engineerek, pedig mar most komoly reszei nagyon sok helyen a fejlesztesi ciklusnak...

  • bambano

    titán

    LOGOUT blog

    válasz #45997568 #2 üzenetére

    nekem az első gondom a szemlélettel van: amikor valaki összevonja a fejlesztést meg az üzemeltetést, akkor azt hiszi, hogy lehet valaki mindkettőben egyszerre jó. ezzel valamelyik vagy mindkét szakmai ágat degradálja. szerintem mindkét szakmai ág teljes embert kíván, annyi kraft senkiben sincs, hogy mindkettőben jó legyen.

    a másik probléma, hogy annak a fajta devopskodásnak, amiket látni a neten, akkor van értelme, ha vagy fizetős cloudba pakolsz, vagy cloud eszközökből saját hardveren privát cloudot építesz. a publikus cloud nálam egyértelműen a szakmai öngyilkosság kategória, a privát cloud meg csak sima tévedés.

    ez az egész cloud mizéria arról szól, hogy mindig kell valami buzzword, amit gyakran hangoztatva managgák kihajthatják egymásból a pénzt. majd kiheverik ezt is, elmúlik, mint az outsource mánia. buzzwordok jönnek, managgák mennek, a karaván pedig halad. a régi megszokott módon.

    a következő probléma a cloud rendszer. világos, hogy ha elkészül egy program(release), akkor azt be kell csomagolni valami telepíthető formába. Ez a forma a két világ közötti antagonisztikus ellentét alapján lehet:
    - az oprendszer saját csomagkezelő rendszerének formátuma
    - a konténer formátuma.

    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. más részére meg egyáltalán nem lenne szükség, ha rendesen raktad volna össze az architektúrát, nem pedig cloudosan.

    probléma még, hogy azt mondod: felgyorsítja a fejlesztési ciklust. ezt azért több oldalról is lehetne vitatni:
    1. nem a fejlesztési ciklus egészét gyorsítja fel, hanem a deployt. ettől nem fog gyorsabban programozni a kódkrampácsoló elvtárs, hogy utána gyorsabban buildelődik a cucc és hamarabb ki tudod tolni a produkcióba.
    2. a fejlesztési ciklus felgyorsítása gyakorlatilag egyet jelent azzal, hogy sokkal hatékonyabban hagyod benne a hibákat. szét lehet nézni a világban, egy informatikai szemétdombon ülünk, de legalább gyorsabban cserélik a pelenkát, ha ijedtedben összef.stad magad. kiemelt példa lehet a fejlesztési ciklus felgyorsítására a trészisztem bérlet alkalmazása... azt is úgy felgyorsították, mint a huzat...
    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. ennek megfelelően csodálkoznak, hogy nagyon nehéz programozót kapni a munkaerőpiacon, akit egyébként is arra használnál, hogy kidobd a munkáját.
    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.

    és akkor még nem beszéltünk arról, hogy magát a konténer technológiát meg a felhőt is pont ugyanolyan elrontott fejlesztési módszertannal fejlesztik, mint aminek az elrontására felhasználják azokat. vagyis bugos mind. minél több réteget húzol a bare metal meg az user közé, annál több bug lesz a komplett rendszerben. annál lassabb lesz. annál nehezebben fogod tudni megtalálni a hibát.

    következmény: a cloud és a devops 90%-ban pazarlás. 10%-ban pedig egy pénzszivattyú, amivel átverik a megrendelőt. a cloud egyetlen entitás-fajtának érdeke: akinek fizetsz érte. csak és kizárólag azért erőltetik, mert másképp már nem tudják növelni a bevételt.

    az, hogy ettől a témától függetlenül is úgy általában informatikai szemétdombon ülünk, szerintem bizonyítás nélkül elfogadható állítás. ma egy desktop pc-ben ugyanolyan számjegy van a memória méreténél, mint régen, csak egy ezressel nagyobb szorzó. ettől senkinek a munkája nem lett érdemben hatékonyabb. max. annyi eredményt hozott, hogy folyamatosan csökken az iq küszöb, ami a gép használatához kell. és ez tényleg olyan jó nekünk, mint rendszergarázdák?

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • emvy

    nagyúr

    válasz bambano #5 üzenetére

    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++;

  • bambano

    titán

    LOGOUT blog

    válasz emvy #6 üzenetére

    "A devops nem arrol szol, hogy nincs ops, hanem arrol, hogy a fejlesztes resze az, hogy aktivan gondolkozunk az uzemeltethetosegrol es az uzemeltetesrol is.": nekem ehhez nem kell devops. egyébként pedig de, a devops arról szól, hogy nem kell ops, majd a dev opsol is.*

    "Pelda: a fejlesztes resze az, hogy megtervezzuk, hogy milyen health checkek lesznek, kell-e circuit breaker, milyen skalazasi problemak varhatoak. Satobbi.": mit értesz circuit breaker alatt? kismegszakítót? mert ha igen, neked fejlesztés közben be kell kalkulálnod, hogy milyen áramellátás lesz? és ha máshova telepítik, újra fogod fordítani?

    egyébként pedig ne tervezd meg, hogy milyen skálázási problémák várhatók. azt tervezed meg, hogy hogyan oldod meg a skálázási problémákat.

    "Az agile nem/sem helyettesiti a megfelelo folyamatszervezest, nyilvan.": a rendes folyamatszervezés megléte kizárja, hogy folyton kihajigálj kódokat, mert a megrendelő nem arra gondolt.

    a kritikádból még mindig nem kaptam elég motivációt, hogy devopsozzak meg cloudoljak.

    * kell valakinek aláírásba? :P :P :P

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • I02S3F

    őstag

    válasz emvy #6 üzenetére

    "Az a helyzet, hogy senkit nem erdekel, hogy nektek mi a jo. A megrendelonek kell, hogy jo legyen."

    Ebben az az érdekes, amikor a vevőnek vannak nem megfogalmazott elvárásai/ő se tudja mit akar/ változtat az igényén/nem ért hozzá.

  • emvy

    nagyúr

    válasz bambano #7 üzenetére

    > mit értesz circuit breaker alatt

    Te nem infrastrukturaval foglalkozol? :)

    while (!sleep) sheep++;

  • ZnVjaw0K

    tag

    válasz bambano #5 üzenetére

    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.

  • Geller72

    veterán

    Ettől az egésztől - nekem legalábbis - herótom van. Egyre bonyolultabb, egyre több szereplős lesz az, ami régebben egyszerűbb volt. Pedig azt gondolhatnánk, hogy a fejlődés előrehaladtával a dolgok leegyszerűsödnek. ;] De neeeem. :D.

  • bencze

    senior tag

    válasz ZnVjaw0K #10 üzenetére

    Érdekes én a fordítottját látom. Fejlesztés oldalon mindenféle kókler ír valami kódot ahogyan ő szeretné de semmi szándék nem mutatkozik semmiféle tervezésre, az architektúra szó olyan, hogy látszólag mindenki jól ismeri látszólag de a fejlesztő széttárja a karját, hogy ó de hát agilisak vagyunk, honnét tudjuk mi lesz ebből a kódból mire kikerül élesbe. Aztán túrja a kis szutykát, lesz valami ami nincs ledokumentálva ergó senki nem lát bele, az üzlet kifizeti kilóra aztán szerencsétlen ops hegesztgesse támogassa a millió problémájával együtt. Hogy rendelkezésre állási sla? Ja hát azt a fogyatkozó opsosok maradéka megoldja okosba valami automatizálással. (vannak ilyenek ezt szokás gánynak hívni de hát mit tudjon szerencsétlen csinálni odarak valami scriptet ami újraindítgatja max meg törölget meg mittudomén devnullba tolja a debug logot hogy ne teljen meg a disk 2 naponta - ne kérdezd miért marad bekapcsolva vagy miért nem konfigolható prod kódnál)
    A fejlesztők 99%-a (nem túlzok, tényleg érzésre kb ez az arány) gyakornoki szintre való. Meg kell mondani mit csináljon de üzlet közelébe ne engedjük mert csak átveri a buzzwordokkel kihúz belőle csomó pénzt aztán akkora szart szállít le amekkorát nem szégyell - szét ne essen a demo alatt.
    Értem, hogy ez az egész abból ered, hogy az üzlet szeretne gyorsabban, olcsóbban haladni, de valójában nincsenek csodák, a cloud sem attól olcsó mert varázslat van benne hanem mert kispórolnak csomó mindent amit magadnak nem spórolnál ki, és persze nem fogsz tudni róla, hogy kezeld a kockázatokat. A nagyok elég jól körbebástyázzák a dolgaikat mindenféle tákolmányokkal ezért nem esett szét a dolog, meg a hype miatt.
    A devops meg gyakorlatban az, hogy majd mindenki csinál mindent és a kód minél hamarabb menjen ki élesbe. Ok. Ennek az árát a megrendelő nem látja de egyre nehezebben üzemeltethető dolgok vannak mert a rövid távú eredményekért feláldozzuk a hosszú távú gondolkodást így nagyon gyorsan egy karácsonyfa lesz az egész. A legacyt szokás szidni, hogy micsoda kupleráj, láttam greenfieldes dolgokat amik rekord idő alatt lehagyták kupleráj kinézetben mindenféle előzetes ígérgetés ellenére. A végére drága lett és szar. Igaz, kezdetben gyorsan jöttek dolgok.
    Szóval egy nagy marketing ez az egész és kell a kritikus gondolkodás, ezek a módszertanok alapján próbálnak mindenkiből kis coding monkey szerűséget csinálni pedig szükség van arra, hogy valamennyire átlásd a dolgokat, hogy hosszú távon is legyen értelme annak amit csinálsz, márpedig az üzlet sem fog felszívódni 1-2 éven belül hanem jó esetben 5, 10 stb év után is stabilan szeretne élni...
    A bambano történeteit eléggé át tudom élni, a konténer / api világ is erősen hangzatos manapság de amikor feltettem pár kérdést, hogy de hát emezt meg amazt hogy oldjuk meg a konténerben ki fog foglalkozni vele mert eddig inkább ops lett volna most a fejlesztői csőből folyik ki, erre meg pingvinezés volt a válasz. Ja értem, hogy ettől gyors.

    p.s. nem vagyok se fejlesztő se üzemeltető csak van szerencsém látni pár területet.

    [ Szerkesztve ]

    -= QFR mx blue / HPE87 mx brown / QFR mx red / Poker 2 mx blue / Poker 3 mx clear / Leopold FC660M mx silent red=-

  • bambano

    titán

    LOGOUT blog

    válasz emvy #9 üzenetére

    de, csak én magyarul :P

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • ZnVjaw0K

    tag

    válasz bencze #12 üzenetére

    Az biztos, hogy sok a kókler. Pont emiatt is van a sok módszertan (a kóklerek jelenléte termelte ki) és pont emiatt is hiszik a managerek, hogy a sok módszertan majd megvéd, úgyhogy nyugodtan lehet kóklereket alkalmazni. Voltam olyan környezetben is amiről te írsz. Ez konkrétan az architekt és a project manager hiánya (vagy a tökeik hiánya). Olyan is volt, hogy felső utasításra (micromanagement) kellett szétgányolni a terméket. Azért ha bizinyos alapszabályokat betartunk és betartatunk(ez az, ami igazán nehéz), akkor lehet jól is csinálni. Professzionális környezetben megvan hogy kinek mi a feladata. Az ops-ost nem kell sajnálni azokért amiket írsz, hiszen pont ez a feladata. Ők ezt választották, ezt élvezik. Ha a felelősök töketlenek és emiatt a dev feladatát is részben az ops kénytelen csinálni, az cumi. Mint ahogy az is, ha az ops feladatát részben vagy egészben a dev-nek kell csinálni. Pont erről írtam amúgy.
    Én se sarat akarok dobálni, csak jelzem, hogy foglalkozzon mindenki azzal, amihez ért. Mindenhez nem lehet érteni. Abból születnek csak az igazi kóklerek.

  • bambano

    titán

    LOGOUT blog

    válasz bencze #12 üzenetére

    "Értem, hogy ez az egész abból ered, hogy az üzlet szeretne gyorsabban, olcsóbban haladni": nem. az üzlet üzletet szeretne kötni. erről szól a történet, hogy ha nincs buzzword, nincs valami hangzatos fícsör, amit marketingelni lehet, akkor senki nem veszi meg a következő verziót. se a konténerből, se a cloudból, se semmiből.

    pontosan ugyanaz a probléma az üzemeltetés környékén, mint az xp. a júzerek elsöprő többségének elég volt az xp, és lehet, még ma is elég lenne. ehhez képest keresztültapostak rajtuk egy vistát, egy w7-et, egy 8/8.1-et meg egy 10-est. ebből a pistát meg a 8.x-et simán ki lehetett volna hagyni. de akkor bizonyos cégnek meg a disztribútoraiknak nem lesz meg az év végi pulykapénz. tehát ki kell találni valamit, amitől a nagyobb vevők a zsebükbe nyúlnak. de ahogy halad az idő, úgy egyre kevesebb dolog maradt, aminek értelme/haszna is van, tehát minél nagyobb dolgot találnak ki, az annál nagyobb valószínűséggel ökörség. most nem kipécéztem az ms-t, csak szemléltettem vele. ugyanez igaz az összes cloud szolgáltatóra, meg a többi köztesszoftver árusra.

    meg azt hallani, igaz, csak olyanok szájából, akik konténert fejlesztenek, hogy ha nem tudsz két perc alatt 100 ezer node-ra deployolni, akkor itt az armageddon és éhező gyerekek fognak hullani az égből. miközben ha kihagynák a szemetet a rendszerből, lehet 200 node elég lenne ugyanarra az ügyfélélményre...
    mesterségesen feltekert igények ezek.

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • dabadab

    titán

    válasz ZnVjaw0K #10 üzenetére

    "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."

    Pont erről szólna a devops, hogy a mindent kézzel hekkelgető öreg szakik helyett az üzemeltetést (pontosabban az üzemeltetés automatizálását) is tekintsük szoftverfejlesztési feladatnak, hogy ott is minden olyan legyen.

    DRM is theft

  • bencze

    senior tag

    válasz ZnVjaw0K #14 üzenetére

    Hát mivel az volt a mantra, hogy az IT csak kiszolgálja az üzletet így sokszor az ops olyasmit vesz át amit régen bottal sem piszkált volna meg (dokumentált, rendesen tesztelt, kész dolgokat). Van olyan, hogy valami úgy van összerakva, hogy üzemeltethető meg van olyan, hogy nem igazán, az előzőhöz több idő kell de mindenki az átadást várja aztán megy más irányba, a megígért dolgok, hogy majd utólag tutibecsszó ritkán szoktak megvalósulni. Tudom, ez PM meg szerződés meg kötbérezés is befolyásolhatná de a PM is csak a fejlesztési ciklusban érdekelt, utólag mindegy mi lesz csak induljon el és onnantól nem az ő problémája. Amit én látok az az, hogy ezeket devops meg agilis meg cd-vel magyarázzák meg. Ahol elég nagy a komplexitás ott az a baj, hogy vagy csökken a minőség, vagy drágább lesz az üzemeltetése, vagy néha valami nagyobb cirkusz van amikor 1-2 embert kirúgnak aztán megy tovább minden ahogy eddig. Devopsban mintha a jómunkásemberek lennének azok akik a leginkább ki tudják találni egyébként okosba', hogy mit hogy csináljanak, mert a ppt-ket lóbáló menedzsmentnek sokszor a bulletpointokon túl fogalma sincs mi legyen.

    (#15) bambano
    Üzleten a megrendelői oldalt értem nem a szolgáltatót amit esetlegesen igénybe vesz a cég. Az más téma, járnak haknizni a felsővezetéshez mindenféle színes szagos dolgokkal és mindegyre eladnak valami nagy dolgot. Irtó korrupció szaga van néha egyébként, nem bírom eldönteni, most kajakra megkentek valakit vagy csak ennyire hülyék...

    ebből az jön le, hogy egy cinikus pöcs vagyok, azért az is lehet, pedig istenbizony látok jó dolgokat is ezekben az új buzzwordökben csak valahogy az implementálásuk jellemzően többnyire siralmasra sikeredik. de alapvetően nekem is unalmas lenne a munkám ha semmi nem változna szóval hajrá

    [ Szerkesztve ]

    -= QFR mx blue / HPE87 mx brown / QFR mx red / Poker 2 mx blue / Poker 3 mx clear / Leopold FC660M mx silent red=-

  • emvy

    nagyúr

    válasz bambano #15 üzenetére

    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++;

  • bencze

    senior tag

    válasz emvy #18 üzenetére

    ez alapján a konténer ugyanaz a fekete doboz amit régen appliancenak hívtak. nem kell integrálni semmivel meg foglalkozni vele csak lerakni és kész. :) addig jó amíg nem kell n=100 fekete dobozt üzemeltess. tudom tudom, nem kell hozzányúlni elketyeg magától...

    [ Szerkesztve ]

    -= QFR mx blue / HPE87 mx brown / QFR mx red / Poker 2 mx blue / Poker 3 mx clear / Leopold FC660M mx silent red=-

  • bambano

    titán

    LOGOUT blog

    válasz emvy #18 üzenetére

    "Kontenereket egyszerubb deployolni, mint .deb fajlokat peldaul.": .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.

    Az összehasonlításod érdekes: feltételezed, hogy vlanokat kézzel fog csinálni a rendszergazda, miközben a docker swarm az meg csak úgy ott van. a múltkor is mentem a szerverszobába, oszt dikkmá, egy docker swarm...

    "Most miert lenne jo nekem, ha nem kontenerrel csinalnam?": mert akkor csak konténert, swarmot, chefet, meg ansible-t nem kell megtanulnod, telepítened, üzemeltetned, debuggolnod, frissítened, stb. ha nekem applikációt kellene frissítenem, pont elég lenne kiharcolni az app frissítési ablakát, nem akarnék még docker frissítési ablakért is kardozni.

    "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.": értem, tehát szerinted ez a két véglet létezik, hogy vagy swarmban két sor (mellesleg: a swarmnak is kell hardver konfig, ha nem úgy van összerakva), vagy pedig öt nap? és biztos nincs arany középút, ahol swarm nélkül is automatizálva van az ilyen, és működik rendesen?

    szerk: ja, és a biztonság meg a konténer szavakat ne írjuk már le egy lapon belül please.

    [ Szerkesztve ]

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • ZnVjaw0K

    tag

    válasz dabadab #16 üzenetére

    Igen, ezt értem, de jelenleg nemhogy a módszertan, hanem az eszközpark sincs meg hozzá ops oldalon. Egész más eszközök vannak, ezek használatához egész más jellegű tudás kell. Szép és jó, hogy valaki kitalálta, hogy ezt a dev a saját területén már megoldotta, ezért oldja meg itt is ő, igen ez tök logikus és mindenkinek jó, csak a dev szopik:D Szívesem csinálnék devops-ot, miután ez a folyamat végbement, addig nagyon keserves. És ez hosszú évekig tartó folyamat lesz. Szterintem mindenki takarítsa el a saját székletét. Ne más szakmától várjuk, hogy megoldja helyettünk, hanem tanuljunk tőlük és oldjuk meg magunk! Biztos van is olyan, aki ezt a tanítást önként vállalná (talán akkor még hatékonyabb is lenne), de ne erőltessük már rá minden dev-es re (legalábbis amíg a gány meg nem szűnik. Akár öreg szakik, akár az ő filozófiájukon nevelkedett fiatal gánymesterek műve).

  • emvy

    nagyúr

    válasz bencze #19 üzenetére

    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++;

  • bambano

    titán

    LOGOUT blog

    válasz ZnVjaw0K #21 üzenetére

    "de jelenleg nemhogy a módszertan, hanem az eszközpark sincs meg hozzá ops oldalon": helyesen: te nem láttál még ilyet.

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • emvy

    nagyúr

    válasz bambano #20 üzenetére

    > .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

    válasz bambano #15 üzenetére

    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

  • ZnVjaw0K

    tag

    válasz bambano #23 üzenetére

    Ha kicsit visszaolavsol, akkor láthatod hogy pont láttam, éppen ezért írom.

    szerk: de a kedvedért és a finomabb fogalmazás kedvéért helyesbítek: épp kiforrás alatt van az eszközpark.

    [ Szerkesztve ]

  • emvy

    nagyúr

    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++;

  • emvy

    nagyúr

    válasz frescho #25 üzenetére

    > 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++;

  • frescho

    addikt

    válasz emvy #28 üzenetére

    Lehet. Lehet S3. Csak soha nem fogja hozni egy szerverbe becsavarozott PCIe kártya teljesytményét. Maga a swarm és k8s viszont nem építi fel helyetted replikákat és intézi a backupot. Üresen képes lehet erre, de van egy pont ami felett nem optimális. Amire igazán jó az az automatikus skálázás és nagy tömegű eldobható instance felhúzása.

    bambanonak abban igaza van, hogy a k8s infrastruktúrát is üzemeltetnie kell valakinek. A gépeket meg kell rendelni, kell hozzá áram, rack, hálózat. Fel kell húzni az alap rendszert, integrálni kell a clusterbe. De a storage sem ugrik csak úgy elő a semmiből. Szóval a devopshoz az addigi opsra ugyanúgy szükség van, csak kicsit másként.

    https://frescho.hu

  • sh4d0w

    nagyúr

    LOGOUT blog

    válasz Geller72 #11 üzenetére

    Ez arr való, hogy egy embert kelljen fizetni kettö helyett.

    https://www.coreinfinity.tech

  • #45997568

    törölt tag

    válasz frescho #29 üzenetére

    Elbeszeltek egymas mellet, csak mert bambano elbagatelizalja hogy az o ervelese legyen "helytallonak" tuno...

    Ugyanazt a feladatot tobbfelekeppen is meg lehet oldani. Van aki a szokvanyos hagyomanyos helyi szerverparkot reszesiti elonyben, van aki a publikus felhot, van aki a hibridet, tok mindegy.

    Tavaly aprilisban mentem at egy kis ceghez felhoben devops-ot csinalni, egy honap utan automatizalva volt a fejlesztesi folyamat, 3 kornyezet futott: Dev- Uat - Prod.
    A fejlesztoknek egy dologra kellet koncentralni, kodolni. Nekem egy dolgom volt, az infrastruktura mukodjon minel megbizhatobban. Egy honap utan 0 kezdo befektetessel (infrastruktura szempontjabol) nyereseget termelt a csapat.

    Ugyanezt a korabbi cegemnel maskepp csinaltak. Jott egy otlet aprilis magassagaban hogy le kellene cserelni a szervereket. 2-3 honap keresgeles utan kivalasztottak egy Hyperflex-et, storage-ok, routerek..., elkezdtek az engedelyezesi folyamatot, par honapra ra elfogadta a vezetoseg, el lehetett kezdeni a szervertermet felujitani, majd megrendelni a cuccot, kozben beszerezni a licenszeket, es a meglevo szoftverkornyezet atultetesenek a tervezeset... amikor egy evvel kesobb eljottem, akkor lett osszerakva a cucc, kezdtek a teszteket es kozben kiszortak az egeszre 1 millio £-ot. Okos. En ezt hivom maradinak, rossz tervezesnek, es az eroforrasok rossz kihasznalasanak. Azt a szervert kinovik par ev alatt, kezdhetik az egeszet elolrol...

    Amikor megkerdeztem hogy gondolkodtak-e felhoben, akkor annyit mondtak ra, hogy nem, szeretik a jol megszokott dolgokat. Par hetre ra felmondtam, azota is boldogan letezem a publikus felhoben, a "szakik" hasznaljak csak a jol megszokott dolgaikat, kozben a vilag meg szepen elmegy mellettuk.

    Mi csapatban dolgozunk, mindenkinek megvan az erossege, van aki Linux Guru, van aki Kubernetes-kontenerek vilagaban jeleskedik, vannak Python-Bash guruk, en foleg automatizalasban es infrastruktura telepitesben jeleskedem (terraform) meg architect feladatokat csinalok. A korabbi helyemen a rendszert amit epitettek 3-an csinaljak, talan mar termelnek vele valami penzt is :DDD . Mindekozben tobb automatizalt rendszert szortam ki, teljes networkingel, szerverparkkal, storage-okkal, CI/CD, clusterek, k8s...

    Amivel beljebb vagyok, nem csak egy reszet latom annak teruletnek amit tamogatnom kell, hanem az egeszet. Elejetol a vegeig. Latom hogy mihez kell hozzanyulni hogy javuljon a hatekonysag, a nyeresegesseg, ne dogoljon meg a "melos" es kozben jol szorakozzunk.

  • frescho

    addikt

    válasz #45997568 #31 üzenetére

    Kiszerveztétek a vas beszerzést, üzemeltetést és még sok mást, ezeknek az SLA-ját is mástól várjátok el.

    Ez jó döntés is lehet. A lényegre tudtok fókuszálni és rugalmasan fejlődni. Kis forgalom, kevés bevétel mellett a kiadás is alacsony, jobb a méretgazdaságosság.

    De van amikor security vagy más szempontok miatt ez nem éri meg. Kezdődhet onnan, hogy ti magatok vagytok a cloud szolgáltató. Az is lehet, hogy szerződési kötelezettség az adatok házon belüli kezelése. Végül lehet, hogy a cloud szolgáltató csak egyedi ajánlatként tud megfelelő teljesítményű gépet biztosítani kb 3x áron 2 hónap átfutással.

    Szóval mindennek meg van a maga helye, nincs üdvözítő megoldás. Nállunk van több tucat cloudban futó mikro service ahova nem kerülhet ki csak anonimizált adat, private cloud és igazi monolitikus saját adatközpont is az érzékeny adatoknak.

    https://frescho.hu

  • #45997568

    törölt tag

    válasz frescho #32 üzenetére

    Persze, ezert mondom, adott feladatra kell a legjobb megoldast talalni.

    On prem, hibrid, vagy publikus felho. A rugalmassagon van a hangsuly, a rugalmatlanok hamar eltunnek.

  • oszi666

    őstag

    válasz bambano #5 üzenetére

    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

    válasz bambano #23 üzenetére

    Nem szoktam hónapokkal később meddő vitákra reagálni, de ez a frusztráltság ami belőled árad öregem... :Y
    Remélem egyszer találkozol olyan cloud megoldással, amire mégiscsak azt mondod, na ez jobb így...hiszen ahogy te is utaltál rá, nem minden fekete és fehér.

Új hozzászólás Aktív témák