Docker image készítése docker build parancs használata nélkül

A Docker build-ről nem először van szó az I.T. szigeten és nem is utoljára. De vajon érted-e, mi zajlik a build parancs mögött? Lehet, hogy elsőre úgy tűnik, erre nincs is szükség, hiszen épp az a lényeg, hogy a Docker megoldjon mindent. Ha viszont hibát kell keresni, nagyon sokat jelent, hogy tudjuk-e, mire utalhat egy hibajelenség. Hacsak nincs valamilyen fizetős támogatásunk, akkor nem árt kicsit a színfalak mögé nézni. A következőkben azt mutatom be, hogyan lehet saját buildert is készíteni, amihez persze meg kell ismerni, milyen lépéseket végez el a builder és ezek alapján milyen lépéseket kel nekünk leprogramozni. A docker build összes funkcióját nem programozzuk le, de éppen eleget ahhoz, hogy egy hiba esetén már legyen fogalmad arról, hogyad légy önmagad supportja.

A bemutatóban használt forráskód:
https://github.com/itsziget/tutorial-docker-build/tree/v1.0.0

Tartalomjegyzék

• RUN utasítás és ami mögötte van
• Exec alakban írt RUN build-je
• Többféle utasítás használata
• Image history lekérdezése
• Saját builder készítése bash-ben
• Végszó

RUN utasítás és ami mögötte van

[Tartalom]

Nézzük tehát, milyen egy egyszerű Dockerfile tartalma.

Dockerfile.v1

A FROM-on kívül mindössze 2 RUN direktívát tartalmaz. Ezek mindegyike valójában elindít egy konténert, amit általában nem látunk, mert azonnal le is törli alapértelmezetten, amint a build lefutott. Ezen viszont lehet változtatni a --rm=false paraméterrel, ahol az "rm" természetesen a "remove"-ot jelenti, amit ezzel letiltunk. Értelemszerűen a RUN után írt parancs lesz lefuttatva a konténerben hasonlóan a docker run utasításhoz. Az alábbi parancs futtatásával folyamatosan lehet figyelni, hogy éppen milyen Docker konténerek vannak, ami majd jól lebuktatja a docker build parancsot.

Itt lényeges, hogy használtam a --no-trunc paramétert, mert különben csak egy töredéke jelent volna meg a hosszú parancsoknak. Ez a paraméter viszont a megjelenített konténer azonosítót is befolyásolja, ezért azt a "printf" go template függvény segítségével visszaalakítottam 12 karakteresre, ami az alapértelmezett megjelenési forma.

Mindeközben egy másik terminálban a buildet futtatjuk.

A fenti kódban a DOCKER_BUILDKIT változó 0-ra állításával a buildkitet kapcsolom ki, ami teljesen megváltoztatná a build folyamatát és nem látnánk a várt módon a konténereket, nem csak a lefutás után, de közben sem. A --no-cache paramétert is használtam, mivel enélkül, ha az adott direktíva eredménye már szerepel a cache-ben, akkor nem jön létre ismét konténer annak létrehozásához. A fenti utasítás hatására a "watch" parancs ablakában pedig valami ilyesmi lesz:

Exec alakban írt RUN build-je

[Tartalom]

Mivel a shell alakot használtam a RUN direktívánál, azaz stringként adtam meg a parancsot, az egész a /bin/sh-nak lett átadva paraméterként. Ennek vannak olyan előnyei, hogy például az "echo" parancs kimenetét át tudtam irányítani fájlba. Ha json-ként adtam volna meg a parancsokat, egy ilyen alternatív Dockerfile lett volna a eredménye jobb híján:

Dockerfile.v2

Build

Eközben a watch parancs ablakában az alábbihoz hasonló jelenik meg:

Többféle utasítás használata

[Tartalom]

