Udv.
Nem is annyira segitseg, inkabb velemeny/tanacs erdekelne a temaval kapcsolatosan. Pro/kontra egyarant, de teljesen mas megoldast is szivesen meghallgatok.
Az alap helyzet a kovetkezo: adott egy kis hazi szerver amelyen futnak kulonbozo szolgaltatasok. Ezen szolgaltatasok: NFS, Samba, M4Sport re-stream, Transmission, Nextcloud, Gitolite, otthoni homerseklet-vezerles adatbazisa es webes felulete, rclone-al titkositott mentes OneDrive-ra, Apache reverse proxy a webes szolgaltatasok eleresere (Transmission, Nextcloud, M4 re-stream es homersekletes-vezerles webes felulete), valamint Certbot, hogy a webes eleres HTTPS-en keresztul menjen.
Egy Ubuntu Server 16.04 fut a szerveren. Regebben minden szolgaltatas nativan volt installalva, de most mikor ujra kellett telepitenem, akkor csak pislogtam, hogy milyen szolgaltatasokat is kell ujra eletre keltenem, mert nincs dokumentalva a lista. Valamint sok esetben fuggok az Ubuntu altal szallitott csomagoktol, amelyek idonkent tul regiek. Arra gondoltam, hogy mindket problemara megoldas lenne, ha nem nativan installalnek mindent, hanem Docker-t hasznalva. Ily modon konnyebben es gyorsabban tudom ujra eletre kelteni a szolgaltatasokat, ha netan szukseg lenne ra. Elmentem a Dockerfile-t (ahol van), valamint egy start scriptet, ami inditja a kontenereket es volume-kent hozzaadja a config filet. Ily modon a host rendszeren csak SSH-t kell engedelyeznem, valamint Docker-t installalni ra. Masik elonye, hogy ha netan oprendszert valtok, akkor nem kell keresgeljem, hogy azon melyik szolgaltatas milyen file-ban van konfiguralva, csak felteszem a Docker, es mindent inditok ugyanugy.
A Dockerfile-ok es a szukseges start scriptek megvannak, es mukodnek is. Egyedul a NFS-vel volt problemam, igy az maradt nativan. Eroforras van ahhoz, hogy kulon Docker kontenerben fusson minden (Core 2 Quad / 12 GB memoria).
A kerdes: jo otlet ez vagy nem? Van-e jobb megoldas?
- 3744 megtekintés
Hozzászólások
Szerintem jó ötlet! ;-)
- A hozzászóláshoz be kell jelentkezni
Jo otlet. BTW, ennek a megkozelitesnek a szep peldaja a RancherOS (http://rancher.com/rancher-os/) amiben _minden_ szolgaltatas kontenerizalt. Az eroforrast nem tudom, miert hozod ide, a Docker kontenerek lenyegeben zero overheaddel mennek.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Azert emlitettem meg, mert nincs elegendo tudasom arrol, hogy mennyi az overhead. Annyit sejtek, hogy nativ < kontener < teljes virtualizacio iranyba novekszik az overhead, de nem tudom, hogy ez 1-2% vagy esetleg 10-20%. Gondoltam ezzel elkerulom az esetleg ezen ok miatt torteno kontra erveket.
Sic Transit Gloria Mundi
- A hozzászóláshoz be kell jelentkezni
<1%
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
1 ezreléknél is kevesebb. A Docker containerek semmi mások, mint a defaulttól eltérő namespace alatt futó processzek. Ez nem VM, hanem a kernel egy izolációs rétegét használják ki.
- A hozzászóláshoz be kell jelentkezni
Valamint sok esetben fuggok az Ubuntu altal szallitott csomagoktol, amelyek idonkent tul regiek.
És a dockerbe honnan rakod fel a programokat?
- A hozzászóláshoz be kell jelentkezni
Ha érdekel a téma, akkor legalább alapszinten nézz utána!
- A hozzászóláshoz be kell jelentkezni
A téma nem érdekel, és hidd el, már utánanéztem :D
Csak azt akarom mondani, hogy mitől lesz megbízhatóbb a docker hub, mint az ubuntu csomagjai. Amúgy az sem ritka, hogy a dockerfileban egy apt-get install van. Ez egy rossz indok a docker mellett.
- A hozzászóláshoz be kell jelentkezni
Nem a bizalomrol van szo, hanem arrol, hogy egy csomag esetleg tul regi, es szeretnek ujabbat. Erre lenebb irtam 3 (ami tulajdonkeppen 2) lehetseges opciot.
A bizalom kapcsan: a hivatalos image-ekben megbizom, azon tul nem bizom az olyan Docker image-ekben, amelyekhez nincs publikus Dockerfile (minden hozzaadott script-el egyutt). Amelyikhez van, ott hasznalom a Dockerfile-t es a script-eket, es keszitek sajat image-t belole.
Sic Transit Gloria Mundi
- A hozzászóláshoz be kell jelentkezni
Erre 3 lehetoseget latok:
1. Ahogy lattam, az utobbi idoben az Alpine Linux lett az alapertelmezett image, ami tartalmazhat ujabb verziot.
2. Hasznalhatok ujabb Ubuntu-t alapkent, nem feltetlen az LTS verziot kell hasznalnom. Vagy akar mas disztribuciobol is kiindulhatok.
3. Azonkivul pedig AFP kapcsan olvastam, hogy Ubuntu eleg regi netatalk verziot szallit, es javasolt forrasbol tenni ujabbat. Ahelyett, hogy az alaprendszerre teszek fel mindent, amire szukseg van az ujabb verzio compillalasahoz, hasznalhatok vagy kesz Docker image-t (Debian alapra installalja), vagy keszithetek sajat image-t, akar Ubuntu-bol indulva, es abba installalom forrasbol, igy nem a host rendszert "szemetelem" ossze forrasbol installalassal vagy kulso ppa hasznalataval (ha egyaltalan van).
Sic Transit Gloria Mundi
- A hozzászóláshoz be kell jelentkezni
Na igen, nekem ez a bajom a dockerrel, hogy igazából a csomagkezelés hiányosságait betömő rés, amire leginkább használható.
- A hozzászóláshoz be kell jelentkezni
Jelen helyzetben ami elonyet en latom:
- konyebben tudok ujabb verzioju programokat felteni
- portabilisebb a rendszer, szukseg eseten konnyeden es gyorsan atkoltoztetheto akar mas disztribuciora is
- tiszta marad a rendszer, nem kell third party ppa-kat hozzaadni
- a tisztabb rendszer miatt kevesebb az eselye, hogy egy frissites soran problema lepjen fel
Sic Transit Gloria Mundi
- A hozzászóláshoz be kell jelentkezni
Ezért mondom, hogy a csomagkezelést kerüli meg, ha lenne egy shell scripted, ami egy program mindenét a függőségeivel együtt felrakná mondjuk az /opt/nginx-be, akkor ugyanott lennél.
- A hozzászóláshoz be kell jelentkezni
Kozben meg akartam szerkeszteni rajta egy kicsit, de lekestem, mar megerkezett a valaszod :}
Annyit akartam meg hozzatenni, hogy ha ez mind a csomagkezeles megkerules/kiegeszites kovetkezmenye is, hatarozottan latom elonyet. Epp ezert vetettem fel a kerdest, hogy van-e mas megoldas eme problemak orvoslasara, vagy jelenleg a Docker a legkenyelmesebb erre a celra. Esetleg van-e hatranya.
Sic Transit Gloria Mundi
- A hozzászóláshoz be kell jelentkezni
Ebből szempontból én se tudok jobbat, mert ugyan van kismillió projekt, ami megoldaná azt pl., hogy egy program több verzióját használhasd egyszerre, amit fel is tud telepíteni, meg eltakarítani maga után, de valahogy a docker az, ami a letöbb hypeot kapta (és a Docker Inc. legtöbb befektetést).
- A hozzászóláshoz be kell jelentkezni
Talan poliverzum promovalt ilyet tamogato disztrot, ha jol emlekszem. De ez off :}}
Amugy azert vetettem fel a kerdest, mert akadnak is uzemeltetok, akik ertenek is hozza, es esetleg kapok egy-ket jo tippet, hogyan is kell(ene) ezt szepen/jol/okosan/hatasosan csinalni...
Sic Transit Gloria Mundi
- A hozzászóláshoz be kell jelentkezni
amit fel is tud telepíteni, meg eltakarítani maga után
meg sandbox-ban futtatni, meg virtuális hálózatot kezelni, meg ...
Mondom, hogy nézz utána!
- A hozzászóláshoz be kell jelentkezni
Redhat/centos pontosan ezt teszi az SCL repokkal, /opt/rh/{app}. Docker esetén azt a hátrányt látom, hogy ha frissíteni kell mondjuk a libc-t vmi 0day miatt, akkor az összes dockert lehet újraépíteni nulláról...
- A hozzászóláshoz be kell jelentkezni
Miért kellene?
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Mert normális esetben frissül a base image.
- A hozzászóláshoz be kell jelentkezni
Ez nem libc kérdés hanem az hogy szoktad-e frissíteni a docker image-eket vagy jóvanazúgy alapon fut aíg világ a világ. Ha szoktad, akkor tökimndegy, mert frissül. Ha nem, akkor meg miért pont a libc aggaszt?
- A hozzászóláshoz be kell jelentkezni
Tegyük fel, hogy Lusta Lajos vagyok. Azt ugyan szeretném, hogy biztonságos legyen a rendszerem, de minél kevesebbet szeretnék érte tenni, gondolkodni meg semmit sem szeretnék. Csak várom a sült galambot.
Ha az OS csomagkezelőjét használom, akkor rendszeresen frissül, aminek frissülnie kell. A futó binárisokat - gondolom - újra kell indítani. Mivel nem figyelem, hogy mi változott, az összes szolgáltatást újrarúgom vagy bootolok egyet.
Docker esetén az összes image-et újra is kell buildelni, mielőtt törlöm a konténereket és újakat indítok.
Nyilván scripttel / Dockerfile-lal intézek mindent, azt egyszer megírom aztán évekig működjön. Melyik a jobb megoldás?
- A hozzászóláshoz be kell jelentkezni
Ha betartod a docker tervezési alapelveket, akkor a konténereid állapotmentesek, és nem tartalaznak érzékeny infót. Ebben az esetben felrakod a docker hub-ra, összerakod hogy működjön az autobuild, és akkor amikor rádjön a frissítés, csak lehúzod az aktuális verziójú image-et, és elindítod a megfelelő környezeti változókkal, volume-mal stb. ahol tartottad a konfigot és állapotot.
Ez a kezdeti kicsit nagyobb munka után konkrétan 2 parancs kiadását jelenti, ami megegyezik az OS csomag frissítéssel. Ráadásul ha itt valami gáz van, egyetlen parancs visszaindítja az előző verziót. A docker nem a virtualizáció szent grálja, de ha arra használod amire való, akkor nagyban megkönnyíti az életet, és ez főleg a frissítések idején jelentkezik.
Ráadásul ne felejtsd el hogy egy konténerben nagyon kevés komponens van, és jól definiált a ki- és belépési pontja, eléggé le van szűkítve a lehetséges támadási vektorok köre - ha nem a kiajánlott szolgáltatásban van a lyuk, akkor az elmaradó frissítés se kritikus.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Nekem egy kérdés jut eszembe erről. Ha van egy nginxes dockerem. Kiderül, hogy security bug van az nginxben, frissíteni kell. Akkor lehúzom a valaki által frissített és karbantartott nginx imaget és bízom benne, hogy elindul azzal is az appom (tudom http szerver, de a példa kedvéért) vagy buildelek forrásból egy konténerbe egy nginxet és én tartom karban magamnak azt az imaget, amit akár feltolok ide oda. Akkor most miért is vagyol beljebb mintha egy disztró nginxét frissítgetem? Tehát ennyiből egy lxc nekem szimpibb, mert abban komplett os van, rendes csomagokkal. Vagy a docker konténerbe is debiant teszek és apt-olok?
Coreos és társaiból indultam ki.
Nem használok konkrétan dockert, csak olvasgattam róla és meghallgattam pár előadást. rkt-t próbáltam, meg lxc-t.
- A hozzászóláshoz be kell jelentkezni
> Akkor lehúzom a valaki által frissített és karbantartott nginx imaget és bízom benne, hogy elindul azzal is az appom (tudom http szerver, de a példa kedvéért) vagy buildelek forrásból egy konténerbe egy nginxet és én tartom karban magamnak azt az imaget, amit akár feltolok ide oda.
Normális esetben lehúzod az official docker imaget az nginx-hez: https://hub.docker.com/_/nginx/
aztán tényleg bízol benne, hogy elindul.
a bizalomban annyit segít a docker, hogy egy másik gépen nagyon könnyen össze tudod rakni ugyanazt a felállást, mert a konténer fix - így nincsenek (sokkal kevesebb van) rejtett dolgokból. Egyszer, valaki feltelepítette ezt, más beállított azt, mi borul meg, etc. meg az nginx dependency frissítés sem szól be a foobar függőségeinek.
> Vagy a docker konténerbe is debiant teszek és apt-olok?
Lehet, lásd: https://hub.docker.com/_/debian/
De egyébként így ránézésre az nginxes image is ezt csinálja: https://github.com/nginxinc/docker-nginx/blob/c8bfb9b5260d4ad308deac534…
- A hozzászóláshoz be kell jelentkezni
Akkor jól gondoltam, köszönöm a választ. Viszont a kérdező ilyet is felvetett
Valamint sok esetben fuggok az Ubuntu altal szallitott csomagoktol, amelyek idonkent tul regiek
Így viszont a nginxes docker imagetől függ a kérdező, ami pl bonyolultabb program függőségeknél (pl. php) ugyan úgy függ az image karbantartójától is, hogy belerak-e mindent ami kell. Szóval ez kicsit fura nekem ebből a szempontból amit a kérdező felvet.
- A hozzászóláshoz be kell jelentkezni
Ahogy eddig lattam, docker-en altalaban ujabb verziok erhetoek el, mint egy tobb eves LTS kiadasban.
PHP kapcsan lattam, hogy a Docker image ugy van elkeszitve, hogy abbol sajat image-t letrehozva konnyeden hozza lehet adni a kulonbozo modulokat. Igen, kell sajat Dockerfile es image keszites, de megvan az a lehetoseg, hogy a szamomra szukseges modulokat beletegyem, valamint annak a lehetosege is, hogy, szukseg eseten, ujabb verziot hasznaljak mint amit a 16.04-es Ubuntu szallit.
Igazabol a PHP-s kontener eseten nem volt szuksegem ujabb PHP-re, viszont a php:7.2-apache image-bol kiindulva 2 parancs segitsegevel aktivaltam a rewrite es headers Apache modulokat valamint a mysqli php kiegeszitest.
Amugy meg csak ismerkedem Docker-el, igy nem kizart, hogy akad mas fura kerdes/felvetes is a reszemrol. Keretik kello higgadtsaggal kezelni oket :}
Sic Transit Gloria Mundi
- A hozzászóláshoz be kell jelentkezni
a random komponensek verzioi kapcsan az is kerdes, melyik linux disztrot valasztod, amelyikben benne van a kivant verzio. Altalaban szokott lenni egy preferalt disztribucio, amiben vagy benne van, ami kell, vagy nincs. Ha benne van, jo, ha nincs, akkor fejvakaras, hogy hogyan oldjuk meg: vagy masik disztroval, vagy csomagot csinalni az uj php/.../whatever verziobol
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Ah, valami miatt a libcontainer-re gondoltam.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Nem, dehogy, ennél sokkal több. Network isolation, állapotmentesség, és még ezer más dolgot tud.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
> A Dockerfile-ok es a szukseges start scriptek megvannak, es mukodnek is.
Én docker-composeba, meg saját Dockerfileba raknám, a start scriptek jelentős részét.
Amit csak lehet, kivennék a shellből, mert nekem fáj azt tutujgatni.
Egyébként én így pöcögtetek egy belső gitlabot nálunk, megy ahogy kell, gond nem sok volt vele. De nem vagyok üzemeltető, szóval ez ilyen best effort alapon megy (jobb, mint ami előtte volt :-) )
- A hozzászóláshoz be kell jelentkezni
Szerintem jó irány, ráadásul azt az előnyét is megkapod, hogy viszonylag egyszerűen tudod verziókövetni a konfigodat, és esetleges újratelepítésnél git clone, aztán (persze ha mindent jól raktál össze) docker-compose up és kész is vagy.
- A hozzászóláshoz be kell jelentkezni
A kerdes: jo otlet ez vagy nem? Van-e jobb megoldas?
jo, van:
- tedd fel az elkeszitett image-eket a docker hub-ra (nyilvan, amit ertelmesen lehet). Aztan ha pl. masik gepre at akarod tenni a cuccokat, akkor nagyon egyszeru dolgod lesz...
- verziokezeld a konfigokat, scripteket, dockerfile-t, ..., es ezek kozul amit csak mersz told fel egy privat repo-ba
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Koszonom a tippeket.
Ha ujra kell kesziteni az image-t masik gepen, nem problema, gyorsan megvannak.
Van egy VPS-em OVH-nal, oda eleg nyugodt szivvel teszek fel privat dolgokat (Valamint a hazi szerveren is megvan, ahonnan naponta mentes keszul rola es atkerul Nextcloud-ba. Onnan meg szinkronizalom telefonra is).
Viszont, ha mar ilyen konkret javaslataid vannak, feltetelezem, hogy aktivan hasznalsz Docker-t. (Igazabol sejtem, mert remlik, hogy pilert ajanlodtad docker formajaban is). Arra mi a bevett szokas, hogy a kodot bejutassuk a kontenerbe? Igazabol 2 opciot latok erre:
1. A Dockerfile-ban bemasolni COPY-val az image-be
2. Volume-kent mountolni a kontenernek.
Ha kulso valaki szamara keszitenek image-t, akkor mindenkepp a Dockerfile-ban masolnam be a kodot, de sajat reszre talan inkabb a masodik modszer elonyesebb, hisz konnyen tudom frissiteni a kodot, anelkul, hogy uj image-t kellene keszitenem. Esetleg erre is van javaslatod? :}
Sic Transit Gloria Mundi
- A hozzászóláshoz be kell jelentkezni
mi a bevett szokas, hogy a kodot bejutassuk a kontenerbe?
nem vilagos, milyen kodra gondolsz. Mondj tobbet, akkor specifikusabbat tudok mondani.
Ennyi info alapjan azt mondanam, hogy ugy ird meg a dockerfile-t, ill. a hivatkozott scripteket, etc. hogy a docker build utan mar egy hasznalhato image-ed legyen, amit nem kell meg utana patkolni. Ha meg kiserletezel, akkor hasznald a docker cp parancsot, amivel a host es a kontener kozott tudsz be- vagy kimasolni file-okat. A volume mount-olas is egy opcio, van, amikor az jobb, de mondom, attol fugg, mit akarsz csinalni azzal a koddal...
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Konkretan a helyzet a kovetkezo: merem a homersekletet a lakasban, es mentem adatbazisba. Van egy webes felulet, hogy barhonnan lathassam az aktualis homersekletet, modositsam a referenciat, valamint visszamenoleg is lathassam, hogyan valtozott grafikonon. Ehhez az adatokat egy webservice-en keresztul kerdezem le az adatbazisbol. A weboldal es a webservice 2 kulon git repoban van, es meg fejlesztes alatt. Ha ugy itelem meg, hogy az uj verzio rendben van, azt szeretnem uzembe helyezni. Elso esetben kell kontener leallit, uj image elkeszit majd uj kontener indit. Masodik esetben sima git pull, es a volume-on keresztul maris az uj verzio fut.
Masik helyzet pedig a config file-ok. Peldaul a Apache reverse proxy config file-ja. Ha akarok egy uj atiranyitast, akkor csak modositom a config file-t, es nem kell uj image-t kesziteni. Vagy ilyen helyzetben javalott egy entrypoint.sh script megirasa, ami a kontenernek ENV valtozokent atadott parameterek alapjan dinamikusan modositja a config file-t?
Sic Transit Gloria Mundi
- A hozzászóláshoz be kell jelentkezni
Az alapelv az, hogy egy image önmagában egy teljes egész, tartalmazza magát az alkalmazást, ami fut - többféle okból.
Egyrészt maga az image az nem az alkalmazások függőségeit csomagolja össze, hanem az egész alkalmazást.
De biztonsági okai is vannak ennek.
Például auditálás: egy image hash alapján mindig megmondható, hogy mi az, amit az image mint futtatható kódot tartalmaz.
Másrészt így kontrollálható a release folyamat: csak úgy kerülhet be futtatható kód az image-be, ha azt a megfelelő személy engedélyezte, és beépül az image-be, amúgy kívülről nem jöhet.
Szóval NE, ne szokj hozzá ahhoz a rossz szokáshoz, hogy a konténer futtatható kódot kap kívülről. Hiába vagy otthon, és ez egy one-man projekt, akkor sem. Az ilyen "otthon is jó volt, munkában is jó lesz" szokások azok, amik kerülendők. Szokj hozzá, hogy otthon is olyan kódot írsz, mintha élesben írnád. Pont azért, mert amúgy számodra ez egy éles kód, amikor felhasználod.
Amire a bind mount meg a volume való, az az , hogy konfigurációt kap a konténer olvasásra, illetve a perzisztens adatait (ha vannak ilyenek), akkor oda írhatja.
A konfiguráció az természetes, hogy jöjjön kívülről, ez alap. Így lehet ugyanazt a kódot teszt meg production környezetben is futtatni, anélkül, hogy az image-hez hozzá
kelljen nyúlni.
És nem kell leállni így:
1. a konténer elé teszel egy proxyt, ez lehet mondjuk HAproxy vagy nginx is.
2. Az image-t elkészíted, amíg a régi backend fut. Ehhez nem kell leállítani semmit.
3. Elindítod az új konténert egy új porton, megmondod a proxynak, hogy van egy új instance abból a szolgáltatásból az új porton, a proxy ezt értelmezi és máris ki tudja szolgálni a kéréseket az új backendből is, meg a régiből is.
4. Ezután megmondod a proxynak, hogy a régi szolgáltatás már nem él, majd leállítod a régi konténert.
5. Eztuán a proxy a kéréseket mindenképpen az új backend felé küldi
6. Kész, 0 downtime.
Ha minderre egy scriptet is írsz, akkor még gyorsabb az egész, észre sem lehet venni semmit kívülről.
https://www.haproxy.com/blog/dynamic-configuration-haproxy-runtime-api/
https://serverfault.com/questions/378581/nginx-config-reload-without-do…
- A hozzászóláshoz be kell jelentkezni
Koszonom szepen a reszletes magyarazatot. Modositani fogom, hogy a kod keruljon be az image-be, es volume-al csak konfiguraciot kapjon.
Amugy az a minimalis downtime, amig ujrainditom a kontenert az uj image-el, nem problema.
Sic Transit Gloria Mundi
- A hozzászóláshoz be kell jelentkezni
Ilenre celszerubb valamelyik orchestrator megoldast hasznalni, ami alapbol tudja az uj verziok cserejet es inditasat, valamint a kontenereid managementjet. Swarm, k8s, mesos/dcos, consul.
Kezzel managelgetni a container-eket oltari nagy szopas. Ha mar kettonel tobb van es valtoznak a verziok mondjuk minimum hetente, akkor haszalj valamilyen orchestratort.
- A hozzászóláshoz be kell jelentkezni
Csinaltam egy kis manage script-et, amivel egy-egy parancs segitsegevel tudom ujrabuild-elni az osszes image-t, valamint leallitani/inditani az osszes container-t. De utananezek ezeknek az orchestratoroknak.
Sic Transit Gloria Mundi
- A hozzászóláshoz be kell jelentkezni
Apróság: a consul nem orchestrator, az egy elosztott kv store.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Bocsi igaz. Viszont nagyon jol lehet kore orchestratort epiteni. Nem voltam pontos.
- A hozzászóláshoz be kell jelentkezni
Ja, de a fene se akar orchestratort epiteni sajat maganak :)
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Ha az ugyfel azt keri en barmit epitek neki. Amugy a consulban levo gossip protokoll igen jol jon egy csomo esetben. Jo kis tool az, csak tenyleg kell meg kore par dolog. Bar - mint azt mondtam - ha az ugyfel keri barmit megcsinalok neki. :D
- A hozzászóláshoz be kell jelentkezni
Ahogy felettem/alattam is irtak, a docker image egy kb. immutable doboz. Ha valtozik valami, pl. az egyik konfig file, akkor bizony ujra kell / ajanlott build-elni, pl. egy masik tag-gel, igy ha gaz van, akkor egyszeru a rollback.
En pl. igy futtatom az egyik kontenert (bar kodot nem adok at, csak konfigot, valtozokat):
docker run -d --net=piler --name worker0 -p 2520:25 -e PILER_HOSTNAME=worker0 \
-v /data/influxdb.inc:/etc/piler/influxdb.inc:ro \
-v /data/build/worker0.lic:/etc/piler/piler.lic:ro \
-e MULTITENANCY=1 -e MULTINODES=1 -e MASTER_NODE="$NODE_GUI" someimage:withtag
Hasznalom a -e-t valtozok atadasara, de a volume mount-ot is. Az utobbi oka egyszeru: nem akarom, hogy a docker hub-ra feltoltott image-ekben benne legyen az influxdb elerese, sem pedig a jatszos licence file.
a Apache reverse proxy config file-ja. Ha akarok egy uj atiranyitast, akkor csak modositom a config file-t, es nem kell uj image-t kesziteni.
ez is egy lehetoseg. En azonban inkabb a fentinel beletettem a piler konfigot a docker build soran.
Az entrypoint.sh es mas hasonlo dinamikus modositas helyett sokkal jobb, ha a continuous integration vizeire evezel, ahol modositasz egy konfigot, utana docker build, docker run es tesztekkel meggyozodni, hogy minden koser, es majd csak aztan hasznalod az uj image-et.
Mivel minden kontener/image 1 dolgot csinal, igy ezeket nem tul nehez ilyesmi folyamatokkal megcsinalni.
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Van amire jo a kontenerizacio es van amire nem. Ugye a "run'n'drop"-ra es a "stateless"-re lett kitalalva es nem "long-running services"-re. Szoval ha stateless egy "szolgaltats"(sime progi), akkor mehet a kontenerbe. Ha annal tobbet kell tudnia, akkor mar kerdeses, hogy erdemes e hasznalni. Itt szoba jovet a kernel kontext switching es az altala okozott tul magas syscpu usage, stb, stb. A jol megvalaszott FS is szamit. Az AUFS, LVM, overlayFS1-2, mind masra jo. Belefuthatsz jo nagy I/O problemaba, vagy hogy elfogynak az inode-ok, stb, stb.
Ha a cel az, hogy a szolgalatatsok konfiguracioja mindig azonos legyen, akkor celszeru inkabb valamilyen IaaS megoldast hasznalni, pl. Ansible. Azt GIT-ben tarolni.
A docker eseteben a konfigvaltozas eseten buildelhetsz egy uj image-t minden alkalommal. Megint oda jutunk, hogy ezt csak akkor erdemes csinalnod, ha stateless szolgaltatasokat futtatsz.
Szoval en a kevert megoldasra szavaznrk. Divat mindent kontenerizalni, csak van amit nem erdemes. Es tobb problemat okoz, mint amennyi elonye van. :D
- A hozzászóláshoz be kell jelentkezni
"A docker eseteben a konfigvaltozas eseten buildelhetsz egy uj image-t minden alkalommal."
Nem kell mindig:
docker commit
docker push
docker history
- A hozzászóláshoz be kell jelentkezni
lehetni eppen lehet, de azert jo, ha erre nem szokik ra az ember...
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
Szerintem semmi baj nincs ezzel, ha tudjuk mikor jó használni, nagyobb baj az, amikor nem tudjuk, hogy egyáltalán van ilyen lehetőség.
- A hozzászóláshoz be kell jelentkezni
Szep es jo dolog minden esetben egy uj reteget hozzaadni az image-hez, csak utana jobb egyet flattenelni, mivel mint irtam is nagyon nem gyors egyik docker filesystem storage sem, ahogy nonek a layerek. Szoval en kiegeszitenem egy export/importtal inkabb.
Regebben meg volt is egy olyan bug, hogy X layer utan nem ment az AUFS (40+ layer asszem, de mar reg volt). Az overlayFS eseten meg aztan fel is zabaltatjuk az underlaying FS osses inode-jat a layerekkel. Az AUFS meg bun lassu lesz a merge-ek miatt. Aztan ott van, hogy ilyenkor egy jo kis 1GB-os file torlese nem jelent semmit sem ugye, hiszen az szepen ott marad. Igy szuletnek az 5GB-os "helloworld" containerek. :D
Szoval most inkabb sj-vel ertek egyet. Inkabb ne is tudjon rola az, aki kezdo dockeres. :D
- A hozzászóláshoz be kell jelentkezni
senki sem írta, hogy nem kell tudni használni
- A hozzászóláshoz be kell jelentkezni
en egyet ertek veled, de sajnos futottunk mar bele olyanba, hogy orult modon hasznaltak a commit funkciot aztan sirtak, hogy de miert lett 17GB a docker image :D
aztan egy export import utan meg mar csak kb. 300MB volt. :D
szoval ezert mondtam, hogy aki nem tapasztalt az inkabb ne hasznalja es maradjon a basic dolgoknal. Azzal kevesebb bajt tud okozni. :D
szoval megegyszer, total egyet ertek veled, de akkor is tartom, hogy odafigyelest igenyel a dolog. Sok mindent kore epitettek az alap koncepcionak (run'n'drop) hogy szolgaltataskent lehessen a kontenereket hasznalni. Az egesz jo nagy ganyhalmaz most mar es eppen ezert nagyon erteni kell mit csinal az ember. Harom negy fele volume, 3-4 fele network osszekapcsolas, stb, stb.
Szoval igen, van sok hasznos funkcio, amiknek nagyon jol kell ismerni a hatulutojet. :D
- A hozzászóláshoz be kell jelentkezni
Ha jol emlekszem 127 layer a limit, amit azert suru commitolassal el lehet erni eleg hamar.
- A hozzászóláshoz be kell jelentkezni
Btrfs esetén is van ilyen probléma?
- A hozzászóláshoz be kell jelentkezni
Sub
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
Nem használtam (még) Dockert, de amit (szintén saját célra) én csinálok: egy Makefile, ami szabályok alapján feltelepíti a szükséges csomagokat, bemásolja (legenerálja) a szükséges konfigfájlokat, elindítja a megfelelő szolgáltatásokat.
- A hozzászóláshoz be kell jelentkezni
Ansible/Puppet nem lenne erre kézenfekvőbb?
Egyébként a Makefile (meg az ansible vonal) pont a disztrók közötti váltást nem oldja meg egyszerűen :'(
- A hozzászóláshoz be kell jelentkezni
Ansible/Puppet nem lenne erre kézenfekvőbb?
Lehet, de így sokkal menőbb :)
Nem bonyolult dolgokra és szolgáltatásokra kell gondolni. A Makefile szerkezetét kb. ismerem, a rendszerben eleve adott, túl sok ész nem kellett hozzá.
pont a disztrók közötti váltást nem oldja meg egyszerűen
Ez nem is célom :)
- A hozzászóláshoz be kell jelentkezni
En ezt varom, hogy vegre elkeszuljon es megszabaduljunk a temaindito altal is vazolt "baromsag"-tol, hogy az os verziotol fuggnek a csomagverziok.
Sajnos vegul az utolso release ugy dontottek, hogy nem modularis lett.
- A hozzászóláshoz be kell jelentkezni
Erdekes otlet, magam is gondolkodtam mar ilyenen... Ilyenkor amugy a mentett config stb hogy marad meg, ha pl frissitem a docker image-et?
Anno kerdeztem hasonlot, de akkor azt a valaszt kaptam, hogy a docker nem erre valo, permanens adatokat nem tarolunk benne. Marpedig ezeknek az alkalmazasoknak is vannak ilyen adatai...
- A hozzászóláshoz be kell jelentkezni
> Ilyenkor amugy a mentett config stb hogy marad meg, ha pl frissitem a docker image-et?
mindent, amit perzisztensnek szeretnél tartani, ki kell rakni volume-ba: https://docs.docker.com/engine/admin/volumes/volumes/
ez nagyon jó felállás szerintem - az adat, és a futó alkalmazás szét van szedve, így mind a mentés, mind a frissítés sokkal egyszerűbb, mint valami egybeheggesztett masszát frissíteni.
- A hozzászóláshoz be kell jelentkezni
Masik megoldas egy jo kis entrypoint script, ami lehuzza a kontenerbe a git-rol amit kell egy parameter alapjan. Persze akkor kell a containerbe a git-et is telepiteni. De azert eleg meno, ha van egy altalanos image-d, amit ha elinditasz hogy "nginx_prod" akkor lehuzza a configokat ez alapjan es aztan elinditja aszolgaltatast.
Igy aztan ha indul egy uj darab belole, akkor az mar a legfrisebb konfiggal indul. A regi meg majd leall, amikor leall.
- A hozzászóláshoz be kell jelentkezni
De azert eleg meno, ha van egy altalanos image-d
-1
Egy docker image-ben pont az a poen, hogy csak a szukseges dolgokat kell belepakolni. Ha inditas utan telepitesz, gyartasz konfigot, ... az foloslegesen megnoveli a latency-t, mire a kontener hasznalhato. Szoval en azt partolom, hogy ez mind a docker build feladata. Az altalanos image egyreszt bloatware-t eredmenyez, masreszt minel tobb minden van egy futo rendszeren (meg ha kontenerben is van), annal inkabb sebezheto, szoval ez a devopssec-kel is szembe megy...
--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni