ugrás a tartalomhoz

docker multi stage build - WTF??

mind1 valami név · 2020. Szep. 23. (Sze), 07.48
Tudja valaki, hogy ez a multistage build nevű izé mire jó valójában?
Biztosan nagyon leépültem agyilag, de nem értem.
Nekem az jött le az olvasmányaimból, hogy létrehoz egy nagy méretű image-t, amire telepíti a saját, statikusan linkelt cuccait, majd ezt az elkészült anyagot átviszi egy sokkal kisebb image-re.
És itt jött a WTF?? ...
Ennek mi értelme?
Nem egyszerűbb lokálisan, docker nélkül legyártani a telepítéshez szükséges fájlokat és azokat bemásolni a kész konténerbe, mondjuk egy tar formájában?
 
1

Forditas

vbence · 2020. Szep. 23. (Sze), 19.47
Altalaban forasbol keszulnek a "gyari" imagek, ekkor szukseged van a forrasra es egy rendszerre a forditoi infrastrukturaval - aminek nagy resze nem kell futasidoben.

Megteheted hogy egy darab nagy RUN parancsban alakitasz ki mindent aminek a vegen gondosan kitorlod a forditoi eszkozoket, lecsupaszitod a rendszert... vagy lebuildeled a cuccot es egyszeruen tiszta alppal indulsz ahova mar csak azt viszed at amit hasznalni szeretnel (futasidoben).
2

Biztosan velem van baj, de

mind1 valami név · 2020. Szep. 23. (Sze), 20.18
Biztosan velem van baj, de továbbra sem értem.
Docker image-t forrásból legyártani??
Van ennek gyakorlati értelme?

Konténerbe leginkább saját fordítású alkalmazást pakolunk vagy kész szoftvert paraméterezünk (mondjuk egy radius vagy web szervert)
Előbbieket mi értelme konténerben fordítani? Utóbbiakat meg egyszerűbb a konténerbe csomagolt OS saját csomagkezelőjével felpakolni, ahhoz meg nem kell semmi extra.

De próbálom újra elolvasni a gyári doksiban foglaltakat, de nagyon nem tudok mást kihámozni belőle.

https://medium.com/capital-one-tech/multi-stage-builds-and-dockerfile-b5866d9e2f84 itt van egy életből vett példa, de mintha pont azt írná, ami ellen minden sejtem tiltakozik: a dockert nem csak futtatásra használják, hanem abban is készítik el a később élesítendő programokat. Na mindegy, az elmúlt tíz évben eléggé megváltozott a világ IT területeken is.
3

Szerintem én kezdem kapisgálni... :)

Pepita · 2020. Szep. 24. (Cs), 15.12
vbence:
Megteheted hogy egy darab nagy RUN parancsban alakitasz ki mindent aminek a vegen gondosan kitorlod a forditoi eszkozoket
Nos én eddig pont ezt csináltam pl "gyári" apache-php image-ekkel. Ugyanis eléggé "csupaszok", sok általam használt extension hiányzik belőlük. Ugyanakkor meglehetősen hosszadalmas a buildelés így, noha a kész konténer elérhető később cache-ből, de ez többnyire nem vonatkozik teszt és éles környezetre, tehát ott időigényes mutatvány.

ami ellen minden sejtem tiltakozik: a dockert nem csak futtatásra használják, hanem abban is készítik el a később élesítendő programokat.
Hát ha jól értem a tiltakozásod, akkor nem neked való eszköz a Docker... Eredetileg pont arra találták ki, hogy teljesen mindegy legyen, hogy a fejlesztő a saját gépén Windows, Linux vagy MacOS "párti" (vagy bármi egyéb), az élessel teljesen megegyező fejlesztői környezetben dolgozhasson - akár a saját gépén.
Nyilván kisebb (környezetfüggő) eltérések lehetnek, de a lényeg az, hogy az oprendszertől a futtató verziójáig minden pontosan ugyanaz dev test és live környezetben.
Ha már fentebb php-t hoztam példaként, itt is megjegyzem, hogy egyes php.ini beállítások eltérhetnek dev-en az éleshez képest (pl error_reporting, display_errors, stb), de csak olyanok, amik a könnyebb fejlesztést szolgálják.

