ชุดอุปกรณ์สร้าง

ซอร์สโค้ดอื่น ๆ

0.17.0

ดาวน์โหลด

บิวด์คิท

BuildKit เป็นชุดเครื่องมือสำหรับการแปลงซอร์สโค้ดเพื่อสร้างอาร์ติแฟกต์ในลักษณะที่มีประสิทธิภาพ แสดงออกได้ชัดเจน และทำซ้ำได้

คุณสมบัติที่สำคัญ:

เก็บขยะอัตโนมัติ
รูปแบบส่วนหน้าที่ขยายได้
ความละเอียดการพึ่งพาพร้อมกัน
แคชคำสั่งที่มีประสิทธิภาพ
สร้างการนำเข้า/ส่งออกแคช
การเรียกใช้งาน build ที่ซ้อนกัน
คนงานที่สามารถแจกจ่ายได้
รูปแบบเอาต์พุตหลายรูปแบบ
สถาปัตยกรรมแบบเสียบได้
การดำเนินการโดยไม่มีสิทธิ์รูท

อ่านข้อเสนอจาก moby/moby#32925

โพสต์บล็อกเบื้องต้น https://blog.mobyproject.org/introduction-buildkit-17e056cc5317

เข้าร่วมช่อง #buildkit บน Docker Community Slack

บันทึก

หากคุณกำลังเยี่ยมชม repo นี้เพื่อใช้คุณสมบัติ Dockerfile ของ BuildKit เท่านั้น เช่น RUN --mount=type=(bind|cache|tmpfs|secret|ssh) โปรดดูข้อมูลอ้างอิง Dockerfile

บันทึก

docker build ใช้ Buildx และ BuildKit เป็นค่าเริ่มต้นตั้งแต่ Docker Engine 23.0 คุณไม่จำเป็นต้องอ่านเอกสารนี้ เว้นแต่ว่าคุณต้องการใช้ BuildKit เวอร์ชันสแตนด์อโลนที่มีคุณสมบัติครบถ้วน

ใช้โดย
เริ่มต้นอย่างรวดเร็ว

รูปภาพ/รีจิสทรี
ไดเรกทอรีท้องถิ่น
ด็อกเกอร์ทาร์บอล
โอซีไอ ทาร์บอล
ที่เก็บรูปภาพคอนเทนเนอร์
การสร้าง Dockerfile ด้วย buildctl
การสร้าง Dockerfile โดยใช้ส่วนหน้าภายนอก
การตั้งค่าลินุกซ์
การตั้งค่าวินโดวส์
การตั้งค่า macOS
สร้างจากแหล่งที่มา
สำรวจ LLB
สำรวจ Dockerfiles
เอาท์พุต

แคช

อินไลน์ (พุชรูปภาพและแคชพร้อมกัน)
Registry (พุชอิมเมจและแคชแยกกัน)
ไดเรกทอรีท้องถิ่น
แคชการดำเนินการ GitHub (ทดลอง)
แคช S3 (ทดลอง)
แคช Azure Blob Storage (ทดลอง)
เก็บขยะ
ส่งออกแคช
การแฮชที่สม่ำเสมอ

ข้อมูลเมตา
การเปิดใช้งานซ็อกเก็ต Systemd
เปิดเผย BuildKit เป็นบริการ TCP

โหลดบาลานซ์

การจัดคอนเทนเนอร์ BuildKit

พ็อดแมน
Nerdctl
คูเบอร์เนเตส
ไร้ภูต

การสนับสนุน OpenTelemetry
การรัน BuildKit โดยไม่มีสิทธิ์รูท
การสร้างภาพหลายแพลตฟอร์ม

การควบคุมเอาต์พุตสี
จำนวนบรรทัดบันทึก (สำหรับขั้นตอนที่แอ็คทีฟในโหมด tty)
การกำหนดค่า buildctl

มีส่วนร่วม

ใช้โดย

BuildKit ถูกใช้โดยโปรเจ็กต์ต่อไปนี้:

Moby & Docker ( DOCKER_BUILDKIT=1 docker build )
รูปภาพ
OpenFaaS คลาวด์
อินเทอร์เฟซการสร้างคอนเทนเนอร์
Tekton Pipelines (เดิมชื่อ Knative Build Templates)
เครื่องมือสร้าง Sanic
วาบ
ริโอ
คิม
กระเป๋าคอนเทนเนอร์
นักเทียบท่า buildx
ออคเทโต้ คลาวด์
ไฟล์ Earthly
กิตพอด
กริช
สภาพแวดล้อม
ดีโป
เนมสเปซ
ยูนิคราฟท์
เดฟซีโร่
ดาซีซี

เริ่มต้นอย่างรวดเร็ว

สำหรับการปรับใช้ Kubernetes โปรดดู examples/kubernetes

BuildKit ประกอบด้วย buildkitd daemon และไคลเอ็นต์ buildctl แม้ว่าไคลเอ็นต์ buildctl จะพร้อมใช้งานสำหรับ Linux, macOS และ Windows แต่ในปัจจุบัน buildkitd daemon จะพร้อมใช้งานสำหรับ Linux และ *Windows เท่านั้น

ไบนารีล่าสุดของ BuildKit มีให้ที่นี่สำหรับ Linux, macOS และ Windows

การตั้งค่าลินุกซ์

buildkitd daemon ต้องการคอมโพเนนต์ต่อไปนี้ที่จะติดตั้ง:

runc หรือ crun
containerd (ถ้าคุณต้องการใช้คนงานคอนเทนเนอร์)

การเริ่มต้น buildkitd daemon: คุณต้องรัน buildkitd ในฐานะผู้ใช้รูทบนโฮสต์

 $ sudo buildkitd

หากต้องการรัน buildkitd ในฐานะผู้ใช้ที่ไม่ใช่รูท โปรดดูที่ docs/rootless.md

buildkitd daemon รองรับแบ็กเอนด์ของผู้ปฏิบัติงานสองรายการ: OCI (runc) และคอนเทนเนอร์

ตามค่าเริ่มต้น จะมีการใช้ผู้ปฏิบัติงาน OCI (runc) คุณสามารถตั้งค่า --oci-worker=false --containerd-worker=true เพื่อใช้คอนเทนเนอร์คนงาน

เราเปิดให้เพิ่มแบ็กเอนด์เพิ่มเติม

เมื่อต้องการสตาร์ท buildkitd daemon โดยใช้การเปิดใช้งานซ็อกเก็ต systemd คุณสามารถติดตั้งไฟล์ buildkit systemd unit ดูการเปิดใช้งานซ็อกเก็ต Systemd

buildkitd daemon จะฟัง gRPC API บน /run/buildkit/buildkitd.sock ตามค่าเริ่มต้น แต่คุณสามารถใช้ซ็อกเก็ต TCP ได้เช่นกัน ดูเปิดเผย BuildKit เป็นบริการ TCP

การตั้งค่าวินโดวส์

ดูคำแนะนำและหมายเหตุที่ docs/windows.md

การตั้งค่า macOS

สูตร Homebrew (ไม่เป็นทางการ) พร้อมใช้งานสำหรับ macOS

 $ ชงติดตั้ง buildkit

สูตร Homebrew ไม่มี daemon ( buildkitd )

ตัวอย่างเช่น Lima สามารถใช้ในการเปิดใช้ daemon ภายใน Linux VM

 ชงติดตั้งเทมเพลตเริ่มต้น limalimactl://buildkitexport BUILDKIT_HOST="unix://$HOME/.lima/buildkit/sock/buildkitd.sock"

สร้างจากแหล่งที่มา

หากต้องการสร้าง BuildKit จากแหล่งที่มา โปรดดู .github/CONTRIBUTING.md

สำหรับการอ้างอิง buildctl โปรดดูเอกสารนี้

สำรวจ LLB

บิลด์ BuildKit อิงตามรูปแบบไบนารีระดับกลางที่เรียกว่า LLB ซึ่งใช้สำหรับกำหนดกราฟการขึ้นต่อกันสำหรับกระบวนการที่ทำงานส่วนหนึ่งของบิลด์ของคุณ tl; dr: LLB คือ Dockerfile สิ่งที่ LLVM IR คือ C

Marshaled เป็นข้อความ Protobuf
ปฏิบัติการได้พร้อมๆ กัน
แคชได้อย่างมีประสิทธิภาพ
ผู้ขายเป็นกลาง (เช่น ภาษาที่ไม่ใช่ Dockerfile สามารถนำไปใช้ได้อย่างง่ายดาย)

ดูคำนิยามรูปแบบ solver/pb/ops.proto และดู ./examples/README.md สำหรับตัวอย่างแอปพลิเคชัน LLB

ปัจจุบัน LLB มีการนำภาษาระดับสูงต่อไปนี้ไปใช้:

Dockerfile (ดูการสำรวจ Dockerfiles)
บิลด์แพ็ก
ม็อกเกอร์ไฟล์
โกเกอร์ไฟล์
ตึก (Pkgfile)
เอชแอลบี
เอิร์ธไฟล์ (Earthly)
ท่าเรือขนส่งสินค้า (สนิม)
ห้าม
ม็อปปี้ (Python)
envd (สตาร์ลาร์ก)
ร้องไห้สะอึกสะอื้น
เบส
kraft.yaml (ยูนิคราฟท์)
r2d4/llb (เกตเวย์ JSON)
(เปิด PR เพิ่มภาษาของตัวเอง)

สำรวจ Dockerfiles

ส่วนหน้าคือส่วนประกอบที่ทำงานภายใน BuildKit และแปลงคำจำกัดความของบิวด์เป็น LLB มีส่วนหน้าพิเศษที่เรียกว่าเกตเวย์ ( gateway.v0 ) ที่อนุญาตให้ใช้รูปภาพใดๆ เป็นส่วนหน้าได้

ในระหว่างการพัฒนา ส่วนหน้า Dockerfile ( dockerfile.v0 ) ก็เป็นส่วนหนึ่งของ repo BuildKit เช่นกัน ในอนาคต สิ่งนี้จะถูกย้ายออก และคุณสามารถสร้าง Dockerfiles ได้โดยใช้อิมเมจภายนอก

การสร้าง Dockerfile ด้วย `buildctl`

 buildctl สร้าง
     --frontend=นักเทียบท่าfile.v0
     --บริบทท้องถิ่น=
     --local dockerfile=.# orbuildctl build
     --frontend=นักเทียบท่าfile.v0
     --บริบทท้องถิ่น=
     --local dockerfile=.
     --เลือกเป้าหมาย=foo
     --opt build-arg:foo=bar

--local เปิดเผยไฟล์ต้นฉบับในเครื่องจากไคลเอนต์ไปยังตัวสร้าง context และ dockerfile เป็นชื่อที่ส่วนหน้าของ Dockerfile ค้นหาบริบทการสร้างและตำแหน่ง Dockerfile

หาก Dockerfile มีชื่อไฟล์ที่แตกต่างกัน ก็สามารถระบุด้วย --opt filename=./Dockerfile-alternative

การสร้าง Dockerfile โดยใช้ส่วนหน้าภายนอก

เวอร์ชันภายนอกของส่วนหน้าของ Dockerfile จะถูกพุชไปที่ https://hub.docker.com/r/docker/dockerfile-upstream และ https://hub.docker.com/r/docker/dockerfile และสามารถใช้ได้กับส่วนหน้าของเกตเวย์ . ปัจจุบันแหล่งที่มาสำหรับส่วนหน้าภายนอกอยู่ใน ./frontend/dockerfile/cmd/dockerfile-frontend dockerfile/cmd/dockerfile-frontend แต่จะย้ายออกจากที่เก็บนี้ในอนาคต (#163) สำหรับการสร้างอัตโนมัติจากสาขาหลักของที่เก็บนี้ สามารถใช้อิมเมจ docker/dockerfile-upstream:master หรือ docker/dockerfile-upstream:master-labs ได้

 buildctl สร้าง
     --ส่วนหน้าเกตเวย์.v0
     --opt source=docker/dockerfile
     --บริบทท้องถิ่น=
     --local dockerfile=.
buildctl สร้าง
     --ส่วนหน้าเกตเวย์.v0
     --opt source=docker/dockerfile
     --opt บริบท=https://github.com/moby/moby.git
     --เลือก build-arg:APT_MIRROR=cdn-fastly.deb.debian.org

เอาท์พุต

ตามค่าเริ่มต้น ผลลัพธ์ของบิลด์และแคชระดับกลางจะคงอยู่ภายใน BuildKit เท่านั้น จำเป็นต้องระบุเอาต์พุตเพื่อดึงผลลัพธ์

รูปภาพ/รีจิสทรี

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

หากต้องการส่งออกรูปภาพไปยังหลายรีจิสตรี:

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

