Docker container-ben változások mentése

Fórumok

Sziasztok!

Docker container fut, remek. Lassan a projekt elér addig a pontig, ahonnan érdemes a backup-on gondolkodni. A konténernek vannak a host állományrendszerében könyvtárai, gyakorlatilag a forráskód, amit írok, ennek mentése egyszerű.

Azonban a konténerben telepítettem ezt-azt, például az mc-t, imagemagick-et, stb. Amikor használom a commit parancsot, az új image-be ezeket látom (éppen menet közben vagyok, sikerült az új image-t elkészíteni, de még nem tudtam ellenőrizni, hogy jó-e). Játékból létrehoztam korábban néhány állományt a konténer /root könyvtárában, de ezeknek nem látom nyomát vagy még nem találtam meg ezeket.

Az a kérdés, hogyan lehet a futó konténerben lévő összes változást elmenteni image-be, hogy onnan az új konténer mindent tartalmazzon már, amit a régiben így vagy úgy beraktam?

Hozzászólások

Úgy érdemes kezelni, hogy egy Dockerfile-ba leírod, hogy a kiindulási image-hez képest milyen változtatásokat akarsz. És ez alapján reprodukálhatóan elkészíthető a saját image-ed, amit utána feltölthetsz pl. egy docker registry-be.

docker commit nem jó irány. hozz létre egy Dockerfilet és az alapján imaget, amiben csak az van ami tényleg szükséges az app futtatásához, mc szinte biztosan nem kell egy containerbe.

Röviden: rosszul használod, a konténer nem chroot környezet.

Hosszan: Konténerben nem turkálunk menet közben, ha bármi változás van, akkor az Dockerfile és/vagy -compose.yml változással jár, abból mindig új image és/vagy környezet készül, benne a változással; a régi konténereket eldobod az újakat meg felhúzod helyette, ha több fut belőle, akkor rolling update.

A történet a következő:

Van egy Laravel konténer, a forráskód külön könyvtárban kiszervezve, ezzel nincs is baj. Odáig jutottam, hogy telepítenem kellett a konténerben a php-imagemagick csomagot, és a php.ini-ben beírni az extension-ök közé a imagick.so-t (a pontos nevekre nem emlékszem). Nos, még nem tudtam ellenőrizni, hogy a commit-tal létrejött új image jól működik-e, de belenéztem és a telepített mc-re és imagick-re utaló könyvtárakat és adatszerkezeteket találtam. A php.ini-t meg még nem találtam meg, így nem tudom, hogy a kézzel bevitt változás is átment-e vagy nem.

Egyáltalán mi a különbség egy kiadott apt install parancs okozta változás és a kézzel okozott bővítés között a commit szempontjából?

https://github.com/mlocati/docker-php-extension-installer

Nezd meg a fenti linket, en ezt hasznalom hivatalos php docker image-el.(alpine alapokon). Tokeletesen telepiti barmelyik extension-t es a hozza tartozo dependency-ket.   Kiveve nehany egzotikusabb dolgot (zeromq github-rol forrasbol, de ahhoz multi stage buildet hasznalok)

Support Slackware: https://paypal.me/volkerdi

Ez nagyon rossz irany. A container az nem virtualis gep

Egy containerben kezzel telepitett csomag vagy barmilyen modositas maximum azt a celt szolgalhatja, hogy roviditsd a Dockerfile megirasanak idejet es ne kelljen rengetegszer buildelned egy image-et, ha nem vagy biztos a dolgodban.

mc-t es semmi mast ne telepits a containerbe, arra van kulon mas debug lehetoseg, hogy egy futo containerre aggass egy masikat amiben megvannak ezek a toolok.

Nagyon sokat segithetsz magadon, ha elofizetsz egy A Cloud Guru vagy Pluralsight csomagra es elkezded ezt rendesen megtanulni.
Elvezni is fogod es rengeteg idot sporolsz.

Semmi gond nincs a commit parancs használatával, nyilván nem véletlenül létezik. ;)

