Senior rendszermérnök

 ( Elbandi | 2017. június 1., csütörtök - 7:05 )

Netvertising Kft.
Senior rendszermérnököt keresünk
(Budapest)

Ilyenek a számaink:

  1. 36 Gbit/s adatforgalom, napi 43.2 Tbyte kiszolgálása
  2. ~ 352 000 000 havi havi oldalletöltés
  3. ~ 3 390 000 feltöltött videó
  4. 56 év és 8 hónapra van szükséged, hogy minden videónkat végig
    nézd
  5. 300+ GByte MySQL és MongoDB adatbázis

Ilyenek vagyunk mi:

  1. Rugalmas munkaidőben, feszültségmentes légkörben dolgozunk
  2. Barátságos, kis létszámú csapatunk van
  3. Elismerjük a munkád hozzáadott értékét a sikerünkhöz
  4. Iparágunkon belül egy nemzetközileg elismert brand vagyunk

Ilyen vagy te:

  1. Magabiztos tudásod van Linux alapú rendszerek üzemeltetésében
  2. Továbbá MySQL, PHP, MongoDB alapú webes szolgáltatások
    üzemeltetésében
  3. Nyitott vagy a fejlődésre és a tanulásra, nem riasztanak el az új
    kihívások

Ami a feladatod lesz:

  1. Több milliós napi látogatottságú webes szolgáltatások
    rendszerfelügyelete
  2. Fejlesztői csapat és a termékfejlesztés szakmai támogatás
  3. Ubuntu Linux alapú infrastruktúra üzemeltetése
  4. Az infrastruktúra optimalizálása és fejlesztése

Kulcsszavak:
#linux, #mysql, #redis, #mongoDB, #elasticsearch, #percona, #lvs,
#jenkins, #gearman, #php7, #bash, #nagios, #puppet, #zabbix, #git, #cacti,
#munin, #vod, #streaming, #cdn, #lighttpd, #nginx, #CI, #bamboo, #conscience, #comprehensivethinking, #agile, #cisco

Amit kínálunk (a fentieken kívül):

  1. Rugalmas munkaidő (törzsidővel), illetve heti két nap home office
    lehetősége
  2. 10 éves, stabil hátterű cég, jól felszerelt iroda, gyümölcs,
    csoki, kávé stb.
  3. Folyamatos kihívások, lehetőség a folyamatos szakmai fejlődésre

Így tudsz jelentkezni:
E-mailben, önéletrajzzal: patrik@netvertise.us

(A hirdetés a HUP-Profession szabadkártya felhasználásával került kihelyezésre)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

De jo is volt... Kis nosztalgia :)

Nem tervezek jelentkezni, csak szakmai kivancsisagbol kerdeznem, hogy nem-e tervezitek lecserelni a felet? :)

Kulonosen ezekre gondolok:
- nagios
- zabbix
- cacti
- munin
- bamboo
- jenkins
- puppet

Es egy ekkora rendszert hogy-hogy nem Kubernetes vagy mas kontener orchestration alatt futtattok? Es hogy-hogy nem cloudban?

(Nincs kotodesem a ceggel, nem ismerem az ottani viszonyokat, csak a sajat cegunkrol tudok nyilatkozni.)

Miert szeretned lecserelni a bevalt es mukodo dolgokat, kulonosen ezekre gondolok: nagios, zabbix, cacti, munin, jenkins, puppet? Tudtommal mind aktivan fejlesztett szoftverek, szeleskoru pluginokkal, aktiv community, stbstb... Nyilvan lehet melle ELK meg grafana, nade ne szurjuk mar tokon magunkat...

Ja, es barmily hihetetlen, a cloud nem silverbullet. Epitettem mar par rendszert, cloudba es fizikai gepekre is, egesz egyszeruen van egy meret, ami felett a fizikai infra jobban megeri. (valamint jogi szempontok is vannak, volt olyan ceg, ahol nem lehetett amerikai gepet/ceget erinteni, kb semmilyen vonatkozasban)

Egyre tobb helyen latom a hype-driven developmentet, sajna kezd ez atszivarogni az uzemeltetesbe is...

Pl a docker is. Nalunk is van, mert jo, mikroszervizeket/kodot spawnolni, de amikor jon a vezeto fejleszto, es kerdi, hogy a master postgres cluster miert nem docker.... Megis mi a fenenek lenne, full dedikalt gep van alatta, minek tennenk meg egy plusz layert, userland proxyt oda...

Miert szeretned lecserelni a bevalt es mukodo dolgokat, kulonosen ezekre gondolok: nagios, zabbix, cacti, munin, jenkins, puppet?

Nem elég trendi.
Nem a google csinálta.

+1. Nyilván egy jól működő rendszert kell lecserélni, azért, hogy a legújabb hype-okat kövesse a cég. Kicsit ilyen gombhoz a kabátot érzésem van.

Múltkor küldött egy fejvadász valami levelet, amiben azt írta, hogy a fejlesztők fontosnak tartják mindig a legújabb technológiák használatát :D Ilyenkor azért kíváncsi lennék, hogy az állandó rewriteon kívül csinálnak-e mást is?

hehe. Igen, ezt nem gondolják végig az emberek, hogy bármit le lehet cserélni.

A kérdés az, hogy az így elért nyereség, kontra az a pénz és idő, amit ebbe ölünk, megéri-e.

+1

Ez tényleg marhaság! :)

Ha ilyet kerdez a vezeto fejleszto hogy a master postgres cluster miert nem docker akkor hajtsd el a p@csaba hogy olvassa el az official docker doksit, amiben vilagosan le van irva hogy ne tegyel bele adatbazist! :D
Sajnos a fejlesztok ilyen hulyek, felulnek a hypevonatra aztan szajkozzak a marhasagokat, de hat errol szol az eletunk hogy rugdaljuk elfele oket a prod szerverek kozelebol.

Mindig elszomorodom amikor ilyen fejlesztőkről hallok. Én fejlesztő vagyok, de fontosnak tartom a környezet megismerését is. Nem tartom magamat rendszergazdának mert az egy másik állatfaj, de eléggé sok mindent megcsinálok a linux rendszerek alatt is, tudom mi merre, mik a határok, kímélem a vasat, stb. Ha kell, felhúzok egy virtual szervert és a legtöbb dolgot beállítom, feltelepítem. Írok scriptet bash alatt is bármikor ha kell.
Nálunk a rendszergazda viccelődik is mindig azzal, hogy én vagyok a helyettese.

Sajnos a mi fejlesztőink is olyanok, hogy a linux felé csak kereszttel mennek. Ha azt mondom, hogy futtassanak le valamit php cli-vel parancssorból (winfos) alatt, akkor már köpködnek, hogy ez üzemeltetés.

Szörnyű.... De ezek szerint, nem nálunk van egyedül ilyen :)

ez mar idejetmult asszem par eve, sokan futtatnak persistence layert dockerben, bar meg valoban nem valami elterjedt

Én el nem tudom képzelni, mivel jobb mondjuk egy konténerbe összelapátolt MySQL, mint egy OS csomagkezelőjével érkező, támogatott verzió, nem beszélve a konfigurálás nehézségeiről.

a kontenerbe osszelapatolt mysql ugyanaz ami az os csomagkezelojevel jon, a konfiguralas meg vagy kornyezeti valtozokon, vagy egy bemountolt konfig fileon keresztul tortenik

https://github.com/docker-library/mysql/blob/dc60c4b80f3eb5b7ef8b9ae09f16f6fab7a2fbf5/8.0/Dockerfile

De olyat tudsz mondani, ahol valóban érdemes, és jobb ezt használni éles üzemben, mint az OS-re felrakott csomagot? Magának a DB-nek úgyis kell hely valahol máshol, azt nem rakod a konténerbe, a felmountolt konfig fájl, az brrrr..., szóval azon kívül, hogy az éles rendszer a lehető legjobban hasonlítson a fejlesztők által használt kuplerájra környezetre.

- nem vagy gephez/gepekhez kotve, ott indul el ahol van eleg eroforras
- pl kubernetes alatt tud maganak olyan storage-ot kerni (persistent volume claim) amilyet szeretnel neki adni
- barmikor tudsz horizontalisan skalazodni
- version rolling update

szivem szerint persze csak managed servicet hasznalnek ilyenekre (pl AWS RDS), de hat nem mindenki fut cloudban.

a konfigfilet bemountolni a kontenerbe nem tudom miert brrr :)

Ezeket a sima VM alapú virtualizáció is tudja, ha meg nincs annyi géped, ahol egyáltalán esélyed van a skálázódásra, akkor minek szivatni magad.
Upgradelni a sima apt és rpm is képes.

- usage alapu automatikus horizontalis skalazodast hogy csinalsz vmekkel?
- upgradelni persze mindegyik kepes, viszont azt hogyan garantalod, hogy a CentOS mysqled ezerszazalekban ugy fog mukodni a production rendszereden, ahogy a fejleszto rendszeren? hibrid rendszerekben gondolkodj

Mint a Kubernetes, a VM-es rendszerekhez is van felügyelő SW, amúgy meg azért választok mondjuk CentOS-t, mert megbízok benne. MySQL-t automatikusan skálázni amúgy se hinném, hogy jó ötlet.

minden van mindenhez mar, a kerdes, hogy _milyen_

egy read-heavy db eseten pedig van ertelme automatikusan skalazni

Láttam én már Kubernetest teszt rendszerben meghülyülni, 100% CPU-t fogyasztani, ész nélkül vm-eket átpakolni. Ilyen van "heavy" VM-es rendszerhez is.

ird mar le legyszives, hogy mi tortent, pprofilelal megneztetek, hogy mi tortenik?