หากต้องการส่งออกแคชที่ฝังด้วยอิมเมจและพุชไปที่รีจิสตรีด้วยกัน จำเป็นต้องพิมพ์ registry เพื่อนำเข้าแคช คุณควรระบุ --export-cache type=inline และ --import-cache type=registry,ref=... . หากต้องการส่งออกแคชไปยังโลคัลโดยตรง คุณควรระบุ --export-cache type=local รายละเอียดในแคชส่งออก

 buildctl สร้าง ...
  --output type=image,name=docker.io/username/image,push=true
   --export-cache type=inline
   --import-cache type=registry,ref=docker.io/username/image

ปุ่มที่รองรับโดยเอาต์พุตภาพ:

name= : ระบุชื่อรูปภาพ
push=true : กดหลังจากสร้างภาพ
push-by-digest=true : ดันรูปภาพที่ไม่มีชื่อ
registry.insecure=true : กดไปที่รีจิสทรี HTTP ที่ไม่ปลอดภัย
oci-mediatypes=true : ใช้สื่อประเภท OCI ในการกำหนดค่า JSON แทน Docker's
unpack=true : แกะอิมเมจหลังการสร้าง (สำหรับใช้กับคอนเทนเนอร์)
dangling-name-prefix= : ชื่อรูปภาพด้วย prefix@ ใช้สำหรับรูปภาพที่ไม่ระบุชื่อ
name-canonical=true : เพิ่มชื่อมาตรฐานเพิ่มเติม name@
compression= : เลือกประเภทการบีบอัดสำหรับเลเยอร์ที่สร้างขึ้นใหม่และแคช gzip เป็นค่าเริ่มต้น ควรใช้ estargz กับ oci-mediatypes=true
compression-level= : ระดับการบีบอัดสำหรับ gzip, estargz (0-9) และ zstd (0-22)
rewrite-timestamp=true : เขียนการประทับเวลาของไฟล์ใหม่เป็นค่า SOURCE_DATE_EPOCH ดู docs/build-repro.md สำหรับวิธีระบุค่า SOURCE_DATE_EPOCH
force-compression=true : ใช้ตัวเลือก compression อย่างเข้มแข็งกับทุกเลเยอร์ (รวมถึงเลเยอร์ที่มีอยู่แล้ว)
store=true : เก็บอิมเมจผลลัพธ์ไว้ในที่เก็บอิมเมจของผู้ปฏิบัติงาน (เช่น คอนเทนเนอร์) รวมทั้งให้แน่ใจว่ารูปภาพมี blobs ทั้งหมดในที่เก็บเนื้อหา (ค่าเริ่มต้น true ) ถูกละเว้นหากผู้ปฏิบัติงานไม่มีที่เก็บรูปภาพ (เช่น ผู้ปฏิบัติงาน OCI)
annotation.= : แนบคำอธิบายประกอบด้วย key และ value ที่เกี่ยวข้องให้กับอิมเมจที่สร้างขึ้น

การใช้ไวยากรณ์ขยาย annotation-.= , annotation[].= และทั้งสองรวมกับ annotation-[].= อนุญาตให้กำหนดค่าตำแหน่งที่จะแนบคำอธิบายประกอบได้อย่างแม่นยำ
ระบุวัตถุที่จะแนบและสามารถเป็น manifest ใดก็ได้ (ค่าเริ่มต้น) manifest-descriptor , index และ index-descriptor
ระบุวัตถุที่จะแนบ (โดยค่าเริ่มต้นคือทั้งหมด) และเป็นคีย์เดียวกันที่ส่งผ่านไปยังตัวเลือก platform โปรดดูที่ docs/multi-platform.md
ดู docs/annotations.md สำหรับรายละเอียดเพิ่มเติม

หากจำเป็นต้องมีข้อมูลประจำ buildctl จะพยายามอ่านไฟล์การกำหนดค่า Docker $DOCKER_CONFIG/config.json $DOCKER_CONFIG มีค่าเริ่มต้นเป็น ~/.docker

ไดเรกทอรีท้องถิ่น

ไคลเอนต์ในเครื่องจะคัดลอกไฟล์ไปยังไคลเอนต์โดยตรง สิ่งนี้มีประโยชน์หากใช้ BuildKit เพื่อสร้างสิ่งอื่นที่ไม่ใช่อิมเมจคอนเทนเนอร์

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

หากต้องการส่งออกไฟล์ที่ต้องการ ให้ใช้บิลด์แบบหลายขั้นตอนที่มีขั้นตอนเริ่มต้น และคัดลอกไฟล์ที่จำเป็นไปยังขั้นตอนนั้นด้วย COPY --from

 ...FROM scratch เป็น testresultCOPY --from=builder /usr/src/app/testresult.xml
-

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

ด้วยการสร้างหลายแพลตฟอร์ม โฟลเดอร์ย่อยที่ตรงกับแต่ละแพลตฟอร์มเป้าหมายจะถูกสร้างขึ้นในไดเร็กทอรีปลายทาง:

 จาก busybox AS buildARG TARGETOSARG TARGETARCHRUN mkdir /out && echo foo > /out/hello-$TARGETOS-$TARGETARCHFROM scratchCOPY --from=build /out /

 $ buildctl สร้าง
   --ส่วนหน้า dockerfile.v0
   --เลือกแพลตฟอร์ม=linux/amd64,linux/arm64
   --output type=local,dest=./bin/release

$ ต้นไม้ ./bin
./ถัง/
└── ปล่อย
    ├── linux_amd64
    │ └── สวัสดี-linux-amd64
    └── linux_arm64
        └── สวัสดี-linux-arm64

คุณสามารถตั้งค่า platform-split=false เพื่อรวมไฟล์จากทุกแพลตฟอร์มเข้าด้วยกันในไดเร็กทอรีเดียวกัน:

 $ buildctl สร้าง
   --ส่วนหน้า dockerfile.v0
   --เลือกแพลตฟอร์ม=linux/amd64,linux/arm64
   --output type=local,dest=./bin/release,platform-split=false

$ ต้นไม้ ./bin
./ถัง/
└── ปล่อย
    ├── สวัสดี-linux-amd64
    └── สวัสดี-linux-arm64

ผู้ส่งออก Tar นั้นคล้ายคลึงกับผู้ส่งออกในพื้นที่ แต่ถ่ายโอนไฟล์ผ่าน tarball

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

ด็อกเกอร์ทาร์บอล

 # tarball ที่ส่งออกยังเข้ากันได้กับ OCI specbuildctl build ... --output type=docker,name=myimage | โหลดนักเทียบท่า