Abban igazuk van a többieknek, hogy jellemzően nem a módosítok-módosítok-commitolok ciklust érdemes követni, hanem a módosítok-Dockerfiletszerkesztek-buildelek ciklust, mert úgy lesz később könnyen reprodukálható, hogy mit csináltál (meg egyszerűbb is visszalépni, ha valamit elszúrsz), cserében kicsit időigényesebb.

Ettől függetlenül arra tökéletesen megfelel a commitolós módszer, hogy kísérletezz, és elmentsd magadnak, amit már egyszer végigszívtál. Valami olyasmi megoldás ez, mint amikor az ember programírás közben először odahány egy "csak működjön" megoldást, aztán mielőtt közzéteszi (pl. git commit/push), szépen kitisztázza. A commitolós megoldás az "odahányás", a Dockerfile-os a szépen letisztázott változat.

De hogy érdemi is legyen:

1. Docker layerek (és így a commit) szempontjából teljesen mindegy, hogy egy-egy fájlmódosítást kézzel csinálsz vagy valami program (beleértve a csomagkezelőt is). A Docker ezzel nem foglalkozik. Ami viszont fontos lehet, hogy az adott könyvtárat (vagy annak valamelyik ősét) milyen módon látja a Docker. Ha valamelyik containerben lévő layer tartalmazza az adott könyvtárat (pl. az image-dzsel jött), akkor annak a módosítását a commitnak elvileg mentenie kell. Ha viszont valamilyen volume van becsatolva és az alatt lévő dolgokat módosítasz, azt a commit nem menti. A doksi így szól róla: The commit operation will not include any data contained in volumes mounted inside the container.

Ahhoz, hogy kiderüljön, volume-ként van-e csatolva a könyvtár, látni kellene pl. a parancssort, amit használtál az indításkor (docker run...)

Másik lehetőség, hogy használod a

docker inspect konténerneve

parancsot, ami a konténer aktuális beállításait fogja kiírni. Abban van egy "Mounts"-blokk, ami mutatja az összes csatolt volume-ot.

Én innen indulnék tovább a nyomozással. :)

2. Írtad, hogy "A php.ini-t meg még nem találtam meg, így nem tudom, hogy a kézzel bevitt változás is átment-e vagy nem." A php.ini helyét egész könnyen ki lehet deríteni úgy, hogy kiadod a

php -i

parancsot, ami minden PHP-beállítást listáz, de a legelején azt is, hogy ezeket a beállításokat milyen ini-fájlokból szedi össze. (Ez a megoldás a parancssoros php-re vonatkozóan mutatja az ini-fájlokat, de általában a web alatt futó php ini-fájljai is ott vannak a környéken valahol.)

Semmi gond nincs a commit parancs használatával, nyilván nem véletlenül létezik. ;)

Nem, nem véletlenül létezik. De nem is azért, amire OP használná.

Ettől függetlenül arra tökéletesen megfelel a commitolós módszer, hogy kísérletezz, és elmentsd magadnak, amit már egyszer végigszívtál.

A jelentős különbség az, hogy a commit egy snapshot-ot készít az alap image és a jelenlegi állapot közötti különbségről. Ha van fogalmad arról, hogy mit műveltél, akkor az legyen leírva a Dockerfile-ban, ha nincs fogalmad róla, hogy mit műveltél, akkor derítsd ki. Az OP commit használata kb. az, hogy fogalma nincs, mit művelt, de mivel pillanatnyilag éppen működik valahogy, ezért be akarja keretezni a művét, mert nem tudja reprodukálni. A Docker lényege viszont az lenne, hogy bárki és bárhol reprodukálni tudja a művet.

A másik fő probléma a commit esetén az, hogy ha kijön egy security fix az alap image kapcsán, akkor nem tudsz átállni rá egy verzió átírásával, ott fogsz állni letolt gatyával.

Ebből a pár fenti kommentből magam is sokat tanultam, hasonló céljaim lennének a jövőben. Köszi!