A többlépcsős Docker buildek lehetővé teszik a Dockerfájlok többes írását FROM nyilatkozatok. Ez azt jelenti, hogy olyan képeket készíthet, amelyek több alapból származnak, amelyek segíthetnek a végleges felépítés méretének csökkentésében.
A Docker képek úgy jönnek létre, hogy kiválasztanak egy alapképet a FROM nyilatkozat. Ezután rétegeket ad hozzá a képhez parancsok hozzáadásával a Dockerfile-be.
Val vel többlépcsős építések, több részre oszthatja a Docker fájlt. Minden szakasznak megvan a maga FROM utasítás, így több képet is bevonhat a buildjeibe. A szakaszok egymás után épülnek fel, és hivatkozhatnak elődeikre, így átmásolhatja az egyik réteg kimenetét a következőbe.
Többlépcsős működés közben
Nézzük meg, hogyan hozhat létre többlépcsős összeállítást. Egy barebones PHP projekttel dolgozunk, amely a Composert használja függőségeihez, a Sass pedig a stíluslapjaihoz.
Itt van egy többlépcsős Dockerfile, amely az egész összeállításunkat összefoglalja:
FROM node:14 AS sass WORKDIR /example RUN npm install -g node-sass COPY example.scss . RUN node-sass example.scss example.css FROM php:8.0-apache COPY --from=composer:2 /usr/bin/composer /usr/bin/composer COPY composer.json . COPY composer.lock . RUN composer install --no-dev COPY --from=sass /example/example.css example.css COPY index.php . COPY src/ src
Mindjárt megfigyelheti, hogy kettőnk van FROM utasítások, amelyek két logikai részre osztják a Docker-fájlunkat. Az első szakasz a Sass összeállításának van szentelve, míg a második arra összpontosít, hogy mindent összekapcsoljon a végső tárolóban.
Használjuk a node-sass a Sass megvalósítása. Ezért egy Node.JS alapképpel kezdünk, amelyen belül telepítjük node-sass globálisan npm-től. Ezután használjuk node-sass hogy összeállítsuk a stíluslapunkat example.scss a tiszta CSS-be example.css. Ennek a szakasznak a magas szintű összefoglalása: elkészítünk egy alap képet, futtatunk egy parancsot, és megszerezzük azt a kimenetet, amelyet később használni szeretnénk a buildben (example.css).
A következő szakasz bemutatja alkalmazásunk alapképét: php8.0-apache. Az utolsó FROM utasítás a Dockerfile-ban határozza meg azt a képet, amelyet a tárolók végül futtatni fognak. Korábbi node A kép végső soron irreleváns alkalmazásunk tárolói számára – pusztán építési idő kényelmi eszközként használják.
Legközelebb a Composer segítségével telepítjük a PHP-függőségeinket. A Composer a PHP csomagkezelője, de nem tartalmazza a hivatalos PHP Docker képeket. Ezért a dedikált zeneszerző képéről átmásoljuk a bináris fájlt a tárolóba.
Nem kellett a FROM nyilatkozat erre. Mivel a Composer kép ellen nem futtatunk egyetlen parancsot sem, használhatjuk a --from zászlóval COPY a kép hivatkozására. Rendszerint, COPY fájlokat másol a helyi build környezetből a képbe; val vel --from és egy képnév, létrehoz egy új tárolót a kép segítségével, majd kimásolja belőle a megadott fájlt.
Később a Dockerfile-t használjuk COPY --from ezúttal is más formában. Vissza a tetejére írtuk az elsőnket FROM nyilatkozat as FROM node:14 AS sass. A AS záradék létrehozott egy elnevezett színpadot sass.
Mi most referencia a tranziens konténer, amelyet ebben a szakaszban hoztak létre COPY --from=sass. Ez lehetővé teszi számunkra, hogy a beépített CSS-t átmásoljuk a végső képünkbe. A lépések további része rutinszerű COPY műveletek, amelyeket a forráskód megszerzéséhez használunk a helyi munkakönyvtárunkból.
A többlépcsős építések előnyei
A többlépcsős összeállítások lehetővé teszik összetett építési rutinok létrehozását egyetlen Dockerfile segítségével. Bevezetésük előtt gyakran előfordult, hogy az összetett projektek több Docker-fájlt használtak, egyet az építkezésük minden szakaszához. Ezeket manuálisan írt shell szkriptekkel kellett összehangolniuk.
Többlépcsős építésekkel a teljes építési rendszerünk egyetlen fájlba foglalható. Nincs szükség csomagoló szkriptekre, hogy a projektet a nyers kódbázistól a végső alkalmazásképig vigye. Rendszeres docker build -t my-image:latest . elegendő.
Ez az egyszerűsítés lehetőséget nyújt a képek hatékonyságának javítására is. A Docker képek nagymértékben megnövekedhetnek, különösen, ha nyelvi futást használ alapként.
Vigye a tisztviselőt golang kép: közel van a 300 MB-hoz. Hagyományosan másolhatja a Go forrást a képbe, és felhasználhatja a bináris fordításához. Ezután a bináris fájlt vissza kell másolnia a gazdagépre, mielőtt újabb építést indítana. Ez egy Dockerfile-t használna, könnyű alapképpel, például alpine (kb. 10 MB). Visszaadná a bináris fájlját, és sokkal kisebb képet eredményezne, mint ha az eredetit használta volna golang alap a konténerek futtatásához.
Többlépcsős építésekkel az ilyen típusú rendszer sokkal könnyebben megvalósítható:
FROM golang:latest WORKDIR /go COPY app.go . RUN go build -o my-binary FROM alpine:latest WORKDIR /app COPY --from=build /go/my-binary . CMD ["./my-binary"]
Nyolc sorban olyan eljárást sikerült elérnünk, amelyhez korábban legalább három fájlra volt szükség – a golang Dockerfile, an alpine Dockerfile és egy shell parancsfájl a közbenső lépések kezeléséhez.
Következtetés
A többlépcsős összeállítások drámai módon leegyszerűsíthetik a bonyolult Docker képek felépítését. Ez lehetővé teszi több összekapcsolt építési lépés bevonását, amelyek továbbíthatják a kimeneti tárgyakat előre.
A modell elősegíti az építés hatékonyságát is. A különböző alapképek egyszerű hivatkozása segít a fejlesztőknek abban, hogy a végső kimenet a lehető legkisebb legyen. Előnyt élvez a csökkentett tárolási és sávszélességi költségek, amelyek jelentősek lehetnek, ha a Dockert CI / CD rendszeren belül használják.