Rdbms-ek pont azok amiket nem fogsz dockerrel skalazni, sokkal elobb fogsz ele rakni read-heavy felhasznalas eseten valami cache megoldast ahelyett hogy azzal szenvednel, hogyan csinalhatsz a 4 mysql szerverbol 40-et linearis skalazodassal.

jogos, azonban megvan a maga szepsege az immutable image-eknek is. Egy kicsit masfajta filozofia van mogotte, de nagy josag...

Nekem valahogy szimpatikusabb, ha mondjuk egy Ansible playbook szettben megírom az egész infrát, a VM-ek létrehozásától kezdve az összes program beállításáig, és ezzel bármikor létrehozhatod/kijavíthatod az egész környezeted.
Ha mondjuk kiderül, hogy kimaradt 2 fájl az összes gépről, akkor nem kell az összes imaget újragyártani, majd elindítani, nem fekete doboz az egész rendszered, nem kell külön szkripelni, konfig managelni, meg Dockerfileozni.

lehet igy is, meg lehet a masik modon is. Btw. az image-ek ujragyartasa (ha csak 2 file maradt ki) gyors. Masfelol, ha pl. rollback-re van szukseg, akkor sokkal gyorsabb elovenni az elozo image-et (mint mondjuk ansible playbook-ot modositani, feltolni review-ra, valami verification sem art, majd lefuttatni a playbook-o(ka)t).

Mondom, nem rossz az ansible, sot, de vannak azert elonyei, ha docker-re epitesz.

Alapvetoen ez a ketto miert zarja ki egymast?;)

bort se kevered a sörrel, pedig mindkettő jó :D

Nalunk speciel a regi verzioju (asszem, 5.1) mysql fut kontenerben. Nyilvan masik porton, mint a csomagbol erkezo, a siteok nagy resze altal hasznalt.
De ha meg van olyan szar, ami 4.7 php, dukal hozza egy ezereves mysql is, ha az ember nem akarja vegigszopni az eletet.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

> olvassa el az official docker doksit, amiben vilagosan le van irva hogy ne tegyel bele adatbazist!

deeplink, pls, nem találom. ty!
--
blogom

Mert asszem nincs is benne...
Ilyenek vannak pl: https://www.percona.com/blog/2016/11/16/is-docker-for-your-database/ (fél éves cikk)
De persze ez sem Egyetlen Nagy Igazság(tm).

"az official docker doksit, amiben vilagosan le van irva hogy ne tegyel bele adatbazist! "

szimplan rosszul erted a Docker doksit, nyugodtan mehet Dockeren belul a _processz_. Blogposztokat most ne linkelj legyszi, a netes bloggerek 98%-a nem ert hozza.

----------------------
while (!sleep) sheep++;

ahogy en latom:

- nagios - elavult, szarul skalazodik, nincs restful api a coreban ha jol latom, nincs whitebox monitoring, gyorsan valtozo infrastrukturat szivas vele monitorozni
- zabbix - egy fokkal jobb, de tovabbra is a arra korlatoz, hogy gepekben gondolkodj, ami egy modern infrastrukturaban mar egyaltalan nem jellemzo
- cacti - rrd alapu, lassu mint a szar ha skalazni akarod, elavult ui
- munin - lasd fent
- jenkins - hasznalhatatlan ui, amugy ok
- puppet - nagyon konnyu nagyon erthetetlen kodot irni benne, csak subset of ruby, rabolja az idot feleslegesen, nem idempotens, mutable infrastrukturaban nincs ket ugyanolyan gep ami mikozben egy hibat deritesz fel...nos el tudod kepzelni

nem arrol van szo, hogy ezek ne lennenek jo toolok, vagy bizonyos meret alatt ne lennenek hasznosan is akar, de es itt a lenyeg: rohadtul nem erdekel, hogy mivel monitorozom az infrastrukturamat, de:

- skalazodjon - franc akarja a monitoringot masszirozni amikor ezer mas egyeb - eloremutato - dolgot is csinalhatnal
- legyen apija - minden monitoring kodban, nincs manualis nyammogas :)
- lehetoseg szerint fedjen le minden teruletet - ne kelljen nyolcfele menni es osszenezni az adatokat egy hibanal
- anomalia detektalas, outliers, trend based alerting - nyilvan ezek tobbseget be lehet hekkelni a fenti monitoring rendszerekbe, de az megint csak a hasznosabb dolgoktol veszi el az idot
- csinalhass magadnak mindenfele dashboardot

szerintem nagyon kevesen talalkoztunk olyan projekttel, ahol a meret indokoltta teszi/teheti egy sajat fizikai infra kialakitasat es itt elso sorban a TCOra gondolok. Egy sajat infra eseten hihetetlen sok dologra kell figyelni es ehhez sok ember is kell magas fizuval...

ez nem hype driven development, csupan belatasa annak, hogy rohadtul nem erdekel az, hogy mivel monitorizok, mivel loggolok csak nezni/analizalni akarom oket. Az se erdekel, hogy hol fut a postgres clusterem, mert fut es kesz. Es igen docker alatt mert igy tobbe-kevesbe 100%ig tudom biztositani azt, hogy a local dev es a prod kornyezet ugyanugy fog viselkedni, es barmikor upgradelhetek hosszas rakeszulodes heklyett es ha valami megdoglik akkor - remelhetoleg :D - helyreallitja magat. Az a max par ms amivel ez az egesz lassabb a plusz layerek miatt meg elhanyagolhato a mai hardverkapacitas mellett, cserebe sokkal jobban menedzselheto.

ugyanez igaz a ci rendszerre, minek nekem sajat amikor masok szazszor jobban megcsinaljak ugyanazt

mutable infra helyett meg imageket egetek es ugy inditom a gepeket, es a ci automatikusan le is teszteli nekem rspeccel, igy ha valamit elrontok akkor legfeljebb nem kerul ki productionbe automatikusan

a Puppetrol alkotott velemenyed kapcsan kerdeznek parat:

  • miben nem konnyu erthetetlen kodot irni szerinted?
  • ha a Puppet csak egy Ruby-subset es rabolja az idot, melyik eszkozben talaltal megoldast minden feladatra, hol kellett a legkevesebb sajat megoldast kifejlesztened?
  • a Puppet tudtommal deklarativ, szoval a leheto legidempotensebb megoldas. szerinted melyik eszkoz csinalja ezt jobban?
  • immutable infrastrukturaban nalad hogy (vagy minek) van konfiguracio-menedzsment?

elore is koszi a valaszokat

bar nem engem kerdeztel, de en az ansible-re eskuszom. De izlesek es pofonok...

na jo, de az ansible hol nem verzik ezer sebbol, ha hozzadorzsolod a fenti 4 kerdesemet?

- Mindenben lehet erthetetlen kodot irni, tapasztalataim szerint Puppetben kulonosen konnyu
- Mivel mindent dockerben futtatok es imageket generalok a gepekre ezert boven eleg a cloud-init vagy ignition, legrosszabb esetben Ansible
- idempotens alatt peldaul azt ertem, hogy mondjuk ha hieraban tarolod a gepen letrehozando felhasznalokat es a kitorolsz egyat, azt a Puppet rohadtul nem fogja kitorolni magatol. Lehet hogy a 4esben mar megcsinaltak, nemtudom. Apropo migraltal mar Puppet verziot? :)
- Lasd kettes pont

Akkor ez fogalomzavar, mert az idempotencia nem ez. A konkrét felvetésben jelzett probléma pedig nem probléma: azt a usert nem törölni kell a Hierából, hanem az ensure property-je értékét kell explicit módon megadni "absent"-ként. Érthető és védhető okokból viselkedik így... Nem védem a Puppetet, de ezt egyetlen cfgmgmt rendszer sem fogja máshogy csinálni, pontosan emiatt.
----------------------
{0} ok boto
boto ?

pedig az idempotensseg alatt ezt is elvarnam egy konfig mgmt eszkoztol, az altalam ismertek egyike se tudja, de az volt a kerdes, h mi a bajom a Puppettel ;)

Ha megnezed mekkora felesleges masszirozas egy nyomorult user eltavolitasa tetszoleges konfig mgmt eszkozzel, maris lathato, hogy mennyi idot rabol el egy ilyen egyszeru feladat.

1) csinalsz egy branchet, kiszeded a usert, atrakod abba a hiera strukturaba ami majd eltavolitja a usert (ezt is meg kell irni)
2) pr, review, merge, taggeled vagy sem, workflowtol fuggoen
3) lefut egy hookbol, vagy manualisan futtatod szinten workflowtol fuggoen

A usered 3 gepen futtat egy screen-t ezeken a gepeken maris nem eleg az absent, vagy kilovod manualisan vagy irsz erre az esetre egy classt ami kikilleli a pidjeit (exec idempotencia nem letezik), tehat mar megint hekkelni kell

aztan ha rendes akarsz lenni, egy ujabb prral kitakaritod a usert a kitorlendo userek listajabol.

Ezt en rengeteg feleslegesen elkurt idonek erzem, amit ennel sokkal hasznosabb dolgokkal is eltolthetnel. pl vitazni a hupon :D

na ezert utalom a konfig mgmt eszkozoket...

értem mit mondasz, de rendszeresen úgy csinálsz, mintha a docker konténerekhez nem kellene normális workflow. Nem igazán látom, hogy a konkrét esetben egy konténeresdiből hogyan tűnik el egyszerűbben a user (ok, nem kell cleanup job)

azt a workflowt hasznalom amit masok mar megirtak pl Kubernetes eseten Deployment (illetve inkabb Helm), de barmelyik tetszoleges orchestration framework adja ezeket a workflowkat

konteneresdiben meg egyszeruen nincs - vagy helyesebben nem ugy van - user ahogy hagyomanyosabb rendszerek eseten, annal is inkabb mivel max belepek a kontenerbe ha valamire ra akarok jonni, amugy meg az esetek 95%ban sehova nem sshzok, mondjuk ez az egesz user mizeria csak marginalis kerdes csak most pont ez jutott eszembe :)