โอซีไอ ทาร์บอล

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

ที่เก็บรูปภาพคอนเทนเนอร์

จำเป็นต้องใช้ผู้ปฏิบัติงานในคอนเทนเนอร์

 buildctl build ... --output type=image,name=docker.io/username/image
ctr --namespace=buildkit รูปภาพ ls

หากต้องการเปลี่ยนเนมสเปซของคอนเทนเนอร์ คุณต้องเปลี่ยน worker.containerd.namespace ใน /etc/buildkit/buildkitd.toml

แคช

วิธีแสดงแคชบิลด์ในเครื่อง ( /var/lib/buildkit ):

 buildctl du -v

หากต้องการตัดแคชบิลด์ในเครื่อง:

 buildctl พรุน

เก็บขยะ

ดู ./docs/buildkitd.toml.md

ส่งออกแคช

BuildKit รองรับผู้ส่งออกแคชต่อไปนี้:

inline : ฝังแคชลงในรูปภาพแล้วดันไปที่รีจิสทรีพร้อมกัน
registry : ดันอิมเมจและแคชแยกกัน
local : ส่งออกไปยังไดเร็กทอรีในเครื่อง
gha : ส่งออกไปยังแคช GitHub Actions

ในกรณีส่วนใหญ่ คุณต้องการใช้ผู้ส่งออกแคช inline อย่างไรก็ตาม โปรดทราบว่าผู้ส่งออกแคช inline รองรับเฉพาะโหมดแคช min เท่านั้น หากต้องการเปิดใช้งานโหมดแคช max ให้ดันรูปภาพและแคชแยกกันโดยใช้ผู้ส่งออกแคชของ registry

ผู้ส่งออกแบบ inline และ registry จะเก็บแคชไว้ในรีจิสทรี สำหรับการนำเข้าแคช type=registry ก็เพียงพอสำหรับทั้งสองอย่าง เนื่องจากไม่จำเป็นต้องระบุรูปแบบแคช

อินไลน์ (พุชรูปภาพและแคชพร้อมกัน)

 buildctl สร้าง ...
   --output type=image,name=docker.io/username/image,push=true
   --export-cache type=inline
   --import-cache type=registry,ref=docker.io/username/image

โปรดทราบว่าแคชแบบอินไลน์จะไม่ถูกนำเข้าเว้นแต่จะมี --import-cache type=registry,ref=...

แคชแบบอินไลน์ฝังข้อมูลเมตาของแคชลงในการกำหนดค่ารูปภาพ เลเยอร์ในรูปภาพจะไม่ถูกแตะต้องเมื่อเทียบกับรูปภาพที่ไม่มีข้อมูลแคช

BuildKit ที่รวม Docker ( DOCKER_BUILDKIT=1 docker build ) และ docker buildx ต้องการ --build-arg BUILDKIT_INLINE_CACHE=1 ที่จะระบุเพื่อเปิดใช้งานผู้ส่งออกแคช inline อย่างไรก็ตาม buildctl แบบสแตนด์อโลนไม่จำเป็นต้องใช้ --opt build-arg:BUILDKIT_INLINE_CACHE=1 และ build-arg ก็จะถูกละเว้น

Registry (พุชอิมเมจและแคชแยกกัน)

 buildctl สร้าง ...
   --output type=image,name=localhost:5000/myrepo:image,push=true
   --export-cache type=registry,ref=localhost:5000/myrepo:buildcache
   --import-cache type=registry,ref=localhost:5000/myrepo:buildcache

--export-cache :

type=registry
mode= : ระบุเลเยอร์แคชที่จะส่งออก (ค่าเริ่มต้น: min )

min : ส่งออกเฉพาะเลเยอร์สำหรับภาพที่ได้
max : ส่งออกเลเยอร์ทั้งหมดของขั้นตอนกลางทั้งหมด

ref= : ระบุการอ้างอิงที่เก็บเพื่อจัดเก็บแคช เช่น docker.io/user/image:tag
image-manifest= : ว่าจะส่งออกรายการแคชเป็นรายการรูปภาพที่เข้ากันได้กับ OCI แทนที่จะเป็นรายการ/ดัชนีรายการหรือไม่ (ค่าเริ่มต้น: false ต้องใช้กับ oci-mediatypes=true )
oci-mediatypes= : จะใช้สื่อประเภท OCI ในไฟล์ Manifest ที่ส่งออกหรือไม่ (ค่าเริ่มต้น: true เนื่องจาก BuildKit v0.8 )
compression= : เลือกประเภทการบีบอัดสำหรับเลเยอร์ที่สร้างขึ้นใหม่และแคช gzip เป็นค่าเริ่มต้น ควรใช้ estargz และ zstd กับ oci-mediatypes=true
compression-level= : เลือกระดับการบีบอัดสำหรับ gzip, estargz (0-9) และ zstd (0-22)
force-compression=true : บังคับให้ใช้ตัวเลือก compression กับทุกเลเยอร์
ignore-error= : ระบุว่าข้อผิดพลาดถูกละเว้นในกรณีที่การส่งออกแคชล้มเหลว (ค่าเริ่มต้น: false )

--import-cache :

type=registry
ref= : ระบุการอ้างอิงที่เก็บเพื่อดึงแคช เช่น docker.io/user/image:tag

ไดเรกทอรีท้องถิ่น

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

เค้าโครงไดเร็กทอรีสอดคล้องกับ OCI Image Spec v1.0

--export-cache :

type=local
mode= : ระบุเลเยอร์แคชที่จะส่งออก (ค่าเริ่มต้น: min )

min : ส่งออกเฉพาะเลเยอร์สำหรับภาพที่ได้
max : ส่งออกเลเยอร์ทั้งหมดของขั้นตอนกลางทั้งหมด

dest= : ไดเร็กทอรีปลายทางสำหรับผู้ส่งออกแคช
tag= : ระบุแท็กที่กำหนดเองของรูปภาพที่จะเขียนลงในดัชนีท้องถิ่น (ค่าเริ่มต้น: latest )
image-manifest= : ว่าจะส่งออกรายการแคชเป็นรายการรูปภาพที่เข้ากันได้กับ OCI แทนที่จะเป็นรายการ/ดัชนีรายการหรือไม่ (ค่าเริ่มต้น: false ต้องใช้กับ oci-mediatypes=true )
oci-mediatypes= : จะใช้สื่อประเภท OCI ในไฟล์ Manifest ที่ส่งออกหรือไม่ (ค่าเริ่มต้น true เนื่องจาก BuildKit v0.8 )
compression= : เลือกประเภทการบีบอัดสำหรับเลเยอร์ที่สร้างขึ้นใหม่และแคช gzip เป็นค่าเริ่มต้น ควรใช้ estargz และ zstd กับ oci-mediatypes=true
compression-level= : ระดับการบีบอัดสำหรับ gzip, estargz (0-9) และ zstd (0-22)
force-compression=true : บังคับให้ใช้ตัวเลือก compression กับทุกเลเยอร์
ignore-error= : ระบุว่าข้อผิดพลาดถูกละเว้นในกรณีที่การส่งออกแคชล้มเหลว (ค่าเริ่มต้น: false )

--import-cache :

type=local
src= : ไดเร็กทอรีต้นทางสำหรับผู้นำเข้าแคช
tag= : ระบุแท็กที่กำหนดเองของรูปภาพที่จะอ่านจากดัชนีท้องถิ่น (ค่าเริ่มต้น: latest )
digest=sha256: : ระบุไดเจสต์ที่ชัดเจนของรายการ Manifest ที่จะนำเข้า

แคชการดำเนินการ GitHub (ทดลอง)

 buildctl สร้าง ...
   --output type=image,name=docker.io/username/image,push=true
   --export-cache type=gha
   --import-cache type=gha

แคช GitHub Actions จะบันทึกทั้งข้อมูลเมตาของแคชและเลเยอร์ไปยังบริการแคชของ GitHub ปัจจุบันแคชนี้มีขนาดจำกัดอยู่ที่ 10GB ซึ่งแชร์ระหว่างแคชต่างๆ ใน repo หากคุณเกินขีดจำกัดนี้ GitHub จะบันทึกแคชของคุณ แต่จะเริ่มกำจัดแคชจนกว่าขนาดรวมจะน้อยกว่า 10 GB การรีไซเคิลแคชบ่อยเกินไปอาจส่งผลให้รันไทม์โดยรวมช้าลง

เช่นเดียวกับการใช้การดำเนินการ/แคช แคชจะถูกกำหนดขอบเขตตามสาขา โดยสาขาที่เป็นค่าเริ่มต้นและเป้าหมายจะพร้อมใช้งานสำหรับทุกสาขา

แอตทริบิวต์ต่อไปนี้จำเป็นในการตรวจสอบสิทธิ์กับ API บริการแคช GitHub Actions:

url : URL เซิร์ฟเวอร์แคช (ค่าเริ่มต้น $ACTIONS_CACHE_URL )
token : โทเค็นการเข้าถึง (ค่าเริ่มต้น $ACTIONS_RUNTIME_TOKEN )

แคชประเภทนี้สามารถใช้กับ Docker Build Push Action โดยที่ url และ token จะถูกตั้งค่าโดยอัตโนมัติ หากต้องการใช้แบ็กเอนด์นี้ในขั้นตอน run แบบอินไลน์ คุณต้องรวม crazy-max/ghaction-github-runtime ไว้ในเวิร์กโฟลว์ของคุณเพื่อแสดงรันไทม์

--export-cache :

type=gha
mode= : ระบุเลเยอร์แคชที่จะส่งออก (ค่าเริ่มต้น: min )

min : ส่งออกเฉพาะเลเยอร์สำหรับภาพที่ได้
max : ส่งออกเลเยอร์ทั้งหมดของขั้นตอนกลางทั้งหมด

scope= : วัตถุแคชขอบเขตใดที่เป็นของ ( buildkit เริ่มต้น)
ignore-error= : ระบุว่าข้อผิดพลาดถูกละเว้นในกรณีที่การส่งออกแคชล้มเหลว (ค่าเริ่มต้น: false )
timeout= : กำหนดระยะเวลาหมดเวลาสำหรับการส่งออกแคช (ค่าเริ่มต้น: 10m )

--import-cache :

type=gha
scope= : วัตถุแคชขอบเขตใดที่เป็นของ ( buildkit เริ่มต้น)
timeout= : กำหนดระยะเวลาหมดเวลาสำหรับการนำเข้าแคช (ค่าเริ่มต้น: 10m )

แคช S3 (ทดลอง)

 buildctl สร้าง ...
   --output type=image,name=docker.io/username/image,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

ต้องมีแอตทริบิวต์ต่อไปนี้:

bucket : ที่เก็บข้อมูล AWS S3 (ค่าเริ่มต้น: $AWS_BUCKET )
region : ภูมิภาค AWS (ค่าเริ่มต้น: $AWS_REGION )

สถานที่จัดเก็บ:

blobs: s3://// , ค่าเริ่มต้น: s3:///blobs/
รายการ: s3://// , ค่าเริ่มต้น: s3:///manifests/

การกำหนดค่า S3:

blobs_prefix : คำนำหน้าส่วนกลางสำหรับจัดเก็บ / อ่าน blobs บน s3 (ค่าเริ่มต้น: blobs/ )
manifests_prefix : คำนำหน้าส่วนกลางสำหรับจัดเก็บ / อ่านรายการบน s3 (ค่าเริ่มต้น: manifests/ )
endpoint_url : ระบุตำแหน่งข้อมูล S3 เฉพาะ (ค่าเริ่มต้น: ว่างเปล่า)
use_path_style : หากตั้งค่าเป็น true ให้ใส่ชื่อที่เก็บข้อมูลใน URL แทนที่จะใส่ในชื่อโฮสต์ (ค่าเริ่มต้น: false )

การรับรองความถูกต้อง AWS:

วิธีที่ง่ายที่สุดคือการใช้โปรไฟล์อินสแตนซ์ IAM ตัวเลือกอื่นๆ ได้แก่:

ระบบใดๆ ที่ใช้ตัวแปรสภาพแวดล้อม/ไฟล์กำหนดค่าที่รองรับโดย AWS Go SDK การกำหนดค่าต้องพร้อมใช้งานสำหรับ buildkit daemon ไม่ใช่สำหรับไคลเอ็นต์
การใช้คุณลักษณะต่อไปนี้:

access_key_id : รหัสคีย์การเข้าถึง
secret_access_key : รหัสการเข้าถึงความลับ
session_token : โทเค็นเซสชัน

--export-cache :

type=s3
mode= : ระบุเลเยอร์แคชที่จะส่งออก (ค่าเริ่มต้น: min )

min : ส่งออกเฉพาะเลเยอร์สำหรับภาพที่ได้
max : ส่งออกเลเยอร์ทั้งหมดของขั้นตอนกลางทั้งหมด

prefix= : ตั้งค่าคำนำหน้าส่วนกลางเพื่อจัดเก็บ / อ่านไฟล์บน s3 (ค่าเริ่มต้น: ว่างเปล่า)
name= : ระบุชื่อของ manifest ที่จะใช้ (default buildkit )

สามารถระบุชื่อรายการได้หลายรายการพร้อมกัน โดยคั่นด้วย ; - กรณีการใช้งานมาตรฐานคือใช้ git sha1 เป็นชื่อ และใช้ชื่อสาขาซ้ำกัน และโหลดทั้งสองคำสั่งด้วยคำสั่ง import-cache 2 คำสั่ง

ignore-error= : ระบุว่าข้อผิดพลาดถูกละเว้นในกรณีที่การส่งออกแคชล้มเหลว (ค่าเริ่มต้น: false )
touch_refresh=24h : แทนที่จะอัปโหลดอีกครั้งเมื่อไม่มีการเปลี่ยนแปลง ไฟล์ blobs จะถูก "สัมผัส" ใน s3 ทุกๆ touch_refresh ค่าเริ่มต้นคือ 24 ชั่วโมง ด้วยเหตุนี้ คุณจึงสามารถตั้งค่านโยบายการหมดอายุบนบัคเก็ต S3 เพื่อล้างไฟล์ที่ไม่มีประโยชน์โดยอัตโนมัติ ไฟล์มานิเฟสต์จะถูกเขียนใหม่อย่างเป็นระบบ โดยไม่จำเป็นต้องแตะไฟล์เหล่านั้น
upload_parallelism=4 : พารามิเตอร์นี้เปลี่ยนจำนวนเลเยอร์ที่อัปโหลดเป็น s3 แบบขนาน แต่ละเลเยอร์จะถูกอัปโหลดด้วย 5 เธรด โดยใช้ตัวจัดการการอัปโหลดที่ AWS SDK มอบให้

--import-cache :

type=s3
prefix= : ตั้งค่าคำนำหน้าส่วนกลางเพื่อจัดเก็บ / อ่านไฟล์บน s3 (ค่าเริ่มต้น: ว่างเปล่า)
blobs_prefix= : ตั้งค่าคำนำหน้าส่วนกลางเพื่อจัดเก็บ / อ่าน blobs บน s3 (ค่าเริ่มต้น: blobs/ )
manifests_prefix= : ตั้งค่าคำนำหน้าส่วนกลางเพื่อจัดเก็บ / อ่านรายการบน s3 (ค่าเริ่มต้น: manifests/ )
name= : ชื่อของรายการที่จะใช้ ( buildkit เริ่มต้น)

แคช Azure Blob Storage (ทดลอง)

 buildctl สร้าง ...
   --output type=image,name=docker.io/username/image,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

ต้องมีแอตทริบิวต์ต่อไปนี้:

account_url : URL บัญชี Azure Blob Storage (ค่าเริ่มต้น: $BUILDKIT_AZURE_STORAGE_ACCOUNT_URL )

สถานที่จัดเก็บ:

blobs: /// , ค่าเริ่มต้น: //blobs/
รายการ: /// , ค่าเริ่มต้น: //manifests/

การกำหนดค่าพื้นที่เก็บข้อมูล Azure Blob:

container : ชื่อคอนเทนเนอร์ Azure Blob Storage (ค่าเริ่มต้น: buildkit-cache หรือ $BUILDKIT_AZURE_STORAGE_CONTAINER หากตั้งค่าไว้)
blobs_prefix : คำนำหน้าสากลสำหรับจัดเก็บ / อ่าน blobs บนคอนเทนเนอร์ Azure Blob Storage ( ) (ค่าเริ่มต้น: blobs/ )
manifests_prefix : คำนำหน้าสากลสำหรับจัดเก็บ / อ่าน blobs บนคอนเทนเนอร์ Azure Blob Storage ( ) (ค่าเริ่มต้น: manifests/ )

การรับรองความถูกต้องของ Azure Blob Storage:

มี 2 ตัวเลือกที่รองรับสำหรับการรับรองความถูกต้อง Azure Blob Storage:

ระบบใดๆ ที่ใช้ตัวแปรสภาพแวดล้อมที่รองรับโดย Azure SDK for Go การกำหนดค่าต้องพร้อมใช้งานสำหรับ buildkit daemon ไม่ใช่สำหรับไคลเอ็นต์
รหัสการเข้าถึงข้อมูลลับ โดยใช้แอตทริบิวต์ secret_access_key เพื่อระบุรหัสบัญชีหลักหรือรองสำหรับบัญชี Azure Blob Storage ของคุณ คีย์บัญชี Azure Blob Storage

บันทึก

ชื่อบัญชียังสามารถระบุด้วยแอตทริบิวต์ account_name (หรือ $BUILDKIT_AZURE_STORAGE_ACCOUNT_NAME ) หากไม่ได้เป็นส่วนหนึ่งของโฮสต์ URL ของบัญชี

--export-cache :

type=azblob
mode= : ระบุเลเยอร์แคชที่จะส่งออก (ค่าเริ่มต้น: min )

min : ส่งออกเฉพาะเลเยอร์สำหรับภาพที่ได้
max : ส่งออกเลเยอร์ทั้งหมดของขั้นตอนกลางทั้งหมด

prefix= : ตั้งค่าคำนำหน้าส่วนกลางเพื่อจัดเก็บ / อ่านไฟล์บนคอนเทนเนอร์ Azure Blob Storage ( ) (ค่าเริ่มต้น: ว่างเปล่า)
name= : ระบุชื่อของรายการที่จะใช้ (ค่าเริ่มต้น: buildkit )

สามารถระบุชื่อรายการได้หลายรายการพร้อมกัน โดยคั่นด้วย ; - กรณีการใช้งานมาตรฐานคือใช้ git sha1 เป็นชื่อ และใช้ชื่อสาขาซ้ำกัน และโหลดทั้งสองคำสั่งด้วยคำสั่ง import-cache 2 คำสั่ง

ignore-error= : ระบุว่าข้อผิดพลาดถูกละเว้นในกรณีที่การส่งออกแคชล้มเหลว (ค่าเริ่มต้น: false )

--import-cache :

