ดาวน์โหลด kaniko - ดาวน์โหลด kaniko ซอร์สโค้ด

kaniko

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

v1.23.2

ดาวน์โหลด

kaniko - สร้างรูปภาพใน Kubernetes

หมายเหตุ: kaniko ไม่ใช่ผลิตภัณฑ์ Google ที่ได้รับการสนับสนุนอย่างเป็นทางการ

ข้อจำกัดและข้อผิดพลาด

ต้องเป็นไปตามเงื่อนไขต่อไปนี้:

คุณต้องเข้าถึง build-machines ที่ใช้สถาปัตยกรรมที่ต้องการ (การรัน Kaniko ในโปรแกรมจำลอง เช่น QEMU ก็ควรจะเป็นไปได้เช่นกัน แต่อยู่นอกเหนือขอบเขตของเอกสารนี้) นี่คือสิ่งที่ควรคำนึงถึงเมื่อใช้เครื่องมือสร้าง SaaS เช่น github.com หรือ gitlab.com ซึ่งในขณะที่เขียนนี้ไม่รองรับ SaaS runner ที่ไม่ใช่ x86_64 ใดๆ (GitHub, GitLab) ดังนั้นควรเตรียมนำเครื่องมือของคุณเองมาเอง เครื่องจักร (GitHub, GitLab.
Kaniko จะต้องสามารถทำงานบนสถาปัตยกรรมที่ต้องการได้ ในขณะที่เขียน คอนเทนเนอร์ Kaniko อย่างเป็นทางการรองรับ linux/amd64, linux/arm64, linux/s390x และ linux/ppc64le (ไม่ใช่ใน *-debug image)
รีจิสทรีคอนเทนเนอร์ที่คุณเลือกจะต้องเข้ากันได้กับ OCIv1 หรือ Docker v2.2

ตัวอย่างไปป์ไลน์ CI (GitLab)

การค้นหาเครื่องมืออัตโนมัติที่ตรงกับความต้องการของคุณที่สุดขึ้นอยู่กับคุณ เราขอแนะนำให้ใช้ระบบ CI/CD ที่ทันสมัย เช่น เวิร์กโฟลว์ GitHub หรือ GitLab CI ในขณะที่เรา (ผู้เขียน) บังเอิญใช้ GitLab CI ตัวอย่างต่อไปนี้ได้รับการปรับแต่งให้เหมาะกับแพลตฟอร์มเฉพาะนี้ แต่หลักการพื้นฐานควรนำไปใช้กับที่อื่น และตัวอย่างจะถูกเก็บไว้อย่างเรียบง่ายเพียงพอ ดังนั้นคุณจึงสามารถปฏิบัติตามได้ แม้ว่าจะไม่มีก็ตาม ประสบการณ์ก่อนหน้านี้กับแพลตฟอร์มเฉพาะนี้ หากมีข้อสงสัย โปรดไปที่หน้าอ้างอิง gitlab-ci.yml เพื่อดูภาพรวมที่ครอบคลุมของคีย์เวิร์ด GitLab CI

การสร้างอิมเมจคอนเทนเนอร์แยกกัน

gitlab-ci.yml:

 # กำหนดงานสร้างคอนเทนเนอร์ build-container: stage: container-build
  # รันการสร้างแบบขนานสำหรับสถาปัตยกรรมที่ต้องการ
  ขนาน:เมทริกซ์:
      - ARCH: amd64 - ARCH: arm64
  แท็ก:# รันแต่ละบิลด์บนรันเนอร์ที่เหมาะสมและกำหนดค่าไว้ล่วงหน้า (ต้องตรงกับสถาปัตยกรรมเป้าหมาย)- รันเนอร์-${ARCH}
  รูปภาพ: ชื่อ: gcr.io/kaniko-project/executor:debugentrypoint: [""]
  script:# สร้างคอนเทนเนอร์อิมเมจสำหรับส่วนโค้งปัจจุบันโดยใช้ kaniko- >- /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" # ผลักรูปภาพไปที่รีจิสตรีคอนเทนเนอร์ GitLab เพิ่มส่วนโค้งปัจจุบันเป็นแท็ก --ปลายทาง "${CI_REGISTRY_IMAGE}:${ARCH}"

การรวมรายการคอนเทนเนอร์

gitlab-ci.yml:

 # กำหนดงานสำหรับการสร้างและผลักดัน manifestmerge-manifests ที่ผสาน: stage: container-build
  # ต้องสร้างคอนเทนเนอร์ทั้งหมดก่อนที่จะรวมเข้าด้วยกัน
  # หรืออีกทางหนึ่งงานอาจถูกกำหนดค่าให้ทำงานในระยะต่อมา
  ความต้องการ:
    - งาน: สิ่งประดิษฐ์ที่สร้างคอนเทนเนอร์: เท็จ
  tags:# อาจทำงานบนสถาปัตยกรรมใด ๆ ที่รองรับโดย manifest-tool image- runner-xyz
  ภาพ: ชื่อ: mplatform/manifest-tool:alpineentrypoint: [""]
  สคริปต์:
    - >- manifest-tool # อนุญาตกับรีจิสตรีคอนเทนเนอร์ของคุณ --username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} push from-args # กำหนดสถาปัตยกรรมที่คุณต้องการผสาน --platforms linux/amd64,linux/arm64 # "ARCH" จะถูกแทนที่ด้วย manifest-tool # โดยอัตโนมัติ พร้อมด้วยส่วนโค้งที่เหมาะสมจากคำจำกัดความของแพลตฟอร์ม --template ${CI_REGISTRY_IMAGE}:ARCH # ชื่อของรูปภาพรวมสุดท้ายที่จะถูกส่งไปยังรีจิสทรีของคุณ --target ${CI_REGISTRY_IMAGE}

ในหมายเหตุของการเพิ่มแท็กเวอร์ชัน

เพื่อความเรียบง่าย เราจงใจละเว้นจากการใช้รูปภาพที่แท็กตามเวอร์ชัน (บิวด์ทั้งหมดจะถูกแท็กเป็น "ล่าสุด") ในตัวอย่างก่อนหน้านี้ เนื่องจากเรารู้สึกว่าสิ่งนี้จะเพิ่มโค้ดเฉพาะแพลตฟอร์มและเวิร์กโฟลว์จำนวนมาก

อย่างไรก็ตาม สำหรับทุกคนที่สนใจวิธีที่เราจัดการการกำหนดเวอร์ชัน (ไดนามิก) ใน GitLab ต่อไปนี้เป็นบทสรุปสั้นๆ:

หากคุณสนใจเฉพาะการสร้างการเผยแพร่แท็ก คุณสามารถใช้ตัวแปร CI_COMMIT_TAG ที่กำหนดไว้ล่วงหน้าของ GitLab เมื่อเรียกใช้ไปป์ไลน์แท็ก
เมื่อคุณ (เช่นเรา) ต้องการสร้างคอนเทนเนอร์อิมเมจเพิ่มเติมนอกเหนือจากรุ่นเผยแพร่ สิ่งต่างๆ จะยุ่งวุ่นวายมากขึ้นเล็กน้อย ในกรณีของเรา เราได้เพิ่มงานเพิ่มเติมที่ทำงานก่อนงานสร้างและผสาน (อย่าลืมขยายส่วน needs ของงานสร้างและผสานตามลำดับ) ซึ่งจะตั้งค่าแท็กเป็น latest เมื่อทำงานบนสาขาเริ่มต้น ไปยังคอมมิตแฮชเมื่อรันบนแบรนช์อื่น และไปที่แท็ก release เมื่อรันบนไปป์ไลน์ของแท็ก

gitlab-ci.yml:

 Container-get-tag: stage: pre-container-build-stage
  แท็ก:
    - รันเนอร์-xyz
  ภาพ : busybox
  script:# สาขาอื่นๆ ทั้งหมดถูกแท็กด้วย SHA hash- | ที่สร้างขึ้นในปัจจุบัน      # หากไปป์ไลน์ทำงานบนสาขาเริ่มต้น: ตั้งค่าแท็กเป็น "ล่าสุด" หากทดสอบ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH"; จากนั้น tag="latest" # หากไปป์ไลน์เป็นไปป์ไลน์ของแท็ก ให้ตั้งค่าแท็กเป็น git commit tag elif test -n "$CI_COMMIT_TAG"; จากนั้น tag="$CI_COMMIT_TAG" # Else ตั้งค่าแท็กเป็น git commit sha else tag="$CI_COMMIT_SHA" fi - echo "tag=$tag" > build.env
  # แยกแท็กสำหรับงานสร้างและผสาน
  # ดู: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
  สิ่งประดิษฐ์: รายงาน: 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 แก้ไขไฟล์ แต่เนื้อหาไม่ เปลี่ยนแปลงตามทฤษฎีแล้วไม่สามารถกำหนดได้ สิ่งนี้ ไม่ส่งผลกระทบต่อเนื้อหา ที่จะยังคงถูกต้อง แต่จะส่งผลต่อจำนวนเลเยอร์

โปรดทราบว่าขณะนี้ปัญหาเหล่านี้เป็นเพียงปัญหาทางทฤษฎีเท่านั้น หากคุณเห็นว่าปัญหานี้เกิดขึ้น โปรดเปิดปัญหา