[Videó] Kubernetes: miért, mikor, hogyan?

HUP

Szabó Dávid (LeanNet)

A Kubernetesről olyan híreket lehet olvasni, hogy "a jövő platformja" vagy "a következő Linux". Nyugaton már rengetegen használják éles környezetekben is, ugyanakkor itthon egyelőre leginkább csak általános érdeklődés és a teszt környezetek jellemzőek. Ez az óvatosság jórészt annak köszönhető, hogy számos előnyét csak komoly, IT stratégiát érintő szemléletváltás mellett lehet kiaknázni. Ahhoz tehát, hogy biztonsággal átléphessünk a tesztből az éles környezetekbe, muszáj feltenni a következő kérdéseket: "miért", "mikor" és "hogyan" alkalmazzuk a Kubernetes-t?

(A videó az IC Enterprise Technologies meetup-sorozat 2020. december 10-i, Kubernetes mindenkinek? című állomásán készült.)

( dotnetlinux | 2021. 03. 08., h – 13:26 )

Izgalmas, megnezem a videót, erdekel. Meg ha a nagy reszet ismerem is. Majd kiderul :) 

( p2pking | 2021. 03. 08., h – 16:12 )

Oreg vagyok mar ehhez es ha annyiszor 100k t kernek fizetest amennyiszer ezt toltak az arcomba, akkor egy ev utan nem kellene a maradek eletemben egy fuszalat sem megmozgatni.

Oke, igy sem kell sokat, ha nem akarok.

Majd szanok ra idot egy ev mulva ha lesz meg valahol akkor talan erdemes egyebklent megy a 99% melle.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

Tok ertem, amit irsz. Ahogy en latom, ez a technologia itt van, es itt lesz 3 ev mulva is, mibol gondolom? Kontenerek nem fognak egyhamar elmenni, es a Kubernetes megnyerte az elso csatat a kontener orhesztracios teruleten. Az alternativai kozeleben sincsenek, Yarn, Mesos, Swarm, Nomad, Rancher 1.0??? Ezek kozul melyiknek van eselye lenyomni. Meg a Nomad a legigeretesebb, de annyira mast celoz, es annyira lightweight, hogy osszehasonlitani is nehez. Szoval vagy van valakinek a tarsolyaban egy titkos jobb megoldas, amit meg tud marketinggel tolni es 2-4 ev alatt talan lesz valami, vagy meg csak most allunk neki az ujat kitalalni, akkor meg 5-7 evrol beszelhetunk also hangon.

 

A masik, hogy - es lehet zseni vagy, akkor ne vedd magadra - aki egy ev mulva nekiall megtanulni valamit, amit evekig tart megtanulni, ugy, hogy evek ota letezik a technologia, az vajon mennyit veszit a versenykepessegebol (nyilvan ha ezen a teruleten akar dolgozni)? A forditottjat tapasztalom, egen foldon ehhez erto embert keresnek, es meg ha rovidtavu is a siker azert jo benne lubickolni. De nyilvan ez teljesen szemelyes preferencia, en szeretem tolni a "living on the cutting edge" dolgot, es hat benne van neha, hogy belefutok valami zsakutcaba.

Coding and ADHD should be best friends

Az alternativak reszhez hozzatennem meg a kovetkezoket:

- docker swarm deprecated felhivatalosan (2019-ben kijelentettek hogy meg 2 evig lesz, utana nem biztos)

- rancher 1.0 mar reg deprecated, az uj foverzio rancher 2.0-ban pedig kidobtak a sajat orchestration layer-juket (cattle) es csak kubernetes support van benne, szoval a rancher is kubernetes alapu lett

( tornai | 2021. 03. 08., h – 21:10 )

Szerkesztve: 2021. 03. 08., h – 21:14

Önmagában jópofa lenne, de az átlag banki slendrián módon összekókányolt rendszer kezelhetetlen, fejleszthetetlen, tesztelhetetlen pokolfajzattá vált már így is és ezt hangos üdvrivalgás közepette a digitális transzformáció jegyében hozzánemértő szakértők 4 storypontért beleerőszakolják mindenféle kubernetesbe, openshiftbe, minishiftbe, akármibe... és az a konfig megy élesbe amivel először elindult az egyik csütörtök, sprintzárás előtti este A Rettenet.

Nem egy újabb eszközzel, technológiával, akármivel fogjuk rendbetenni a dolgokat... persze könnyebb egy hamis ígéretet eladni a managereknek, döntéshozóknak, mint a valóságot.

Kicsit azert arnyalja a kepet, hogy nem csak ilyen projektek leteznek. Es amugy ez a fajta hozzallas pontosan a szakertelem nelkuliseget reprezentalja, amirol aztan rohadtul nem a technologia tehet. Ha valaki szerint az ember eletet konnyebbe teszi egy dolog, aminek a kezikonyvenek a boritojara ra van irva az, hogy "ezt csak akkor csinald, ha nagyon tudod mit csinalsz! De komolyan", az egy idiota. Mar bocsanat. A Kubernetes rohadt bonyolultta teszi a dolgokat, es meg azt se merem kijelenteni, hogy legalabb tokeletesen szabvanyositott, es reprodukalhato bonyolultsag :D

