Beranda>Terkait pemrograman>Kode sumber lainnya
Unduh
buildkit

1730704257718836.png

MembangunKit

BuildKit adalah perangkat untuk mengonversi kode sumber guna membangun artefak dengan cara yang efisien, ekspresif, dan dapat diulang.

Fitur utama:

  • Pengumpulan sampah otomatis

  • Format frontend yang dapat diperluas

  • Resolusi ketergantungan secara bersamaan

  • Cache instruksi yang efisien

  • Bangun impor/ekspor cache

  • Pemanggilan pekerjaan build bersarang

  • Pekerja yang dapat didistribusikan

  • Berbagai format keluaran

  • Arsitektur yang dapat dicolokkan

  • Eksekusi tanpa hak akses root

Baca proposal dari moby/moby#32925

Entri blog pengantar https://blog.mobyproject.org/introducing-buildkit-17e056cc5317

Bergabunglah dengan saluran #buildkit di Docker Community Slack

Catatan

Jika Anda mengunjungi repo ini untuk menggunakan fitur Dockerfile khusus BuildKit seperti RUN --mount=type=(bind|cache|tmpfs|secret|ssh) , silakan merujuk ke referensi Dockerfile.

Catatan

docker build menggunakan Buildx dan BuildKit secara default sejak Docker Engine 23.0. Anda tidak perlu membaca dokumen ini kecuali Anda ingin menggunakan BuildKit versi mandiri berfitur lengkap.

  • Digunakan oleh

  • Mulai cepat

    • Gambar/Registrasi

    • Direktori lokal

    • tarbal buruh pelabuhan

    • tarbal OCI

    • penyimpanan gambar kontainer

    • Membangun Dockerfile dengan buildctl

    • Membangun Dockerfile menggunakan frontend eksternal

    • Pengaturan Linux

    • Pengaturan Windows

    • Pengaturan macOS

    • Bangun dari sumber

    • Menjelajahi LLB

    • Menjelajahi Dockerfiles

    • Keluaran

  • Cache

    • Inline (mendorong gambar dan cache bersama-sama)

    • Registri (mendorong gambar dan cache secara terpisah)

    • Direktori lokal

    • Cache Tindakan GitHub (eksperimental)

    • Cache S3 (eksperimental)

    • Cache Penyimpanan Blob Azure (eksperimental)

    • Pengumpulan sampah

    • Ekspor cache

    • Hashing yang konsisten

  • Metadata

  • Aktivasi soket Systemd

  • Ekspos BuildKit sebagai layanan TCP

    • Penyeimbangan beban

  • Kontainerisasi BuildKit

    • Podman

    • Nerdctl

    • Kubernet

    • Tanpa Daemon

  • Dukungan OpenTelemetri

  • Menjalankan BuildKit tanpa hak akses root

  • Membangun gambar multi-platform

    • Kontrol Keluaran Warna

    • Jumlah baris log (untuk langkah aktif dalam mode tty)

    • Mengonfigurasi buildctl

  • Berkontribusi

Digunakan oleh

BuildKit digunakan oleh proyek-proyek berikut:

  • Moby & Docker ( DOCKER_BUILDKIT=1 docker build )

  • gambar

  • Awan OpenFaaS

  • antarmuka pembuatan kontainer

  • Tekton Pipelines (sebelumnya Knative Build Templates)

  • alat pembuatan Sanic

  • vab

  • Rio

  • Kim

  • Wadah Kantong

  • Pembuatan Dockerx

  • Awan Okteto

  • File bumi duniawi

  • Gitpod

  • Belati

  • envd

  • Depot

  • Ruang nama

  • unikraft

  • DevZero

  • dacc

Mulai cepat

Untuk penerapan Kubernetes, lihat examples/kubernetes .

BuildKit terdiri dari daemon buildkitd dan klien buildctl . Meskipun klien buildctl tersedia untuk Linux, macOS, dan Windows, daemon buildkitd saat ini hanya tersedia untuk Linux dan *Windows.

Biner BuildKit terbaru tersedia di sini untuk Linux, macOS, dan Windows.

Pengaturan Linux

Daemon buildkitd memerlukan instalasi komponen berikut:

  • runc atau crun

  • containerd (jika Anda ingin menggunakan pekerja containerd)

Memulai daemon buildkitd : Anda perlu menjalankan buildkitd sebagai pengguna root di host.

 $ sudo buildkitd

Untuk menjalankan buildkitd sebagai pengguna non-root, lihat docs/rootless.md .

Daemon buildkitd mendukung dua backend pekerja: OCI (runc) dan containerd.

Secara default, pekerja OCI (runc) digunakan. Anda dapat menyetel --oci-worker=false --containerd-worker=true untuk menggunakan pekerja containerd.

Kami terbuka untuk menambahkan lebih banyak backend.

Untuk memulai daemon buildkitd menggunakan aktivasi soket systemd, Anda dapat menginstal file unit buildkit systemd. Lihat aktivasi soket Systemd

Daemon buildkitd mendengarkan API gRPC di /run/buildkit/buildkitd.sock secara default, namun Anda juga dapat menggunakan soket TCP. Lihat Mengekspos BuildKit sebagai layanan TCP.

Pengaturan Windows

Lihat instruksi dan catatan di docs/windows.md .

Pengaturan macOS

Rumus homebrew (tidak resmi) tersedia untuk macOS.

 $ minuman instal buildkit

Rumus Homebrew tidak mengandung daemon ( buildkitd ).

Misalnya, Lima dapat digunakan untuk meluncurkan daemon di dalam VM Linux.

 pembuatan bir instal limalimactl mulai template://buildkitexport BUILDKIT_HOST="unix://$HOME/.lima/buildkit/sock/buildkitd.sock"

Bangun dari sumber

Untuk membangun BuildKit dari sumber, lihat .github/CONTRIBUTING.md .

Untuk referensi buildctl , lihat dokumen ini.

Menjelajahi LLB

Build BuildKit didasarkan pada format perantara biner yang disebut LLB yang digunakan untuk menentukan grafik ketergantungan untuk proses yang menjalankan bagian build Anda. tl;dr: LLB bagi Dockerfile sama dengan LLVM IR bagi C.

  • Dikerahkan sebagai pesan Protobuf

  • Dapat dieksekusi secara bersamaan

  • Dapat disimpan dalam cache secara efisien

  • Vendor-netral (yaitu bahasa non-Dockerfile dapat diimplementasikan dengan mudah)

Lihat solver/pb/ops.proto untuk definisi format, dan lihat ./examples/README.md untuk contoh aplikasi LLB.

Saat ini, bahasa tingkat tinggi berikut telah diterapkan untuk LLB:

  • Dockerfile (Lihat Menjelajahi Dockerfiles)

  • paket build

  • file pengejek

  • file gocker

  • bldr (file Pkg)

  • HLB

  • Earthfile (Bumi)

  • Dermaga Kargo (Karat)

  • Nix

  • mopy (Python)

  • envd (burung bintang)

  • Lapisan lemak

  • Bas

  • kraft.yaml (Unikraft)

  • r2d4/llb (Gerbang JSON)

  • (buka PR untuk menambahkan bahasa Anda sendiri)

Menjelajahi Dockerfiles

Frontend adalah komponen yang berjalan di dalam BuildKit dan mengonversi definisi build apa pun menjadi LLB. Ada frontend khusus yang disebut gateway ( gateway.v0 ) yang memungkinkan penggunaan gambar apa pun sebagai frontend.

Selama pengembangan, frontend Dockerfile ( dockerfile.v0 ) juga merupakan bagian dari repo BuildKit. Di masa depan, ini akan dipindahkan, dan Dockerfiles dapat dibuat menggunakan image eksternal.

Membangun Dockerfile dengan buildctl

 buildctl membangun
     --frontend=dockerfile.v0
     --konteks lokal=.
     --local dockerfile=.# orbuildctl build
     --frontend=dockerfile.v0
     --konteks lokal=.
     --file buruh pelabuhan lokal=.
     --memilih target=foo
     --opt build-arg:foo=bar

--local memaparkan file sumber lokal dari klien ke pembuat. context dan dockerfile adalah nama yang dicari frontend Dockerfile untuk konteks build dan lokasi Dockerfile.

Jika Dockerfile memiliki nama file yang berbeda maka dapat ditentukan dengan --opt filename=./Dockerfile-alternative .

Membangun Dockerfile menggunakan frontend eksternal

Versi eksternal frontend Dockerfile didorong ke https://hub.docker.com/r/docker/dockerfile-upstream dan https://hub.docker.com/r/docker/dockerfile dan dapat digunakan dengan frontend gateway . Sumber untuk frontend eksternal saat ini terletak di ./frontend/dockerfile/cmd/dockerfile-frontend namun akan dipindahkan dari repositori ini di masa mendatang (#163). Untuk pembuatan otomatis dari cabang master repositori ini gambar docker/dockerfile-upstream:master atau docker/dockerfile-upstream:master-labs dapat digunakan.

 buildctl membangun
     --gerbang depan.v0
     --opt sumber=buruh pelabuhan/file buruh pelabuhan
     --konteks lokal=.
     --file buruh pelabuhan lokal=.
buildctl membangun
     --gerbang depan.v0
     --opt sumber=buruh pelabuhan/file buruh pelabuhan
     --opt konteks=https://github.com/moby/moby.git
     --opt build-arg:APT_MIRROR=cdn-fastly.deb.debian.org

Keluaran

Secara default, hasil build dan cache perantara hanya akan tetap ada secara internal di BuildKit. Output perlu ditentukan untuk mengambil hasilnya.

Gambar/Registrasi

 buildctl build ... --output type=image,name=docker.io/username/image,push=true

Untuk mengekspor gambar ke beberapa registri:

 buildctl build ... --output type=image,"name=docker.io/username/image,docker.io/username2/image2",push=true

Untuk mengekspor cache yang disematkan dengan gambar dan mendorongnya ke registri bersama-sama, ketik registry diperlukan untuk mengimpor cache, Anda harus menentukan --export-cache type=inline dan --import-cache type=registry,ref=... . Untuk mengekspor cache ke lokal secara langsung, Anda harus menentukan --export-cache type=local . Detail dalam Ekspor cache.

 membangunctl membangun ...
  --tipe keluaran=gambar,nama=docker.io/nama pengguna/gambar,push=true
   --export-cache type=sebaris
   --import-cache type=registry,ref=docker.io/nama pengguna/image

Kunci yang didukung oleh keluaran gambar:

  • name= : tentukan nama gambar

  • push=true : push setelah membuat gambar

  • push-by-digest=true : mendorong gambar tanpa nama

  • registry.insecure=true : dorong ke registri HTTP yang tidak aman

  • oci-mediatypes=true : gunakan tipe media OCI dalam konfigurasi JSON, bukan Docker

  • unpack=true : membongkar gambar setelah pembuatan (untuk digunakan dengan containerd)

  • dangling-name-prefix= : memberi nama gambar dengan prefix@ , digunakan untuk gambar anonim

  • name-canonical=true : tambahkan nama kanonik tambahan name@

  • compression= : pilih jenis kompresi untuk lapisan yang baru dibuat dan di-cache, gzip adalah nilai default. estargz harus digunakan dengan oci-mediatypes=true .

  • compression-level= : tingkat kompresi untuk gzip, estargz (0-9) dan zstd (0-22)

  • rewrite-timestamp=true : menulis ulang stempel waktu file ke nilai SOURCE_DATE_EPOCH . Lihat docs/build-repro.md untuk mengetahui cara menentukan nilai SOURCE_DATE_EPOCH .

  • force-compression=true : menerapkan opsi compression secara paksa ke semua lapisan (termasuk lapisan yang sudah ada)

  • store=true : menyimpan gambar hasil ke penyimpanan gambar pekerja (misalnya containerd) serta memastikan bahwa gambar tersebut memiliki semua gumpalan di penyimpanan konten (default true ). Diabaikan jika pekerja tidak memiliki penyimpanan gambar (misalnya pekerja OCI).

  • annotation.= : melampirkan anotasi dengan key dan value masing-masing ke gambar yang dibuat

    • Menggunakan sintaksis yang diperluas, annotation-.= , annotation[].= dan keduanya dikombinasikan dengan annotation-[].= , memungkinkan konfigurasi dengan tepat di mana untuk melampirkan anotasi.

    • menentukan objek apa yang akan dilampirkan, dan dapat berupa manifest apa pun (default), manifest-descriptor , index , dan index-descriptor

    • menentukan objek mana yang akan dilampirkan (secara default, semua), dan merupakan kunci yang sama yang diteruskan ke platform opt, lihat docs/multi-platform.md .

    • Lihat docs/annotations.md untuk lebih jelasnya.

Jika kredensial diperlukan, buildctl akan mencoba membaca file konfigurasi Docker $DOCKER_CONFIG/config.json . $DOCKER_CONFIG defaultnya adalah ~/.docker .

Direktori lokal

Klien lokal akan menyalin file langsung ke klien. Ini berguna jika BuildKit digunakan untuk membuat sesuatu selain gambar container.

 buildctl build ... --output type=local,dest=path/to/output-dir

Untuk mengekspor file tertentu, gunakan build multi-tahap dengan tahap awal dan salin file yang diperlukan ke tahap tersebut dengan COPY --from .

 ...DARI awal sebagai testresultCOPY --from=builder /usr/src/app/testresult.xml .
...
 buildctl build ... --opt target=hasil tes --output type=local,dest=path/to/output-dir

Dengan pembangunan multi-platform, subfolder yang cocok dengan setiap platform target akan dibuat di direktori tujuan:

 DARI busybox AS buildARG TARGETOSARG TARGETARCHRUN mkdir /out && echo foo > /out/hello-$TARGETOS-$TARGETARCHFROM scratchCOPY --from=build /out /
 $ buildctl membangun
   --file buruh pelabuhan frontend.v0
   --opt platform=linux/amd64,linux/arm64
   --tipe keluaran=lokal,tujuan=./bin/rilis

