Sziasztok!
Érdekelne a véleményetek, tapasztalatotok!
A karácsonyi bejgli hatására eldöntöttem, hogy KVMről átnyergelek Docker-re.
Cél a production, stabilitást, "gondozás mentességet" szeretnék elérni, úgy ahogy az Debian Stable nyújtja a KVM-mel jelenleg.
Első és legfontosabb, hogy teljességgel zöldfülű vagyok a Docker és a production viszonylatában. magamnak már el mórickáztam vele localhost-on, de az messze van a prodtól.
Több domain hostolása a feladat, websiteok + levelezés. OpenVPN lenne még. Website-ok alá mongodb, mysql..de ezek az apró körítések már csak.
A DNS-t a domain regisztrátora adja.
Első kérdés:
Ki mit ajánl host os-nak bare metal-ra? ( HP DL360 gen6, 12 szál, 12Gb ram, 600Gb storage)
Ha nem muszály, ajánlott, javasolt cserélni, megtartanám a Debian Stable-t.
Ismerem, szeretem, és nem kell remote konzolt kérni a szerver újratelepítéséhez,(illetve Victor Hugo-ba fáradni) ha marad host-nak :D
Ubuntu, hát nem tudom, ( bizlmatlan vagyok, mióta a Cannonical kezd "el Microsoft-osodni" )
Ellenben a Fedora Atomic szóba jöhetne. Tetszik az OSTree megoldás alapvetően. Tudomásom szerint a RHEL8 már béta teszten van,
esetleg érdemes lenne kivárni még a Centos 8 kijön, sima, esetleg atomic verzióban? Fedora release "túl gyors" szerintem szerverként, a Centos 7 jelenleg meg
le van maradva mint a befőtt. Ugyan nem tudom Docker futtatása esetén ez mérvadó-e. Hiszen a konténerek 90%-a úgyis Alpine Linux, ott kell frissnek és szépnek lenni.
Ha már szóba jött, valakinek van szervere Alpine Linux-xal?
Csábító dolog a CoreOS, RancherOS is.
Második kérdés:
A docker áltat létrehozott hálózaton érdemes tovább tekerni, vagy megfelelő úgy ahogy van éles környezethez?
Gondolok itt elsősorban arra, hogy a konténerek ugye közzé teszik a saját kis portjaikat, amik ezáltal a publikus ip-n elérhetőek lesznek.
Érdemes-e inkább valamilyen saját vitruális hálózatot csinálni, amit aztán lehet farigcsálni kényem kedvem szerint, esetleg megfejelni valamilyen IPS/IDS megoldással,
ha van rá szükség, esetleg javasolt?
Harmadik kérdés(ek):
Kinek milyen tapasztalata van Postfix, Dovecot, MongoDB, OpenVPN futtatásával Docker konténerben?
Érdemes mások által már összeállított image-ekkel dolgozni, vagy jobb az ha az ember fia saját magának építi?
- 2673 megtekintés
Hozzászólások
s
- A hozzászóláshoz be kell jelentkezni
Hali!
Az emberek hajlamosak belefogni a mákos bejgli hatására nagy dolgokba. Ilyenek a hamarosan aktuális újévi fogadalmak. :)
A "muszáj" pontos j! Bocsi, de bántja a szemem.
Engedd meg én is kérdezzek pár dolgot, illetve, amiket tegyél fel magadnak és válaszold meg önmagadnak.
- Tudod mi a különbség a Docker és a KVM között?
A leírásod alapján nem vagyok benne biztos, azért kérdezem.
- Hogy akarsz egy rendszert production-ben üzemeltetni, ha nem is ismered kellő mélységében a technológiát? (Te magad írtad)
Amit írtál azt nem szabad egy lépésben meglépni szerintem.
Szerintem a sikeres projekt titka:
- Feladatok összegyűjtése. (Milyen szolgáltatások kell,hogy elérhetőek legyenek most és milyen szolgáltatások várhatóak a jövőben? Felhasználók igényei.
- Ezek után jöhet a realizálás. Például túl sok időt igénylő elvárások törlése.
- Majd az új szolgáltatás tervezése. (Hány node van/kell, közös storage, hálózat, mennyire fontos a rendelkezésre állás, szükség van-e skálázhatóságra, security, konténer update, OS upgrade, hogy lesz, backup, hogyan állítod vissza, he egy konténer hibára fut stb.)
- Ha megvan a terv, akkor előző lépéssel összhangban a számodra megfelelő tudás megszerzése, majd a lehetséges megoldások tesztelése zárt környezetben. (teszt rendszer), különböző tesztek futtatása, hogy ne érjen meglepetés.
- Következő lépésben felépíteni egy staging-et, ahova már néhány teszt felhasználót is be lehet engedni. Itt is tesztelni, hogy az általad összerakott rendszer megfelel az elvárásoknak vagy még hangolni kell rajta.
- Ha megvan, akkor meg kell tervezni az átállást, majd szépen fokozatosan átállni az új technológiára.
Kérlek segítségnek vedd soraim, mert annak szántam! Ezzel tudok a legtöbbet segíteni neked. Írhatok konkrét tapasztalatokat, de amíg az alapokat és a lehetőségeid sem ismered megfelelő mélységében, addig azzal te nem leszel előrébb és ha valami nem úgy sikerül, akkor én kapom a hideg zuhanyt, hogy hülyeséget mondtam neked és szakmaiatlan vagyok. Arra figyelj oda, hogy valami egyedi alkalmazást kell konténerbe tenned, nem biztos, hogy fel van készítve rá maga az alkalmazás.
Aminek mindenképp javaslom, hogy olvass utána:
- Docker alapok (konténerek készítése, hálózat kezelése, volume-ok, port binding)
- Cluster lehetőségek ( Docker Swarm vagy Kubernetes)
Remélem sikerült átadnom, amire szeretném felhívni a figyelmed és megérted, hogy ha jó munkát szeretnél kiadni a kezedből lehetőleg minél kevesebb problémával, akkor ez egy járható út hozzá.
- A hozzászóláshoz be kell jelentkezni
Még annyi kiegészítést tennék hozzá, hogy szerintem alapvetően el kellene döntenie, hogy mit is vár az átállástól, mi a cél.
Például: Költségcsökkentés? Rendelkezésre állás növelés? Alacsony RPO/RTO DR esetén?
A Docker nem egyenlő "gondozás mentességgel"! Aki ezt hiszi, azok csinálnak olyan "múmiákat", amiket később mindenki csak kerülgetni fog, amíg működik. Aztán ha beüt a krach, akkor jön a pingvinezés. Valahol láttam erről egy jó előadást is, de most nem tudom a címét.
A topicnyitó 2. kérdésére: mindenképp érdemes a hálózatot minél szeparáltabbra megcsinálni. Legyen tűzfal mindenhol. Szívem szerint IDS/IPS-t is tennék be. Első körben a külső kapcsolatokra, később akár a belső hálózatok közé is.
- A hozzászóláshoz be kell jelentkezni
Köszönöm a hozzászólást!
A "muszáj" miatt sorry :D
Magával a KVM-mel tisztában vagyok évek óta, és több mint fél éve foglalkozom a Dockerrel. Lehet hogy nem tudnék a különbségekről teljeskörű esszét írni, de ki merem jelenteni, hogy igen, tisztában vagyok vele.
Így ha nem is teljeskörűen, de szerintem a nagy átlaghoz képest tisztább a kép ami a Dockert illeti.
A felhasználók igényei, illetve a jövőbeni kérdések már tisztázottak, azzal is rendben vagyunk.
Egyetlen szerver van, és ebből nem is lesz más..megmarad standalone. Így nincs se HA, se shared storage, sem cluster igény.
A megfelelő tudás megszerzése. ezt szerintem 70-80%ban megvan, nyilvánvalóan production tapasztalat nincs. Ezért is írtam, hogy ha valakinek van, és megosztaná...
Segítségnek veszem, és egyet is értek a válaszoddal. Én nem voltam elég egyértelmű. Nem új keletű az átállás gondolata, és előkészületek, tesztek is történtek már dögivel.
Mivel alapvetően rendben zajlottak, ezért született meg a döntés, hogy akkor élesbe átállás.
"Írhatok konkrét tapasztalatokat, de amíg az alapokat......Arra figyelj oda, hogy valami egyedi alkalmazást kell konténerbe tenned, nem biztos, hogy fel van készítve rá maga az alkalmazás."
Nos, köszönöm, ilyen, és hasonló dolgok érdekelnének első sorban. Mert jelenleg nincs olyan alkalmazásunk ami ne menne az előzetes tesztek alapján.
Az pedig, igen, figyelmen kívül lett hagyva mint buktató, hogy lehet-e vagy sem.
- A hozzászóláshoz be kell jelentkezni
Ha muszáj, akkor muszáj :)
Nem kell nagy esszéket írni csak értsd, hogy mi az alapvető különbség a kettő között.
Nem kis munka egy ilyet production-be üzemeltetni,tehát ahogy fentebb írták meg kell nézni,hogy megéri-e a befektetett munka és találkozik-e célokkal.
Ha csak egy node-od van és semmi esély sincs rá,hogy kelleni fog több node (itt most jót mosolyogtam, mert az esetek nagy részében kiderül,hogy jó az adott dolog és kéne több node is! ) , akkor simán docker. De, ahogy fentebb írtam a zárójelben, amint felmerül az igény,akkor ez megy a kukába és lehet nézetni a Docker Swarm-ot, meg a Kubernetest.
Ha minden menni fog, akkor lehetne egy staging rendszert építeni valahol és teszt jelleggel pár szolgáltatást betenni alá. Amiket írtam azt ne felejtsd el, mint volume-ok, security concept, konténer frissítési terv, Host OS frissítési terv, Backup.
Így elsőre nem látom értelmét mindent bekonténerezni, mert amiket írtál azok jól megférnek egymás mellett is.
- A hozzászóláshoz be kell jelentkezni
A karácsonyi bejgli hatására eldöntöttem, hogy KVMről átnyergelek Docker-re.
jujujuj, -1. De ha a mysql-t docker-ben apro koritesnek erzed, akkor inkabb -2*.
Azt nem mondtad, hogy hany szervered van. Ha 1, akkor nem jo. KVM-re sem. Hol van a storage-od? Ha nem valami redundans san/nas, akkor erre sem fogadnek nagyobb osszeggel.
Csábító dolog a CoreOS, RancherOS is.
az, de ha nem ismered ugy, mint a debian-t, akkor (addig) nem ajanlom production-be (neked).
a konténerek ugye közzé teszik a saját kis portjaikat
ez egyaltalan nem azt jelenti, hogy kivulrol is elerhetoek (hint: -p kapcsolo). De ha egy bizonyos port egy masik kontenernek kell, akkor csinalj annak a 2 (vagy tobb) kontenernek egy docker halozatot, es akkor -p nelkul is elerik egymas portjait.
Kinek milyen tapasztalata van Postfix, Dovecot, MongoDB, OpenVPN futtatásával Docker konténerben?
arra kell figyelni, hova teszed a perzisztens adatokat. Ha 600 GB-od van osszesen, az nagyon karesznak tunik.
Érdemes mások által már összeállított image-ekkel dolgozni, vagy jobb az ha az ember fia saját magának építi?
ha official, akkor (valoszinu) lehet. De lehet, hogy jobban jarsz, ha te rakod ossze, igy kezedben van a frissites.
Ja, es a monitorozast is erdemes elkezdeni: https://sj.acts.hu/2018/11/02/using-cadvisor-to-get-a-peek-to-docker/
*: a gerrit code review-ban a -2 az ubergaz szinonimaja
--
O1G
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Oké Oké Oké!
Elmúlt a bejlgi hatása. Nem lesz itt semmi amíg ilyen és ehhez hasonló dolgok történnek a nagyvilágban...
Kizárt hogy 3rd party image-et beengedjek, de már a kedvem is elment az egésztől...
S senkinek sem ajánlom..aki meg úgy gondolja, hogy beszél a zöldfülű, akkor lássunk egy példát.
Kíváncsi leszek az eredményre....
lehet nyitni a bash-t, és parancssorba lehet gépelni.
1, "id" => az aktuális useredet látod.
sudoval vagy ahogy tetszik, hozz létre egy usert..
2, sudo useradd -u 4000000000 malory
3, passwd malory
4, su malory
5, systemctl reboot -i
aztán amikor a géped újra indult úgy, hogy SEMMI JOGA sincs egy mezei "Malory"-nak a GÉP ÚJRAINDÍTÁSÁRA...aztán visszatérsz ide a fórumra.
ezt a pár parancsot minden gond nélkül be lehet tolni egy docker konténerbe létrehozás, vagy futtatásnál...
vagy ami még rosszabb, ha a script csinál egy saját systemd service-t, valami finom fork bomb-ot rak bele, vagy "a képzeletetekre bízom azt a bármit" és vígan lefuttatja a buildet a gyanútlan "devops", aztán mehet a run...mert hát az image az trusted forrásból származik....
aztán meg elpánikol a kernel..
jó az a KVM, mindig ugyanoda kanyarodok vissza valahogy...
- A hozzászóláshoz be kell jelentkezni
hubaz, most kivert a viz rendesen. Te bebaszva hupozol? Nincs egy kicsit koran a szilveszteri tomenyhez?
ezt a pár parancsot minden gond nélkül be lehet tolni egy docker konténerbe létrehozás, vagy futtatásnál...
$ docker run -ti --rm --name malory ubuntu:18.04 bash
root@4da4516950d1:/# useradd -u 4000000000 malory
root@4da4516950d1:/# passwd malory
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
root@4da4516950d1:/# su malory
$ systemctl reboot -i
sh: 1: systemctl: not found
$
jaj-jaj, vajon mit rontottam el?
vagy ami még rosszabb, ha a script csinál egy saját systemd service-t
lol, aminek mi koze is lesz a host-hoz? Semmi (ld. fentebb)?
valami finom fork bomb-ot rak bele,
hat, mindenesetre az biztos, hogy a te docker image-eidtol nem kell felni. A tobbire meg lehet kulonfele limiteket rakni (memoria, cpu, whatever). De abban igazad van, hogy csak olyan image-et hasznalj, aminek megbizol a keszitojeben is (legalabbis abban az ertelemben, hogy nem akar neked artani).
aztán meg elpánikol a kernel..
az elmeleti veszelye valoban megvan. Mint ahogy a kvm eseten is.
jó az a KVM, mindig ugyanoda kanyarodok vissza valahogy...
tenyleg jo. De aki nalad csak egy kicsit jobban otthon van docker ugyben, annak nem kell felnie tole. Te meg egyed tovabb a bejglit, de a pialast nem kene eroltetni hupozas kozben, lol...
--
O1G
- A hozzászóláshoz be kell jelentkezni
O1G
gépeld be a hoston...
de hagyjuk...én be vagyok baszva.
igaz nem próbáltam én se felmountolni a dbust meg a systemd-t csak poénból
-v /var/run/dbus:/var/run/dbus -v /run/systemd:/run/systemd -v /usr/bin/systemctl:/usr/bin/systemctl -v /etc/systemd/system:/etc/systemd/system
várom az újabb így se működik commentet...de hoston lefutott az is fix...
- A hozzászóláshoz be kell jelentkezni
sigh. De ki az a nagyon nem normalis, aki dbus-t, systemd-t be akar huzni egy docker kontenerbe, amiben jellemzoen egyetlen processz/szolgaltatas fut? El-o-el, belukam. Mondom, hogy be vagy baszva.
Meg mielott valami hasonlo korszakalkoto otleted lenne: probald meg root-kent (a hoszton) kiloni magad alol a particios tablat. Sikerulni fog! Whooaaa! Nem fog bootolni a geped! Vilagvege! SzanaLOLm...
--
O1G
- A hozzászóláshoz be kell jelentkezni
Mondjuk az az aranyos agyonnyomott "developer" aki aztán tényleg részeg velem ellentétben.
S akkor majd én leszek a részeg mert biztosan egy xar rendszert építettem...
Vagy nálad a jó isten szeme minden deployt, meg agyon automatizált buildet lát?
Amúgy szívesen...a hiba mind máig javítatlan...és ha csak abból indulok ki hogy minden systemd-s linux érintett jelenleg...
- A hozzászóláshoz be kell jelentkezni
"Vagy nálad a jó isten szeme minden deployt, meg agyon automatizált buildet lát?" nem, nalunk code review van ;)
- A hozzászóláshoz be kell jelentkezni
Értem.
Tehát akkor egy olyan kis cégnél, ahol az a maroknyi fejlesztő ugyanúgy fölényeskedik egymással mint itt ti..pusztán csak azért mert valamit jobban tudtok a másiknál...
A szakmai féltékenység mintapéldányai...épp úgy ahogy a minősítgetések érkeznek itt.
Mi van ha a cégnek nincs erőforrása 20 db szerverre csak max 2 re, és ne adj isten, ha feljődni szeretne akkor inkáb húzza le magát a vécén mert mi a fenét ugrál, biztos részeg??
A productionbe szánt kódnak még dokumentációja nincs, nem hogy review...igen, gáz, de ez a való világ, nem a hortonworks, meg ahogy egyéb szebb jobb helyeken van...
De azért kíváncsi lennék, hogy vajon a többség akik ilyen bátrak, azok vajon anyatejben szívták magukba a tudást?
Vagy esetleg ők is voltak kezdők?
de az eredeti kérdésre eddig 2 használható sor érkezett eddig...maga a HUP -3, mert azzá teszitek...nemtudom a a gerrit code review mit mond erre....
El se olvassátok a kérdést rendesen...leginkább azok akik egyből támadnak...
Nah lehet moderálni, meg törölni a felhasználómat is...
érdemi segítséget egyszer kaptam itt tőletek...ha meg véleményt, vagy tapasztalatot szerettem volna kérni, mindig ugyan ez lett a vége..
Személyeskedés, és olyan vélemény formálás, aminek köze sincs már az eredeti topichoz...
" Orvos, gyógyítsd önmagad! "
- A hozzászóláshoz be kell jelentkezni
Különböző méretű projektek és környezet okozza az ilyen vitákat.
Jómagam szintén KKV és van 2 db prod szerver. Az egyik igazából egy backup és telephelyi router a másik hostingolt fizikai vas, amin fut az egész céget vezérlő alkalmazás.
Azokon a gondolatokon, hogy KVM, Docker én is végigmentem. Arra jutottam, hogy számomra nem egyszerűsítene semmit sem, mert minden ami informatika azt én csinálom egyedül. Ha a rendszerek és alrendszerek számát szaporítom, akkor a hibák számát és a beleölt munkaórákat is szaporítom akaratlanul.
Meg kell említenem, hogy a kritikus szó mást jelent egy ilyen környezetben. Konkrétan azt jelenti, hogy a rendszer megléte lét kérdés, de pár órás szolgáltatás kiesés költsége kisebb, mint amennyibe kerül, hogy ne legyen ilyen (HA).
Továbbá fontos tényező az is, hogy valós rendszerfelhasználó ezeken a szervereken 1 db van: én. Mindenki más virtualuser. Emiatt sincs olyan gondom, hogy jól szeparált rendszereket kelljen csinálnom.
Persze az érveket ismerem: miért nem megyek VPS-re. Csak. Szeretek dönteni a sorsom felett. Szeretem, ha kezemben van az irányítás. Egy lúzer vár, egy tökös cselekszik. Ez a különbség az emberek között és én utálok másoktól függeni, másokra várni.
ps.: a fejlesztői gépeim OS-se és verziója is azonos proddal
- A hozzászóláshoz be kell jelentkezni
Köszönöm Oregon!
+1
Ilyen és ehhez hasonló hozzászólásokra lenne szükség valójában. Mert itt is szinte ugyanez a helyzet. Azért van tolva a Docker mert a fejlesztők tolják..és egy darabig én is lelkes voltam, mert azt éreztem, hogy ha már a dev megcsinálja "magának" akkor ugyanazt a konténert akár prodban is lehetne futtatni...lehetne.
Azán valahogy mégsem egyszerűsödik tőle az élet, sőt, már inkább több veszélyt látok benne mint hasznot.
- A hozzászóláshoz be kell jelentkezni
Amúgy a másik oldalnak is igaza van, nagy n-ek esetén. Kis n-ek más stratégiát kívánnak. Így ami kicsiben nem gond, az nagyban egy hatalmas baklövés tud lenni.
- A hozzászóláshoz be kell jelentkezni
Amugy itt jonnek kepbe a devops-ok, akik segitenek a deveknek, hogy naluk is mukodjon meg osszedolgoznak az opsokkal, hogy ott se legyen tragya, es megtervezik a pipelinet, hogyan lesz a dev changbol futo rendszer. Nem azt mondom, hogy lehetetlen devops engineer nelkul ez jol megcsinalni, de az biztos, hogy az egymasra mutogatas ugyanugy megmarad, mint elotte :)
- A hozzászóláshoz be kell jelentkezni
Van egy erzesem, hogy amit ramontottel, azt ugy a kozobe szantad, mert en nem vetettem ellened :) Amugy a code reviewhoz nem kell giga cegnel dolgozni, ahol 2 ember van ott lehet reviewzni, ez csak szokas/megegyezes kerdese. Szoval azert nem erdemes a dockert hibaztatni, mert lehet vele hulyeeget csinalni. Vegulis vegul ugyis egy kutyakozonseges process fog futni, es ha adsz jogot a processznek, akkor lesz neki.
Nem anyatejben szivtuk magunkba, hanem elkezdtuk hasznalni, eloszor kevesbe kritikus rendszereknel, es haladtunk a productionhoz. Egy meglevo mukodo rendszert csak nagy korultekintessel erdemes lecserelni. Amugy magaval a docker stabilitassal nincs gondd, a futo rendszerig eljutni macerasabb talan, 1000 olyan helyen pusztulhat el, ami kontenerek nelkul fel sem merul. En azt javaslom, hogy tegyel at egy hostot, lodd be a monitorozast!, a tobbi meg jon majd magatol. Sajnos eleg nehez elore megmondani, hogy mivel fogsz szivni, leveln nem ismerjuk a mit akarsz rajta futtatni.
Nalunk pl policy, hogy kerulni kell a mindenfele imageket. Sajnos ez oriasi para a kontenerekkel, hogy mindegyik hozza a kornyezetet, ami 100 sebbol verezhet, es verzik is. Leteznek eszkozok, hogy vizsgaljak az imageket, es pontozzak biztonsagi besorolas szerint. Nalunk egy kulon reszleg foglalkozik kb ezzel a reszevel. Mert sajnos hiaba buildeled magadnak az imaget, semmi nem garantalja, hogy nem huzol be egy sebezheto libet. amire mondjuk mar van javitas a repoban, csak az imageben nem frissul.
Ha mar production en azt javaslom, hogy torekedj az immutable infrara, tehat a kontener nem valtozhat, nem nohet a root disk, stb. minden ami valtozo adat az keruljon volumeba. Ezzel is el lehet szoszolni. Eleg kellemetlen, amikor egy ko ntener elszabadul, mert a default volume amit ad a docker eleg karcsu, es hamar betelik.
Amugy terevezitek devek szintjere felvinni a dockerezest? vagy ok odaadjak az appot, es tebuildelsz mindenbol imaget? Utobbi jo nagy szivas, elobbivel meg az a szivas, hogy a teljes dev/test/release folyamaton at kell verni a dolgot.
Network, olvass utanna rengeteg banchmark van. A legtobb dologra jo a default network, foleg amig egy gepen vagy, ott lenyegeben netfilter magia van csak.
Ossz egeszeben oriasi szivas az egesz kontenerizacio, bar mar rengeteg tapasztalat van vele, megis szerintem az van, hogy tud egy csomo dolgot, es ha a tudasa passzol a kovetelmeny listaddal, akkor erdemes belevagni, ha pedig nem, akkor nem oldd meg letezo problemat cserebe general ujjakat.
- A hozzászóláshoz be kell jelentkezni
Köszönöm mhmxs!
+1, hasznos tanácsok tömkelege!
Igen, globál szólt a "világfájdalom", természetesen nem neked!
Jelenleg folyamatosan kapom a forráskódot a dev-től, és szépen kipakolom a prod rendszerre. Lényegében ezen szeretnénk változtatni, gyorsítani, egyszerűsiteni.
Kézenfekvő választásnak tűnt a Docker, mert jelenleg a feljesztők csak indítanak egy két konténert, nginx, mysql, amit kell, és máris mehet a webapp fejlesztés.
Aztán én meg sírok mint az oltár előtt hagyott menyasszony, hogy adjátok a forrást, meg a mysql dumpot, vagy épp amit kell (csak példa volt), és dobom szét a VM-ekre, prodon.
Eredeti tervek szerint a dev már a kész image-et adná, sőt, lényegében az lenne a cél, hogy én ne is kelljek egyáltalán az alkalmazások frissítéséhez, prodba rakásához.
S a Docker azt az érzetet kelti, hogy cseréljük le a jelenlegi rendszert úgy ahogy van, és megoldódik.
Mert vagy marad a jelenlegi rendszer, és megfejeljük valamilyen CI/CD-vel, mert most jelenleg én vagyok a "Continous Delivery". Hozzáteszem nem nekem van vele bajom, mert nem halok bele ha kapok már php scriptet, meg typescript kódot.
- A hozzászóláshoz be kell jelentkezni
"és megoldódik" hat nem. sokat kell rajta maszirozni, mire eleritek, hogy dev commitol, lefutnak a tesztek megbuildelodnek a kontenerek, kimegy qa-ra, ott megfutnak meg tesztek, aztan prodba kerul, es a prod kornyezet eszreveszi ha valami nem jo, es rollbackel. Mert vegulis ezt kene megvalosiotani, igy ad pluszt a docker, azzal, hogy garantalja, hogy ugyanazon futott a teszt, mint ami elesbe megy, es nem csak valami hasonlon.
- A hozzászóláshoz be kell jelentkezni
+1
Köszönöm!
Már én is kezdem jobban átértékelni, hogy koránt sem kánan amibe bele akarunk nyúlni.
- A hozzászóláshoz be kell jelentkezni
Ahogy én látom arra (pl) tökéletes, hogy a felelősségeket lehessen becsomagolni. Amennyiben a felelősség ugyanarra az emberre vonatkozik, már ez az előny elveszik.
- A hozzászóláshoz be kell jelentkezni
en kerek elnezest, mert az nyilvan folenyeskedes, ha figyelmeztetnek, hogy tokon loni keszulsz magad.
A szakmai féltékenység mintapéldányai
igen! Igy van. Tehat van egy 1 szerveres rendszered debiannal, amit (sajat bevallasod alapjan) nagyon ismersz. OK. Ez az en olvasatomban azt jelenti, hogy meg a kozeleben sem voltal egy nagyobb es osszetettebb, egyszoval csak egy kicsit is komolyabb setup-nak. A code review-t hirbol sem ismered, ami szinten sokat mondo dolog arrol is, nalatok hogy mennek a dolgok. Szerintem biztos nem en vagyok az egyetlen, aki mar ennyibol is feltekeny rad.
Mi van ha a cégnek nincs erőforrása 20 db szerverre csak max 2 re, és ne adj isten, ha feljődni szeretne akkor inkáb húzza le magát a vécén mert mi a fenét ugrál, biztos részeg??
hogy jutottunk idaig el? Valami volt a bejglidben, es az egyetlen gepeden kvm-rol docker-re akarsz atallni ugy, hogy nincs vele igazan tapasztalatod. Kapsz 1-2 kommentet, hogy ez nem a legjobb otlet, mire dobsz egy 180 fokot, es mar nem bizol meg az image-ek keszitoiben, mert biztos ki akarnak tolni veled. Majd ezt alatamasztod egy systemd-s hulyeseggel, ami kontenerben nem is mukodik, de legalabb ertelme sincs. Amikor azt irtam, hogy be vagy baszva, akkor finoman probaltam a tudtodra adni, hogy hulye vagy b+.
Btw. nem a fizikai szerverek mennyisegeben hataroznam meg a csapasiranyt, hanem azt dontenem el, havonta mennyi penz van infrastrukturara (itt egy kis kavart okoz, hogy most capex vagy opex, de ne bonyolitsuk most ezzel), ill. hogy milyen igenyeknek kell megfelelni. Pl. rendszeres mentes, a prod mellett test/qa konfiguracio (a dev-et nem is emlitem, ha szoros a keret), es ez meg kis ceg eseten is egy hosszu listaba tud torkollani. Ha eddig eljutsz, akkor pedig azt kell megnezni, hogy a havi keretbol hogyan lehet ezeket megoldani. A jo hir viszont az, hogy sok dolog (pl. code review, automatizalas, tesztek, ...) nem penz kerdese.
A productionbe szánt kódnak még dokumentációja nincs, nem hogy review...
mondom en, hogy csakis a szakmai feltekenyseg szol a karogokbLOL.
igen, gáz, de ez a való világ,
valoban gaz, de ha kicsit is tovabb latnal a homokozodnal, akkor egne az arcod, hogy akar egy 2 fos Bt. is komolyabban tudja tolni nalatok (ugyanabbol a keretbol!). Mert egyaltalan nem ez a valo vilag, hanem a te/ti inkompetenciatokmi szakmai felekenysegunk.
De azért kíváncsi lennék, hogy vajon a többség akik ilyen bátrak, azok vajon anyatejben szívták magukba a tudást?
a problema akkor kezd igazan sulyosbodni, amikor a sajat felelossegedrol attersz masokra. De hadd mondjak 2 konkret peldat. #1: amikor a piler-t dizajnoltam, megoldast kerestem arra, hogy lehet csillio kulonfele meretu file-t hatekonyan tarolni. Bedobtam itt a hupon, jott jo par otlet, meg megbrainstormoltuk, aztan meglett a konkluzio. #2: Egy juzernel lattam egy fasza kis dashboard-ot (=grafana), megtetszett, dumcsiztunk, beleastam magam, azota nekem is van.
de az eredeti kérdésre eddig 2 használható sor érkezett eddig
paradoxon: csak olyan diaknak lehet sugni, aki tudja az anyagot. Mar sok eve kulsos oraadokent tanitottam 14-eseknek digitalis szamitogepek tantargyat, es amikor dolgozat kozben az egyik kiscsavotol elveszem a tankonyvet, akkor elkezd panaszkodni, hogy nem talalta benne a valaszt. Szoval ennyit arrol, hogy 2 hasznalhato sort talaltal eddig...
--
O1G
- A hozzászóláshoz be kell jelentkezni
A btw része a hozzászólásodnak értékelhető, de az előzmény miatt
-1
Minősítgetés továbbra is, és pocsék, modortalan stílus...
Te nem figyelmeztettél elsőnek, hanem megkérdőjelezted a tudásomat. Ismeretlenül.
Most meg magát a céget ítéled el, és minősíted...
Tanítottál? mindent értek!
Köszönöm a hozzászólásaid!
- A hozzászóláshoz be kell jelentkezni
mi van akkor, ha minositem* a cegeteket? Ez egyaltalan baj? Megtiltod? Tolem aztan hisztizhetsz, majd a kovetkezo fuves bejgli megvigasztal. De egy barati tanacs a vegere: allj ellen a hangoknak, ha azt mondjak, allj at microservice-ekre...
*: az elejtett morzsakkal valojaban te teregeted ki a szennyest. Ami (marmint a szennyes) lassuk be: eleg gaz...
--
O1G
- A hozzászóláshoz be kell jelentkezni
Amúgy erre tényleg erős benned a hajlam.
Amikor valaki kalapácsot használ szögbelövő helyett, akkor nem biztos, hogy hülye, lehet csak nincs áram vagy csak 1 db szöget akar beverni. Ezt a kis méretet valamiért te nem érted. Lehet azért, mert nem piacod, de attól még működik a dolog.
- A hozzászóláshoz be kell jelentkezni
Amikor valaki kalapácsot használ szögbelövő helyett, akkor nem biztos, hogy hülye, lehet csak nincs áram vagy csak 1 db szöget akar beverni
jo, nem biztos, de mi van, ha megis? En nem mentem fel ilyen konnyen az embereket. Foleg, ha bedobja a szakmai feltekenyseg kartyat. Azert jo, hogy ultem, amikor ezt olvastam. Nem birja mar az en szivem ezt a sok izgalmat...
--
O1G
- A hozzászóláshoz be kell jelentkezni
Szövegértelmezés...a szakmai féltékenység a devekre vonatkozott...
- A hozzászóláshoz be kell jelentkezni
na bakker, hat mindketten iszunk? Nezd el nekem, foleg, ha abban a 2 mondatodban elegge egybefolyt, hogy mi van nalatok, ill. mi van a hupon...
--
O1G
- A hozzászóláshoz be kell jelentkezni
Az van, hogy azzal magadat is minősíted, persze ha ez téged nem zavar, más meg ezen nem tud változtatni, csak te magad.
Baj-e? Tekintve azt, hogy én sem téged, sem a tudásodat, sem azt ami csinálsz. Azt viszont igen, ahogy ide irogatsz.
Valós production tapasztalatot nem sikerült kiadnod magadból...jah semmi baj..az csak a topic nyitó volt...
Ellen fogok megígérem, addig bizos amíg nem érzem azt, hogy valós megoldása annak amit szeretnénk elérni.
De nyugi, nem te érted el.
Az elejtett morzsákat meg helyezd vissza kontextusba...aztán szövegértelmezés, nyilván a patyolat tiszta körülmények megzavartak, azért sikerült kiragadni.
Mindenesetre a hozzászólásaid tanulságosak voltak összességében, sajnos negatív, de tanulságos...
- A hozzászóláshoz be kell jelentkezni
igy van. Ha tfh azt latom, hogy pl. sj2 fogja a fejet 1-2 olyan boszmeseg lattan, ami pl. nalatok van, abbol azt a kovetkeztetest vonom le, hogy sj2 ezt az 1-2 konkret boszmeseget nem csinalna meg nalunk (lehet, hogy 5 masikat igen, de legalabb ezeket nem). Ebben mi is kene zavarja sj2-t?
Tekintve azt, hogy én sem téged, sem a tudásodat, sem azt ami csinálsz.
ne torodj vele, akarhogy is all az en szenam, az rajtad nem segit se igy, se ugy.
Azt viszont igen, ahogy ide irogatsz.
meg mindig a hiszti. Btw, azt tudtad, hogy te is irogatsz? Na latod.
Valós production tapasztalatot nem sikerült kiadnod magadból
ok, gyonas ido: nekem nincs egyetlen 600 GB-os szerverem sem, szoval elmondhatod, hogy te nagyobb gepet kalapalsz, mint en. Debiant sem hasznalok, szoval lehet, hogy nekem kene az a remote konzol az ujratelepiteshez. Erzem, kezdek is megint feltekeny lenni.
Dockert viszont leginkabb tesztelesre hasznalom (systemd specifikus dolog meg csak veletlenul sincs benne, es - ha mar gyonas ido - akkor bevallom, en megbizom az official ubuntu image-ekben). Erre a celra nekem kivalo. Docker 2 hoszton is fut, de mivel a kontenerek viszonylag rovid eletuek nem komplikaltam orkesztratorral a dolgot (swarm, k8s, ...), bar 1-2 fancy feature-t toluk azert tudnek hasznalni, ugy hogy meg meglatjuk ezt a reszet. Production-ben fut docker-ben egy redmine alapu ticketing cucc, ill. egy postfix smtp relay. Meg amin gondolkozom az a piler demo site kontenerbe pakolasa (uj leveleket mar nem akarok bele amugy sem), es igy konnyen lehetne ide-oda mozgatni, ill. reset-elni, ha barmi gubanc van.
De nyugi, nem te érted el.
tenyleg irigy vagyok ra: nevezd meg a bunost, rogton!
OK, game on. Lehet, hogy felreertheto voltam, de nekem nem faj, ha tokon lovod magad. Max. ramutatnek, hogy miert nem hallgattal ram, masokra. De mivel jo par evig aligha keresztezzuk egymas szakmai utjat (tudod, irigy is vagyok, mint allat), tolem nyugodtan csinalhattok mindent ugy, ami mar 2000-ben is gaznak szamitott.
Mindenesetre a hozzászólásaid tanulságosak voltak összességében, sajnos negatív, de tanulságos...
ez a lenyeg. Amig epito, addig megeri bepotyogni. Az mar a te dolgod, hogy tul tudsz-e lepni a kognitiv disszonanciadon. Mondom, szeretem latni, ha valaki megfogadja egy tanacsomat, de a youtube-on levo fail videokat is szeretem. Meg kitalalom, melyiket jobban...
--
O1G
- A hozzászóláshoz be kell jelentkezni
Köszönöm az értékelhető szakmai részét..de..
Nem tudsz normális hangvételben hozzászólni, mi? :D
De olvasni azért tudj már légyszi...még mindig lovagolod ezt a szakmai féltékenység dolgot(ha már másba ugye nem lehet kapaszkodni)..mikor eleve félreértetted, és még 3mal feljebb le is írtam, hogy mire vonatkozott.
A kongitív diszlófaxal meg nincs dolgom, nem magamból indulok ki...pont az ilyen és ehhez hasonló megjegyzéseidet kifogásolom/tam eddig...
S lexarom ha számodra ez hiszti..akkor van még másik száz téma ahol lehet tombolni...nem kötelező itt a sírósok között tanárbácsit játszani...a faxomat verjem bele....
Nah most feltoltad a pumpámat...
Isten bizony, én elmegyek akkor pszichológushoz, megnézetem hátha baj van az agyammal..
a cégvezetést meg beiratom hozzád, tanácsadásra, hogy nehogy böszmeség legyen a vége.
De legjobb is lenne ha be is zárnánk a fenébe, mert az sj megmondta hup-on, mi a stájsz
Gratulálok magadnak!
- A hozzászóláshoz be kell jelentkezni
ok, kuldd nyugodtan a cegvezetest, a frankot mindig szivesen mondom. De ezt mar tudod...
--
O1G
- A hozzászóláshoz be kell jelentkezni
A productionbe szánt kódnak még dokumentációja nincs, nem hogy review
ezen agyaltam meg egy sort, hogy valoban akkora gaz, ha a kodnak nincs dokumentacioja? Ha a termeknek, amit a userek hasznalnak nincs doksija, az tobb, mint gaz.
De pl. nem biztos, hogy egy C++ kodot tele kell szemetelni (szajbaragos) dokumentacioval (amit a vegfelhasznalo ugy sem lat). Egy rovid ideig hasznaltam pl. a pylint nevu lintert, ami kulon sir, ha nincs minden fuggveny alatt rogton ott egy komment, hogy mit csinal az adott rutin. Ezt azert tulzasnak tartom, foleg ha a fuggvenyeknek (meg a valtozoknak is) beszelo nevuk van: eolvasod a nevet, es tudod, hogy (szandek szerint) mit csinal.
Ha van egy hack a kodban, oda el kel a magyarazat, hogy ez most miert, vagy egyeb olyan info, hogy ha fel ev mulva veszed elo a kodot, akkor azok alapjan nem kell sok ido ahhoz, hogy ujra kepbe kerulj, hogy mi tortent, miert igy nez ki a kod...
--
O1G
- A hozzászóláshoz be kell jelentkezni
nah ezt sikerült megérteni...
Bizony a feljesztői doksi, és a végfelhasználónak szánt doksi bizony bizony nem ugyanaz.
A végfelhasználóról nem esett szó...
- A hozzászóláshoz be kell jelentkezni
van ra egy cve hogy >maxint uiddal root joggal futtatod - tan upstreamben mar javitott is.
- A hozzászóláshoz be kell jelentkezni
Mindenkinek köszönöm a hozzászólását!
Tanulságos volt, több szempontból is.
S köszönöm mindenkinek aki érelmes módon világította meg a dolgokat.
- A hozzászóláshoz be kell jelentkezni
Ha a host OS "egyetlen" feladata a Docker futtatása lesz, akkor hovatovább teljesen mindegy, hogy mit tolsz, tolj olyat amit ismersz, magabiztosan elkezelsz (gondolom backup, disk kezelés, LVM, társai be fognak ugyanúgy jönni).
A debian current stable (stretch) teljesen megfelel Docker futtatására, a korábbi release-k régi kerneljeiből voltak gondok, de ezzel nem lesz.
--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene
- A hozzászóláshoz be kell jelentkezni
+1
Köszönöm!
Pontosan ezért merült fel bennem a kérdés, hogy a debiant esetleg cserélni kellene, mert rengeteget olvastam róla, hogy a Debian kernelével a Docker állandóan hisztzik, vagy fordítva. illetve az adott kernel verzió. Debian Stretch van jelenleg, és tesztelni magát a Dockert ugyanezen Stretchen végeztük, gyakorlatilag gondmentes volt.
- A hozzászóláshoz be kell jelentkezni
"akkor hovatovább teljesen mindegy" Arch linuxxal sokat szivok :) rendszeresen kell az update utan /var/lib/docker-t torolni, meg hasonlo finomsagok.
- A hozzászóláshoz be kell jelentkezni
Hát az még lehet csak a kevesebbb. Tömve van a net Docker használatát befejező figurákkal, irományokkal.
Egy blogban a srác azt írja, soha többé Dokcer-t mert a verzió frissítések nincsenek tisztelettel az előzményekre, gyakorlatilag nullának értékelte a backward compatibility-t.
Rendszeresek a breaking change-ek, a verziók között..Nos nyilván ami volt, az volt, ma már nem biztos hogy így van, ez nem tudom.
Részben ezért is gondoltam, írok nektek, kinek mi a tapasztalata. sajnálom hogy elfajult az eleje.
Elég tanulságos az alábbi post is, ugyan nem épp tegnap írta az illető:
http://docker-saigon.github.io/post/Docker-Caveats/
a videó viszont nagyon jó. sj, ezt még neked is ajánlom figyelmedbe, ha már szóba került a youtube videó, hátha még nem ismerted eddig.
- A hozzászóláshoz be kell jelentkezni
Most puffogtathatnék egy rakás közhelyet, úgy mint:
- először tesztelünk és utána upgradelünk, és nem rögtön éles rendszeren upgradelünk vaktában
- elolvassuk a release note-okat
- mivel a docker is fejlődik, előfordul hogy breaking change-eket vezetnek be, ezeket pedig migrálnunk kell a saját rendszerünkben
- és a többi.
Megint azok a leghangosabbak akik az aktuális találmányt valami csodaszernek vélték, és mikor rájöttek hogy nem az, elkezdtek jó hangosan károgni. Én már több (nagy) projekten is dockereztem, és sosem volt az a vége hogy "soha többé".
--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene
- A hozzászóláshoz be kell jelentkezni
+1, atszaladtam rajta, sigh. Nem veletlenul javasoltam egy qa rendszert is fentebb. Jo, hat az igazi pro userek nyilvan az eles rendszeren szerkesztik a kodot, de nem mindenki ekkora rock star...
--
O1G
- A hozzászóláshoz be kell jelentkezni
A Dockerben az a rossz, hogy keveri a futtatókörnyezetet (container runtime) a fejlesztőkörnyezettel (docker build). És pont ez volt (szerintem) az egyik oka, hogy gyorsan el tudott terjedni, mert a fejlesztőknek kényelmes volt.
Viszont pont emiatt érdemes lenne ránézned a Kubernetesre, még akkor is, ha csak egy gépen akarsz productionben futtatni konténereket, mert ott sokkal jobban figyelnek a stabilitásra, és cserélhetőre van csinálva a container runtime.
- A hozzászóláshoz be kell jelentkezni
Nekem ez egy kicsit zavaros: a kubernetes meg a docker pont hogy nem ugyanarra való, így kár egyiket ajánlani a másik helyett.
--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene
- A hozzászóláshoz be kell jelentkezni
Igen, a Kubernetes jobb arra, hogy container alapon üzemeltessen production rendszert. Egy mezitlábas Docker annyit tud, hogy kézzel elindítgat konténereket. Esetleg még egy docker-compose -zal több egymástól függőt.
Ellenben a Kubernetes ennél sokkal többet tud: ad egy API-t, amivel kompletten le lehet írni az appok környezetét storage, network, konténerek (illetve Podok) szintjén, beleértve a skálázódási / újraindítási szabályokat. Nyilván 1 szerveren nem lesz redundáns a rendszer, de ha a saját egygépes rendszerén összerakja, és később migrálni akar Cloudba, akkor gyakorlatilag minden nagy Cloud szolgáltató ad menedzselt Kubernetes rendszert (már a DigitalOcean is).
- A hozzászóláshoz be kell jelentkezni
> és később migrálni akar Cloudba, akkor
...es ha nem?
- A hozzászóláshoz be kell jelentkezni
Azert azt tisztazzuk egy eles kubernetes rendszerhez miniumum 5 node szukseges 3 etcd 2 k8s master es akkor meg a worker nodekrol nem is beszeltunk.
Neki jelenleg meg container mint filozofia es tanulando szoval tok felesleges egy orhestrationt ajanlagatni ami egy csillag rombolo az o rendszerehez kepest.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
- A hozzászóláshoz be kell jelentkezni
Single node-on is lehet K8S-t telepíteni, persze nem lesz HA, de ha 1 db szervere van, azzal akármit csinál soha nem lesz HA. Viszont ha összerak egy K8S alapú deploymentet, akkor akár disaster recoverynél, akár tervezett migrációnál könnyű dolga lesz átmenni egy profi menedzselt K8S példányra, vagy ha az az igény, akkor saját üzemeltetésűre.
Ezt összerakni egyszerű rendszernél is szerintem 2-3 hónap minimum, ha van elég idő foglalkozni vele, de utána sokszorosan meg fog térülni a megszerzett tudás és az új szemléletmód.
Az viszont tény, hogy az egész csak úgy tud működni, ha a fejlesztői oldal is magáévá teszi ugyanezt a szemléletet és a szükséges módosításokat elvégzik az alkalmazás architektúrán.
- A hozzászóláshoz be kell jelentkezni
En nem aludnek nyugodtan oszinten szoval.. mondjuk ha egy szerverem lenne se ez a teny nem valtoztat rajta.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
- A hozzászóláshoz be kell jelentkezni
1) OS oldalról szerintem nem a disztró lesz a mérvadó, hanem a kernel, tehát próbálj meg olyan disztróra lőni, ami nincs több major verzióval lemaradva.
2,a) Nem minden containerben futó port van expose-olva, csak az amit te is külön kiraksz. Amennyiben 1-1 conténerben futó alkalmazást nem kell direktben elérni (én most pl. nem látok okot arra, hogy bármilyen DB-t expose-oljak egy egy szerveres felállásban), akkor azt simán hagyd meg localhost-on.
2,b) IPS/IDS pontosan ugyan annyira kell a gép elé, mint KVM esetén - az, hogy az adott programjaid natívan, vagy valamilyen izolációban futnak nem változtat a networking footprint-eden.
3) Saját image-et csinálni valahol jobb, valahol rosszabb is. 1 részről egy package maintainer feladatkörét veszed a nyakadba (folyamatosan le kell követned az adott termékek életciklusát, frissítés esetén új image-et kiadni) más részről az elkészült image-eket illik ha átfutnak valami CI rendszeren, hogy normálisan tesztelve is legyenek - ez pedig mind mind qrva sok meló. Ez miatt vagy megbízol a publikusan elérhető image-ekben (lehetőség szerint a fejlesztő által kiadott image), vagy ha nincs erőforrás, akkor maradj a csomagszintű telepítésnél (akkor csak az OS repojában és a package maintainerben kell megbíznod). Esetleg meg lehet próbálni keverni is a megoldásokat (valamit containerben, valamit meg natívan futtatni)
Személyes vélemény: A containereknek akkor van inkább értelme ha az abban futtatott applikáció natívan képes skálázódni, és így automatizálni tudod a horizontális és a vertikális skálázódást is - a te általad említett programok közül szerintem egyik se nagyon ez a kategória (bár 1-2 plus komponenssel talán játszható lenne, de 1 szerverről beszélünk, ott meg a skálázódást nem tudom értelmezni), szóval én nem sok értelmét látnám átállni containerekre a te use case-edben..
Bonusz kérdés: Amúgy mit vársz egy ilyen átállástól? Mi a technical/business driver ami miatt szerinted ezt érdemes lenne meglépni?
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..
- A hozzászóláshoz be kell jelentkezni
Ubuntu hivatalosan tamogatja a K8S-t igy biztos lehetsz benne ,hogy a Docker tamogatsaga mindig megfelelo es hosszu tavu lesz.
A Docker abban tud neked segiteni ,hogy a fejlesztok konnyen tudnak az alkalamzas alatt verziokat ugrani anelkul ,hogy ebbe teged egy pillanatig is bekellene vonniuk. Ezt a 3rd party dockertol valo felelmet jobb lenne lejebb adni ami a hivatalos docker hub repobol elerheto azok nyugodtan hasznalhatod. A sajat containerekhez meg kicsik vagytok es tok felesleges es rohadt nagy macera karbantartani.
A plain docker tudja futtatni a containert es egy-ket extra beallitas de ennyi. Ahhoz, hogy ennel kicsit is tobbet tudjon kulso szolgaltatasokra lenne/lesz szuksegetek docker-compose meg tarsai nem igazan valok eles alkalmazas uzemeltetesere ertem ,hogy valaki csinalja de elege tokon szuras dolog. Szoval elegge nagy a belepesi kuszobb es jelenleg nem jott el a ti iditok a dologban.
En megforditanam a kerdeset mi az a problema amiert szuksegetek van Dockerre mi az a problema amit jelenlegi rendszer nemtud megoldani es ezert be kell vezetni.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
- A hozzászóláshoz be kell jelentkezni
Kedves o_O, Huncraft!
Köszönöm a hozzászólásotok!
Az, hogy jelenleg egyetlen prod szerver van, ennek az oka elég prózai..kicsik vagyunk, és jelenleg nincs is olyan kritikus alkalmazásunk, vagy olyan kritikus ügyféligény, ami HA-t követelne. Persze én is tudom a nagykönyvet, de inkább arra koncentráltunk, hogy hiba esetén a recovery menjen a lehető leggyorsabban, egyszerübben.
Hogy ez mit jelent, mindenki felfogta, tudomásul vette...(ügyfél oldalon is).
Skálázhatóság: nincs rá szükség jelenleg, inkább a jobb erőforrás kihasználás lenne a lényeg.
Jelenleg is meg tudunk oldani mindent, amit kell, leszámítva azt, hogy ha újabb VM-eket kellene indítanom, hát már bajban lennék. Már pedig ez várható a következő fél évben, így kénytelenek leszünk vagy HW erőforrást bővíteni, vagy a jelenlegit megpróbálni, jobban kihasználni.
Tettem anno egy kis kitérőt az LXC irányába is. Érzetre jobb volt mint a kvm vm, és a fent említett dolgot már ez is kezelné valamelyest.
De úgy láttam a karbantartása, egy dekát sem egyszerűbb mint a hagyományos vm-ek esetén, és megmarad ugyanaz a probléma lxc-vel is, jön a kollega a kis (docker) konténer image-ével...."itt a prodra szánt alkalmazás, tokkal vonóval, tesztelve...mehet élesbe"...
S elkezdem kibányászni belőle a forrást...hogy tudjam a prodot frissíteni. (Vagy a prodot teszem át úgy ahogy van, és akkor talán egyszerűbb lesz az élet)
Vagy elregélem hogy a prod az imaget letojja, add a forrást barátom.
Lehet nekem inkább a "Sucker Rod" kellene (man syslog), nem a Docker...
De mi van akkor ha az ember fia, jó pap módjára tanulni akar, és nem akarja homokba dugni a fejét, és megkövülni mint OP.
Így nekilát Dokcerezni, ha már a devek is azt teszik.
Nálunk csupán ilyen "Noob" problémák vannak, nem igazi szakmai nyalákságok...ami tudom, mind abból fakad, hogy egy ilyen kis környezetben nem értelmezett az, hogy "havi keret". (Az max a nyomtató patronra, meg papírlapra...). Nem értelmezett az hogy HA, meg több node, shared storage, mert ahhoz a 30 milla is kevés, ha úgy igazán komolyan gondolod....
Legalábbis KVM-nél biztosan...
S természetesen elfogadom tőletek maga a topic "válaszaként", ha azt tanácsoljátok ne dockerezzünk prodban,
- MERT egyetlen szerveren (semmi?) hozadéka nincs, DE önmagában az a tény, hogy mert csak egy szerver..az kevés nekem.
Ilyen erővel a KVM is felesleges, lehetne minden a hoston...aztán dolgozz ki rá rendes backup, recovery plant...(sj, na ez volt böszmeség már a 2000es években is)
Lássuk be egyszerübb a tegnapi image mentést visszadobni a szerverre, és elindítani...
De VM-ekkel legalább meg van az esélye, hogy nem egyszerre száll el minden szolgáltatás. Persze, nyilván ha a vas hal meg...akkor meg berohanok a backup vasammal
ami SW konfigban ugyanaz mint a prod, és ahova mentem az imageket...
- MERT nem kevesebb a karbantartási igénye mint egy sima vm-nek, vagy bármi másnak, DE én jelenleg nem ezt érzem, bizonyos szempontból.
Úgy látom egyszerűsödik a dev/test/release folyamat a feljesztett alkamazások szempontjából.
Arra viszont többen rávilágítottatok, s ezt köszönöm, hogy a prod szempontjából már korántsem ilyen szép az élet.
S akkor most lehet megint ostorozni majd engem, mert jelenleg a terv ez lenne:
Csinálnék egy VM-et ami IPS/IDS, és ez meg is adná a virtuális hálózatot is gyakorlatilag, majd erre a hálózatra kezdeném felpakolni a konténereket, levelezést, websezervereket, adatbázis szervereket, meg amit kell.
S lehet hogy ez sokak számára szakmailag nulla, DE
- ha tud működni stabilan
- jobban kihasználható a jelenlegi erőforrás
- üzemeltethető biztonságosan
- "közelebb kerül" a dev a prodhoz
- s netán még az én hajam se hullik ki OP szempontból,s még tanulok is egy csomót közben.
Akkor megérné az átállás szerintem.
- A hozzászóláshoz be kell jelentkezni
Magamat ismetelve, kene egy ci/cd pipeline, es maris tobb okod lenne kontenerzni.
- A hozzászóláshoz be kell jelentkezni
Igen, köszönöm, értettem, de Huncraft kérdésére gondoltam picit jobban leírom amit várok, várnék, meg ami van..még ha helyenként tudom, ismételtem magam én is!
Megfogadom a tanácsod, és beleásom magam jobban a CI/CD kérdésbe, ez már biztos! Teljesen egyértelmű, hogy már ez önmagában kezelni fogja a dev, prod viszonylatában fennálló problémát.
- A hozzászóláshoz be kell jelentkezni
Azzal semmi baj nincs, hogy fejleszteni akarod magadat, SŐT! Az egyedüli felvetés itt inkább az, hogy mivel production-re volt a kérdés kihegyezve, így ilyen irányú válaszokat is kaptál, míg a te use case-edre egy staging rendszer sokkal alkalmasabb lenne (ahol nyugodtan lehet hibázni, és a hibákból tanulva gyorsabban is fejlődni).
De hogy valamit még megpróbáljak hozzá is tenni az egészhez: Kicsit olyan érzésem van még mindig, hogy a konténerizációnak még mindig csak 1-1 oldalát veszed figyelembe, miközben nekem olyan érzésem van, hogy más oldalak meg esetleg fontosabbak lennének - szóval had térjek ki ezekre, aztán majd elmondod, hogy valóban hasznos e amit írok, vagy sem:
- A te esetedben ahogy én értem minden kb a szeparációról / izolációról szól. Ezért jön elő a VM, LXC (system container) és most az application container is (docker). 1 szerveren belül technikailag lehetőséged van minden általad futtatott dolgot bare metal környezetben natívan futtatni (minden komponens egy OS alatt, egymás mellett), de ennek is meg van az ára (főként biztonsági oldalról)
- Ha ez így van, akkor innentől már tényleg csak az a kérdés, hogy milyen féle szeparáció / izoláció az ami a te igényeidnek a legfőképp megfelel. Mindegyik technológiának megvan a maga előnye/hátránya (az új dolgot is meg kell tanulni, és az is ugyan úgy el tud romlani). A VM-et már ismered, használod, tehát felteszem tudod is mik ezek. Amiben a containerek (system, vagy application) többet tudnak (és ami miatt manapság már inkább ebbe az irányba terelődik a szakma), az az, hogy 1 OS-en belül tudják megadni ugyan azt az izolációt amit egy VM, viszont nem kell egy teljes rendszert betölteni 1 komponens miatt, ha annak amúgy arra nincs szüksége, ergo 1 új app indítás nem percekben mérhető, hanem tized másodpercekben.
- A fentiek mindaddig állnak, amíg a "régi rendszerű üzemeltetésben" gondolkodunk. DevOps-os világban ezek kicsit borulnak, mivel a fejlesztők és az üzemeltetők nyomban egy hajóba kerülnek, és innentől nyomban lehetőség nyílik (sőt, szinte kötelezővé is válik) egymás toolsetjeit igénybe venni. Itt már simán lehet, hogy a 2 oldalnak igazodnia kell egymáshoz, és valamilyen kompromisszum(ok) mentén igazgatni a munkájukat. Ez azt is jelenti, hogy ha a fejlesztőitek már most Docker containerekben gondolkodnak (mert pl a build környezetet így könnyebben tudják egymás között adogatni) akkor már lehet tényleg megéri a prod oldalon is Dockerben gondolkodni, vagy elkezdeni gondolkodni benne. Persze ez nem jelenti azt, hogy mindent úgy kell átvenni, ahogy ők gondolják: Simán lehet, hogy Ops oldalról is kicsit bele kell nyúlni a dolgokba, és pl megkövetelni a CI-t (ami lehet jelenleg nincs is nálatok, viszont containerek esetén olyan könnyen megoldható, hogy szinte kötelező is innentől implementálni, mert nagyon sok előnye van).
Ezen kívül még azt is el tudom képzelni, hogy lehet érdemes lenne még megnézni 1-2 más dolgot is (mint Proxmox, OpenVZ), mert még az is lehet, hogy egyikkel/másikkal jobban meg lehetne valósítani azt amit szeretnél, mint LXC-vel vagy Docker-rel.
ps: Teljesen mindegy amúgy milyen új irányba akarsz elindulni, mindegyiknek meglesznek a maga buktatói és hibái. Így egy ilyen átállást kötelezően egy staging/test rendszeren kezdj el, és amikor az ott már elég stabilan néz ki, akkor lehet elkezdeni gondolkodni a prod-os átálláson. Az összes többi igényre (backupok, hálózati biztonság, monitoring) ezek után is ugyan úgy szükség lesz.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..
- A hozzászóláshoz be kell jelentkezni
"amit jelenlegi rendszer nemtud megoldani" +1 annyival egeszitenem ki, hogy mondjuk egy CI/CD platform (megtanulasa es) bevezetese nem csak a rendszert javitana, hanem a cv-ben is jol nez ki. Raadasul segitsegevel bele lehet tekinteni a devops szemleletbe, es ezaltal talan a kontenerizacio is jobban kepbe kerul. Arrol nem beszelve, hogy kell valami alap, amire lehet epitkezni, es a CD pipeline eppen az. Eloszor az appot kell vegigvezetni, aztan johet az infra.
- A hozzászóláshoz be kell jelentkezni