Es itt jon a DE! Amikor el akarod erni a hasonlo funkcionalitast; RBAC, isolacio, process security, network policies, resource limitek, load balancer, failure detection, stb. Az is bonyolult lesz, csak maskent. Ott majd kepbejon X szamu megoldas, amiknek tokeletes osszhangban kell egyutt dolgozni.

 

A konnyebbseget az adja, hogy itt az alkalmazas melle odateszel par manifestet, ki kivel beszelhet a halon, kinek milyen capabilityjei vannak, ki mihez ferhet hozza, kivel mit shareljen, mennyi eroforras engedelyezett, hogy legyen a service kiajanlva, hogy menjen a rolling upgrade, es hasonlo nyalanksagok, buildelsz egy imaget es apply. Akar abba az egy szem namespacebe, amihez jogod van.

Innentol az alkalmazas fejlesztok, akik ertenek az alkalmazashoz le tudjak irni az infrastrukturat, az uzemeltetok, akik meg ertenek az uzemelteteshez tudnak adni egy platformot. Es igen, ez a budos nagy helyzet, hogy itt az egyik tabor masik *val veri a csalant :D

Coding and ADHD should be best friends

Kubernetes / konténerek (és előtte az 1-feladatos VM-ek) előtt ez úgy nézett ki, hogy a fejlesztő elkészített egy "HA" webappot, amit teszteltek valamilyen "fejlesztői" környezetben, majd azt .tar.gz-ben odalökték az üzemeltetésnek, akik megpróbálták "productionben" életre lehelni. Ha 3 userrel bírta a terhelést, akkor ment ki élesbe. Aztán az első kicsit nagyobb terhelésen megfeküdt az egész (tisztelet a kivételnek), a fejlesztők és az üzemeltetés meg néztek, hogy mi van.

Ma ez úgy néz ki, hogy az üzemeltetés (ma már devops) olyan automatizált rendszert tud gombokért összerakni bármelyik cloud szolgáltatónál, ahol az alap HA tesztesetek + terheléses tesztek lefuttathatók és hiba esetén visszalökhetők a fejlesztőknek extra kézimunka nélkül. Funkcionális / architektúrális hibák ettől még vannak / lesznek, de a szint, amit el lehet érni óriási befektetések nélkül, az sokkal magasabban van.

“az üzemeltetés (ma már devops)“

Azért ezt nagyon ne mossuk össze, a legtöbb, pláne nagy helyen ezek bőven külön vannak szerencsére, van devops, de a klasszikus üzemeltetést békén hagyják és leginkább nincs semmiféle átfedés a feladatokban.

Igen, halistennek a klasszikus sysops uzemeltetesre nincs szukseg k8s kornyezetben, ugyhogy nem tudnak semmit elkurni meg takolni ssh-n keresztul ugy hogy utana soha senki nem bogozza ki mi van manualisan, dokumentalatlanul megpatkolva.

3 eve mikor a mostani ceghez kerultem itt is az volt a procedura hogy a devek emailben kuldtek a .jar file-okat a sysopsnak akik bash scriptekkel masolgattak ki a szerverekre :) Ettol mostanra eleg messze kerultunk :) Docker, microservices, k8s.

Terraformbol felhuzzuk a k8s clustereket xy felhoszolgaltatoknal es orulunk. Mostanra legtobbjuk kinal managed cluster-t olcson ugyhogy nem kell szivni a control plane-el, a worker node-ok autohealingelnek autoscaling-en keresztul, a node protectiont meg elvegzi eviction-el a kubernetes sajat maga ha rendesen van bekonfiguralva a kubelet.

( bazso | 2021. 03. 09., k – 05:55 )

Szerkesztve: 2021. 03. 09., k – 05:56

Nem értem ezt a negatívizmust a hozzászólásokban. Azzal a managgák is tisztában vannak, hogy bármely eszköz esetén igaz a "shit ín, shit out". Egy platform menedzser eszköz nem oldja meg, ha dilettáns akár a fejlesztő, akár az üzemeltető. De azt igenis megoldja, hogy egyiknek se kelljen mindenhez is érteni. 

Az a fejlesztő, aki sprint zárás előtt kezdi cipőkanállal konténerbe rakni az alkalmazását, az valószínűleg notepad-ben is írja a programot és nem hallott verziókezelőről sem. Ennél jobb fejlesztő támogató eszköz nem sok van - egy parancs és ott van egy olyan környezet, amire korábban hetekig kellett könyörögni egy komplett IT osztálynak. Mindezt akár a fejlesztő eszközből szerkesztve, konfigurálva és futtatva. Nem, a VM template nem ugyanez. A konfiguráció menedzsment eszközök betanulási ideje rosszabb, és ott mélyen érteni kell mihez is piszkál hozzá. Talán a Vagrant járt a legközelebb ehhez az egyszerűséghez fejlesztői szemmel, de az meg az üzemeltetőnek nem segített.