igen, és a config management eszközökhöz nincsenek workflowk? Meg ha valami adja őket, akkor nem kell végigcsinálni? Mert ugye az volt a kifogás, hogy pr, review, mittomén, brr...

Képzeld, van képem arról, hogy van-e (és egyébként van az az elbaszott eset, amikor uideket érdemes volna szinkronizálni), viszont akkor most ott tartunk, hogy a confimanagement eszközök szarok, mert szerinted kényelmetlenül kezelnek egy olyan problémát, amit a te kedvenc eszközöd sehogy sem. Most akkor döntsd el, hogy a config management eszközöket rühelled, vagy a hagyományos szervereket, ahol ilyenekkel kell foglalkozni?

a konfig menedzsment eszkozok olyan problemat oldanak meg ami regen volt, mar mar nem feltelenul, ha nem akarod es van akarat a valtoztatasra

btw uid szinkronizacioval most is kuzdok es mas megoldason agyalok :)

nem kedvenc eszkozokrol van szo, max kedvelt eszkozrol...

ennek azért a másik oldalára könnyen oda lehet állítani a kiforratlan, állandóan változó bugos szarokat :D

meg azokat a problémákat, amik pl régen nem voltak, mint hogy játszhatsz disztribútort a saját imageidhez, vagy próbálhatsz automatán secholeokat keresni a fasz se tudja honnan jövőkben.

Tudsz peldat mondani az elsore? Mert ugyan jol hangzik, de konkretumok nelkul keveset er.

Minek jatszanek disztributort? Mondjuk fogom a coreost, beallitom amit kell, abbol csinalok egy imaget es azt teritem. Nem nagy cucc legeneralni es rolling deployolni.

Tudok, csak most hadd ne gepeljek ennyit telefonról, uh majd később :-) meg Elbandi egyébként sem hiszem, hogy rajong az offert :-)

"Tudsz peldat mondani az elsore? Mert ugyan jol hangzik, de konkretumok nelkul keveset er."

Na szóval, ha már docker. Akkor pár pl arra.
1) Rögtön azzal nyitunk, hogy storage driver, melyik ujjamat harapjam.
- aufs - köszi, de én is láttam, amit a neten még sokan, hogy simán összefosta magát. Többször is, úgy, hogy nem nevezném terhelésnek, amit kapott. Az is sokatmondó, hogy a redhates srácok inkább írtak egy saját drivert a devicemapperre, minthogy beengedjék
- szóval devmapper? Hát, az legalább az lvm alatt már jó, cserébe a dockeres arcok huzzák rá az orrukat láthatólag
- overlay / overlay2 - mindkettő fiatal. fiatalabb mint pl a brtfs, amit még nem mertek élesbe engedni, és emlékszünk még, mennyi idő volt, míg az ext4-et kikupáltálták, szóval eleve vannak kétségek. Hogy az overlay2 azért létezik, mert rájöttek, hogy az overlayt fubar cseszték el, az nem növeli az abba vetett hitet, hogy majd pont nekik fog sikerülni gyorsan.
- brtfs - egyrész lásd fent, másrészt ránézésre úgy tűnt, a driver is félkész.
- zfs - az még docker nélkül is véleményes linuxon

Csupa jó választás, és ugye üzembiztonság szempontjából azért nem mindegy.

2) 1.12-ben lett healthcheck (ami elég jippi, mert az egész koncepcióban sok helyen elég fájdalmas, hogy ha a container elindult, akkor az jó, és jön a wait-for-it.sh és társai). Ami azt csinálja, hogy... hogy beleírja a metadatába hogy healthy, sajnos semmi mást, hacsak nem írod meg te magad. Hasznos :) 150 sor alatt meg lehetett csinálni pythonban, hogy listeneljen az api eventekre, és applikálja rá a container restart policyját, érthetetlen, hogy ezt miért nem tudja magától.

3) Nagynehezen eljutottak odáig, hogy lehet törölni a registryből. Micsoda feature :) Igaz, ha jól láttam, kivezetve még nincs, csak api call, és az is csak bemarkolja deletere, de offline kell vinni a registryt, mikor valóban takarítasz, mert annyira jól tervezték meg az adatstruktúrát, hogy nem tudják másképp kezelni azt, hogyha változna a kétlépcsős először megnézzük mit lehet törölni, majd töröljük őket processz közben.

4)

root@host:~# docker images -f dangling=true | wc -l
63
root@host:~# docker images -f dangling=false | wc -l
61
root@host:~# docker images |wc -l
84

és nem, nem azért mert közben változott, azt is rendszeresen látom, hogy egy ilyen után akasztott |xargs docker rmi harákol, hogy fogja valami a layert.

"Minek jatszanek disztributort? Mondjuk fogom a coreost, beallitom amit kell, abbol csinalok egy imaget es azt teritem. Nem nagy cucc legeneralni es rolling deployolni."

Mert az összes használt cucc security követését meg kell oldanod magadnak. Vagy elhiszed annak, akitől az image van, hogy jó -- ezt sajnos én a nagyobb disztribútoroknak is csak módjával tudom, pedig ők rég ezt csinálják, a random app gyártójának csak nagyon nagyon mértékelten, szóval
- vagy valami automatával scannelsz folyamatosan, hogy hol sikerül bent felejteni egy régi vulnerable libet (aztán agyalani azon, hogy hogyan forkolod le a dockerfilet, ha az upstream balfék)
- vagy csinálod magad, és integrálsz be egy csomó upstream repot, változatos formában.
- Bónuszként, ha esetleg szeretnéd tudni fél év múlva is reprodukálni, akkor ki kell találni azt is, hogyan artifactolod el az összes upstreamet a githubtól az ubuntu repojáin át a pipig a cpanig, meg az istentudja miig bezáróan, vagy azt, hogy hogyan követed a verziókat manuálisan.

Ez egyébként jellemző probléma az összes ilyesmire a snappyn át az apkig, ahol izolációval csinálnak securityt, és azt tesz oda a vendor amit akar, nem a docker sajátja.

Koszi, ezen mar lehet agyalni :)

1)

- aufs - ha bubuntun vagy debianod van hasznald, de elsosorban PaaS jellegu terhelesre igazan jo, eleg mature.
- devicemapper - kosz nem, szivtam vele en is, mondjuk nem foglalkoztam vele tul sokat mert ott volt nekem az overlay
- overlay - az egyesnek elsosorban az volt a baja, h iszonyat inode ehes volt, u h ennek megfeleloen kellett csinalni a filerendszert a /var/lib/docker mountpoint ala
- overlay2 - ez mar nem inode hungry :) teljesitmenyben nekem megfelelt mind a ketto (hozzateszem az aufs is)
- btrfs, zfs - ezeket nem hasznaltam soha, sztem ki fognak halni (marmint docker alatt), de ez csak megerzes

A lenyeg az, hogy ha van egy megfelelo orchestrationod es mondjuk tegyuk fel valamilyen okbol kifolyolag mondjuk osszefossa magat az egyik geped az overlay/2 vagy barmelyik masik miatt, attol meg a szolgaltatas futni fog a tobbi gepen es atmasznak oda a kontenerek.

2) Docker nagyon nyomul ezen a teren, de eleg nagy is a lemaradasuk, nezd meg ezt https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

3) Ezt nem ertem, ti sajat docker registryt futtattok? :) Sose volt meg ra szuksegem.

4) Ha arra gondolsz, hogy a geprol idonkent le szeretned torolni a nem hasznalt imageket? Erre regen mindenfele priviledged modban futo magicet futtattam, de Kubernetesben a kubelet gondoskodik a gcrol https://kubernetes.io/docs/concepts/cluster-administration/kubelet-garbage-collection/

5) Valasszuk kette a dolgot

- a coreos image keszitese soran abszolut minimalis valtoztatasok tortennek, kb annyi, hogy fusson a Kubernetes megfelelo komponense egy VMen. Mivel ezen kivul minden kontenerbol fut (pl maga a kubernetes is) igy ebben az esetben annyit kell trackelnem, hogy van-e uj release etcdbol vagy hyperkube-bol es miert.
- docker imagek eseten mar kicsit kacifantosabb a kerdes, alapvetoen csak hivatalos docker inc altal keszitett imageket hasznalok, egy se joskapista altal keszitett. Mind a quay.io es a dockerhub is kinal securityscan szolgaltatast es ezekre is lehet hookokat kesziteni, hogy ha vmelyik komponens serulekeny es van uj verzio akkor csinaljon uj imaget.
- miert akarnam reprodukalni? Erre mondj mar egy peldat pls, lehet hogy csak az en fantaziam tul szegenyes :/ Penzugyi intezeteknel van ilyen esetleg?

1)
Köszi, de az aufst mint mondtam én láttam maga alá fosni csúnyán, uh kösz nem, mi most devmapperre lőttünk első körben de csak megjegyzés, mert

"A lenyeg az, hogy ha van egy megfelelo orchestrationod es mondjuk tegyuk fel valamilyen okbol kifolyolag mondjuk osszefossa magat az egyik geped az overlay/2 vagy barmelyik masik miatt, attol meg a szolgaltatas futni fog a tobbi gepen es atmasznak oda a kontenerek."

.. a lényeg az, hogy ja, ha van elég vas, meg olyan orchestration, ami ezt tudja. Magyarul ha nem random cloudba pakolsz, akkor ez egész üzembiztossága erősen kérdőjeles. Mondhatnám, hogy félkész, bugos szar :) aminek a méregfogát csak azzal lehet kihúzni, hogy sok vasat teszel alá.

2) Tudom, hogy van a kubernetesben ilyen. Arra hoztam példát, hogy kiforratlan :)