$ pohon ./bin
./bin/
└── rilis
    ├── linux_amd64
    │ └── halo-linux-amd64
    └── linux_arm64
        └── halo-linux-arm64

Anda dapat mengatur platform-split=false untuk menggabungkan file dari semua platform ke dalam direktori yang sama:

 $ buildctl membangun
   --file buruh pelabuhan frontend.v0
   --opt platform=linux/amd64,linux/arm64
   --tipe keluaran=lokal,dest=./bin/rilis,platform-split=false

$ pohon ./bin
./bin/
└── rilis
    ├── halo-linux-amd64
    └── halo-linux-arm64

Pengekspor tar mirip dengan eksportir lokal tetapi mentransfer file melalui tarball.

 buildctl build ... --output type=tar,dest=out.tar
buildctl build ... --output type=tar > out.tar

tarbal buruh pelabuhan

 # tarball yang diekspor juga kompatibel dengan OCI specbuildctl build ... --output type=docker,name=myimage | beban buruh pelabuhan

tarbal OCI

 buildctl build ... --output type=oci,dest=path/to/output.tar
buildctl build ... --output type=oci > output.tar

penyimpanan gambar kontainer

Pekerja containerd perlu digunakan

 buildctl build ... --output type=image,name=docker.io/username/image
ctr --namespace=gambar buildkit ls

Untuk mengubah namespace containerd, Anda perlu worker.containerd.namespace di /etc/buildkit/buildkitd.toml .

Cache

Untuk menampilkan cache build lokal ( /var/lib/buildkit ):

 buildctl du -v

Untuk memangkas cache build lokal:

 buildctl pangkas

Pengumpulan sampah

Lihat ./docs/buildkitd.toml.md .

Ekspor cache

BuildKit mendukung eksportir cache berikut:

  • inline : menyematkan cache ke dalam gambar, dan memasukkannya ke registri bersama-sama

  • registry : dorong gambar dan cache secara terpisah

  • local : ekspor ke direktori lokal

  • gha : ekspor ke cache Tindakan GitHub

Dalam kebanyakan kasus, Anda ingin menggunakan eksportir cache inline . Namun, perhatikan bahwa pengekspor cache inline hanya mendukung mode cache min . Untuk mengaktifkan mode cache max , dorong gambar dan cache secara terpisah dengan menggunakan eksportir cache registry .

eksportir inline dan registry keduanya menyimpan cache di registri. Untuk mengimpor cache, type=registry sudah cukup untuk keduanya, karena tidak perlu menentukan format cache.

Inline (mendorong gambar dan cache bersama-sama)

 membangunctl membangun ...
   --tipe keluaran=gambar,nama=docker.io/nama pengguna/gambar,push=true
   --export-cache type=sebaris
   --import-cache type=registry,ref=docker.io/nama pengguna/image

Perhatikan bahwa cache inline tidak diimpor kecuali --import-cache type=registry,ref=... disediakan.

Cache inline menyematkan metadata cache ke dalam konfigurasi gambar. Lapisan dalam gambar tidak akan tersentuh dibandingkan dengan gambar tanpa informasi cache.

BuildKit yang terintegrasi dengan Docker ( DOCKER_BUILDKIT=1 docker build ) dan docker buildx memerlukan --build-arg BUILDKIT_INLINE_CACHE=1 ditentukan untuk mengaktifkan pengekspor cache inline . Namun, buildctl mandiri TIDAK memerlukan --opt build-arg:BUILDKIT_INLINE_CACHE=1 dan build-arg diabaikan begitu saja.

Registri (mendorong gambar dan cache secara terpisah)

 membangunctl membangun ...
   --tipe keluaran=gambar,nama=localhost:5000/myrepo:gambar,push=true
   --export-cache type=registry,ref=localhost:5000/myrepo:buildcache
   --import-cache type=registry,ref=localhost:5000/myrepo:buildcache

Opsi --export-cache :

  • type=registry

  • mode= : tentukan lapisan cache yang akan diekspor (default: min )

    • min : hanya mengekspor lapisan untuk gambar yang dihasilkan

    • max : mengekspor semua lapisan dari semua langkah perantara

  • ref= : tentukan referensi repositori untuk menyimpan cache, misalnya docker.io/user/image:tag

  • image-manifest= : apakah akan mengekspor manifes cache sebagai manifes gambar yang kompatibel dengan OCI dan bukan daftar/indeks manifes (default: false , harus digunakan dengan oci-mediatypes=true )

  • oci-mediatypes= : apakah akan menggunakan tipe media OCI dalam manifes yang diekspor (default: true , karena BuildKit v0.8 )

  • compression= : pilih jenis kompresi untuk lapisan yang baru dibuat dan di-cache, gzip adalah nilai default. estargz dan zstd harus digunakan dengan oci-mediatypes=true

  • compression-level= : pilih tingkat kompresi untuk gzip, estargz (0-9) dan zstd (0-22)

  • force-compression=true : menerapkan opsi compression secara paksa ke semua lapisan

  • ignore-error= : tentukan apakah kesalahan diabaikan jika ekspor cache gagal (default: false )

Opsi --import-cache :

  • type=registry

  • ref= : tentukan referensi repositori untuk mengambil cache, misalnya docker.io/user/image:tag

Direktori lokal

 buildctl build ... --export-cache type=local,dest=path/to/output-dir
buildctl build ... --import-cache type=local,src=path/to/input-dir

Tata letak direktori sesuai dengan OCI Image Spec v1.0.

Opsi --export-cache :

  • type=local

  • mode= : tentukan lapisan cache yang akan diekspor (default: min )

    • min : hanya mengekspor lapisan untuk gambar yang dihasilkan

    • max : mengekspor semua lapisan dari semua langkah perantara

  • dest= : direktori tujuan untuk pengekspor cache

  • tag= : tentukan tag gambar khusus untuk ditulis ke indeks lokal (default: latest )

  • image-manifest= : apakah akan mengekspor manifes cache sebagai manifes gambar yang kompatibel dengan OCI dan bukan daftar/indeks manifes (default: false , harus digunakan dengan oci-mediatypes=true )

  • oci-mediatypes= : apakah akan menggunakan mediatype OCI dalam manifes yang diekspor (default true , karena BuildKit v0.8 )

  • compression= : pilih jenis kompresi untuk lapisan yang baru dibuat dan di-cache, gzip adalah nilai default. estargz dan zstd harus digunakan dengan oci-mediatypes=true .

  • compression-level= : tingkat kompresi untuk gzip, estargz (0-9) dan zstd (0-22)

  • force-compression=true : menerapkan opsi compression secara paksa ke semua lapisan

  • ignore-error= : tentukan apakah kesalahan diabaikan jika ekspor cache gagal (default: false )

Opsi --import-cache :

  • type=local

  • src= : direktori sumber untuk pengimpor cache

  • tag= : tentukan tag khusus gambar yang akan dibaca dari indeks lokal (default: latest )

  • digest=sha256: : tentukan intisari eksplisit dari daftar manifes yang akan diimpor

Cache Tindakan GitHub (eksperimental)

 membangunctl membangun ...
   --tipe keluaran=gambar,nama=docker.io/nama pengguna/gambar,push=true
   --tipe ekspor-cache=gha
   --impor-tipe cache=gha

Cache Tindakan GitHub menyimpan metadata dan lapisan cache ke layanan Cache GitHub. Cache ini saat ini memiliki batas ukuran 10 GB yang dibagikan ke berbagai cache di repo. Jika Anda melebihi batas ini, GitHub akan menyimpan cache Anda tetapi akan mulai mengeluarkan cache hingga ukuran totalnya kurang dari 10 GB. Mendaur ulang cache terlalu sering dapat menyebabkan waktu proses menjadi lebih lambat secara keseluruhan.

Sama halnya dengan penggunaan tindakan/cache, cache dicakup berdasarkan cabang, dengan cabang default dan target tersedia untuk setiap cabang.

Atribut berikut diperlukan untuk mengautentikasi terhadap API layanan GitHub Actions Cache:

  • url : URL server cache (default $ACTIONS_CACHE_URL )

  • token : Token akses (default $ACTIONS_RUNTIME_TOKEN )

Jenis cache ini dapat digunakan dengan Docker Build Push Action di mana url dan token akan diatur secara otomatis. Untuk menggunakan backend ini dalam langkah run inline, Anda harus menyertakan crazy-max/ghaction-github-runtime dalam alur kerja Anda untuk mengekspos runtime.

Opsi --export-cache :

  • type=gha

  • mode= : tentukan lapisan cache yang akan diekspor (default: min )

    • min : hanya mengekspor lapisan untuk gambar yang dihasilkan

    • max : mengekspor semua lapisan dari semua langkah perantara

  • scope= : milik objek cache cakupan mana ( buildkit default)

  • ignore-error= : tentukan apakah kesalahan diabaikan jika ekspor cache gagal (default: false )

  • timeout= : menetapkan durasi batas waktu untuk ekspor cache (default: 10m )

Opsi --import-cache :

  • type=gha

  • scope= : milik objek cache cakupan mana ( buildkit default)

  • timeout= : menetapkan durasi batas waktu untuk impor cache (default: 10m )

Cache S3 (eksperimental)

 membangunctl membangun ...
   --tipe keluaran=gambar,nama=docker.io/nama pengguna/gambar,push=true
   --export-cache type=s3,region=eu-west-1,bucket=my_bucket,name=my_image
   --import-cache type=s3,region=eu-west-1,bucket=my_bucket,name=my_image