type=azblob
prefix= : ตั้งค่าคำนำหน้าส่วนกลางเพื่อจัดเก็บ / อ่านไฟล์บนคอนเทนเนอร์ Azure Blob Storage ( ) (ค่าเริ่มต้น: ว่างเปล่า)
blobs_prefix= : ตั้งค่าคำนำหน้าส่วนกลางเพื่อจัดเก็บ / อ่าน blobs บนคอนเทนเนอร์ Azure Blob Storage ( ) (ค่าเริ่มต้น: blobs/ )
manifests_prefix= : ตั้งค่าคำนำหน้าส่วนกลางเพื่อจัดเก็บ / อ่านรายการบนคอนเทนเนอร์ Azure Blob Storage ( ) (ค่าเริ่มต้น: manifests/ )
name= : ชื่อของรายการที่จะใช้ (ค่าเริ่มต้น: buildkit )

การแฮชที่สม่ำเสมอ

หากคุณมีอินสแตนซ์ BuildKit daemon หลายอินสแตนซ์ แต่คุณไม่ต้องการใช้รีจิสทรีเพื่อแชร์แคชระหว่างคลัสเตอร์ ให้พิจารณาการปรับสมดุลโหลดฝั่งไคลเอ็นต์โดยใช้การแฮชที่สอดคล้องกัน

ดู . ./examples/kubernetes/consistenthash kubernetes/consistenthash

ข้อมูลเมตา

หากต้องการส่งออกข้อมูลเมตาของบิวด์ เช่น การย่อยรูปภาพ ให้ส่งแฟล็ก --metadata-file ข้อมูลเมตาจะถูกเขียนเป็นออบเจ็กต์ JSON ไปยังไฟล์ที่ระบุ ไดเร็กทอรีของไฟล์ที่ระบุต้องมีอยู่แล้วและสามารถเขียนได้

 buildctl build ... --metadata-ไฟล์ metadata.json

 เจคิว '.' เมตาดาต้า.json

 { "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "containerimage.descriptor": {"คำอธิบายประกอบ": { "config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", "org.opencontainers.image.created": "2022-02-08T21:28:03Z"}, "สรุป": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3", "mediaType": "application/vnd.oci.image.manifest.v1+json", "ขนาด": 506
  }, "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3"}

การเปิดใช้งานซ็อกเก็ต Systemd

บนระบบที่ใช้ Systemd คุณสามารถสื่อสารกับ daemon ผ่านการเปิดใช้งานซ็อกเก็ต Systemd โดยใช้ buildkitd --addr fd:// คุณสามารถดูตัวอย่างการใช้การเปิดใช้งานซ็อกเก็ต Systemd กับ BuildKit และ Systemd ได้ใน ./examples/systemd systemd

เปิดเผย BuildKit เป็นบริการ TCP

buildkitd daemon สามารถฟัง gRPC API บนซ็อกเก็ต TCP

ขอแนะนำอย่างยิ่งให้สร้างใบรับรอง TLS สำหรับทั้ง daemon และไคลเอนต์ (mTLS) การเปิดใช้งาน TCP โดยไม่มี mTLS เป็นสิ่งที่อันตราย เนื่องจากคอนเทนเนอร์ของตัวดำเนินการ (หรือที่เรียกว่าคอนเทนเนอร์ Dockerfile RUN ) สามารถเรียกใช้ BuildKit API ได้เช่นกัน

 buildkitd
   --addr tcp://0.0.0.0:1234
   --tlscacert /path/to/ca.pem
   --tlscert /path/to/cert.pem
   --tlskey /path/to/key.pem

 buildctl
   --addr tcp://example.com:1234
   --tlscacert /path/to/ca.pem
   --tlscert /path/to/clientcert.pem
   --tlskey /path/to/clientkey.pem
   สร้าง ...

โหลดบาลานซ์

buildctl build สามารถเรียกใช้กับ buildkitd daemons ที่สมดุลโหลดแบบสุ่ม

ดูเพิ่มเติมที่การแฮชที่สอดคล้องกันสำหรับการทำโหลดบาลานซ์ฝั่งไคลเอ็นต์

การจัดคอนเทนเนอร์ BuildKit

BuildKit ยังสามารถใช้งานได้โดยการรัน buildkitd daemon ภายในคอนเทนเนอร์ Docker และเข้าถึงจากระยะไกล

เราจัดเตรียมอิมเมจคอนเทนเนอร์เป็น moby/buildkit :

moby/buildkit:latest : สร้างจากรีลีสปกติล่าสุด
moby/buildkit:rootless : เหมือนกับ latest แต่ทำงานในฐานะผู้ใช้ที่ไม่มีสิทธิพิเศษ ดูที่ docs/rootless.md
moby/buildkit:master : สร้างจากสาขาหลัก
moby/buildkit:master-rootless : เหมือนกับ master แต่ทำงานในฐานะผู้ใช้ที่ไม่มีสิทธิ์ ดู docs/rootless.md

หากต้องการรัน daemon ในคอนเทนเนอร์:

 นักเทียบท่าวิ่ง -d --ชื่อ buildkitd --สิทธิพิเศษ moby/buildkit:latestexport BUILDKIT_HOST=docker-container://buildkitd
buildctl สร้าง --help

พ็อดแมน

หากต้องการเชื่อมต่อกับ BuildKit daemon ที่ทำงานอยู่ในคอนเทนเนอร์ Podman ให้ใช้ podman-container:// แทน docker-container://

 podman run -d --name buildkitd --สิทธิพิเศษ moby/buildkit:latest
buildctl --addr=podman-container://buildkitd build --frontend dockerfile.v0 --local context= --local dockerfile=. --ประเภทเอาท์พุท=oci | podman โหลด foo

sudo ไม่จำเป็น

Nerdctl

หากต้องการเชื่อมต่อกับ BuildKit daemon ที่ทำงานอยู่ในคอนเทนเนอร์ Nerdctl ให้ใช้ nerdctl-container:// แทน docker-container://

 nerdctl run -d --name buildkitd -- สิทธิพิเศษ moby/buildkit:latest
buildctl --addr=nerdctl-container://buildkitd build --frontend dockerfile.v0 --local context= --local dockerfile=. --ประเภทเอาท์พุท=oci | โหลดเนิร์ดซีทีล

sudo ไม่จำเป็น

คูเบอร์เนเตส

สำหรับการปรับใช้ Kubernetes โปรดดู examples/kubernetes

ไร้ภูต

หากต้องการรันไคลเอ็นต์และ daemon ชั่วคราวในคอนเทนเนอร์เดียว ("โหมด daemonless") ให้ทำดังนี้

 นักเทียบท่าวิ่ง
     -มัน
     --rm
     --สิทธิพิเศษ
     -v /path/to/dir:/tmp/work
     --จุดเข้าใช้งาน buildctl-daemonless.sh
     moby/buildkit:master
         สร้าง
         --ส่วนหน้า dockerfile.v0
         --บริบทท้องถิ่น=/tmp/work
         --local dockerfile=/tmp/work

หรือ

 นักเทียบท่าวิ่ง
     -มัน
     --rm
     --security-opt seccomp=ไม่ถูกจำกัด
     --security-opt apparmor=ไม่ถูกจำกัด
     -e BUILDKITD_FLAGS=--oci-worker-no-process-sandbox
     -v /path/to/dir:/tmp/work
     --จุดเข้าใช้งาน buildctl-daemonless.sh
     moby/buildkit:master-rootless
         สร้าง
         --ส่วนหน้า
         dockerfile.v0
         --บริบทท้องถิ่น=/tmp/work
         --local dockerfile=/tmp/work

การสนับสนุน OpenTelemetry

BuildKit รองรับ OpenTelemetry สำหรับคำสั่ง buildkitd gRPC API และ buildctl หากต้องการบันทึกการติดตามไปยัง Jaeger ให้ตั้งค่าตัวแปรสภาพแวดล้อม JAEGER_TRACE เป็นที่อยู่การรวบรวม

 docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latexport JAEGER_TRACE=0.0.0.0:6831# restart buildkitd และ buildctl เพื่อให้พวกเขารู้ว่า JAEGER_TRACE# คำสั่ง buildctl ใด ๆ ควรติดตามไปที่ http:/ /127.0.0.1:16686/

บน Windows หากคุณใช้งาน Jaeger นอกคอนเทนเนอร์ jaeger-all-in-one.exe ให้ตั้งค่าตัวแปรสภาพแวดล้อม setx -m JAEGER_TRACE "0.0.0.0:6831" รีสตาร์ท buildkitd ในเทอร์มินัลใหม่และการติดตามจะเป็น รวบรวมโดยอัตโนมัติ

การรัน BuildKit โดยไม่มีสิทธิ์รูท

โปรดดู docs/rootless.md

การสร้างภาพหลายแพลตฟอร์ม

โปรดดูที่ docs/multi-platform.md

การกำหนดค่า `buildctl`

การควบคุมเอาต์พุตสี

buildctl รองรับการแก้ไขสีที่ใช้ในการส่งข้อมูลไปยังเทอร์มินัล คุณสามารถตั้งค่าตัวแปรสภาพแวดล้อม BUILDKIT_COLORS ให้เป็น run=green:warning=yellow:error=red:cancel=255,165,0 เพื่อตั้งค่าสีที่คุณต้องการใช้ การตั้งค่า NO_COLOR เป็นอะไรก็ได้จะปิดใช้เอาต์พุตที่มีสีตามที่แนะนำโดย no-color.org

ข้อผิดพลาดในการแยกวิเคราะห์จะถูกรายงานแต่จะไม่สนใจ ซึ่งจะส่งผลให้มีการใช้ค่าสีเริ่มต้นตามที่จำเป็น

รายการสีที่กำหนดไว้ล่วงหน้า

จำนวนบรรทัดบันทึก (สำหรับขั้นตอนที่แอ็คทีฟในโหมด tty)

คุณสามารถเปลี่ยนจำนวนบรรทัดบันทึกที่มองเห็นได้สำหรับขั้นตอนที่ใช้งานอยู่ในโหมด tty โดยการตั้งค่า BUILDKIT_TTY_LOG_LINES เป็นตัวเลข (ค่าเริ่มต้น: 6)

มีส่วนร่วม

ต้องการมีส่วนร่วมใน BuildKit หรือไม่? สุดยอด! คุณสามารถค้นหาข้อมูลเกี่ยวกับการมีส่วนร่วมในโครงการนี้ได้ใน CONTRIBUTING.md

ขยาย

ข้อมูลเพิ่มเติม

เวอร์ชัน 0.17.0
ประเภท ซอร์สโค้ดอื่น ๆ
เวลาอัปเดต 2024-11-05
ขนาด
ภาษา ภาษาจีนตัวย่อ

แอปที่เกี่ยวข้อง

แนะนำสำหรับคุณ

ข้อมูลที่เกี่ยวข้อง ทั้งหมด

ความคิดเห็นจากผู้ใช้

ชุดอุปกรณ์สร้าง

บิวด์คิท

ใช้โดย

เริ่มต้นอย่างรวดเร็ว

การตั้งค่าลินุกซ์

การตั้งค่าวินโดวส์

การตั้งค่า macOS

สร้างจากแหล่งที่มา

สำรวจ LLB

สำรวจ Dockerfiles

การสร้าง Dockerfile ด้วย buildctl

การสร้าง Dockerfile โดยใช้ส่วนหน้าภายนอก

เอาท์พุต

รูปภาพ/รีจิสทรี

ไดเรกทอรีท้องถิ่น

ด็อกเกอร์ทาร์บอล

โอซีไอ ทาร์บอล

ที่เก็บรูปภาพคอนเทนเนอร์

แคช

เก็บขยะ

ส่งออกแคช

อินไลน์ (พุชรูปภาพและแคชพร้อมกัน)

Registry (พุชอิมเมจและแคชแยกกัน)

ไดเรกทอรีท้องถิ่น

แคชการดำเนินการ GitHub (ทดลอง)

แคช S3 (ทดลอง)

แคช Azure Blob Storage (ทดลอง)

การแฮชที่สม่ำเสมอ

ข้อมูลเมตา

การเปิดใช้งานซ็อกเก็ต Systemd

เปิดเผย BuildKit เป็นบริการ TCP

โหลดบาลานซ์

การจัดคอนเทนเนอร์ BuildKit

พ็อดแมน

Nerdctl

คูเบอร์เนเตส

ไร้ภูต

การสนับสนุน OpenTelemetry

การรัน BuildKit โดยไม่มีสิทธิ์รูท

การสร้างภาพหลายแพลตฟอร์ม

การกำหนดค่า buildctl

การควบคุมเอาต์พุตสี

จำนวนบรรทัดบันทึก (สำหรับขั้นตอนที่แอ็คทีฟในโหมด tty)

มีส่วนร่วม

การสร้าง Dockerfile ด้วย `buildctl`

การกำหนดค่า `buildctl`