3) Igen, saját registryt futtatunk. Valahova tenni kell a saját imageket.

4) Nem, arra gondolok, hogy amikor ilyet akarok csinálni -- a dangling=true azt hivatott filterezni, ami imagere már nincs hivatkozás, ezért nyugodtan lehet rmi-zni. Namost, ha a docker szerint van 63 ilyen, meg 62 ami nem ilyen, akkor elvárnám, hogy ne összesen 82 image legyen, hanem 63+62, lévén ezeknek határozottan diszjunkt halmazoknak kéne lennie. Na jó, több még esetleg lehetne, ha van olyan állapot is, hogy dangling=fassetudja, (de mondjuk akkor meg azt is ki lehetne vezetni) de kevesebb semmiképp. Ha egyébként látod azt is, hogy a "docker images -f dangling=true -q | docker rmi" -- aminek ugye le kéne szedni a danling imageket időnként sír, hogy amit ő megpróbált most leszedni, az nem ment, mert valmi még használja, akkor eljutunk a félkész mellett a bugosig is.

5)
"- docker imagek eseten mar kicsit kacifantosabb a kerdes, alapvetoen csak hivatalos docker inc altal keszitett imageket hasznalok, egy se joskapista altal keszitett. Mind a quay.io es a dockerhub is kinal securityscan szolgaltatast es ezekre is lehet hookokat kesziteni, hogy ha vmelyik komponens serulekeny es van uj verzio akkor csinaljon uj imaget. "

Magyarul bejött egy új problématér, a random imagek security scanje, ami korábban így nem volt. Attól, hogy te ezt outsourceolod, még új problémák, amiket kezelni kell (vesd össze, fizethettél volna valakinek a puppet üzemeltetésért is)

"-- miert akarnam reprodukalni? Erre mondj mar egy peldat pls, lehet hogy csak az en fantaziam tul szegenyes :/ Penzugyi intezeteknel van ilyen esetleg?"
Azért, mert pl van egy verzió egy ügyfélnél belőle, és amikor fél évvel később bugot jelent, akkor jó lenne tudni abban a környezetben javítani, ami nála van. Ahhoz meg az kell, hogy elő tudd állítani azt a környezetet.

---
Egyébként meg a kiforratlant az is jól példázza, hogy én hozom a docker hibáit, te meg mutogatsz arra, hogy de ezt kubernetesben meg lehet oldani. A kiforratlannak az is jó fokmérője, hogy időnként nagyot kell csavarni (pl mikor majd -- ha -- a docker behozza lemaradását orchestration téren, és ezért érdemes lesz arra menni, mondjuk a kubernetesről).

Félre ne érts, egyáltalán nem rossz eszközök ezek, de vannak olyan helyzetek, amikor ezt a fajta rugalmasságot nem lehet elvárni a környezettől.

1) Egyaltalan nem errol van szo, csak a legrosszabb esetet vazoltam. Es ebben semmi kiforratlan nincs, de bugok mindenhol elofordulnak es semmi sem tokeletes. A multkori Ubuntu glibc update miatt (https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1674532) megallt a DNS ami nem kis problema, ez akkor azt jelenti, hogy kiforratlan az Ubuntu?

Es nem arrol van szo, hogy csillionyi vasat teszek ala, hanem arrol, hogy mondjuk AWS alatt ha az egyik gep lehal azt a Kubernetes erzekeli es elkezdi attolni a kontenereket egy masik gepre, ha pedig nem lat eleg eroforrast akkor kb 3 perc alatt automatikusan (autoscaling group) elindit egy gepet es es oda tolja. Ezt ejszakai telefonhivas, bejelentkezes es manualis beavatkozas nelkul hogyan tudod megcsinalni egy sima VMes kornyezetben? Biztos van ra modszer, de ezzel _sem_ kell foglalkoznom, az orchestration megcsinalja magatol. Masnap reggel majd latom, h mi tortent es utananezek, hogy hogyan lehetne ezt megakadalyozni. Ilyen mellesleg meg nem tortent velem. A kontenerizacio nem kiforratlan technologia es eleg uzembiztos ahhoz, hogy oriasi cegek bizzak ra a szolgaltatasaikat.

2) Ez szinten nem kiforratlansagra utal. Ez egy okoszisztema es nem kell mindent a Dockernek megoldania, hiszen van ra megfelelo tooling. Ahogy a logrotate-et sem a syslognak kell megoldania, bar meg tudna ha akarna (nem neztem utana de tutira van olyan megoldas, hogy megcsinalja :)). Ezt hivjak separation of concerns-nek.

3) Van valami kulonosebb oka ennek? Miert nem hasznaltok private repokat DockerHubon vagy Quay.io-n? Erre gondoltam fentebb, hogy minek cseszekedjek ilyenekkel amikor masok szazszor jobban megoldjak helyettem, mikozben nincs jelentos impactja az alkalmazasaim szempontjabol.

4) lasd 3as pont. Amugy minek torolnek a registrymbol? Nekem teljesen jo ha ott van az osszes verzio amit valaha buildeltem :)

5) Ez semmiben nem uj problemater csak egy masfajta megoldas ugyanarra a problemara amikor updatelgetned kellett a disztrot amit hasznaltal. Az image forrasa ugyanugy pl debian mint amit a vmeden futtatnal. Tovabbra is ugy teszel, mintha az imagek scratchbol forgatott custom disztrok lennenek, pedig nem igy van.

6) Pont ebben brutaljo a docker, hogy _pontosan_ ugyanazt az envet tudod reprodukalni ami az ugyfelnel van, mig egy mutable infranal ez erosen kerdeses. Fogod azt az imaget (nyilvan taggelitek az imageket) ami az ugyfelnel van es reprodukalhatod a hibat.

---

Szerintem kevered a szezont a fazonnal, a Dockernek vagy barmilyen mas kontenerizacionak (pl rkt) nem az a lenyege, hogy mindent tokeletesen megcsinaljon, erre ott van a Kubernetes es a kismillio egyeb orchestration framework. Alapvetoen par dolgot kell csupan tudnia ami ahhoz kell, hogy fusson az image - ha nagyon leegyszerusitem. Amint fentebb leirtam ez egy okoszisztema, ahogyan a Linux is egy okoszisztema.

Az mas kerdes, hogy a Dockerinc - latvan hogy mekkora business az orchestration - mar jo par eve mozog abba az iranyba is, de az altaluk szallitott megoldasok nem exkluzivak, egyaltalan nem kotelezo hasznalni oket.

"Es ebben semmi kiforratlan nincs, de bugok mindenhol elofordulnak es semmi sem tokeletes."

Szerinted, szerintem meg van. És igen, az ubuntu is egy gány egy csomó helyen.

"2) Ez szinten nem kiforratlansagra utal. Ez egy okoszisztema es nem kell mindent a Dockernek megoldania, hiszen van ra megfelelo tooling. Ahogy a logrotate-et sem a syslognak kell megoldania, bar meg tudna ha akarna (nem neztem utana de tutira van olyan megoldas, hogy megcsinalja :))."

De, arra utal, mert a fene sem tudja, hogy most éppen ki a nyerő. Ez az egész ökoszisztéma még kiforratlan, te magad is mondtad, hogy a docker nagyon nyomul a kubernetes tortája irányába. Cserébe alulról rágja szét a systemd, a guglis arcok tolják az rkt-t, és igazából a franc se tudja, mi lesz ebből pár év múlva.

"Ezt hivjak separation of concerns-nek."

Légyszíves és ne oktass ki, hidd el, hogy nem vagyok nyeretlen kétéves.

"3) Van valami kulonosebb oka ennek? Miert nem hasznaltok private repokat DockerHubon vagy Quay.io-n? Erre gondoltam fentebb, hogy minek cseszekedjek ilyenekkel amikor masok szazszor jobban megoldjak helyettem, mikozben nincs jelentos impactja az alkalmazasaim szempontjabol."

Igen, van nálunk ez igény, és pötty. (Segítek, egy igény nem feltétlen műszaki, lehetnek neki jogi okai, vagy akár csak az, hogy mondjuk valaki nem szeretné a komplett szolgáltatásbiztonságát a quay.io-nak adni) Egyébként meg én is ezt mondtam: attól, hogy a problémát mások oldják meg helyett, attól még azok problémák, amiket meg kell oldani. És értem, hogy neked elképzelehetlen, hogy valaki saját infarstruktúrát akarjon üzemeltetni, de ettől ez még valós igény.

"4) lasd 3as pont. Amugy minek torolnek a registrymbol? Nekem teljesen jo ha ott van az osszes verzio amit valaha buildeltem :)"
Elnézést, de kénytelen leszek visszaszúrni, ha már te ezt megengedted magadnak :) Meg kéne ismerni kicsit alaposabban az általad használt toolokat, itt ugyanis szó nincs registryről, itt a dockerd local image cacheéről van szó. Ami olyan szinten bugzik itt, az egyik alapvető higéniás izéjénél, hogy nagyon.

"5) Ez semmiben nem uj problemater csak egy masfajta megoldas ugyanarra a problemara amikor updatelgetned kellett a disztrot amit hasznaltal. Az image forrasa ugyanugy pl debian mint amit a vmeden futtatnal. Tovabbra is ugy teszel, mintha az imagek scratchbol forgatott custom disztrok lennenek, pedig nem igy van."

Kivéve a gyevi bírót ugye. Egyrészt ahány image, annyi distró, másrészt meg ugye pont az dev irányból az egyik fontos pont, hogy ha a libfoobar az ubuntuban régi, akkor még mindig fel lehet tenni az én appomnak megfelelőt mondjuk pip installal, vagy brew-val, vagy valamivel. És akkor azt onnan máris követni kell. Vagy jófej a dev, és oda mást használ, hogy ne legyen gányolva, így lesz a szolgáltatás alatt hol ubuntu, hol alpine, hol gentoo hol az istense tudja mi, és ezt bizony le kell kezelni. Vagy úgy, hogy megtanulod követni, vagy úgy, hogy visszatérünk ground zerora, hogy "kedves dev, azzal főzől, ami az ubuntuban van", csak akkor meg dev szempontból az egyik fontos előnyét veszti el a játék.

"6) Pont ebben brutaljo a docker, hogy _pontosan_ ugyanazt az envet tudod reprodukalni ami az ugyfelnel van, mig egy mutable infranal ez erosen kerdeses. Fogod azt az imaget (nyilvan taggelitek az imageket) ami az ugyfelnel van es reprodukalhatod a hibat."

Igen, ez egy népszerű féltévképzet. :) Vagyis inkább azt mondanám, hogy nem szokás látni, hol vannak a mantra határai. Igen, egy image immutable. Viszont egy dockerfile már nagyon nem az, tipikusan legalább kettő dolog szokott benne nem az lenni. Az egyik a FROM foobar:latest, ahol ugye a latest akármit is jelent (és ironikus módon van is olyan ticket, hogy lehessen már a fromban változót használni, ahol a fogalmatlan magyarázza, hogy de reprodukálhatónak kell lenni, és ott nem lehet változó, mert akkor mutable, az ember meg próbálja elmagyarázni, hogy a pipelineban ő ugyan pontosan tudja, hogy melyik imageből kellene most dolgozni, mert minek a következő stepjében vagyunk, és épp ezt szeretnénk odaírni, csak ezt nem tudjuk, a latest meg ugye mondjuk egy build rendszerben kissé gyorsan mozgó célpont) a másik meg az apt-get install, ami fél év múlva szintén mást fog jelenteni.
És odáig rendben, hogy az imageből reprodukálod, de aztán azt patchelni is kéne. És tudom, hogy van, ahol ezt nyugodtan lehet a frissből, de ez nem mindig van így.

"Szerintem kevered a szezont a fazonnal, a Dockernek vagy barmilyen mas kontenerizacionak (pl rkt) nem az a lenyege, hogy mindent tokeletesen megcsinaljon, erre ott van a Kubernetes es a kismillio egyeb orchestration framework. Alapvetoen par dolgot kell csupan tudnia ami ahhoz kell, hogy fusson az image - ha nagyon leegyszerusitem. Amint fentebb leirtam ez egy okoszisztema, ahogyan a Linux is egy okoszisztema.

Az mas kerdes, hogy a Dockerinc - latvan hogy mekkora business az orchestration - mar jo par eve mozog abba az iranyba is, de az altaluk szallitott megoldasok nem exkluzivak, egyaltalan nem kotelezo hasznalni oket."

Igen, pontosan ez volna a lényeg, hogy lépj egy kicsit hátra, és onnan szemléld mi történik az egészben, ne pedig a példák részleteiben vessz el, azok csak példák. Ez egy új terület, ami még most jött ki abból, hogy az early adopterek után a következő hullám is jönne, (és nekik adott esetben vannak másféle igényeik). Mivel friss terület, viszonylag gyorsan változik, és az ehhez való adoptálódás infrastruktúrális oldalról tud problémás lenni, mindezt úgy, hogy pl a bejáratott puppethez képest nem biztos, hogy fog hozni érdemi előnyöket. Egy csomó dolgot te elütsz azzal, hogy ezt megcsinálják mások a felhőben, de ez nem mindenkinek hihető ugy, meg ilyen alapon eddig is meg lehetett venni mondjuk a vmwaret, ott olyan orchestration van, hogy beszarsz, meg az appok tudta nélkül oldja meg a redundanciát (bizonyos szintig úgy is, ahogy a konténeresdi sose fogja) csak elég drága. Cserébe az adminok köszönik, ismerik, elvannak vele. És pl nincs szükség akármeddig vertikális skálázódásra, mert nem olyan a szolgáltatás. Az enterspize tipikusan nem arról szól, hogy valami nem bírja a terhelést, vagy hirtelen 2 nagyságrendet változik a terhelés, mert tipikusan a komplexitás a baj, nem a teljesítmény.

2) "De, arra utal, mert a fene sem tudja, hogy most éppen ki a nyerő." Pont ez a munkank, hogy el tudjuk donteni, hogy mi a jelenlegi legjobb megoldas, nincs silverbullet, de van jopar megoldas ami mar most eleg mature ahhoz, h nyugodtan rabizd magad.

Amugy nem akarlak kioktatni, csak beszelgetunk :)

3) Ok nalatok ez az igeny, ugyan sztem felesleges igeny (jogilag is), de akkor ez van, szivtok is vele amint irtad :) A teljesen sajat infra felett meg korabban leirtam, hogy nagyon kezd eljarni az ido mert nagyon draga es iszonyat felesleges energia es ido megy el a megfelelo uzemeltetesere aminek az ugyfelek megfelelo kiszolgalasaban semmi kezzelfoghato haszna nincs.

4) Akkor hasznald a megfelelo szavakat es akkor majd megertem mit akarsz mondani. Orulok, h tisztaztuk hogy docker cache != docker registry. A cachet takaritom, a registrybol sohase akarok torolni, hogy barmikor barmelyik verziora rollbackelni tudjak vagy a fentebb leirtaknak megfeleloen bugot tudjak keresni.

5,6) Neked mint devopsnak pont az a feladatod, hogy ne engedj :latest-et hasznalni es enforcold a best practise-eket, jellemzoen toolinggal (pl https://github.com/projectatomic/dockerfile_lint). Biztos van olyan alkalmazas ahol kell a legujabb foobar-lib, de azert erre mondjal egy peldat, mert a legtobb esetben van erre egyszeru megoldas es illetve a komponenseket nem klasszikus csomagokbol rakod fel, hanem mondjuk npm eseten ugye packages.json vagy composernel composer.json esatobbi. Amugy meg ha teszem az valami :latest-tel keszult is, az taggelt imagem ott van a registrymben es pont tok ugyanaz ami az ugyfelnel fut.

Ez mar regen nem az early-adopterek utani hullam, de nekem mindegy ha valaki igy latja, hat igy latja. A kiprobalt Puppettel meg semmi baj, ha a tovabbi lehetosegek ellenere dontenek mellette, bar ezt ismerven mind a kettot rettento nehez lenne megertenem :D

VMware meg nagyon szep es nagyon jo, csak monjduk rakjal mar ossze egy altalad leirt rendszert 5 perc alatt kodbol, kattintgatas es egyebek nelkul. A komplexitas csokkentese meg pont nem az enterspajzokra jellemzo, hanem a modern infrakra.

"Pont ez a munkank, hogy el tudjuk donteni, hogy mi a jelenlegi legjobb megoldas, nincs silverbullet, de van jopar megoldas ami mar most eleg mature ahhoz, h nyugodtan rabizd magad."

Egyrészt igen, ez, és éppen azt próbálom magyarázni, hogy vedd már észre, hogy vannak olyan usecasek, ahol a konténeresdi nem jobb, mint valami régi. Nem én jöttem azzal, hogy miért nem konténer ;) A maturity eldöntése meg megint olyan, mint mondtam, hogy szerinted már jó, más szerint meg lehet, hogy még nem elég.

"3) Ok nalatok ez az igeny, ugyan sztem felesleges igeny (jogilag is), de akkor ez van, szivtok is vele amint irtad :) A teljesen sajat infra felett meg korabban leirtam, hogy nagyon kezd eljarni az ido mert nagyon draga es iszonyat felesleges energia es ido megy el a megfelelo uzemeltetesere aminek az ugyfelek megfelelo kiszolgalasaban semmi kezzelfoghato haszna nincs."

Erre megint maradjunk annyiban, hogy szerinted. :) Kissé visszautalva az elejére, "Mert ugyan jol hangzik, de konkretumok nelkul keveset er." :)

"4) Akkor hasznald a megfelelo szavakat es akkor majd megertem mit akarsz mondani. Orulok, h tisztaztuk hogy docker cache != docker registry. A cachet takaritom, a registrybol sohase akarok torolni, hogy barmikor barmelyik verziora rollbackelni tudjak vagy a fentebb leirtaknak megfeleloen bugot tudjak keresni."

Ne haragudj, de én a négyes pont kapcsán sosem ejtettem ki a számon a registry szót, azt te képzelted bele. Én ott indításnak csak egy kopipasztát adtam, amiben "docker images" parancsok voltak, feltételezvén, hogy tudod mit látsz magad előtt. Ráadásul középen úgy tűnt, érted is. A kérdéses példa meg egyébként nem éles renszerből jött, hanem konkrétan egy olyanból, ami buildeli az imageket, szóval a kubernetes ott nem tud gczni.

"5,6) Neked mint devopsnak pont az a feladatod, hogy ne engedj :latest-et hasznalni es enforcold a best practise-eket, jellemzoen toolinggal (pl https://github.com/projectatomic/dockerfile_lint)."

Jaja, azzal a toolinggal, aminek a vaskalapos írói nem akarják engedni, hogy ezt csináljam. Nyilván meg tudom oldani azt a rettenetes műszaki problémát, hogy azt írjak egy docker file FROM részébe, amit nem szégyenlek, csak zavar, hogy a tool szerzői nem értik, hogy azt oda minek, ezért nem megy közvetlenül. A linter meg ne haragudj, de megint nem értem, hogy jön ide. Szerintem nem érted, miről beszélek. Nem lehet ma egy dockerfileba olyat írni, hogy FROM foobar:${TAG} vagy hogy FROM foobar@{HASH}, mert azt a docker build nem helyettesíti be. Azért nem, mert fujj, változó, nem variable. Csak egy átlagos pipeline meg pont tudja, mondjuk amikor dependent imageket buildelsz, hogy most ezt konkrétan miből kéne, és horrible diktu automata testek is futnak, párhuzamosan, szóval ez pont amiatt kell. Nyilván, be lehet helyettesíteni helyette seddel, lehet használni a buildelésre compose-t vagy bármi mást, mert nem egy komoly probléma, csak mikor még jól meg is van ideologizálva, hogy miért nem lehet, az vicces.