A helyzet viszont az, hogy nem csak a RUN direktívák miatt indulnak el konténerek. Valójában bármelyik direktíva egy konténer indítását is eredményezi, viszont lesznek, amik csak metaadatokat állítanak be, ezért valódi parancs nem fut majd a konténerben. Hogy akkor mégis mi, azt nézzük meg a Dockerfile.v3 használatával.

Itt már van ARG, ENV és CMD direktíva is. Annak ellenére, hogy a CMD-ben is parancsot adunk meg, ennek nem kell build időben futnia, tehát valójában csak metaadat lesz. Ezt ráadásul általában nem shell alakban adjuk meg. Lássuk akkor a buildet:

Ismét lett 5 újabb konténer, ám ebből 3 nagyon furcsa shell paranccsal, amiknek az állapota ráadásul nem "exited" hanem "created", azaz sosem futottam, csak létre lettek hozva:

A #(nop) valójában csak egy komment a shellben, ahol a "nop" a "no operation" rövidítése, azaz akkor sem futtatott volna semmit, ha a konténer el is indul, mivel a csak egy kommentet tartalmazó szkriptnek adja át paraméterül a metaadat definícióját.

Image history lekérdezése

[Tartalom]

Tudjuk, hogy minden konténerhez egy image is tartozik, amiből létrehoztuk. A következő image listából látszik, hogy tényleg minden ideiglenes konténerhez létrejött egy image is.

Itt fontos a --all paraméter, különben az ideiglenes konténerekből létrejött image-ek nem jelennének meg.

A fenti listában az "IMAGE ID" oszlop értékeit összevetve az image-ek listájával látható, hogy melyek azok az image-ek, amik egy adott buildhez tartoznak. Ha arra vagy kíváncsi, egy konkrét image milyen további image-ekből épült fel, a docker image history ezt is megmutatja:

Azt is le lehet kérdezni, hogy egy adott image melyik konténerből lett létrehozva:

Az eredmény pedig:

Ez pedig pont az, amit az image history "Created by" oszlopában is lehetett látni.

Saját builder készítése bash-ben

[Tartalom]

Ezek után a kérdés, lehet-e ezen információk birtokában Dockerfile nélkül is image-et készíteni. A válasz pedig: igen, lehet. Ehhez már csak annyit kell tudni, hogy a docker container commit paranccsal tudunk elmenteni konténert image-ként. A lépések tehát a következők a saját builder írásához:

• Hozd létre a konténert az image-ből, amit a FROM utasításban is használnál, vagy az előző utasítás eredményeként létrejött image-ből.
• Ha programot szeretnél futtatni a konténerben a telepítés egy lépéseként, akkor indítsd is el, metaadatok esetén hagyd "created" állapotban.
• Ha másolni szeretnél fájlokat az image-be, akár az el sem indított konténerbe is lehetséges a docker container cp paranccsal.
• Mentsd el a konténert image-ként a docker container  commit paranccsal. Itt opcionálisan a -c paraméterrel még metaadatokat is változtathatsz. A CMD utasítás értékének beállítása például ezzel történhet.
• Adj nevet az image-nek a docker image tag paranccsal. Az utolsó kivéve a töbinek nincs szüksége névre.

A következőkben pedig egy Bash szkriptben írt buildert mutatok be.

Ha rettentően bonyolult a megoldás, az persze nem sokat segít, ezért képzeld el, hogy nem kell új, teljesen egyedi utasításokat megtanulni a már ismert FROM, ENV és például RUN, hanem szinte ugyanazt írhatod, mint eddig, csak elé kell tenni, hogy: build_layer "$image_id". Ezek után egy image buildelése például így nézne ki:

Ez persze csak az egyes rétegek elkészítéséhez a függvények hívása. Természetesen a függvényt meg kell írni és lesz még néhány sor kód azon kívül is, ami a Dockerhez hasonló inforációkat ír ki a build után, illetve az utolsó image-hez egy nevet is rendel. Minden build_layer függvényhívás megváltoztatja a globális $image_id változó értékét, amikor pedig a legelső utasítást adjuk meg a FROM kulcsszóval, a FROM utáni image névből fogja kitalálni annak az azonosítóját. Ez az a lépés, amikor nem is kell semmi mást sem tenni.

