Cum să utilizați Docker Buildx Bake pentru a crea conducte complexe de creare a imaginilor

Grupul de comandă docker buildx buildx folosește BuildKit pentru a expune capabilități avansate de creare a imaginilor. Construcțiile coapte sunt o caracteristică de nivel înalt care poate fi utilizată pentru a defini conductele de construcție automate. Vă permit să produceți mai multe imagini dintr-o singură operațiune de construcție.

Fluxurile de lucru coapte sunt utile atunci când doriți să publicați diferite variante ale imaginilor dvs. sau să construiți mai multe proiecte legate în paralel. În acest articol, vom acoperi caracteristicile cheie ale docker buildx bake și modul în care le puteți utiliza pentru a eficientiza versiunile complexe.

Noțiuni de bază

Comanda docker buildx bake execută mai multe „ținte” de construcție care produc fiecare o imagine de container. Țintele rulează în paralel, acolo unde este posibil, pentru a maximiza performanța. Țintele pot, de asemenea, să facă referire directă la predecesori pentru a crea conducte secvențiale.

Țintele de construcție pot fi definite folosind mai multe mecanisme diferite, inclusiv fișierele existente Docker Compose. Buildx va construi automat toate imaginile identificate în fișier.

Funcții mai avansate sunt expuse atunci când enumerați ținte de construcție în fișiere JSON sau HCL. Acestea acceptă variabile, funcții și interpolarea valorilor pentru a vă personaliza versiunile.

Comanda buildx bake caută următoarele fișiere în ordine:

• docker-compose.yml
• docker-compose.yaml
• docker-bake.json
• docker-bake.override.json
• docker-bake.hcl
• docker-bake.override.hcl

Puteți specifica un fișier diferit cu indicatorul de comandă -f .

Construiți ținte

Țintele de construcție încapsulează toată configurația legată de construcția dvs. Acestea includ detalii precum

• calea către fișierul Docker pentru a construi
• construiți căi de context, definind conținutul disponibil în fișierul dvs. Docker
• etichete și etichete de atașat la imaginile de ieșire
• platformele pentru a produce imagini.

O listă completă a câmpurilor de configurare acceptate este disponibilă în documentație. Anterior, este posibil să fi furnizat aceste setări ca semnalizatoare de linie de comandă pentru docker buildx build (sau chiar pentru docker docker build simplu), forțându-vă să vă amintiți valorile corecte de fiecare dată. Cu buildx bake puteți utiliza în mod fiabil aceleași valori definindu-le în fișierul Baked controlat de versiune.

Iată un exemplu simplu de comandă docker-bake.hcl care definește o singură țintă de construcție:

 target "default" { dockerfile = "app/Dockerfile" contexts = { app = "app/src" shared = "shared-components/src" } tags = ["my-app:latest", "docker.io/my-org/my-app:latest"] }

Rularea docker buildx bake cu acest fișier bake va încărca app/Dockerfile Dockerfile din directorul dvs. de lucru. Va avea acces la directoarele app/src și shared-components/src ca contexte de compilare. Imaginii care este produsă i se vor atribui două etichete.