"Biztos van olyan alkalmazas ahol kell a legujabb foobar-lib, de azert erre mondjal egy peldat,"
Ne viccelj már, ha te még sose láttál fejlesztőt, aki kaffog, hogy miért LTS, meg pláne RedHat, hát abban minden ősi, akkor valami más bolygón lakunk.

"mert a legtobb esetben van erre egyszeru megoldas es illetve a komponenseket nem klasszikus csomagokbol rakod fel, hanem mondjuk npm eseten ugye packages.json vagy composernel composer.json esatobbi. Amugy meg ha teszem az valami :latest-tel keszult is, az taggelt imagem ott van a registrymben es pont tok ugyanaz ami az ugyfelnel fut."
Úgy látom, megint nem érted. Ha már npm meg ésatöbbi (láthatólag a pipet meg a cpant, amit példának hoztam nem ismered, bocsánat, mert akkor rá jöttél volna, hogy erről beszélek), akkor ott már neked kell figyelni arra, hogy az onnan jövő izékkel mi van, mert azok egy átlagos disztróhoz képest jóval kevésbé fogják ilyen szempontból rendben. Más megvilágításban: egy distró is pont onnan csomagol, ha kihagyod a disztrót, akkor neked "kell disztrót játszani magadnak"

"VMware meg nagyon szep es nagyon jo, csak monjduk rakjal mar ossze egy altalad leirt rendszert 5 perc alatt kodbol, kattintgatas es egyebek nelkul. A komplexitas csokkentese meg pont nem az enterspajzokra jellemzo, hanem a modern infrakra." Egyrészt a vmwarenek tök használható APIjai vannak, úgyhogy akár azt is lehet, másrészt bár az infrastrcture as code egy tök jó szemlélet, de nem mindenható. Arról nem beszélve, hogy olyat konténeresdiből sem fogsz összerakni 5 perc alatt (pláne, ha alá az infrát is neked kell -- tudom tudom, olyan nincs)

"A komplexitas csokkentese meg pont nem az enterspajzokra jellemzo, hanem a modern infrakra."
Megint nem értetted. Így van, az enterspájz komplex. Ott ugyanis sokszor nem jellemző, hogy skálázódási probléma lenne, az jellemző, hogy baszott bonyolult rendszererket kell építeni, mert arra van igény. És ezért a microserviceknek az az előnye, hogy jól skálázhatóak, nem igazán érdekes.

"Ez mar regen nem az early-adopterek utani hullam, de nekem mindegy ha valaki igy latja, hat igy latja. A kiprobalt Puppettel meg semmi baj, ha a tovabbi lehetosegek ellenere dontenek mellette, bar ezt ismerven mind a kettot rettento nehez lenne megertenem :D"

Az a baj, hogy neked van egy saját világod, amit próbálsz mindenhova kivetíteni, és képtelen vagy megérteni, hogy van, ahol vannak más szempontok, meg igények. (Gyanús egyébként, hogy ezen igények nálad is ott vannak, csak nem nagyon veszed észre őket), és hiába írod le, hogy nincs silver bulett, csak nem akarod megérteni, hogy én is csak ennyit mondok :) Hogy ez sem jó így mindenhova, illetve, hogy van, ahol jó lenne, de egyszerűen nem éri meg a befektetett energiát a rá való átállás, mert vagy nincs annyi hozadéka (mert a fujj dolgokat már megoldották a puppetben, és nem kér enni), a lehetséges előnyök meg ott nem annyira relevánsak, vagy legalábbis egyelőre úgy ítélik meg, hogy még túl magas a kockázata annak, hogy 2 év múlva megint alapjairól kelljen baszakodni, vagy hogy folyamatosan sok erőt fog elvinni a tooling változása utáni rohanás. (3 hónapos docker release cycle megvan?). Egy szóval nem mondtam, hogy nem jó, nem előremutató, nyilván mi sem véletlen foglalkozunk vele, hanem azért, mert látjuk az előnyeit is.

4) Nyilvan tudom mit latok magam elott, nem kell az oltogatas ;) Megint egy olyan problemat hozol fel amit magadnak csinalsz, mi a francnak buildel ugy a build-toolotok ha a fenti problemat okoz, azert a harom percert ami a cache elonye build kozben (--no-cache)? Fejlesztes kozben nem buildelsz imageket, hogy ez az - egyebkent - jelentos elony meglegyen, ha meg olyan zavaro ahelyett, hogy a cleanupon duhongsz, rakjal ala eleg nagy storaget, hogy ne legyen gond vagy hasznalj valamilyen sidekick gc-t (https://github.com/meltwater/docker-cleanup). Biztos olcsobb mint kezzel takaritgatni vagy cronnal bohockodni.

5,6) "Nem lehet ma egy dockerfileba olyat írni, hogy FROM foobar:${TAG}"

Mert teljesen felesleges es/vagy tobbet art mint hasznal. Valami nagyon el van cseszve azzal a pipeline-nal ahol a FROMot dinamikusan akarod valtoztatgatni, de ha akarod ott a sed nekem mindegy. Ez nem a docker hibaja.

"Ne viccelj már, ha te még sose láttál fejlesztőt, aki kaffog, hogy miért LTS, meg pláne RedHat, hát abban minden ősi, akkor valami más bolygón lakunk." -

Evekkel ezelott ;) Mivel nekem - bizonyos kereteken belul - teljesen mindegy, mivel futtatja a fejleszto az alkalmazasat es az az image minden olyan dependencyt tartalmaz ami kell neki kell, innentol kezdve a problema ismeretlen.

"láthatólag a pipet meg a cpant, amit példának hoztam nem ismered, bocsánat, mert akkor rá jöttél volna, hogy erről beszélek" - pipnek es cpannak is van dependency managementje (requirements.txt es Carton) bar cpannal halistennek az elmult 5 evben nem talalkoztam :D A fejleszto felelossege, hogy a megfelelo verziokat pinelje nem az enyem. Sot, o buildel es deployol is, a you wrote your shit, you run your shit jegyeben :) Bar mivel vertikalis csapatok vannak manapsag egyre ritkabb a fejlesztes vs uzemeltetes szeparacio.

" Egyrészt a vmwarenek tök használható APIjai vannak, úgyhogy akár azt is lehet, másrészt bár az infrastrcture as code egy tök jó szemlélet, de nem mindenható" Ennel jobb szemlelettel eddig nem talalkoztam. Reprodukalhato, unit tesztelheto, nem kell felesleges - hamar elavulo - dokumentaciot irni hozza estabbi, https://techbeacon.com/infrastructure-code-engine-heart-devops

"Ott ugyanis sokszor nem jellemző, hogy skálázódási probléma lenne, az jellemző, hogy baszott bonyolult rendszererket kell építeni, mert arra van igény." mert altalaban nem ertik, hogy milyen elonyei vannak a komplexitas csokkentesenek, tobbek kozt ezert se dolgozom mar enterspajzoknak bar ez mellekes :D

Sztem az alapveto kulonbseg a kettonk latasmodja kozott, hogy te enterspajzozol en meg - mar - nem. Tudom milyen agyament f@szsagok mennek a nagy cegeknel es mennyire fontos a politika a szintiszta technikai dontesek helyett (lasd nem az a fontos amit mond, hanem h ki mondja)

kezdem elveszíteni a reményemet arra, hogy megérted, mit akarok mondani.

"4) Nyilvan tudom mit latok magam elott, nem kell az oltogatas ;)"
Akkor mégis miért hadováltál arról, hogy minek törölnék a registrymből

"Megint egy olyan problemat hozol fel amit magadnak csinalsz, mi a francnak buildel ugy a build-toolotok ha a fenti problemat okoz, azert a harom percert ami a cache elonye build kozben (--no-cache)? Fejlesztes kozben nem buildelsz imageket, hogy ez az - egyebkent - jelentos elony meglegyen, ha meg olyan zavaro ahelyett, hogy a cleanupon duhongsz, rakjal ala eleg nagy storaget, hogy ne legyen gond vagy hasznalj valamilyen sidekick gc-t (https://github.com/meltwater/docker-cleanup). Biztos olcsobb mint kezzel takaritgatni vagy cronnal bohockodni."
Ne csessz már fel. Egyrészt --no-cache buildelünk, bár nem tudom, ez hogy jön ide, mivel itt bakker imagekről van szó, másrészt pl azért, mert tudod, devops, minden potenciális release, azt meg imagek nélkül nehéz, harmadrészt meg persze, tegyek alá végtelen storaget, negyedrészt meg FIGYELJ NAGYBETŰ, tök mindegy én hogy csinálom, meg mit csinálok rosszul, mert ez egy példa volt arra, hogy bugokat kértél, ez meg egy ordenáré nagy bug a dockerban, hogy bemarkol danglingnak olyan imageket, amik nem azok. És hiába próbálod elkenni, hogy te vagy a hülye, hogy egyáltalán ilyet akarsz csinálni (ami szerintem alapvető higénia egyébként), ettől az még bug marad.

5,6) "Nem lehet ma egy dockerfileba olyat írni, hogy FROM foobar:${TAG}"

Mert teljesen felesleges es/vagy tobbet art mint hasznal. Valami nagyon el van cseszve azzal a pipeline-nal ahol a FROMot dinamikusan akarod valtoztatgatni, de ha akarod ott a sed nekem mindegy. Ez nem a docker hibaja.

Hát persze, ha valaki nem úgy akarja csinálni, ahogy azt nagyságos ideológus urak elképzelték, akkor az csak szar lehet. :) Épp erről beszélek.

"Ennel jobb szemlelettel eddig nem talalkoztam." És már megint, az a francos szerintem. A világ nem úgy működik, hogy mivel ez egy jó szemlélet, ezért most azonnal átállunk. Azt meg elegánsan átsiklottad, hogy vmwareben is lehet infra as a codeot csinálni, azt már meg sem merem említeni, hogy természetesen a vmware kattogtatós orchestrationjai is úgy vannak felépítve, hogy kezelik az infrastruktúrát önmagukban

"Evekkel ezelott ;) Mivel nekem - bizonyos kereteken belul - teljesen mindegy, mivel futtatja a fejleszto az alkalmazasat es az az image minden olyan dependencyt tartalmaz ami kell neki kell, innentol kezdve a problema ismeretlen.

Értem én, hogy le van szarva, hogy secure-e, mert az az ő dolga, csak mi van akkor a vertikális csapatokkal. Vagy ezt kompletten le lehet szarni, értem én....

"mert altalaban nem ertik, hogy milyen elonyei vannak a komplexitas csokkentesenek, tobbek kozt ezert se dolgozom mar enterspajzoknak bar ez mellekes :D"
ez így van. Meg mert általában komplex igényeik vannak :)

"Sztem az alapveto kulonbseg a kettonk latasmodja kozott, hogy te enterspajzozol en meg - mar - nem. Tudom milyen agyament f@szsagok mennek a nagy cegeknel es mennyire fontos a politika a szintiszta technikai dontesek helyett (lasd nem az a fontos amit mond, hanem h ki mondja)

Nem, most éppen nem enterspájzozok, az alapvető különbség kettőnk között szerintem, hogy én képes vagyok megpróbálni helyén kezelni a technológiákat, te meg bár állítod hogy nem, de felültél egy hypetrainre, és láthatólag személyes sértésnek veszed, ha az ember beszél arról, hogy az sem tökéletes, vagy hogy hoz be új kihívásokat.

Sztem igyal meg egy pohar vizet mert nagyon felmehett a vernyomasod. A szemelyeskedo hangveteld meg sztem egy szakmai forumon igyekezz mellozni. Reszemrol off a veled valo kommunikacio.

Jajj de kis sértődékeny lettél. :)

Elnézést, nem akartam személyeskedni, a vérnyomásom meg kösz jól van. Egyébként szerintem nem is tettem, ha igen, tényleg elnézést. Ami volt benne, az teljesen pariban van azzal, ahogy te próbálsz engem kioktatni arról, hogy mit csinálok rosszul. Nem látom, hogy hol támadtam volna a személyedet. A véleményed meg az érveid igen, de hát ez meg erről szól. A hadoválszra gondolsz? Ami arra volt válasz, hogy előadtad, hogy ja, ha nem beszélnék összevissza, miközben sosem mondtam a registryről egy szót sem?

Egyébként tök jó volt a beszélgetés eddig, nekem, mint fejlesztőnek egy csomó dologra rávilágított, amivel eddig nem nagyon foglalkoztam.

Az egyik talán legnagyobb probléma a különböző disztribeken található különböző verziójú adatbázis/java/etc. kezelése. Egyszerűen baromira
kényelmetlennek tartom, hogy arra figyeljek, hogy egyszerre X darab disztribució Y verziójával kelljen foglalkozi. Erre talán a docker
egy egészen jó megoldást adna. Viszont ugye ilyenkor bejön a kérdés, hogy ki fogja update-elgetni az egyes image-eket, amikor pl. kijön
egy javítás...

Akkor volt értelme legalább :)

Hozzáteszem egyébként, hogy azt a toolingot, ami e körül kialakul, és azért lökdösi a CI landscapet, egyébként lehet fordítva is tartani és azt leautomatizálni, hogy tesztelődjön sok féle target paltformon.

dup

Ja, azt még hadd tegyem hozzá, hogy az is elég köhögés, hogy azért állunk neki új fsnek, mert valaki köhögött, hogy kell egy tunefs? Ne már, óvoda...

Nehany megjegyzes a Puppet-hez:
- A puppet full ruby a tetejen a DSL-el. Ha nem eleg a DSL akkor lehet irni Type-ot meg provider-t. Es az full ruby. Providerbol meg lehet olyat csinalni, hogy akar WinAPI-t hivsz. (Kicsit perverz, de van, hogy az a legjobb :) )
- Puppet meg docker teljesen megfer egymas mellett. Puppet kodbol tudsz generalni dockert kontainert. Es ez sokkal elorebb mutato, mint a millio soros shell scriptel valo image keszites.
- Idempotens: ha a dockerfile-ban kitorolsz egy felhasznalot, tortenik barmi? Nem, ujra kell buildelned az egeszet, es deployt kell ra.

mar leirtak masok is, de az idempotencia mas.
migraltam mar Puppet verziot, egy 0.24.4-gyel kezdett kodbazist raktam at 2.7-rol 4.1-re.
szerintem az erthetetlen kod a nem idiomatikus kod es pontosan ugyanolyan konnyu eloallitani barmilyen kornyezetben, mert nem a kornyezettol, hanem a felhasznalotol fugg. a Puppetnek ebbol a szempontbol viszonylag meredek a tanulasi gorbeje.

mindegy, csak azert kerdeztem ra mert ugy tunt a hozzaszolasbol, hogy lehet erdekes velemenyed is.

es mennyi ideig tartott a migracio? :)

Gratula a sikeres migraciohoz, de azon kivul, hogy olvashatobb lett a kod, refaktoraltatok par dolgot, gyakorlati haszna ezen kivul lett valami?

Feltetelezem tobbe-kevesbe ugyanazt csinalta amit addig, csak immaron 4.1-en. A felhasznalok/alkalmazasok szempontjabol milyen gyakorlati haszna lett?

Nem kotekedni szeretnek, csak megindokolni, hogy szamomra miert idoelcseszes ezekkel foglalkozni.

par hetig tartott, es arra az idore kaptam egy irodat (mellesleg soha nem voltam meg olyan hatekony, szoval irodat mindenkinek).

a regi kodban hostok helyett objektumokban volt a gepek konfigja, ez megszunt. hierat sem hasznaltunk, az is elmult. kiesett kb. 50 modul es bejott par uj ami atvette a funkcioikat, pl. az 5 apache modul helyett 1. hibaturobb es gyorsabb lett. az uj gepeken megszuntettem a 15 percenkenti agent futtatast es attertunk mco-ra, ezt nem tudom, hogy tovabbvittek-e, mert azota eljottem onnan.

neked a konfiguraciomenedzsment sem ertekes, mert mas a munkameneted, de vannak meg VM-ek meg fizikai gepek a vilagon es azokat is konfiguralja valaki. nekunk sokat jelentett, hogy tamogatott verziora kerult a kodbazis es az uj kollegaknak nem fel ev atlatni, mint nekem volt anno.

Sokkal jobban es atlathatobban felepitheto az ujban az egesz resourcemanagement.
Az sem mellekes, hogy a 2.7-hez egy ideje lejart a support ;)
Tehat nem idoelcseszes, foleg keves ember, tobb ezer szerver eseten :)

A "Jenkinst mire cseréljem" témára subscribe.

Travist ismerem behatobban azt nyugodt szivvel tudom ajanlani. Ezen kivul circleci, wercker amit meg lattam

Infrastruktura CIhoz meg kitchenci

Király, köszi!

Arra figyelj, hogy a Travis-t bizonyos céges környezetben nem tudod majd használni (nem saját infrastruktúrán futtatod)

van nekik olyan valtozat, ahol sajat infran fut. mi igy hasznaljuk, full belso, de ugyanaz a travis kod, mint a kulso, ceges SSOval, mindennel

Mi Codeshipet nyomunk abbol is a Pro-t leginkabb. Ezen keresztul deployolunk is. :)
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

On prem-ben helyette Jetbrains Teamcity. Nalunk nagyon bevallt. De ez csak build, nem "rendes" deployment tool. Lehet deploymentet is csinalni benne, de az egy picit hakolas, ahogy a Jenkisben is, mert az is csak egy build tool.

ahogy a Jenkisben is, mert az is csak egy build tool.

mar miert is?

pl. mert nincs eletciklus-menedzsment, se rollback, se rolling upgrade. de arra jo peldaul, hogy ha a build keszen van, akkor jelezze valami fele, beinditva egy deployt.

akkor engem eddig atvertek, mert en rendszeresen csinalok vele a build utan deployt is (dacara az emlitett dolgoknak)...

nem lepodunk meg

mind a 6-an?

csinalni en is csinalom, csak nem gondolom kozben, hogy az lenne:)

Ha rendes depoloy tool lenne akkor lenne benne olyan, hogy jóváhagyási workflow támogatás, meg olyan, rendes szerepkör szeparáció. ( Aki megcsinálja a folyamatot, az nem indíthatja el, az indító ember meg nem szerkesztheti, és így tovább.)

Nekem a rendes deployment tool az az Octopus . Az tudja a fenti kritériumokat.

Attól, hogy command line stepként megcsinálod a deployt, attól az eszköz (Jenkins, TC, Bamboo, stb) még nem arra való.

ugy imadom, amikor okos emberek megmondjak, hogy mi mire valo. Ha neked nem is fer bele a 'rendes' deployment cuccok koze, a keszitoi szerint attol meg arra is valo...

Bizonyos kornyezetekben ez elvaras, de ettol meg nem rosszabb a masik sem. Tobbsegeben erre egyszeruen nincs szukseg.

Es itt fogtad meg a lenyeget: Az esetek 99%-ban azert lehet hasznalni a CI toolt deployra, mert nem kellenek / nem hianyoznak azok a feature-k amit egy deployment tool tud. De attol meg nem art tisztaba lenni azzal, hogy attol, hogy lehet, meg nem arra van kitalalva.

"Aki megcsinálja a folyamatot, az nem indíthatja el, az indító ember meg nem szerkesztheti, és így tovább."
Tehat a role-okra gondolsz, mert tudja ;)

+1

Halal rajuk, sok oskori monolit statikus vacak: nagios, zabbix, cacti, munin, icinga
Sokat hasznaltam oket, manapsag mar a rosszullet kerulget ha meghallom a nevuket.
Helyettuk lehet valogatni: Influxdb + Grafana, Elastic + Beats, Datadog, New Relic igy hirtelenjeben.

"oskori monolit statikus vacak"

a) Attól hogy valami régi még bőven nem feltétlen vacak
b) Nem minden alkalmazást célszerű atomjaira cincálni, van néhány elhízott projekt amit -amíg van aki átlátja- jobb egyben tartani

Miért van mindenki meggyőződve arról hogy ezek az alkalmazások drag&drop helyettesítik egymást? Tisztára mintha egy épp csak végzett műmanagert hallana az ember. vagy valami ellszált frontendhypstert aki esetenként többet csereberéli az eszközeit mint hogy használná őket..

Talan abbol vagyok meggyozodve hogy a kommentemben felsorolt alkalmazasok mindegyiket epitettem fel 0-rol illetve uzemeltettem hosszutavon az elmult 15 evben.
Es biztosithatlak hogy barki aki egyszer mar dolgozott influxdb+grafana-val peldaul, az soha a budos eletben a tobbe kozelebe nem megy semmifele rrd alapu osi hulladeknak, max langszoroval.

Ne keverd a szolgaltatast az alkalmazassal.

Az influxdb + grafana, illetve az elastic + beats alkalmazasok es nem szolgaltatasok, a masik ketto valoban szolgaltatas.
A szolgaltatasok pedig szerintem siman labdaba rugnak az alkalmazasok mellett mert amennyi mernokorat ra kell forditani annyibol megveszed a szolgaltatast is, ez foleg kis csapatoknal tud kritikus lenni ahol nincs eleg ember.

Akkor se keverd ossze, te tegyel kozejuk egyenloseg jelet. Fingod (fingunk) nincs, milyen megfontolasbol olyan az infrastruktura amilyen.
Nemmellesleg tokmind1, melyik szolgaltatast vagy alkalmazast hasznaljak, ha azzal viszik sikerre a projektet.

Ne itelkezz latatlanban:)

vannak cuccok amik osidok ota velunk vannak, jol mukodnek, teszik a dolgukat, "nem kell oket megjavitani" (pl jenkins+pbuilder). majd ha elromlanak megjavitjuk oket, ha nem lehet, akkor lecsereljuk valami masra. (igy jar pl a nagios is epp).

a puppet is bevalt, nalunk teszi a dolgat, nincs semmi okunk levaltani. (meg a migralas koltsege > valami mas hasonlo cucc nyeresege).
majd ha elfogytak a futo projectek, es unatkozunk akkor ilyeneken is elgondolkodunk :)

docker: van X webkiszolgalo, Y database kiszolgalo, Z mas egyeb kiszolgalo gep, mindegyik a neki megfelelo aranyu hw komponensekkel (cpu/ram/ssd), nemvagyunk eroforras szukeben, nemkell se uj eroforras, se ide-oda maszkalnia a cuccoknak. (es megint ottvagyunk hogy a docker adta elonyok nincsenek egyszinten a migralas ido es penz koltsegevel)

de ofc. nyitottak vagyunk, ha latunk valamiben potencialt, es hasznos/jo a cucc, akkor azt hasznalni fogjuk

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nem nekem szolt a kerdes, de:
- nagios
Nagiosnal jobbat eddig nem talaltam. Probaltam mindenfelet de amint odakerult, hogy elkezdtek dbbe tarolni adatokat meg check resultokat onnantol kezdve vegtelen eroforras kellett mindnek.

Szoval en inkabb kozponti helyen db paroson tartom configot es onnan szorja ki valtozas eseten (gepek lejelentik magukat es automatan monitorozodnak). nagiosonkent most van ~35k service check, de lofasz gepeket lofasz diskel hasznalok erre a celra es igy sincs load vagy tul sok mem hasznalat. A nagios status.dat fileokat meg kozponti monitoring osszemergeli es azt jeleniti meg.
A service/host addolas siman rest apin megy. biztos volt vagy 2-3 ora megirni hozza apit, de cserebe nem kell szopni egyeb tulbonyolitott "skalazodo" megoldasokkal.
Meg annyi, hogy nem hasznalom regi nscat, hanem normalis van helyette, mert a checkek nagy resze passziv.

De ha valakinek van nagios alternativaja, ami nem ker tobb eroforrast mint a checkelendo gepek, akkor johet tipp :D Termeszetesen nem egy 50-100 servert checkelo megoldast keresek, mert azt egy bash script is tokeletesen ellatna.

- munin
Amit viszont le akartam cserelni en is az a munin. Vegul maradt, de nem hasznalom cgiket meg png/html generalas featuret, hanem rrd fileokat js olvassa fel es highcharts megjeleniti.
Igyis sokat eszik, de nem annyira veszes mar. Viszont ezt nagyon le akarnam cserelni vmi jobbra :D

Nezd meg a Prometheust, Grafanaval eleg meno tud lenni, persze itt is kell masszirozni es igen eroforrasigenyes is tud lenni of course :) https://prometheus.io/docs/introduction/comparison/#prometheus-vs.-nagios

Nem rossz cucc a prometheus (nekem is fut par darab itt-ott), de velemenyem szerint egy jol belott zabbix totalisan jo ilyen celokra is.

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

amig nem lattad a datadogot. :)

a datadog fasza, viszont pl Kubernetes eseten sokkal kevesebb metricet ismer mint a Prometheus es vannak ezek kozott fontosak is

mintha olyan nehez lenne barmit betolni bele...

raadasul ha az official plugin hianyos, akkor vagy szolni kell nekik, hogy sracok, toljatok, vagy bele kell irni.

Nem a nehezseg, csak mivel nativan exposeol Prometheus metriceket nekem egyszerubb azzal monitorozni.

datadog nagyon jonak tunik. De ez havi ~400k dollar. Persze latom van volume discount. Tudod esetleg mennyi az annyi?
Mert havi 400k-ert esetleg jobb toolt lehet iratni, mint ez. Vagy akar fedezi valami mar letezo java alapu monitoring havi hostingkoltseget. :D

ha elore fizeted akkor olcsobb; 100-as packokban lehet venni eves fizetessel, PO-val, illetve lehet kotni ceges master agreementet; 1000 gep felett kezdodik a discount

dinamikus kornyezetekre jo az is, hogy ha mondjuk vettel 1000 licenszet, de neha atleped, akkor az nem szamit - ha jol emlekszem, a 95%-at nezik a havi hasznalatnak, orankenti bontasbol

Neked mi volt elotte es milyen temakorben erzed, hogy elorebb leptel datadoggal? Tehat milyen real life elonyeit hasznalod ki?

zabbix volt, es epp prometheus/influxdb+collectd+grafana paroson gondolkoztunk amikor jott a lehetoseg, hogy valtsunk

ami szerintem tok jo:
- statuspage integracio (mi hasznaljuk, ez az "exec dashboard")
- pagerduty integracio az on-callhoz riasztasokhoz ha leallna vmi (ezt most vezetjuk be)
- app integraciok (kismillio appunk van, nem nekunk kell megirni oket - rabbitmq, haproxy, etc)
- nem kell foglalkoznom azzal, hogy most epp gyujtom-e a metrikakat, van-e alatta eleg helyem, etc (SaaS elonye)

ha kellett egy custom metric zabbixba regen (pl ceph osd latency) azert rament sok ido osszerakni, most eleg behuzni az integraciot, es altalaban ott van. ha meg custom metricet akarunk feltolni, amit nem tud semmi, akkor egyszeru.

persze van az az osszeg, ahol mar erdemes akar kulon embert felvenni aki csak ezt csinalja - ez a 400k amit irtal, ilyen, viszont a valo elet meg ugy mukodik a legtobb nagy cegnel, hogy egyszerubb ranyomni a 400kt egy PO-ra, mint embert felvenni akar fele ennyiert...

Szia,
a puppett-et javitsd ki legyszi. Koszi.

ah kosz. ez atcsuszott az ellenorzeskor... :(

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

bocs, hogy lenyultuk a hirdetest, mondjuk igy legalabb szem elott van :)

nempara, jo diszkurzus kerekedett a temaban. :)

meg mindig jobb ez mint a szokasos me' kell mindenhez is erteni/me' nincs dijazas kiirva/stb fikazas...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

me' kell mindenhez is erteni
me' nincs dijazas kiirva

???

:(((

Miert kell elrontani a jatekot ?

Pont most akartam ezeket ideirni. :D

Ez igy nem hupikus, hogy nincs ilyen egy hirdetesnel.

http://karikasostor.hu - Az autentikus zajforrás.

Miert nincs cim, legalabb kerulet?
Ha nem a 27. keruletben van, nem is probalok jelentkezni!

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Jó fejek, tényleg lehet sokat tanulni ott, sok mindent jól csinálnak, akad javítani való is, de hol nem?!

Amerikában nagy buli van most emiatt a mérnökösködésből. Hacsak nem végeztél mérnök infót akkor nem vagy mérnök.
Progmat, egyébb okj nem mérnök. Sztem lesz még ebből itthon is gond.

--
GPLv3-as hozzászólás.

linket erről? köszi :)

Megvizsgálnám a politikát is: ki politikus valójában? Hasonlóképpen. Mindenki "az", akinek mondja magát, LOL.

--
robyboy

sub

----
올드보이