Feltűnhet még, hogy az argumentumokat másképpen adtam át, mint ahogy azt a korábbi vizsgálódások alapján sejteni lehetett volna. A cél viszont nem az, hogy leprogramozzuk a Dockert, hanem hogy hasonló eredményt érjünk el. A /bin/sh elé márpedig nem tehetem az változó beállítását, mivel ott még nincs shell és a Docker fájlnévként értelmezné az értékadást.

A függvény elején az $image_id és az $instructionváltozókat állítom be, ahol az utóbbiban lesz például a RUN kulcsszó, ami alapján eldönthető később, hogy hogyan kell kezelni az azt követő összes további argumentumot, amit pedig az $args tömbbe fogok betölteni:

Ami nagyjából mindegyik utasításban közös, hogy létre fog jönni egy konténer, csak nem mindegyik fog elindulni. Így tehát egy egyszerű "case" elágazással különböző paraméterezéssel ugyan, de megszerzem a konténer azonosítóját:

Látható, hogy igazából csak az ENV a kakukktojás, mivel nem csak egy parancsot kell megadni a konténernek, hanem változókat is be kell állítani. Itt persze még akkor hiányzik a FROM utasítás, aminél viszont pont az image azonosítót kell megszerezni, hiszen itt nem volt előző ID, csak az image neve, mint a FROM argumentuma és ezen a ponton még nem kell konténert indítani, majd csak a következő utasításnál.

Megjegyzés: A fenti kód az átláthatóság kedvéért csak a parancsok elejét tartalmazza.

Mindezek után, ha RUN utasításról volt szó, akkor el is kell indítani a konténert az előtérben:

Ha pedig van konténer azonosító, az azt jelenti, hogy azt a konténert el kell menteni egy image-ként:

Persze ez egyedül akkor nem fog futni, ha az utasítás a FROM volt, de pont ez volt a cél. És máris itt van az image azonosító, ami jelenleg egy lobális változó a szkripten belül, tehát a függvény meg tudja változtatni, hogy a következő utasítás aramétereként az új érték legyen elérhető. Nyilván, mivel a változó globális, akár meg is lehetne szüntetni a paramétert, így viszont a függvény önmagában is képes bármelyik image-ből újat készíteni, ahol pontosan látszik, hogy melyik ID-t adtuk át.

Nem említettem még a change változót, ami jelen egy tömb, így ha az üres, nem lesz átadva semmi a commitnak, ha viszont tartalmazza például, hogy -c 'CMD ["env"]', akkor az új image-ben futtatandó alapértelmezett parancsot is beállítja az adott rétegben metaadatként.

Van még egy rész a függvényen kívül, ami fontos lesz, ez pedig az image-hez egy név rendelése, hiszen eddig csak azonosítókkal dolgoztunk:

Ezen kívül még van néhány kiírás, tehát a teljes szkript most már törölt részek nélkül az alábbi:

A futtatás pedig a következőképpen történik:

A kimeneten az egyik feltűnő különbség az lesz, hogy a build lépések számlálásánál nem jelenítem meg, hogy hány van összesen, csak hogy hányadiknál tart éppen.

Végszó

[Tartalom]

Bátorítok mindenkit, hogy módosítgassa kedvére a szkriptet tanulási céllal. Házi feladat a COPY utasítás implementálása. Ez nem csak egy jó mód arra, hogy közelebb kerüljünk a build működésének megértéséhez, de szükség esetén valóban használható egy olyan build processz megvalósítására, amit nem támogat még a Dockerfile szintaktikája. Persze ha egy mód van rá, én javaslom szkriptben csak azt az extra információt összeállítani, am aztán változóként átadható és továbbra is használható a Dockerfile.