Szuper vékony dokkoló konténerek

Útmutató a Docker képek méretének csökkentéséhez

Gondolkodott már azon, hogy az egyalkalmazású Docker tároló miért nő 400 MB-ra? Vagy talán miért eredményez egy néhány tíz MB-os bináris alkalmazás binárisan egy több MB-os Docker-képet?

Ebben a cikkben áttekintjük a konténerek hizlalásához hozzájáruló főbb tényezőket, valamint a bevált módszereket és tippeket, amelyek a szupervékony Docker konténerekhez vezetnek a projekt számára.

A Docker-tároló képe lényegében halmozott fájlok, amelyeket később futó tárolóként példányosítani lehet. A Docker az Union File System (UnionFS) kialakítást használja, amelyben a fájlok rétegekbe vannak csoportosítva. Minden réteg tartalmazhat egy vagy több fájlt, és minden réteg az előző réteg tetején helyezkedik el. A rétegek összes tartalmának virtuális futásidejű egyesítése végfelhasználóként egységes fájlrendszerként tapasztalható:

Az UnionFS mögöttes megvalósítása által a végső fájlrendszer-nézet (a Docker jó néhány különféleet támogat plug-in tároló-illesztőprogramokon keresztül) tartalmazza az összes réteg teljes méretét. Amikor a Docker létrehoz egy tárolót egy képhez, akkor a kép összes rétegét csak olvasható formátumban használja, és egy vékony írási-írási réteget ad a tetejükre. Ez a vékony olvasási-írási réteg lehetővé teszi számunkra a futó Docker-tároló fájljainak tényleges módosítását:

Mi történik, ha egy fájlt törölnek a fenti 4. rétegből? Bár a törölt fájl többé nem jelenik meg a megfigyelt fájlrendszerben, az eredetileg elfoglalt méret továbbra is része lesz a tároló lábnyomának, mivel a fájl egy alacsonyabb, csak olvasható rétegben szerepelt.

Viszonylag könnyű kezdeni egy kis bináris alkalmazással, és végül egy zsírtartály-képpel rendelkezik. A következő szakaszokban különféle módszereket tárunk fel, hogy a képeink minél vékonyabbak legyenek.

Mi a legelterjedtebb módja a Docker-képek készítésének?

A . a fenti parancs azt mondja Docker-nek, hogy az aktuális munkamappát tekintjük az építési folyamat gyökérfájl-rendszer elérési útjának.

Annak érdekében, hogy jobban megértsük, mi történik valójában a fenti parancs kiadásakor, szem előtt kell tartanunk, hogy a Docker build egy kliens-szerver folyamat. A Docker CLI (kliens), ahonnan a docker build parancsot hajtjuk végre, az alapul szolgáló Docker motor (kiszolgáló) segítségével tároló képet készít. A kliens mögöttes fájlrendszeréhez való hozzáférés korlátozásához a készítési folyamatnak tudnia kell, hogy mi a virtuális fájlrendszer gyökere. A Dockerifle bármelyik parancsa éppen ezen az útvonalon próbálja megtalálni azokat a fájlforrásokat, amelyek potenciálisan az épülő képbe kerülhetnek.

Gondoljuk át egy pillanatra azt a helyet, ahol általában elhelyezzük a Dockerfile-t. Talán a projekt gyökerében? Nos, egyesítsen egy Dockerfile-t a projekt gyökérzetében egy docker build-mel, és hatékonyan hozzáadtuk a teljes projekt mappát, mint lehetséges fájlforrást a buildhez. Ez azt eredményezheti, hogy több MB és több ezer fájl kerül feleslegesen a build környezetbe. Ha gondatlanul meghatározunk egy ADD/COPY parancsot a Dockerfile-ban, akkor ezek a fájlok a végső kép részét képezhetik. Legtöbbször nem erre van szükségünk, mivel csak néhány kiválasztott projekt-műtárgyat kell felvenni a végleges tároló képbe.

Mindig ellenőrizze, hogy megadja-e a megfelelő építési utat a dokkoló buildjéhez, és hogy a Dockerfile nem ad-e felesleges fájlokat a képéhez. Ha valamilyen okból valóban meg kell határoznia a projekt gyökerét építési kontextusként, szelektíven felveheti/kizárhatja a fájlokat a .dockerignore oldalon .

A képek maximális rétegeinek száma 127, feltéve, hogy az alapul szolgáló tárolóillesztőprogram támogatja. Ez a korlát megnövelhető, ha valóban szükséges, de akkor szűkíti a választási lehetőségeket, hogy ez a kép hol építhető fel (azaz szükség van egy Docker-motorra, amely egy hasonlóan módosított alapmagon fut).

Amint azt a fenti Docker képrétegek szakaszban tárgyaltuk, az UnionFS miatt bármelyik fájl erőforrás, amely egy rétegbe kerül, akkor is megmarad a fóliában, ha ezt a fájlt egy későbbi rétegben tárolja. Lássuk, hogy egy Dockerfile mintával: