Docker-ben epites - kell uj image-et csinalni minden alkalommal?

 ( Vamp | 2019. január 17., csütörtök - 22:10 )

Sziasztok!

Vyos-t hasznalok tuzfalnak, de ugye 1.2.0-tol az elore buildelt iso-k csak az elofizetoknek jarnak. Termszetesen a forraskodbol (https://github.com/vyos/vyos-build/tree/crux) meg lehet epiteni a friss release-eket, erre pedig a konteneren beluli build a legjobb(a Vyos fejlesztok is azt ajanljak), mert ott minden fuggoseg rendben megvan.

A kerdesem, hogy ha frissul az adott tree amit pull-al befrissitek, kell minden alkalommal a dockerfile-bol uj image-et/kontenert krealni,vagy erre csak akkor van szukseg, ha maga a dockerfile is frissul? Eleg sokaig csinalja a szukseges kontenereket, nem tul jo minden alkalommal ujracsinalni...

Nem surun hasznalok ilyenet, ezert a tudatlansagom, elnezest.

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

Nem ismerem ezt a Vyos dolgot de felesleges uj image-t buildelni ha nem valtozik a Dockerfile es az adott source tree nem build-kor kerul be az image-be (hanem a container-be lesz be mount-olva)
A build soran keletkezik az image es amikor futattod az image-t akkor lesz container. Az image keszites tarthat sokaig de a container maga gyorsan letre jon es elkezd benne futni az "alkalmazas".

Hello!
A Dockerfilet ilyenkor azért kell(het)/szokás újra buildelni, mert az upstream repokban lévő csomagok frissül(het)nek.

A software build folyamatát nem néztem, csak a Dockerfile-t. (linkeléstől függ) előfordulhat, hogy menne a build egy régebbi konténerben, s végül a production környezet frissebb csomagjaival ugyan azt a végeredményt/biztonsági szintet kapnád, de mire ezt kiteszteled, ellenörzöd... már lefutott a Docker build.

Szóval két egymást követő build során valóban felesleges a konténert is újra buildelni. Nagyobb időt követően:
HA (ismétlem, HA) nem változott a Dockerfile, akkor elég ha belépve nyomsz egy apt update & upgrade kombót a teljes rebuild helyett.

Üdv,
Laci

Igazad van, ha biztosra akarsz menni akkor ujra kell build-elni.
De azert is vannak (kellene legyenek) a software-eknek kulonbozo verzioi, hogy egy software meg tudja mondani (es meg is kellene mondja), hogy egy masik software x verziojaval az elvaras szerint mukodik vagy neki y verzio kell belolle.

"elég ha belépve nyomsz egy apt update & upgrade kombót a teljes rebuild helyett" en ezt erosen ellenjavallom. Immutability-re kell torekedni. Ha valami ir a kontenerbe, akkor baj van. Azt ki kell vezetni volumera. A Kontener nem valtozhat! A kontener nem vm.

Ha valtozik valami ujra kell buildelni a kontenert. Ha jol van sorrendezve a Docker file, akkor alig jon letre uj reteg, szoval helyet alig foglal az uj. A Dockerfile valtozas csak akkor lehet manko, ha abban konkret verzio van. Viszont change eseten valtozik a Dockerfile, szoval ujra kell buildelni. Ha nincs verzio, akkor meg ujra kell buildelni. Szoval vegul ha valtozik valami ujra kell buildelni.

-
First impressions of the new Cloud Native programming language Ballerina

-2, nagyon gaz, amit leirsz...

--
O1G = orbanegygeci

OK, akkor inkabb ujra letrehozom a docker image-et, az a biztos. Vegul is nem frissul olyan gyakran a Vyos, belefer az az egy ora.

Vegul is nem frissul olyan gyakran a Vyos, belefer az az egy ora.

egy kontenerben nem csak az alkalmazas van, hanem a fuggosegei, pl. libek, programok, akarmi. Ezek nem frissulnek? Pedig kellene. Ha kijon pl. egy ubuntu fix (tfh ubuntu alapu a kontenered), akkor azt nem teszed fel? Pedig kellene: igen, ugy, hogy ujraepited az image-et, es termeszetesen verziozod, ill. leteszteled, hogy meg mindig frankon mukodik-e benne a vyos, whatever...

--
O1G = orbanegygeci

A dockerfile egy image -t ír le, ami a hordozható/kezdeti állapota a konténernek. Amint elindítod, már nem image, hanem konténer, mutábilis fájlrendszerrel. Ezen belül nyugodtan csinálhatsz bármit, módosíthatsz fájlokat, illetve ha pl. van benne valami git repo meg build toolok, nyugodtan pullozhatsz és lefordíthatod az alkalmazásodat, nem kell új image -t csinálnod. Arra ügyelj csak, hogy eltávolítod a konténert, akkor ugrott az image indítása óta keletkezett delta. Ugyanakkor konténerből a vissza irány is működik, van olyan docker parancs amiből egy konténerből image -t lehet csinálni. Ha időnként egy git repot huzol benne és buildelsz akkor ez pont egy olyan helyzet amikor a build végeztével érdemes docker commit -al imaget gyártani belőle.

pl. imageneve:v1.12, imageneve:v1.23, stb

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

a build végeztével érdemes docker commit -al imaget gyártani belőle.

-1, antipattern

--
O1G = orbanegygeci

Plz elaborate. De légyszi te olvasd el kétszer a kérdést, nem úgy mint lent a kollega :)

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

oke, emese, elolvastam. Tehat egy alkalmazas build-elese a feladat. Ennek reprodukalhatonak kell lennie. Ehhez pedig automatizalhatonak kell lennie. Amit te felvazoltal, az a kokany matyiskodas meg erre a use case-re is.

Irtam fentebb, de ugy latszik, neked 1x sem sikerult elolvasni (vagy esetleg a koncepciot nem ertetted), de egy alkalmazashoz altalaban OS-beli fuggosegek is tarsulnak. Ezert nagyon nem eleg az, hogy ha a repo frissul, majd akkor build-elsz. Hanem ha az OS megvaltozik alatta (biztonsagi frissitesek nalatok nem rulez?), akkor is build-elni kell, sot le kell tesztelni, hogy az igy ujrabuild-elt cucc meg mindig jol mukodik-e. Aztan ha lett egy uj verziod az app-bol (ami akkor is uj verzionak szamit, ha csak az OS, fuggosegek valtoztak meg alatta, es amit valahogy jelolni kell), akkor azt el kell tarolni valahogy.

Olyat meg biztos nem lattal, hogy a docker ugy meggajdul, hogy olyankor a /var/lib/docker-re kuldott ecetes rm -rf a megoldas. Ilyenkor mit csinalsz az eppen nem futo kontenereddel? Szoval a legjobb az, ha az egeszet egy ci pipeline-ra bizza az ember. Gondolom, te ilyet messzirol sem lattal, ezert batoritasz ugyetlen antipattern-t.

De kerdezheted, mi van akkor, ha a sokaig tart az (docker) image build-elese, mert sok cuccot bele kell tenni? En ezt ugy oldottam meg, hogy csinaltam egy koztes stage-et, amiben benne van minden fuggoseg, legyen a neve pl. myapp/stage1, es ebbe kerul bele az app, amit build-elni kell. A stage1-et meg inger szerint update-elem (pl. hetente, minden sec. fix eseten, whatever). Ja, tfh sokaig tart a stage1 elkeszitese: pont ez egy ujabb erv, hogy ne kezzel csinald, aztan malmozz, amig minden felmegy, hanem elindul mondjuk egy jenkins job, ami a vegen szol, hogy kesz.

Jo ez a forum, hogy olyanoktol is kerdezhetsz, akik tobbet lattak nalad, nem? ;-) Tetete nagyarc...

--
O1G = orbanegygeci

Iparilag alkalmazom én is a dockert, awst, gitlabi-cit, jenkinst, terraformot, ansible-t, építettem fizikai/virtuális infrákat banki és ecommerce környezetben, build pipeline-okat, automatizált deployment és teszt rendszereket. Pontosan értem amiket fent irsz de _szerintem_ (és ha tévedek, mea culpa), a kérdezőnek egyszerű, netán otthoni környezet kell, és az egyszerű kérdésére egyszerű válaszra volt szüksége, nem arra, hogy iparilag megalapozott, mission critical rendszerekben milyen patterneket kellene követni.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

jo, hat annyira meggyozoen toltad az antipattern-t, hogy mindjart lattam, pro user vagy, LOL...

--
O1G = orbanegygeci