És ellenőrizni is könnyebb az élesítéskor, mert a fejlesztő nem tud kihatni a futtató környezetre. Nincs a "de hát deven még ment" pingvinezés.

Ja hogy tanulni kell hozzá, az igaz. De akinek ez fáj az IT-ban, az rossz szakmát választott.

Azzal a managgák is tisztában vannak, hogy bármely eszköz esetén igaz a "shit ín, shit out".

Sajnos ez nagyon nem igy van. Megszamolni sem tudom, hogy hany olyan meetingben ultem az elozo munkahelyemen (telko), ahol a managerek valtig allitottak, hogy marpedig a Kubernetes megoldja minden uzemeltetesi problemajukat, mert akkor mar nincsenek oprendszer upgradek. Nekem kellett elmagyarazni nekik, hogy hallo, a kontener imageket is kene neha frissiteni.

Mint olyan, akinek az a foallasa es hobbija is, hogy a Kubernetes kodjat simogatja, sajnos atlagon feluli a botranyosan szar kod mennyisege. Ez reszben az orult fejlesztesi temponak es a kontributorok szamank koszonheto, de reszben annak is, hogy az ebbe belefejleszto emberek nem elhanyagolhato resze nem a "clean code" vilagbol jott.

Ez igy is van, mert onnantol hogy docker van a fejlesztok felelossege frissiteni a container image-et, nem az uzemeltetese :)))

Viccet felreteve mivel a fejlesztok valasztjak ki mi a base image, ugyhogy ok is felelnek erte hogy a release-ekbe ne csak feature-k keruljenek bele hanem tartsak a lepest a base image teren is.

Raadasul mostanra a normalisabb kontener registry szolgaltatok (aws, docker) alapbol csinalnak security check-et a feltoltott image-eken, egybol lehet latni ha valami serulekenyseg van.

Netán akkor képzést kéne nekik nyújtani; ha már sikeresen rá lett lőcsölve az üzemeltetés egy része is a fejlesztőkre, meg ugye az adatbázishoz is értsenek, meg a business domainnel is legyenek tisztában, meg írjanak automata teszteket is, mert csak manual teszter van a csapatban, stb.

A fejlesztő mindenhez _is_ ért. De azt nem az ujjából szopja ki: ha érdekli, megtanulja magától, ha meg rá lett tolva az a felelőség is, mert pl. a sysadminok képtelenek normálisan üzemeltetni egy alkalmazást / kommunikálni a fejlesztő csapattal, akkor legalább annyit lesszivesek megtenni, hogy a saját szarjukat elmesélik a fejlesztőnek, hogy tudják, hogy mi is az épp aktuális extra feladat, amit nekik kell elvégezniük, mert a többiek képtelenek azt normálisan csinálni / költségoptimalizálás van és nincs rá ember.

+1

A "java fejleszto" az java-ban ir programot, a JVM finomhangolasaval bezarul az o feladatkore. Az, hogy holnaptol az image-et is neki kell szolgaltatnia es karbantartania, az hatalmas paradigma valtas, nagyon sok mindent kell megtanulnia az "xyz fejlesztonek", hogy ne lyukas, kokany image-eket adjon at. Lehet ezt szepiteni, de ra lett tolva az uzemeltetes egy resze a fejlesztokre.

Nekem ezzel semmi bajom nincs egyebkent, java fejlesztokent szivesen elfogadom azt a penzt, amit korabban az uzemeltetonek fizettek az ennek megfelelo tevekenysegert. 

Mivel a fejlesztok altalaban minden lehetseges modon megkeseritik az uzemeltetes eletet a kismillio dependency-jukkel, soha semmit nem lehet frissiteni mert osszeszarja magat az alkalmazasuk amiben hardcode-olva vannak a fuggosegek, tisztan environment security miatt torteno frissites tesztelesere soha nincs idejuk/eroforrasuk mert minden mas fontosabb, stb. igy en teljesen jogosnak latom hogy akkor mostantol ez az o problemajuk es ok lesznek erte seggberugva.

Ertelemszeruen nem kell ehhez mindenkinek erteni, de azert minden teamben ildomos hogy legyen egy lead/architect fejleszto aki keres annyit hogy elvarhato legyen tole hogy az environmentet is ossze tudja rakni.

Ha nem kell semmi bele csak java -jar fut akkor ugyse lesz vele gond, hasznaljon egy alap openjdk image-et es mindig release-kor gyozodjon meg rola hogy a legfrissebbet hasznalja, es problema letudva. Ha meg telebassza minden szarral az image-et akkor ne varja hogy utana annak a frissentartasa a mas felelossege legyen (amit o raadasul aktivan akadalyoz).

Ott valaki nagyon lemaradt 5-10 évvel ezelőtt. Manapság már nem divat java -jar-ozni, Fat/Uber/Executable jar a menő. Vállalkozó kedvűebbek esetleg GraalVM Native Image-t is használhatnak. Security szempontból az OWASP dependency checkerje megoldja, hogy a dependency-k up-to-date-k legyenek.