Alap "dockeres" fejlesztői környezet: konténerben a futtató környezet, gazdagépen a megfelelő IDE a kedvenc oprendszerem alatt, ugyanígy a forráskód is a gazdagépen, de bemountolva a konténerbe. Plusz az esetleges logok szintén kint a gazdagépen is.

A fejlesztés fontos része a futtató környezet is, van amikor azon is kell változtatni, így az is előfordul, hogy az image-ek egy repóban vannak a forráskóddal...
4

Csak jelzem, így sem lesz

mind1 valami név · 2020. Szep. 24. (Cs), 15.55
Csak jelzem, így sem lesz feltétlenül ugyanaz. Ha eltérő a host, akkor van rá esély, hogy a konténer is másképp viselkedjen.
Mást ne mondjak, te fejlesztesz ubuntun, az éles meg redhat, egyiken apparmor, másikon selinux a divat.
És ezek önmagukban is tudnak vicces dolgokat :(


Update: build konténerben... Ami (természetesen) kimaradt az előzményekből... Mindenhol azt olvasom, hogy a konténer nem vm, az arra való, hogy abban egy-egy szolgáltatást futtasunk. Namost ezzel (szerintem) eleve szembe megy az, hogy mondjuk javac-k/gcc-k/stb tömegét futtatom benne, build címszóval. Nem tudom, így érthetőbb-e, hogy ezzel mi bajom.
5

Forrasbol

vbence · 2020. Szep. 25. (P), 11.40
A forditassal telpites egyidos a Linuxszal, nem csak a kernelforditas, de csomagok telepitenek resze a forditas pl BSD-ken (ami, ok, nem Linux), de Linux distrok is vannak amik teljesen magukeva tettek a source-bol torteno installt (Gentoo?, Arch? nem 100%).

Tipikusan a nepszeru szerver distrokban (ubuntu, centos) nem a legfrissebb verziokat talalod meg a csomagokbol (az altalad hasznalt stack-tol fugg mennire gyorsan fejlodik, mennire jelentos ujdonsagokat, mennyi bugfixet kapsz egy-egy ujabb verzioval).

A distrokkal jovo csomagok tipikusan NEM kontenerizalt futtatasra lettek konfigolva (logfajlokat hasznalnak, logrotalasra szamitanak, neha bajos foreground-ban futtatni oket).

Szoval ezer okbol forrsabol fogod installalni, nem csomagbol, es ha a celkornyezeted tortenetesen Docker akkor az installalas az image epitesekor fog tortenni. - Nem fogsz olyan cikket olvasni hogy "ne futtass C compilert build-timeban". Az egy kontener egy szerviz okolszabaly production-re vonatkozik, nem build timera, es szigoruan veve a forditas sem jelent tobb kulobozo szerviz egideju futtatasat.

Nagy altalanossagban a meglevo Linux disztribuciok nem kontenerizaciora vannak kitalalva, a Docker-kultura resze kicsit hogy nem tamaszkodik kulso segitsegre. Elsore lehet hogy "a kalapacsos ember esete a problemamegoldassal" latszhat parhuzamnak, de ha mar adott a Docker, miert ne hasznalnank az elonyeit egy reprodukalhato build kornyezet eloteremtesere is.
6

A gentoo az, ami teljesen

mind1 valami név · 2020. Szep. 25. (P), 12.51
A gentoo az, ami teljesen forrásból települ
Az arch egy rolling distro, viszonylag kis erőforrásigénnyel.

Én már a slackware 1.2(?)-re is csak a kernelt raktam fel forrasból, azóta meg javult annyit a csomagkezelés technológiaja, hogy eszembe nem jutna kéez csomagként elérhető szoftvert telepíteni forrasból. Túl sok a nyűg velük.

Konténerben én egy ok miatt látok fantáziát: kellőképp elszelarálódik a service az alaprendszertől, de mégis összekapcsolhatóak, ha kell. És egyszerűbb a használata, mint egy chrootolt környezetnek.
12

Docker

LotteWisswald · 2021. Már. 16. (K), 13.10
A képek készítésének egyik legnagyobb kihívása a képméret csökkentése. A Dockerfile minden egyes utasítása hozzáad egy réteget a képhez, és a következő rétegre való áttérés előtt emlékeznie kell arra, hogy meg kell tisztítania az összes szükséges tárgyat. Egy igazán hatékony Dockerfile megírásához hagyományosan héjtrükköket és egyéb logikákat kell alkalmaznia, hogy a rétegek a lehető legkisebbek legyenek, és biztosítsák, hogy minden rétegben megtalálhatók legyenek az előző réteghez szükséges tárgyak és semmi más. Az utamat a ... helyről kezdtem, ez a kezdet.
13

spam :D

mind1 valami név · 2021. Már. 16. (K), 13.35
Na basszus... Itt tart az AI? Kihámozza a szövegből, hogy miről van szó és úgy válaszol, hogy làtszólag kapcsolódik a témához. :D
(Vagy ez biodroid lenne? Régóta keresek olyan lehetőséget, amivel le lehet buktatni a botokat, de a hagyományos turing-teszt már kevés. :D
14

#spam

Arnold Layne · 2021. Már. 16. (K), 13.36
Semmitmondó, kattintásvadász SEO feketemágia. Nincs helye itt.
7

Végül is mire való a docker?

mind1 valami név · 2020. Szep. 27. (V), 10.17
Úgy elgondolkodtam, hogy mire való ez az eszköz?
Én úgy tudtam/gondolom, elsősorban biztonsági eszköz, kb átmenet a chroot és a virtuális gép között.
Itt írtatok olyat, hogy fejlesztői eszköz, ami biztosítja, hogy mindig azonos környezetben fusson a kész program.
(Dev-teszt-éles)
Egyéb?
8

terheléselosztás

Pepita · 2020. Szep. 28. (H), 09.06
Vehetjük szerintem "egyébnek", egy jól skálázható szoftver esetében megkönnyíti éles környezetben a terheléselosztást, ha a kész image-ekből bármikor bármennyi konténer indítható - amilyen "fajta" konténereken nagyobb a terhelés, abból több, másikakat meg le lehet lőni.
Mindezt automatizálni is lehet.
Így jól elkülönül a tényleges fizikai hardverkörnyezet a szoftvertől, nincs olyan probléma pl, hogy "az adatbázis-vason még lenne RAM meg proci, de az alkalmazás másik vason van és ott kéne plusz teljesítmény", hanem - akár automatikusan - elindul egy újabb app-konténer példány.
9

http://weblabor.hu/forumok/te

mind1 valami név · 2020. Okt. 1. (Cs), 08.25
http://weblabor.hu/forumok/temak/155705

Akkor mégsem vagyok annyira szenilis, csak lapozni kellett volna. :D
(Emlékeztem, hogy ezt a kérdést egyszer már feltettem valahol, csak azt hittem, valamelyik cenzúrázott lapon és azért nem találom, mert törölték)
10

Nana :)

Pepita · 2020. Okt. 1. (Cs), 08.40
Szerintem egyáltalán nem szenilitás ugyanazt a kérdést többször, más irányból körüljárni.
Pláne ha nem igazán lehet egy mondatban megválaszolni.
11

Az nem. De ha nem emlékszem,

mind1 valami név · 2020. Okt. 1. (Cs), 09.54
Az nem. De ha nem emlékszem, hogy hol kérdeztem valamit... :)
15

Ha már felhozta egy

mind1 valami név · 2021. Már. 18. (Cs), 21.45
Ha már felhozta egy spammer... :)
Az imént jött szembe egy olyan probléma ami kissé más megvilágításba helyezi a történetet.

A forrásból telepítést általában a természet ellen való cselekedetként értékelem :)
Viszont van amikor nincs egyéb lehetőség: pythonra vagyok rákattanva, ennek van egy saját kis csomagkezelője, a pip,
Ez többnyire "bináris" csomagokat telepít: lerántja a csomagolt fájlokat, bemásolja őket a helyükre, és kész.
De bizonyos esetekben ragaszkodik, hogy részben fordítani kell. Ami most szembe jött, az a psycopg2 (alias PostgreSQL python modul). Ennek elvben van -binary verziója, de az pont a kis helyigényű alpine image-re nem megy fel.
Na itt, ha jól értem ezt a multi-stage dolgot, már van érthető szerepe: létrehozom a telepítéséhez szükséges környezetet, felrakom, majd a felesleges szemetet törlöm, így viszonylag kis méretű maradhat a végeredmény.