kaniko

kaniko - Membangun Gambar Di Kubernetes

CATATAN: kaniko bukan produk Google yang didukung secara resmi

Keterbatasan dan Kesalahan

Kondisi berikut harus dipenuhi:

1. Anda memerlukan akses ke mesin build yang menjalankan arsitektur yang diinginkan (menjalankan Kaniko di emulator, misalnya QEMU juga dapat dilakukan tetapi melampaui cakupan dokumentasi ini). Ini adalah sesuatu yang perlu diingat ketika menggunakan alat pembuatan SaaS seperti github.com atau gitlab.com, yang pada saat penulisan ini tidak mendukung pelari SaaS non-x86_64 (GitHub, GitLab), jadi bersiaplah untuk membawa milik Anda sendiri mesin (GitHub,GitLab.

2. Kaniko harus dapat berjalan pada arsitektur yang diinginkan. Pada saat penulisan, container resmi Kaniko mendukung linux/amd64, linux/arm64, linux/s390x dan linux/ppc64le (bukan pada gambar *-debug).

3. Registri kontainer pilihan Anda harus kompatibel dengan OCIv1 atau Docker v2.2.

Contoh Pipa CI (GitLab)

Terserah Anda untuk menemukan alat otomatisasi yang paling sesuai dengan kebutuhan Anda. Kami merekomendasikan penggunaan sistem CI/CD modern seperti alur kerja GitHub atau GitLab CI. Karena kami (penulis) menggunakan GitLab CI, contoh berikut disesuaikan dengan platform khusus ini, namun prinsip dasarnya harus berlaku di mana pun dan contoh dibuat cukup sederhana, sehingga Anda dapat mengikutinya, bahkan tanpa perlu menggunakan GitLab CI. pengalaman sebelumnya dengan platform khusus ini. Jika ragu, kunjungi halaman referensi gitlab-ci.yml untuk gambaran menyeluruh tentang kata kunci GitLab CI.

Membangun Gambar Kontainer Terpisah

gitlab-ci.yml:

 # tentukan pekerjaan untuk membangun containerbuild-container: stage: container-build
  # menjalankan pembangunan paralel untuk arsitektur yang diinginkan
  paralel:matriks:
      - LENGAN: amd64 - LENGAN: arm64
  tag:# jalankan setiap build pada runner yang sesuai dan telah dikonfigurasi sebelumnya (harus cocok dengan arsitektur target)- runner-${ARCH}
  gambar:nama: gcr.io/kaniko-project/executor:debugentrypoint: [""]
  skrip:# buat gambar kontainer untuk lengkungan saat ini menggunakan kaniko- >- /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" # dorong gambar ke registri kontainer GitLab, tambahkan lengkungan saat ini sebagai tag. --tujuan "${CI_REGISTRY_IMAGE}:${ARCH}"

Menggabungkan Manifes Kontainer

gitlab-ci.yml:

 # tentukan tugas untuk membuat dan mendorong gabungan manifestmerge-manifests: stage: container-build
  # semua container harus dibuat sebelum digabungkan
  # alternatifnya, pekerjaan dapat dikonfigurasi untuk dijalankan pada tahap berikutnya
  kebutuhan:
    - pekerjaan: artefak pembuatan kontainer: salah
  tag:# dapat berjalan pada arsitektur apa pun yang didukung oleh alat manifes image- runner-xyz
  gambar:nama: mplatform/manifest-tool:alpineentrypoint: [""]
  naskah:
    - >- manifest-tool # otorisasi terhadap registri kontainer Anda --username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} push from-args # tentukan arsitektur yang ingin Anda gabungkan --platforms linux/amd64,linux/arm64 # "ARCH" akan secara otomatis digantikan oleh alat manifes # dengan lengkungan yang sesuai dari definisi platform --template ${CI_REGISTRY_IMAGE}:ARCH # Nama gambar gabungan akhir yang akan dimasukkan ke registri Anda --target ${CI_REGISTRY_IMAGE}

Pada Catatan Menambahkan Tag Berversi

Demi kesederhanaan, kami sengaja menahan diri untuk tidak menggunakan gambar berversi yang diberi tag (semua build akan diberi tag sebagai "terbaru") pada contoh sebelumnya, karena kami merasa ini menambah banyak kode khusus platform dan alur kerja.

Namun demikian, bagi siapa pun yang tertarik dengan cara kami menangani pembuatan versi (dinamis) di GitLab, berikut adalah ikhtisar singkatnya:

• Jika Anda hanya tertarik untuk membuat rilis yang diberi tag, Anda cukup menggunakan variabel CI_COMMIT_TAG yang telah ditentukan sebelumnya di GitLab saat menjalankan saluran tag.

• Saat Anda (seperti kami) ingin membuat image container tambahan di luar rilis, segalanya menjadi sedikit lebih berantakan. Dalam kasus kami, kami menambahkan pekerjaan tambahan yang berjalan sebelum pekerjaan membangun dan menggabungkan (jangan lupa untuk memperluas bagian needs dari pekerjaan membangun dan menggabungkan sesuai), yang akan mengatur tag ke latest ketika dijalankan pada cabang default, ke hash penerapan saat dijalankan di cabang lain dan ke tag rilis saat dijalankan di saluran tag.

gitlab-ci.yml:

 tag-penampung-dapatkan: tahap: tahap pra-pembangunan-kontainer
  tag:
    - pelari-xyz
  gambar: kotak sibuk
  skrip:# Semua cabang lainnya ditandai dengan hash SHA komit yang sedang dibangun- |      # Jika pipa berjalan pada cabang default: Setel tag ke "terbaru" if test "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH"; lalu tag="terbaru" # Jika pipa adalah pipa tag, setel tag ke tag git commit elif test -n "$CI_COMMIT_TAG"; lalu tag="$CI_COMMIT_TAG" # Else setel tag ke git commit sha else tag="$CI_COMMIT_SHA" fi - echo "tag=$tag" > build.env
  # parse tag ke pekerjaan pembuatan dan penggabungan.
  # Lihat: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
  artefak:laporan: dotenv: build.env

Perbandingan dengan Alat Lain

Alat serupa meliputi:

• MembangunKit

• gambar

• pembangunan orca

• umoci

• membangunah

• FTL

• Aturan Bazel_docker

Semua alat ini membuat gambar container dengan pendekatan berbeda.

BuildKit (dan img ) dapat berfungsi sebagai pengguna non-root dari dalam container tetapi memerlukan seccomp dan AppArmor dinonaktifkan untuk membuat container bersarang. kaniko sebenarnya tidak membuat container bersarang, sehingga tidak memerlukan seccomp dan AppArmor untuk dinonaktifkan. BuildKit mendukung kontainer multi-lengkungan "cross-building" dengan memanfaatkan QEMU.

orca-build bergantung pada runc untuk membuat image dari Dockerfiles, yang tidak dapat dijalankan di dalam container (untuk alasan yang mirip dengan img di atas). kaniko tidak menggunakan runc sehingga tidak memerlukan penggunaan teknik namespace kernel. Namun, orca-build tidak memerlukan Docker atau daemon dengan hak istimewa apa pun (sehingga pembangunan dapat dilakukan seluruhnya tanpa hak istimewa).

umoci bekerja tanpa hak istimewa apa pun, dan juga tidak memiliki batasan pada sistem file root yang sedang diekstraksi (meskipun memerlukan penanganan tambahan jika sistem file Anda cukup rumit). Namun, ia tidak memiliki perkakas build seperti Dockerfile (ini adalah alat dengan tingkat yang sedikit lebih rendah yang dapat digunakan untuk membangun pembuat tersebut -- seperti orca-build ).

Buildah berspesialisasi dalam membangun citra OCI. Perintah Buildah mereplikasi semua perintah yang ditemukan di Dockerfile. Hal ini memungkinkan pembuatan image dengan dan tanpa Dockerfiles tanpa memerlukan hak akses root apa pun. Tujuan utama Buildah adalah menyediakan antarmuka coreutils tingkat rendah untuk membuat gambar. Fleksibilitas pembuatan image tanpa Dockerfiles memungkinkan integrasi bahasa skrip lain ke dalam proses pembuatan. Buildah mengikuti model fork-exec sederhana dan tidak dijalankan sebagai daemon tetapi didasarkan pada API komprehensif di golang, yang dapat dijual ke alat lain.

FTL dan Bazel bertujuan untuk mencapai pembuatan image Docker secepat mungkin untuk subset image. Ini dapat dianggap sebagai "jalur cepat" kasus khusus yang dapat digunakan bersama dengan dukungan untuk Dockerfiles umum yang disediakan kaniko.

Masyarakat

grup Google pengguna kaniko

Untuk Berkontribusi pada kaniko, lihat DEVELOPMENT.md dan CONTRIBUTING.md.

Keterbatasan

mtime dan snapshotting

Saat mengambil snapshot, algoritme hashing kaniko menyertakan (atau dalam kasus --snapshot-mode=time , hanya gunakan) mtime file untuk menentukan apakah file telah berubah. Sayangnya, ada penundaan antara saat perubahan pada file dilakukan dan saat mtime diperbarui. Artinya:

• Dengan mode snapshot waktu saja ( --snapshot-mode=time ), kaniko mungkin melewatkan seluruh perubahan yang diperkenalkan oleh perintah RUN .

• Dengan mode snapshot default ( --snapshot-mode=full ), apakah kaniko akan menambahkan lapisan atau tidak jika perintah RUN memodifikasi file tetapi isinya tidak berubah secara teoritis non-deterministik. Hal ini tidak mempengaruhi isi yang masih benar, namun mempengaruhi jumlah lapisan.

Perlu dicatat bahwa isu-isu tersebut saat ini hanya bersifat teoritis. Jika Anda melihat masalah ini terjadi, silakan buka masalah tersebut.

Perintah Dockerfile --chown dukungan

Kaniko saat ini mendukung perintah COPY --chown dan ADD --chown Dockerfile. Itu tidak mendukung RUN --chown .

Referensi

• Kaniko - Membangun Gambar Kontainer Di Kubernetes Tanpa Docker.