Ținta default este construită automat când rulați docker buildx bake . De asemenea, puteți defini ținte denumite care pot fi construite la cerere:

 target "app" { // ... }

 $ docker buildx bake app

Utilizarea țintelor multiple

Puteți construi o altă imagine simultan definindu-o ca o nouă țintă în fișierul de coacere:

 group "default" { targets = ["app", "api"] } target "app" { dockerfile = "app/Dockerfile" contexts = { app = "app/src" shared = "shared-components/src" } tags = ["my-app:latest", "docker.io/my-org/my-app:latest"] } target "api" { dockerfile = "api/Dockerfile" contexts = { src = "api/src" } tags = ["my-api:latest", "docker.io/my-org/my-api:latest"] }

Aceste imagini pot fi construite simultan, deoarece sunt imbricate într-un grup. Imaginile api și app vor fi construite în paralel de fiecare dată când rulați comanda docker buildx bake , deoarece grupul default este selectat automat. Puteți utiliza grupuri denumite în mod similar cu exemplul de ținte denumite de mai sus.

Creați moștenirea țintă

Țintele de compilare se pot moșteni unele de la altele pentru a reutiliza configurația. Un scenariu în care acest lucru poate fi util se referă la imaginile care trebuie personalizate pentru diferite medii. Poate doriți să adăugați fișiere de configurare suplimentare la variantele de imagine destinate dezvoltării. Iată un docker-bake.hcl care demonstrează acest model:

 group "default" { targets = ["backend", "backend-dev"] } target "backend" { dockerfile = "backend/Dockerfile" contexts = { src = "api/src" config = "api/config" } tags = ["backend:latest"] } target "backend-dev" { inherits = ["backend"] contexts = { config = "api/config-dev" } tags = ["backend:dev"] }

Ținta backend-dev moștenește toate proprietățile țintei backend , dar suprascrie contextul de config și aplică o etichetă diferită.

Puteți previzualiza structura fișierului îmbinat rulând comanda bake cu steag-ul --print :

 $ docker buildx bake --print ... "backend-dev": { "context": ".", "contexts": { "config": "api/config-dev", "src": "api/src" }, "dockerfile": "backend/Dockerfile", "tags": [ "backend:dev" ] } ...

Utilizarea unei ținte anterioare ca imagine de bază

Uneori este posibil să doriți ca o țintă de construcție să folosească imaginea creată de o țintă anterioară ca bază proprie. Aceasta este o alternativă la versiunile în mai multe etape care pot fi utilizate atunci când fișierele Dockerfile depind unele de altele, dar nu pot fi îmbinate împreună, poate pentru că există în proiecte diferite.

 group "default" { targets = ["org-base-image", "api"] } target "org-base-image" { dockerfile = "docker-base/Dockerfile" tags = ["org-base-image:latest"] } target "api" { dockerfile = "api/Dockerfile" contexts = { base = "target:org-base-image" } tags = ["api:latest"] }

Exemplul construiește mai întâi ținta org-base-image . Acesta ar putea conține unele utilitare care sunt comune pentru încărcăturile de lucru containerizate ale organizației dvs. Ținta api este apoi construită cu rezultatul din ținta org-base-image accesibilă ca context de base de compilare. API Dockerfile poate face referire acum la conținutul din imaginea de bază:

 COPY --from=base /utilities/example /usr/bin/example-utility

Acesta este un model puternic care vă permite să creați legături de dependență între imagini, menținând în același timp fișiere Dockerfile separate.

Suprascrierea proprietăților țintelor în timpul construirii

Comanda docker buildx bake vă permite să suprascrieți proprietățile țintelor dvs. atunci când rulați construcția:

 $ docker buildx bake --set api.dockerfile="api/Dockerfile-dev"

Acest exemplu modifică fișierul Docker al țintei api . Caracterul metalic * este acceptat la identificarea țintei de schimbat. * pe cont propriu selectează fiecare țintă în timp ce api* va modifica toate țintele care încep cu api .

Setarea variabilelor

Fișierele HCL pot defini variabile pe care le puteți face referire în țintele dvs. de compilare. utilizați un bloc variable pentru a le configura:

 variable "TAG" { default = "latest" } group "default" { targets = ["app"] } target "app" { dockerfile = "src/Dockerfile" tags = ["my-app:${TAG}"] }

Rularea docker buildx bake cu această configurație va eticheta app țintă ca my-app:latest . Puteți modifica valoarea variabilei TAG setând o variabilă de mediu înainte de a executa comanda:

 $ TAG=v1 docker buildx bake

Puteți utiliza toate capacitățile de interpolare și comparare variabile ale limbajului HCL pentru a face țintele dvs. de construcție reutilizabile. Sunt disponibile și funcții pentru analizarea și transformarea valorilor.

rezumat

Compilările Baked Buildx vă permit să încapsulați configurația de compilare a imaginii ca „ținte” definite într-un fișier. Când rulați buildx bake , imaginile pentru toate țintele la care se face referire sunt construite în paralel.

Țintele pot moșteni și pot depinde unele de altele. De asemenea, puteți utiliza variabile și funcții pentru a crea conducte de construcție extrem de complexe și configurabile.

Comanda docker buildx bake este o operație de nivel înalt care nu este necesară în fiecare flux de lucru. Nu trebuie să îl utilizați atunci când creați imagini simple fără dependențe între proiecte. Utilizarea docker compose docker compose build este o alternativă mai bună pentru majoritatea cazurilor de utilizare care păstrează configurația de compilare în fișierul docker-compose.yml . Trecerea la build-uri coapte ar trebui să fie luată în considerare atunci când construiți mai multe imagini simultan folosind diferite variabile, platforme, contexte de construcție și înlocuiri de configurare.