Atribut berikut diperlukan:

  • bucket : Ember AWS S3 (default: $AWS_BUCKET )

  • region : wilayah AWS (default: $AWS_REGION )

Lokasi penyimpanan:

  • gumpalan: s3://// , default: s3:///blobs/

  • manifes: s3://// , default: s3:///manifests/

Konfigurasi S3:

  • blobs_prefix : awalan global untuk menyimpan/membaca blob di s3 (default: blobs/ )

  • manifests_prefix : awalan global untuk menyimpan/membaca manifes di s3 (default: manifests/ )

  • endpoint_url : tentukan titik akhir S3 tertentu (default: kosong)

  • use_path_style : jika disetel ke true , masukkan nama keranjang di URL, bukan di nama host (default: false )

Otentikasi AWS:

Cara termudah adalah dengan menggunakan profil Instans IAM. Pilihan lainnya adalah:

  • Sistem apa pun yang menggunakan variabel lingkungan/file konfigurasi yang didukung oleh AWS Go SDK. Konfigurasi harus tersedia untuk daemon buildkit, bukan untuk klien.

  • Menggunakan atribut berikut:

    • access_key_id : ID Kunci Akses

    • secret_access_key : Kunci Akses Rahasia

    • session_token : Token Sesi

Opsi --export-cache :

  • type=s3

  • mode= : tentukan lapisan cache yang akan diekspor (default: min )

    • min : hanya mengekspor lapisan untuk gambar yang dihasilkan

    • max : mengekspor semua lapisan dari semua langkah perantara

  • prefix= : mengatur awalan global untuk menyimpan/membaca file di s3 (default: kosong)

  • name= : tentukan nama manifes yang akan digunakan ( buildkit default)

    • Beberapa nama manifes dapat ditentukan secara bersamaan, dipisahkan dengan ; . Kasus penggunaan standar adalah menggunakan git sha1 sebagai nama, dan nama cabang sebagai duplikat, dan memuat keduanya dengan 2 perintah import-cache .

  • ignore-error= : tentukan apakah kesalahan diabaikan jika ekspor cache gagal (default: false )

  • touch_refresh=24h : Alih-alih diunggah lagi ketika tidak diubah, file blob akan "disentuh" ​​​​di s3 setiap touch_refresh , defaultnya adalah 24 jam. Oleh karena itu, kebijakan kedaluwarsa dapat diatur pada bucket S3 untuk membersihkan file yang tidak berguna secara otomatis. File manifes ditulis ulang secara sistematis, tidak perlu menyentuhnya.

  • upload_parallelism=4 : Parameter ini mengubah jumlah lapisan yang diunggah ke s3 secara paralel. Setiap lapisan individual diunggah dengan 5 thread, menggunakan Manajer unggahan yang disediakan oleh AWS SDK.

Opsi --import-cache :

  • type=s3

  • prefix= : mengatur awalan global untuk menyimpan/membaca file di s3 (default: kosong)

  • blobs_prefix= : menyetel awalan global untuk menyimpan/membaca blob di s3 (default: blobs/ )

  • manifests_prefix= : menyetel awalan global untuk menyimpan/membaca manifes di s3 (default: manifests/ )

  • name= : nama manifes yang akan digunakan ( buildkit default)

Cache Penyimpanan Blob Azure (eksperimental)

 membangunctl membangun ...
   --tipe keluaran=gambar,nama=docker.io/nama pengguna/gambar,push=true
   --export-cache type=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image
   --import-cache type=azblob,account_url=https://myaccount.blob.core.windows.net,name=my_image

Atribut berikut diperlukan:

  • account_url : URL akun Azure Blob Storage (default: $BUILDKIT_AZURE_STORAGE_ACCOUNT_URL )

Lokasi penyimpanan:

  • gumpalan: /// , default: //blobs/

  • manifes: /// , default: //manifests/

Konfigurasi Azure Blob Storage:

  • container : Nama kontainer Azure Blob Storage (default: buildkit-cache atau $BUILDKIT_AZURE_STORAGE_CONTAINER jika disetel)

  • blobs_prefix : Awalan global untuk menyimpan/membaca blob pada kontainer Azure Blob Storage ( ) (default: blobs/ )

  • manifests_prefix : Awalan global untuk menyimpan/membaca blob pada kontainer Azure Blob Storage ( ) (default: manifests/ )

Autentikasi Azure Blob Storage:

Ada 2 opsi yang didukung untuk autentikasi Azure Blob Storage:

  • Sistem apa pun yang menggunakan variabel lingkungan yang didukung oleh Azure SDK for Go. Konfigurasi harus tersedia untuk daemon buildkit, bukan untuk klien.

  • Kunci Akses Rahasia, menggunakan atribut secret_access_key untuk menentukan kunci akun primer atau sekunder untuk akun Azure Blob Storage Anda. Kunci akun Azure Blob Storage

Catatan

Nama akun juga dapat ditentukan dengan atribut account_name (atau $BUILDKIT_AZURE_STORAGE_ACCOUNT_NAME ) jika bukan bagian dari host URL akun.

Opsi --export-cache :

  • type=azblob

  • mode= : tentukan lapisan cache yang akan diekspor (default: min )

    • min : hanya mengekspor lapisan untuk gambar yang dihasilkan

    • max : mengekspor semua lapisan dari semua langkah perantara

  • prefix= : mengatur awalan global untuk menyimpan/membaca file di kontainer Azure Blob Storage ( ) (default: kosong)

  • name= : tentukan nama manifes yang akan digunakan (default: buildkit )

    • Beberapa nama manifes dapat ditentukan secara bersamaan, dipisahkan dengan ; . Kasus penggunaan standar adalah menggunakan git sha1 sebagai nama, dan nama cabang sebagai duplikat, dan memuat keduanya dengan 2 perintah import-cache .

  • ignore-error= : tentukan apakah kesalahan diabaikan jika ekspor cache gagal (default: false )

Opsi --import-cache :

  • type=azblob

  • prefix= : mengatur awalan global untuk menyimpan/membaca file di kontainer Azure Blob Storage ( ) (default: kosong)

  • blobs_prefix= : mengatur awalan global untuk menyimpan/membaca blob pada kontainer Azure Blob Storage ( ) (default: blobs/ )

  • manifests_prefix= : mengatur awalan global untuk menyimpan/membaca manifes pada kontainer Azure Blob Storage ( ) (default: manifests/ )

  • name= : nama manifes yang akan digunakan (default: buildkit )

Hashing yang konsisten

Jika Anda memiliki beberapa instans daemon BuildKit, tetapi Anda tidak ingin menggunakan registri untuk berbagi cache di seluruh klaster, pertimbangkan penyeimbangan beban sisi klien menggunakan hashing yang konsisten.

Lihat ./examples/kubernetes/consistenthash .

Metadata

Untuk menghasilkan metadata build seperti ringkasan gambar, berikan tanda --metadata-file . Metadata akan ditulis sebagai objek JSON ke file yang ditentukan. Direktori file yang ditentukan harus sudah ada dan dapat ditulisi.

 buildctl build ... --metadata-file metadata.json
 jq '.' metadata.json
 { "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "containerimage.descriptor": {"anotasi": { "config.digest": "sha256:2937f66a9722 f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "org.opencontainers.image.created": " 08-02-2022T21:28:03Z"},"digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3","mediaType": "application/vnd.oci.image.manifest.v1+json","size": 506
  }, "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"}

Aktivasi soket Systemd

Pada sistem berbasis Systemd, Anda dapat berkomunikasi dengan daemon melalui aktivasi soket Systemd, gunakan buildkitd --addr fd:// . Anda dapat menemukan contoh penggunaan aktivasi soket Systemd dengan BuildKit dan Systemd di ./examples/systemd .

Ekspos BuildKit sebagai layanan TCP

Daemon buildkitd dapat mendengarkan API gRPC pada soket TCP.

Sangat disarankan untuk membuat sertifikat TLS untuk daemon dan klien (mTLS). Mengaktifkan TCP tanpa mTLS berbahaya karena kontainer eksekutor (alias kontainer Dockerfile RUN ) juga dapat memanggil BuildKit API.

 buildkitd
   --tambahkan tcp://0.0.0.0:1234
   --tlscacert /path/ke/ca.pem
   --tlscert /path/ke/cert.pem
   --tlskey /path/ke/key.pem
 buildctl
   --addr tcp://example.com:1234
   --tlscacert /path/ke/ca.pem
   --tlscert /path/ke/clientcert.pem
   --tlskey /path/ke/clientkey.pem
   membangun ...

Penyeimbangan beban

buildctl build dapat dipanggil terhadap daemon buildkitd seimbang yang memuat secara acak.

Lihat juga Hashing yang konsisten untuk penyeimbangan beban sisi klien.

Kontainerisasi BuildKit

BuildKit juga dapat digunakan dengan menjalankan daemon buildkitd di dalam container Docker dan mengaksesnya dari jarak jauh.

Kami menyediakan gambar kontainer sebagai moby/buildkit :

  • moby/buildkit:latest : dibuat dari rilis reguler terbaru

  • moby/buildkit:rootless : sama seperti latest tetapi berjalan sebagai pengguna yang tidak memiliki hak istimewa, lihat docs/rootless.md

  • moby/buildkit:master : dibangun dari cabang master

  • moby/buildkit:master-rootless : sama seperti master tetapi dijalankan sebagai pengguna yang tidak memiliki hak istimewa, lihat docs/rootless.md

Untuk menjalankan daemon dalam sebuah container:

 docker run -d --name buildkitd --privileged moby/buildkit:latestexport BUILDKIT_HOST=docker-container://buildkitd
buildctl build --membantu

Podman

Untuk terhubung ke daemon BuildKit yang berjalan di container Podman, gunakan podman-container:// alih-alih docker-container:// .

 podman run -d --name buildkitd --privileged moby/buildkit:latest
buildctl --addr=podman-container://buildkitd build --frontend dockerfile.v0 --konteks lokal=. --file buruh pelabuhan lokal=. --tipe keluaran=oci | podman memuat foo

sudo tidak diperlukan.

Nerdctl

Untuk terhubung ke daemon BuildKit yang berjalan di container Nerdctl, gunakan nerdctl-container:// alih-alih docker-container:// .

 nerdctl run -d --name buildkitd --privileged moby/buildkit:latest
buildctl --addr=nerdctl-container://buildkitd build --frontend dockerfile.v0 --konteks lokal=. --file buruh pelabuhan lokal=. --tipe keluaran=oci | beban nerdctl

sudo tidak diperlukan.

Kubernet

Untuk penerapan Kubernetes, lihat examples/kubernetes .

Tanpa Daemon

Untuk menjalankan klien dan daemon sementara dalam satu wadah ("mode tanpa daemon"):

 menjalankan buruh pelabuhan
     -dia
     --rm
     --istimewa
     -v /path/ke/dir:/tmp/work
     --entrypoint buildctl-daemonless.sh
     moby/buildkit:master
         membangun
         --file buruh pelabuhan frontend.v0
         --konteks lokal=/tmp/work
         --local dockerfile=/tmp/work

atau

 menjalankan buruh pelabuhan
     -dia
     --rm
     --security-opt seccomp=tidak dibatasi
     --security-opt apparmor=tidak dibatasi
     -e BUILDKITD_FLAGS=--oci-pekerja-tanpa-proses-kotak pasir
     -v /path/ke/dir:/tmp/work
     --entrypoint buildctl-daemonless.sh
     moby/buildkit:master-tanpa akar
         membangun
         --depan
         dockerfile.v0
         --konteks lokal=/tmp/work
         --local dockerfile=/tmp/work

Dukungan OpenTelemetri

BuildKit mendukung OpenTelemetry untuk buildkitd gRPC API dan perintah buildctl. Untuk menangkap jejak ke Jaeger, setel variabel lingkungan JAEGER_TRACE ke alamat koleksi.

 docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latestexport JAEGER_TRACE=0.0.0.0:6831# restart buildkitd dan buildctl sehingga mereka mengetahui JAEGER_TRACE# perintah buildctl apa pun harus dilacak ke http:/ /127.0.0.1:16686/

Di Windows, jika Anda menjalankan Jaeger di luar wadah, jaeger-all-in-one.exe , atur variabel lingkungan setx -m JAEGER_TRACE "0.0.0.0:6831" , mulai ulang buildkitd di terminal baru dan jejaknya akan menjadi dikumpulkan secara otomatis.

Menjalankan BuildKit tanpa hak akses root

Silakan merujuk ke docs/rootless.md .

Membangun gambar multi-platform

Silakan merujuk ke docs/multi-platform.md .

Mengonfigurasi buildctl

Kontrol Keluaran Warna

buildctl memiliki dukungan untuk memodifikasi warna yang digunakan untuk mengeluarkan informasi ke terminal. Anda dapat menyetel variabel lingkungan BUILDKIT_COLORS menjadi seperti run=green:warning=yellow:error=red:cancel=255,165,0 untuk menyetel warna yang ingin Anda gunakan. Menyetel NO_COLOR ke apa pun akan menonaktifkan keluaran berwarna apa pun seperti yang direkomendasikan oleh no-color.org.

Kesalahan penguraian akan dilaporkan tetapi diabaikan. Hal ini akan mengakibatkan nilai warna default digunakan jika diperlukan.

  • Daftar warna yang telah ditentukan sebelumnya.

Jumlah baris log (untuk langkah aktif dalam mode tty)

Anda dapat mengubah berapa banyak baris log yang terlihat untuk langkah aktif dalam mode tty dengan mengatur BUILDKIT_TTY_LOG_LINES ke angka (default: 6).

Berkontribusi

Ingin berkontribusi pada BuildKit? Luar biasa! Anda dapat menemukan informasi tentang berkontribusi pada proyek ini di CONTRIBUTING.md

Memperluas
Informasi Tambahan
Aplikasi Terkait
Direkomendasikan untuk Anda
Informasi Terkait Semua
Komentar Pengguna