De még ha a régi iskolával is megyünk: kismillió dependencyvel az üzemeltetésnek nem is kellene/szabadna foglalkoznia: a build pipeline lerántja a dependencyket, majd felépíti a Docker image-t. Ebben az esetben az üzemeltetésnek csak annyit kell tudnia, hogy a build/*(?) könyvtárat át kell másolni a konténerbe - a class-pathra - automatizáltan, build time alatt. Gondolom ez nem egy megugrohatatlan feladat egy üzemeltetőnek, de láttam én már karón varjút. Valószínüleg nem is a képesség hiánya, hanem a lustaság/nemtörődömség miatt nem akarják ezt megcsinálni, megérteni. Hiszen Ők üzemeltetők, hagyják már őket a fejlesztői feladatokkal, hát milyen dolog már az, hogy interdiszciplinárisan kéne dolgozni. Megáll az ész, komolyan!

Szerencsére ezt a management is észrevette, így rátukmálta a build pipeline, release pipeline, a konténerizáció, a skálázódás, a monitoring, stb. feladatköreit a fejlesztőkre, akik képesek és nem lusták a rájuk bízott dolgot elvégezni. Sysadmin szemszögből ez jó is és rossz is.

Jó, mert végre nem idegesítik őket a fejlesztők a szar appjaikkal, amik végeredményben mégiscsak a béreket termelik meg, ehelyett simán legózhatnak a szerverekkel naphosszat, hiszen ők arra szerződtek, ők azt szeretik, fene akar a fejlesztőkkel is kommunikálni, hát ahhoz people-skills is kéne, ami meg nincs.

Viszont rossz, mert ez egy egyirányú utca. Egy alkalmazás-fejlesztő szükségből könnyedén meg tudja tanulni az üzemeltetés rá eső részét, és ha kelletlenül is, de megcsinálja, mert ezt kívánja a haza cég érdeke. Egy sysadminnak már sokkal nehezebb dolga lenne, ha ő akarna váltani és kicsit T-shaped-dé válni, ld. fentebb, hogy egy alkalmazás fejlesztő élete nem csak játék és mese, nagyon komoly és egyre kiterjedtebb tudással kell rendelkeznie, ha meg akar maradni a piacon / szeretne előrelépni a ranglétrán.

Ahogy _zb_ írta fentebb, egy devOps szemléletű fejlesztő már most komolyan keresett a piacon, és ugyan nincs pontos, naprakész adatom, de valószínüleg jobban is keres, mint egy átlag sysadmin (vagy mondjuk egy átlag fejlesztő, megemlítve a korrektség kedvéért). És ez az olló csak nyílni fog köszönhetően annak, hogy a cégek jó része szereli lefele a saját Data Centerjeiket, mert cloud-native alapon költöznek az AWS/GCP/Azure managelt platformok valamelyikére. Egy fejlesztő könnyedén felskilleli magát a legújabb hipiszupi cloud technológiából, míg egy sysadmin sokkal nagyobb bajban van, mert az alkalmazás-fejlesztést, az összes többi rálőcsölt extra felelősséggel együtt nem lehet egy 3 hónapos online trainingen elsajátítani.

Ehhez még vegyük azt is hozzá, hogy ha egy fejlesztő nem csak backend/devops szemlélettel, hanem esetleg full-stack tudással rendelkezik, akkor a lehetőségek tárházával néz szembe a munkaerő piacon.

Egy szívfájdalmam van, hogy historikus okok miatt a full-stack az általában web-frontend-et takar (a régi szép idők, mikor a weboldalt még a szerver renderelte és nem a kliens), ami engem nem mozgat. Sokkal jobban érezném magam egy iOS/macOS frontend + devopsy backend role-lal, ahol az app egész lifecycle-je ténylegesen egy kézben/csapatban összpontosul.

És ebben a jövőképben sajnos nem sok igényt látok régivágású sysadmin skillekre...

Igen, nalunk is a devops szemleletu fejlesztok, akik konnyeden felskilleltek magukat a cloud technologiabol csinaltak olyanokat hogy minden env-en minden egyes deploy utan uj persistent volume-ot kert az app, aztan 1 ev mulva talaltunk havi 80.000 dollarnyi unattached ebs volume-ot. Meg amikor minden fejleszto sajat loadbalancert inditott a service-nek, es hipphopp lett 250 db loadbalancer attache-olva egy darab envben egy darab K8S clusterhez mert pechjukre ezt dobta ki a stackoverflow es nem az ingress controllert. Es meg sorolhatnam orakig az elmult 7 ev tapasztalatat sysadminbol jott devopskent.

Egyebkent a kommented tokeletesen tukrozi a helyzetet: A fejlesztok jo resze kurvara onelegult es arrongas, mert "ok termelik a penzt" (ami termeszetesen nem igaz, mert az a sales meg a marketing, hany milliard olyan app van a vilagon ami nem kell a kutyanak sem ugye?), ok konnyeden fel tudjak magukat skillelni uzemeltetesbol (ami megint csak nem igaz mert orbitalis baromsagokat csinalnak biztonsag, rendelkezesre allas, koltseghatekonysag szempontjabol).

Az altalad felvazolt screnario a mindenre (is) jo fejlesztokrol meg az egyre haszontalanabb uzemeltetesrol tapasztalatom szerint az elso komoly betoresnel (mivel a fejlesztok nagyreszenek a security group related tudasa megall az "allow all 0.0.0.0/0"-nal) vagy az elso parszazezer dollaros nem vart AWS szamlanal megdol barmilyen managementnel.

A docker image es az abban levo env egyszeruen azert lett a fejlesztok felelossege mert a managementnek tele lett a toke azzal az ezereves dumaval hogy "az en gepemen mukodik". Ha annyi dollarom lenne ahanyszor en ezt hallottam az elmult 20 evben akkor meg Jeff Bezos is nalam kopogtatna penzert.

Idéznék fentebbről:

Netán akkor képzést kéne nekik nyújtani, ha már sikeresen rá lett lőcsölve az üzemeltetés egy része is a fejlesztőkre...?

Már ugye azért hozom fel ezt megint, mert úgy látszik, hogy a devOps/üzemeltetés még mindig ellenségként és nem kollégaként kezeli a fejlesztőket. Úgy tűnik, mintha a sysadmin azt hinné, hogy ő valami külön kaszt, aki nem ereszkedik le az alja nép közé (aka. "fejlesztők").

Vajon hogy történhettek meg az általad hozott példák? A sysadmin/devOps übermentsh közösség azt hitte, hogy ha lepasszolja az üzemeltetés egy részét a pórnépnek, akkor azzal már nem is kell foglalkozni? Hány standupon vagytok jelen, ahol felteszitek a kérdést: "srácok/lányok, lesz-e ma változtatás a környezetben? Tudunk-e segíteni"? Hány codereview-t nézett át az a csodálatos devOps csapat, hogy ilyen ne fordulhasson elő? Kötelező-e egy pipa a devOpsosoktól mielőtt kimegy élesbe az environmentet érintő változás? Ha igen, akkor hogy csúszhatott át egy olyan változtatás, ami 80.000 dollárnyi kárt okozott a cégnek? Ha nem, akkor miért nem? Tényleg évente csak egyszer néznek rá a magasságos devOpsosok a környezet statisztikáira? Nincs folyamatos monitorozás, hogy a fentebb említett diszkrepanciákat kiszűrjék? Miért nincs? Azt már meg se merem kérdezni, hogy készítettetek-e DSL-t a fejlesztők számára, hogy megkönnyítsétek számukra a karbantartást?

Miért nem vállal felelőséget a devOps az általa managelt dolgokért? Miért mindig a fejlesztőkre mutogatnak? Ha a fejlesztő lepasszol egy jar-t az üzemeltetésnek, akkor az a baj. Ha a fejlesztő saját maga bizergálja a környezetet, akkor az a baj. Az üzemeltetés legnagyobb szerencséje, hogy vannak az un. "fejlesztők", akikre folyamatosan lehet mutogatni, hogy eltakarják a saját hiányosságaikat.

Erről jut eszembe egy keserédesen vicces történet, melyben mint valaki aki a Payment Systemsben dolgozik, nem férhettem hozzá, nem is nézhettem rá a teszt/éles környezetek beállításaira (Docker adoptálása előtti idők). A kód "az én gépemen működött", teszt környezetben működött, productionben nem. Mondom a sysadmin/devOps kollégának, hogy ugyanmár nézze már át a konfigokat, mert lokálban megy, a teszt környezetben megy, élesben nem megy, ez nekem environmental problemnek tűnik. "Hát az nem lehet, a prod konfig jó, a kóddal van valami baj". Ez ment egy ideig, majd ugye debug a fejlesztői gépen, docker image készítése (hiszen a devOpsosok nem tudtak nekem egyet adni, mert hát akkor láthatnám a konfigot(!!) (szerintem csak lusták voltak)), stb, stb.

Mondanom se kell, ~1 hónapnyi debug után kiderült, hogy igen, a probléma nem a kóddal van; kiderült, hogy a prod environment félre lett konfigurálva, levágta a header nagy részét, így nyilván nem érkezett értelmes adat az appba.

A docker image és az abban lévő env egyszerűen azért lett a fejlesztők felelőssége mert a managementnek tele lett a töke azzal az ezeréves dumával hogy "a környezet jól van beállítva, a kóddal lesz valami probléma".

Szóval igen, a sysadminok/devOpsosok egy jó része kurvára önelégült és arrogáns, ami még nem is lenne akkora baj, de a tetejébe még lusták is. Lusták a fejlesztőkkel együtt dolgozni, fennhordják az orrukat, hogy "hát még ezt se tudja ez a barom", de fail-safe (vagy egyáltalán konzisztens) környezetet már képtelen beállítani. Lusták továbbképzést tartani. Lusták code-reviewolni. Lusták odamenni a fejlesztőhöz elmagyarázni és megkérdezni, hogy "figyu, ez a változtatás ezt és ezt fogja okozni, biztos hogy ezt akarod? Nem gond ha igen, csak gondoltam rákérdezek, mert észrevettem a legújabb changelogban".

Nem ártana, ha a sysadmin/devOpsosok leszállnának a magas lóról és elkezdenék cég más dolgozóit nem leküzdendő akadályokként, hanem esetleg kollégaként kezelni, lehet, hogy úgy hatékonyabb lenne az együttműködés, és sysadmin/devOps nemtörődömsége nem okozna 80.000 dolláros kárt a cégnek.

De, hogy ne csak a levegőbe beszéljek, itt egy példa a jó dev-devOps együttműködésre.

Én értem, hogy a sysadminból körülbelül így válik devOps, de azért nem ártana egy kis people-skillst is növeszteni, mert a sysadminok arroganciája és lustasága komoly veszteségeket tud okozni a cégeknek.

Elnézést, ha nagyon kevertem őket; mivel a jar átpasszolása is szóba került (bár már akkor is artifactory linkeket tettünk a release ticketbe) és legutoljára akkor kellett ilyet csinálnom, mikor a sysadmin és a devOps közt még nem volt akkora különbség, és a deployt leginkább a sysadminok csinálták, ezért vettem őket egy kalap alá. Természetesen azóta ez a két ág külön vált, bár nem tudom mennyire vannak sysadminok cloud-natív környezetben, az utóbbi időkben nálunk tribe specific devOps, meg coreDevOps volt.

Persze ahol még van DC, ott a sysadmin és a devOps külön válik; ezért nagyon nehéz a témáról beszélni, és a fentebbi kommentjeim is irgalmatlan általánosítások, mert cége válogatja, hogy hol milyen processzek vannak, milyen a vállalati kultúra, mennyire segítőkészek, vagy épp mennyire fújnak egymásra a kollégák.

Fent csak annyit akartam kifejezni, hogy az éremnek két oldala van, és sokkal jobb kollaboratívan együtt működni, mert az viszi előre a dolgokat, nem a bűnbak keresés ("no-blame culture"). Ehhez persze sok-sok türelem kell, hiszen az IT kiterjedtsége miatt nem mindenki ugyanolyan tudással, háttérrel, érdeklődéssel érkezett az adott pozícióba. Nagyon sok vak folt lehet egyének közt még ugyanazon pozícióban is, nem is beszélve arról, ha több különböző területről érdekezett kollégával kell együtt dolgozni.

Én se tudok mindent (nyilván) és a multidisciplinary teamek is azért lettek úgy kitalálva, ahogy, mert a fejlesztő nem érthet mindenhez olyan mélységben, amennyire az adott terület szakijai értenek hozzá. Egy agile team-ben ezért van a fejlesztőkön felül egy product owner, aki a business kívánalmakkal van tisztában, egy system analyst, hogy tudjon adatot szolgáltatni, vagy el tudja magyarázni a fejlesztőnek, hogy egy egy business process hogy is működik, egy tesztelő, hogy feltegye azokat a kellemetlen kérdéseket, egy devOps ember, hogy segítsen, amikor a dev teamnek elfogy a tudása; és ez még csak egy átlagos backend team. Ha frontend is szóba kerül, akkor kell egy designer, meg egy conversion analyst, meg még ki tudja hány fajta ember. Persze ezek egy része lehet több csapat közt elosztva, de a lényeg, hogy a devnek van kihez fordulnia, ha valami nem tiszta neki.

Az fejlesztők ezen szakemberekre támaszkodnak és emiatt a kommunikáció a különböző szakterületek közt nagyon fontos. Fent nyilván elég sarkos véleményt írtam a devOps(/sysOps) egészéről, de azt is látni kell, hogy ez mindkét irányba működik: a fejlesztő se szabad, hogy arrogáns legyen a szakikkal szemben, és ez fordítva is elvárható.

Nagyon sok empátia, türelem és segítőkészség kell ahhoz, hogy a modern IT rendesen tudjon működni. Rég elmúltak már azok az idők, mikor a magányos programozó/sysadmin/bárki leült egy sötét sarokba és átkódolta az egész napot anélkül, hogy bárkihez is szólt volna.

A mai IT (az elégséges technológiai tudáson kívül) legfőképpen kommunikációból áll. Beszélni kell ezzel, beszélni kell azzal, meg kell érteni, hogy mi a hasfájása; ha szorít a határidő és ideges, ha nincs elég tapasztalata a területben és 3x el kell neki magyarázni ugyanazt (lehetőleg minden alkalommal kicsit másképpen, hátha úgy megérti), stb.

Én nem vagyok sysadmin vagy devOps ellenes; találkoztam épp elég segítőkész kollégával, hogy tudjam, hogy ők is tudnak normálisak lenni. De valahogy még mindig kívülállók akár szervezeti felépítés, akár önmeghatározás miatt. Ha ilyen problémák vannak egy cégben, lehet érdemes lenne elmenni egyet sörözni (vagy fagyizni, ha a kollégák ilyen-olyan okokból nem isznak/ihatnak alkoholt*), ahol át lehet ezeket a dolgokat beszélni.

Szerintem senki se akar ellenségeskedni a munkahelyen, a probléma valószínüleg a kommunikációval van bármelyik oldalról.

 

*: egyik munkahelyemen (UK) felmondás után ugye jön a szokásos búcsúztató pub-sörözés. Mivel elég sok muszlim kollégám volt akikel együtt dolgoztam és kedveltem, ezért úgy küldtem ki az invite-ot, hogy itt és itt lesz sörözés; aki valamilyen oknál fogva nem szeretne ezen az eseményen részt venni, de szívesen elbúcsúzna, azzal délben elmegyünk a legközelebbi cukiba fagyizni egyet. Az érintett kollégák eléggé meghatódtak, mondták, hogy én voltam az első és egyetlen eddig, aki gondolt rájuk. Remélem azóta ez bevett szokás lett arrafele.

Ezuton szeretnek koszonetet mondani ezert a kommentedert, minden szavaval egyetertek.

 

 "De valahogy még mindig kívülállók akár szervezeti felépítés, akár önmeghatározás miatt."

Ez szerintem minden nagyobb/regebbi cegnel megtalalhato problema a "jo oreg" fejleszto vs. rendszergazda haboru miatt. Tapasztalatbol mondom hogy rettento kemenyen kell dolgozni erte a devopsoknak hogy ez megvaltozzon, de nem lehetetlen, es meg igy is mindig vannak emberek akiken nem lehet segiteni mert egyszeruen nem hajlandoak nyitni senki fele (mindket taborban).

Nalunk a paradigmavaltast az hozta el hogy nekem pl. szemelyes jobaratom 2 lead fejleszto/architect, a product VP + az o jobbkeze, a legnagyobb product teamunk directora. Es ok tudjak hogy az en devops csapatom mindig segit, mindig a megoldasra torekszik, mindig normalisan kommunikal. Igy amikor eleinte minket probaltak besarozni a regi fejlesztok akkor ez nem nagyon jott ossze egesz egyszeruen azert mert a key stakeholderek ismernek minket szemelyesen es tudjak hogy amit mondanak rolunk a hatunk mogott az egyszeruen nem igaz.

Viszont ha nincs egy ilyen eros management supportunk akkor nem tartom valoszinunek hogy ezt a mentalitasbeli valtozast vegig tudtuk volna vinni.

Megmondom neked pontosan honnan lett a havi 80k dollarnyi ebs volume: a fejlesztok kikoveteltek a managementnel hogy az adott AWS accounthoz full admin-juk legyen "mert ok anelkul nem tudnak dolgozni". Ertsd: nem tetszett nekik az altalunk bevezetett devops code review es az env jogaik korlatozasa mert "az lassitja a munkat". Megkaptak a full accot ("mert ok termelik a penzt"), ez lett az eredmenye. Mostmar nincs semmilyen joguk a kornyezethez, es mit tesz isten miutan a product VP megmondta nekik hogy vagy dolgoznak igy vagy mehetnek mashova erdekes modon rajottek hogy igy is tudnak dolgozni. Mellekesen nem sokkal kesobb (1 honap) a ket fo "a devopsok/uzemeltetes hulyek" hangado fejlesztot kirugtak, bar az igazsaghoz hozzatartozik az is hogy szerintuk alapvetoen mindenki hulye volt, a sajat teamjuk is nem csak a devopsok, szoval biztos nem emiatt az 1 ugy miatt lettek elkaszalva.

Maradjunk annyiban hogy ugylatom te munkadbol kifolyolag egy csomo megrugdalnivalo uzemeltetovel talalkoztal a karriered soran en meg ugyanezen okbol egy csomo ugyanigy felrugnivalo fejlesztovel. Valoszinuleg mindketten orakig tudnak peldalozni kapitalis okorsegekkel amikkel talalkoztunk mindket oldalrol, meg felpofozni valo arrogans emberekrol akiknek 0 kommunikacios kepessege van. Bar en azt hiszem ez csak az embereket reprezentalja altalanossagban, fuggetlenul a fejleszto/uzemeltetes dologtol, sot egyaltalan az IT-tol is.

Hat eloszor is sajnalom, hogy te ilyen emberekkel dolgozol egyutt, megnyugtatlak nem mindenhol van ez. En amugy ezt pofazom itt evek ota, hogy nincs junior devops, mert ahhoz, hogy valaki felelosseggel el tudja latni ezt a szerepkort nem art ha van jopar ev fejlesztes es uzemeltetes is a hata mogott. De azt csak halkan mondom, hogy az onjelolt fejlesztobol devops-nal egy szikra szemmel sem jobb az onjelolt sysadminbol devops. Ott masmilyen problemak vannak, es attol, hogy valaki bele tud irni egy if-et egy playbookba meg nem lesz koder.

"mert a managementnek tele lett a toke azzal az ezereves" meg azzal is, hogy "minden IS alkalmazas hiba". Egy hangyanyit az az erzesem, hogy te tovabb viszed a regi iskolat, amivel nincs semmi baj, szived joga, de elarulom, hogy az uzemeltetest sem kell felteni, ha balfaszkodasrol vagy eppen kifogasok kereseserol van szo. Maradjunk annyiban, hogy ketton all a vasar.

(En ennek csak orulok amugy, mert nagyban felertekelodott a tudasom ugy 7-8 eve amikor nevet adtunk a szakteruletemnek, amit ez a Kubernetes korszak meg tovabb tolt :D)

Coding and ADHD should be best friends

Abszolut soha nem tamogattam a regi iskolat, en mar nagyon regota azt a hitet vallom hogy a devops/uzemeltetes egyik alapveto filozofiaja az hogy az en ugyfeleim a fejlesztok, oket kell kiszolgalni.

Szerintem ezt alatamasztja hogy az elozo helyemen amikor az egesz javas fejlesztocsapat felallt managerestol architectestol mindenestol 3 eve, akkor nem azert hivtak es vittek magukkal az uj ceghez mert en is a regi iskolat viszem :)

Csak sajnos nagyon sok olyan fejlesztovel talalkoztam es talalkozom a mai napig akik a regi iskolat viszik.

( zsolt | 2021. 03. 09., k – 10:02 )

Fejlesztőként az érdekelne, hogy esetleg valaki tud-e olyan szolgáltatót, akik a magyar interneten, BIX-en lógva szolgáltatnak managelt módon Kubernetest?

Olyan az alkalmazás, hogy nagyon számít a latency és német, francia szerverek már túl messze vannak.

:D
Na, ezért is nincsenek ilyen szolgáltatók idehaza...

Amúgy mi beszélgettünk még pre-covid időkben (lassacskán 2 éve) potenciálisan szóbajöhető magyar szolgáltatókkal, hogy ha gondolkodnának ilyesmiben, akkor szívesen segítünk. Volt, aki már nézegette, de nem láttak benne akkora fantáziát. Meg volt olyan nagy magyar szolgáltató, ahol a vezetésben senki nem is értette, hogy mi ez a (managed) Kubernetes-dolog, ők az ügyfeleiktől ilyesmi igényt még csak nem is hallottak, a meetingre berángatott egy szem műszaki emberük tudta csak, hogy mi ez az egész.

( mhmxs v | 2021. 03. 09., k – 10:15 )

Altalaban keves szo esik az operatorokrol (controllerekrol), de amugy szerintem az a super power of Kubernetes. Az a teny, hogy ugyanazzal az eszkozzel tudok reagalni konfig || ingress || secret valtozasokra, vagy node || process jovesere-menesere a rendszerben, es hosszu meg a sor, baromi jo dolog. Teret ad egy csomo fejlesztesnek, mint halozat automatizacio, vagy automatikus skalazas, distributed storage megoldas, stb.

Akartunk adni lehetoseget az ugyfelnek, hogy sajat route szabalyokat tudjon allitani a hoston, bumm. Kaptak egy operatort, amit ugyanugy kell telepiteniuk, mint barmelyik masik alkalmazast `kubectl apply`, es egy custom resource-ba meg beallitja a cuccot megint csak egy `kubectl apply`, es az osszes nodejan ott lesz a route szabaly, ha ujak jonnek azokon is rajta lesz, plusz RBAC-al tudja szabalyozni kinek ad jogot, szinten `kubectl apply`. Igazabol nekunk a business logicot kellet megirni, imaget sutni minden mast alanktett a platform.

Coding and ADHD should be best friends

Es ha ezt az egeszet becsomagolod Helm-be akkor gyonyoruen kovetheto lesz az egesz, upgradelheto, rollbackelheto, renderelheto, templatezheto, miegymas.

Az operator is nagyon jo dolog, de szerintem a Helm meg nagyobb varazslat.

Nalunk mostanra az a szabaly hogy aki kubectl-el csinal barmit is egy clusteren debuggolason/tesztelesen kivul az nagyon sulyos ejnyebejnyevel fog szembenezni. Ugyanis a kubectl-nek ugyanaz a baja mint az ssh-nak, nem reprodukalhato es nem kovetheto hogy mi tortent.

Az operator is nagyon jo dolog, de szerintem a Helm meg nagyobb varazslat.

Én pont fordítva látom. A Helm az egy nagyon fapad cucc, az operatorhoz képest pedig pláne.

Rengeteg dolog van, amit előbb akarnék Ansible-ben megcsinálni, mint Helmmel.

Ugyanis a kubectl-nek ugyanaz a baja mint az ssh-nak, nem reprodukalhato es nem kovetheto hogy mi tortent.

kubectl apply :D