ผู้ชาย
v1.23.2
ต้องเป็นไปตามเงื่อนไขต่อไปนี้:
การค้นหาเครื่องมืออัตโนมัติที่ตรงกับความต้องการของคุณที่สุดขึ้นอยู่กับคุณ เราขอแนะนำให้ใช้ระบบ CI/CD ที่ทันสมัย เช่น เวิร์กโฟลว์ GitHub หรือ GitLab CI ในขณะที่เรา (ผู้เขียน) บังเอิญใช้ GitLab CI ตัวอย่างต่อไปนี้ได้รับการปรับแต่งให้เหมาะกับแพลตฟอร์มเฉพาะนี้ แต่หลักการพื้นฐานควรนำไปใช้กับที่อื่น และตัวอย่างจะถูกเก็บไว้อย่างเรียบง่ายเพียงพอ ดังนั้นคุณจึงสามารถปฏิบัติตามได้ แม้ว่าจะไม่มีก็ตาม ประสบการณ์ก่อนหน้านี้กับแพลตฟอร์มเฉพาะนี้ หากมีข้อสงสัย โปรดไปที่หน้าอ้างอิง gitlab-ci.yml เพื่อดูภาพรวมที่ครอบคลุมของคีย์เวิร์ด GitLab CI
gitlab-ci.yml:
# define a job for building the containers
build-container :
stage : container-build
# run parallel builds for the desired architectures
parallel :
matrix :
- ARCH : amd64
- ARCH : arm64
tags :
# run each build on a suitable, preconfigured runner (must match the target architecture)
- runner-${ARCH}
image :
name : gcr.io/kaniko-project/executor:debug
entrypoint : [""]
script :
# build the container image for the current arch using kaniko
- >-
/kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile
"${CI_PROJECT_DIR}/Dockerfile" # push the image to the GitLab container
registry, add the current arch as tag. --destination
"${CI_REGISTRY_IMAGE}:${ARCH}" gitlab-ci.yml:
# define a job for creating and pushing a merged manifest
merge-manifests :
stage : container-build
# all containers must be build before merging them
# alternatively the job may be configured to run in a later stage
needs :
- job : container-build
artifacts : false
tags :
# may run on any architecture supported by manifest-tool image
- runner-xyz
image :
name : mplatform/manifest-tool:alpine
entrypoint : [""]
script :
- >-
manifest-tool # authorize against your container registry
--username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} push
from-args # define the architectures you want to merge --platforms
linux/amd64,linux/arm64 # "ARCH" will be automatically replaced by
manifest-tool # with the appropriate arch from the platform definitions
--template ${CI_REGISTRY_IMAGE}:ARCH # The name of the final, combined
image which will be pushed to your registry --target ${CI_REGISTRY_IMAGE} เพื่อความเรียบง่าย เราจงใจละเว้นจากการใช้รูปภาพที่แท็กตามเวอร์ชัน (บิวด์ทั้งหมดจะถูกแท็กเป็น "ล่าสุด") ในตัวอย่างก่อนหน้านี้ เนื่องจากเรารู้สึกว่าสิ่งนี้จะเพิ่มโค้ดเฉพาะแพลตฟอร์มและเวิร์กโฟลว์จำนวนมาก
อย่างไรก็ตาม สำหรับทุกคนที่สนใจวิธีที่เราจัดการการกำหนดเวอร์ชัน (ไดนามิก) ใน GitLab ต่อไปนี้เป็นบทสรุปสั้นๆ:
CI_COMMIT_TAG ที่กำหนดไว้ล่วงหน้าของ GitLab เมื่อเรียกใช้ไปป์ไลน์แท็กneeds ของงานสร้างและผสานตามลำดับ) ซึ่งจะตั้งค่าแท็กเป็น latest เมื่อทำงานบนสาขาเริ่มต้น ไปยังคอมมิตแฮชเมื่อรันบนแบรนช์อื่น และไปที่แท็ก release เมื่อรันบนไปป์ไลน์ของแท็กgitlab-ci.yml:
container-get-tag :
stage : pre-container-build-stage
tags :
- runner-xyz
image : busybox
script :
# All other branches are tagged with the currently built commit SHA hash
- |
# If pipeline runs on the default branch: Set tag to "latest"
if test "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH"; then
tag="latest"
# If pipeline is a tag pipeline, set tag to the git commit tag
elif test -n "$CI_COMMIT_TAG"; then
tag="$CI_COMMIT_TAG"
# Else set the tag to the git commit sha
else
tag="$CI_COMMIT_SHA"
fi
- echo "tag=$tag" > build.env
# parse tag to the build and merge jobs.
# See: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
artifacts :
reports :
dotenv : build.env เครื่องมือที่คล้ายกันได้แก่:
เครื่องมือทั้งหมดเหล่านี้สร้างอิมเมจคอนเทนเนอร์ด้วยแนวทางที่แตกต่างกัน
BuildKit (และ img ) สามารถทำหน้าที่เป็นผู้ใช้ที่ไม่ใช่รูทจากภายในคอนเทนเนอร์ได้ แต่ต้องปิดการใช้งาน seccomp และ AppArmor เพื่อสร้างคอนเทนเนอร์ที่ซ้อนกัน kaniko ไม่ได้สร้างคอนเทนเนอร์ที่ซ้อนกัน ดังนั้นจึงไม่จำเป็นต้องปิดใช้งาน seccomp และ AppArmor BuildKit รองรับคอนเทนเนอร์แบบหลายโค้ง "แบบข้ามอาคาร" โดยใช้ประโยชน์จาก QEMU
orca-build ขึ้นอยู่กับ runc เพื่อสร้างอิมเมจจาก Dockerfiles ซึ่งไม่สามารถทำงานภายในคอนเทนเนอร์ได้ (ด้วยเหตุผลที่คล้ายกันกับ img ด้านบน) kaniko ไม่ได้ใช้ runc ดังนั้นจึงไม่จำเป็นต้องใช้เทคนิคการกำหนดเนมสเปซเคอร์เนล อย่างไรก็ตาม orca-build ไม่ต้องการ Docker หรือ daemon ที่มีสิทธิ์พิเศษใดๆ (ดังนั้นการสร้างจึงสามารถทำได้ทั้งหมดโดยไม่มีสิทธิ์)
umoci ทำงานโดยไม่มีสิทธิ์ใด ๆ และยังไม่มีข้อจำกัดเกี่ยวกับระบบไฟล์รูทที่กำลังแตกออกมา (แม้ว่าจะต้องมีการจัดการเพิ่มเติมหากระบบไฟล์ของคุณซับซ้อนเพียงพอ) อย่างไรก็ตาม ไม่มีเครื่องมือสร้างที่เหมือน Dockerfile (เป็นเครื่องมือระดับต่ำกว่าเล็กน้อยที่สามารถใช้สร้างเครื่องมือสร้างดังกล่าวได้ เช่น orca-build )
Buildah เชี่ยวชาญในการสร้างอิมเมจ OCI คำสั่งของ Buildah จะจำลองคำสั่งทั้งหมดที่พบใน Dockerfile ซึ่งช่วยให้สามารถสร้างอิมเมจที่มีและไม่มี Dockerfiles โดยที่ไม่ต้องการสิทธิ์รูทใดๆ เป้าหมายสูงสุดของ Buildah คือการจัดหาอินเทอร์เฟซ coreutils ระดับล่างเพื่อสร้างอิมเมจ ความยืดหยุ่นในการสร้างอิมเมจโดยไม่ต้องใช้ Dockerfiles ทำให้สามารถรวมภาษาสคริปต์อื่นๆ เข้ากับกระบวนการสร้างได้ Buildah ดำเนินตามโมเดล fork-exec ธรรมดา และไม่ได้ทำงานเป็น daemon แต่ใช้ API ที่ครอบคลุมใน golang ซึ่งสามารถขายให้กับเครื่องมืออื่นๆ ได้
FTL และ Bazel มุ่งหวังที่จะสร้างภาพ Docker สำหรับชุดย่อยของภาพให้เร็วที่สุด สิ่งเหล่านี้ถือได้ว่าเป็น "เส้นทางด่วน" กรณีพิเศษที่สามารถใช้ร่วมกับการสนับสนุนสำหรับ Dockerfiles ทั่วไปที่ kaniko มอบให้
ผู้ใช้ kaniko ในกลุ่ม Google
หากต้องการสนับสนุน kaniko โปรดดู DEVELOPMENT.md และ CONTRIBUTING.md
เมื่อถ่ายภาพสแนปชอต อัลกอริธึมการแฮชของ kaniko จะรวม (หรือในกรณีของ --snapshot-mode=time ให้ใช้เฉพาะ mtime ) ของไฟล์เพื่อพิจารณาว่าไฟล์มีการเปลี่ยนแปลงหรือไม่ ขออภัย มีความล่าช้าระหว่างเวลาที่ทำการเปลี่ยนแปลงกับไฟล์และเวลาที่อัปเด mtime ซึ่งหมายความว่า:
--snapshot-mode=time ) kaniko อาจพลาดการเปลี่ยนแปลงที่แนะนำโดยคำสั่ง RUN โดยสิ้นเชิง--snapshot-mode=full ) ไม่ว่า kaniko จะเพิ่มเลเยอร์หรือไม่ในกรณีที่คำสั่ง RUN แก้ไขไฟล์ แต่เนื้อหาไม่ เปลี่ยนแปลงตามทฤษฎีแล้วไม่สามารถกำหนดได้ สิ่งนี้ ไม่ส่งผลกระทบต่อเนื้อหา ที่จะยังคงถูกต้อง แต่จะส่งผลต่อจำนวนเลเยอร์โปรดทราบว่าขณะนี้ปัญหาเหล่านี้เป็นเพียงปัญหาทางทฤษฎีเท่านั้น หากคุณเห็นว่าปัญหานี้เกิดขึ้น โปรดเปิดปัญหา
--chown support ปัจจุบัน Kaniko รองรับคำสั่ง COPY --chown และ ADD --chown Dockerfile มันไม่รองรับ RUN --chown