"kezdeti állapota a konténernek" ami a veg allapota is egyben, ha az ember koveti az ajanlast
"mutábilis fájlrendszerrel" igen, amit erdemes monitorozni, es jol tarkon verni valakit, ha ir a kontener a fajlrendszerre. abbol csak a baj van
"nyugodtan csinálhatsz bármit, módosíthatsz fájlokat" ne tedd, meg fogod szivni
"nyugodtan pullozhatsz és lefordíthatod az alkalmazásodat" legyel ideges, amikor ilyet csinalsz vagy valaki mas
"ugrott az image indítása óta keletkezett delta" az egyik oka, hogy nem irunk a kontenerben, ugyanis annak elveszik a historyja, es kesobb ember legyen a talpan, aki megmondja mi fut
"Ugyanakkor konténerből a vissza irány is működik" nem mukodik, marmint van ra parancs, de eles rendszer uzemeltetesenel hosszu tavon nem mukodik
"van olyan docker parancs amiből egy konténerből image -t lehet csinálni" van, csak az igy keszult imagekben rejtely, hogy mi van, nem mukodinek a jol bevalt dockeres parancsok, az F.A.SZ. se fogja tudni, hogy mi van a kontenerben
"érdemes docker commit -al imaget gyártani belőle" nem erdemes. Docker filebol buildelunk imaget ha egy kicsit is igenyesek vagyunk, es azt taroljuk private/public repoban, mert ugy sokkal nehezebb sundabundat rejteni a kontenerbe, valamint nem lesz olyan, hogy valamit kifelejtunk x verzioban, ami y verzioban utolag hozza takoltunk

szoval roviden, lehet ganyolni dockerben, de nem kotelezo, sot erossen ellenjavalt. Ez a komment azt irja le, hogyan ne csinald!!! Meg azt honnan kell menekulni ha ilyesmit latsz!!!

-
First impressions of the new Cloud Native programming language Ballerina

A csóka azt mondta, hogy a dockert arra használja hogy lebuildeljen egy alkalmazást. Leszed egy git repót, amiban van Dockerfile, megbuildeli, belép, megcsinálja az app buildet, kimásolja valahova és ott elindítja (valami ISO fájlokról is szó volt). Utána leállítja a konténert, és legközelebb akkor indítja el, amikor a belül használt git repoban van mit pullozni és újra lehet appot buildelni. Senki nem beszélt semmiféle üzemeltetésről. A kérdés pedig arra irányult hogy ha új verziót akar buildelni, akkor kezdje-e elölről az egészet, vagy ne. Az én tanácsom a fenti use case -re az hogy ne, hiszen elég újra elindítani a konténert, belépni, git pullozni és buildelni.

Ez a konténer nem az a konténer amit te (egyébként jól alátámasztott érveid alapján) elképzelsz, csak egy fiókba tehető és újra elővehető build környezet.

A tanácsaid nagyon jók _üzemeltetett_ szolgáltatások esetén, de úgy tűnik az óriási arcod eltakarta hogy mi a feladat. Szóval köszi Emese. :)

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

"hiszen elég újra elindítani a konténert, belépni, git pullozni és buildelni." ertem en, hogy ezt is meg lehet csinalni, csak ez igy nem igazan automatizalhato. Mennyival atlathatobb, deklarativabb, ha az egesz buildet beteszi a Docker fileba, ne adj isten egy multi buildel oldja meg, hogy az a resze, ami nem valtozik, az nem buildelodik ujra. Igy a teljes build folyamat le van irva, lehet verziokovetni, es egyetlen parancs futtatasaval megtortenik a magia. Es a vegen eldobja amivel buildelt, es ujrahuzza 0-rol barmikor.

Nem az arcom takarja el a dolgokat, hanem tapasztalatbol beszelek ;) Ha nem reprodukalhato a megoldas, akkor az SZ.A.R., mert gondolom 2nel tobbszor kell majd csinalni a dolgot a jovoben. Ne adj isten egy CI-is csinlahatna ha valtozik a repo.

-
First impressions of the new Cloud Native programming language Ballerina

Ha csak build környezet, akkor is lehet immutable, csak a munkakönyvtárat kell volume-ként beadni. Mutable konténer antipattern és kész ;)

Ez igaz, de a srác még a fogalmak tapogatásánál tart (image vs konténer), majd a következő lecke a volume handling lesz.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene