docker multi stage build - WTF??
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?
■ 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?
Forditas
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).
Biztosan velem van baj, de
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.
Szerintem én kezdem kapisgálni... :)
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...
Csak jelzem, így sem lesz
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.
Forrasbol
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.
A gentoo az, ami teljesen
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.
Docker
spam :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
#spam
Végül is mire való a docker?
É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?
terheléselosztás
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.
http://weblabor.hu/forumok/te
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)
Nana :)
Pláne ha nem igazán lehet egy mondatban megválaszolni.
Az nem. De ha nem emlékszem,
Ha már felhozta egy
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.