Menggunakan cache Kaniko

Ringkasan

Kaniko meng-cache artefak build container dengan menyimpan dan mengindeks lapisan menengah dalam registry image container, seperti Artifact Registry Google sendiri. Untuk mempelajari kasus penggunaan lainnya, lihat repositori Kaniko di GitHub.

Cache Kaniko berfungsi sebagai berikut:

  • Cloud Build mengupload lapisan image container langsung ke registry saat di-build sehingga tidak ada langkah push yang eksplisit. Jika semua lapisan berhasil dibuat, manifes gambar yang berisi lapisan tersebut akan ditulis ke registry.

  • Kaniko men-cache setiap lapisan sesuai dengan konten perintah Dockerfile yang membuatnya, beserta semua perintah yang mendahuluinya, hingga ringkasan gambar di baris FROM.

Mengaktifkan cache Kaniko di build Anda

Anda dapat mengaktifkan cache Kaniko di build Docker dengan mengganti pekerja cloud-builders/docker dengan pekerja kaniko-project/executor di file cloudbuild.yaml sebagai berikut:

Build Kaniko 

steps:
- name: 'gcr.io/kaniko-project/executor:latest'
  args:
  - --destination=${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}
  - --cache=true
  - --cache-ttl=XXh

Build Docker 

steps:
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', '${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}', '.']
images:
- '${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}'

dengan:

  • --destination=${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE} adalah image container target. Cloud Build secara otomatis mengganti PROJECT_ID dari project yang berisi Dockerfile. LOCATION, REPOSITORY, dan IMAGE adalah substitusi yang ditentukan pengguna.
  • LOCATION adalah lokasi regional atau multi-regional repositori tempat gambar disimpan, misalnya us-east1.
  • REPOSITORY adalah nama repositori tempat gambar disimpan.
  • IMAGE adalah nama gambar.
  • --cache=true mengaktifkan cache Kaniko.
  • --cache-ttl=XXh menetapkan waktu habis masa berlaku cache, dengan XX adalah jam hingga masa berlaku cache berakhir. Lihat Mengonfigurasi waktu habis masa berlaku cache.

Jika menjalankan build menggunakan perintah gcloud builds submit --tag [IMAGE], Anda dapat mengaktifkan cache Kaniko dengan menetapkan properti builds/use_kaniko ke True seperti yang ditunjukkan di bawah ini:

gcloud config set builds/use_kaniko True

Contoh: Menggunakan cache Kaniko di build Node.js

Contoh ini menunjukkan cara menjalankan build inkremental untuk aplikasi Node.js menggunakan praktik terbaik Dockerfile umum. Praktik di sini berlaku untuk build dalam semua bahasa lain yang didukung.

Di sini, Anda memindahkan perintah yang tidak mungkin berubah di antara build ke bagian atas Dockerfile, dan memindahkan perintah yang mungkin akan berubah ke bagian bawah. Hal ini membuat proses build lebih inkremental dan dapat meningkatkan kecepatan build.

Pertimbangkan Dockerfile berikut:

FROM node:8
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install
COPY . .
CMD [ "npm", "start" ]

Dockerfile ini melakukan hal berikut:

Saat Anda menjalankan build ini, Cloud Build harus menjalankan setiap langkah setiap kali build berjalan karena tidak ada cache lapisan gambar lintas-build di Cloud Build. Namun, saat Anda menjalankan build ini dengan cache Kaniko yang diaktifkan, hal berikut akan terjadi:

  1. Selama pengoperasian pertama, Cloud Build menjalankan setiap langkah dan setiap perintah menulis lapisan ke registry image container.

  2. Kaniko memberi tag pada setiap lapisan dengan kunci cache yang berasal dari konten perintah yang menghasilkan lapisan tersebut dan semua perintah sebelumnya.

  3. Saat berikutnya Cloud Build menjalankan build dari Dockerfile yang sama, Cloud Build akan memeriksa apakah file telah berubah atau belum. Jika belum, Cloud Build akan menggunakan lapisan cache yang disimpan dalam registry untuk menyelesaikan build, sehingga build dapat diselesaikan lebih cepat. Lihat di bawah:

FROM node:8                # no change -> cached!
COPY package*.json ./      # no change -> cached!
RUN npm install            # no change -> cached!
COPY . .                   # no change -> cached!
CMD [ "npm", "start" ]     # metadata, nothing to do

Jika Anda mengubah file package.json, Cloud Build tidak perlu menjalankan perintah sebelum langkah COPY karena kontennya belum berubah. Namun, karena mengubah file package.json akan mengubah langkah COPY, Cloud Build harus menjalankan ulang semua langkah setelah langkah COPY. Lihat di bawah:

FROM node:8                # no change -> cached!
COPY package*.json ./      # changed, must re-run
RUN npm install            # preceding layer changed
COPY . .                   # preceding layer changed
CMD [ "npm", "start" ]     # metadata, nothing to do

Jika hanya konten aplikasi yang berubah tetapi dependensinya tidak, (skenario paling umum), file package.json tetap tidak berubah dan Cloud Build hanya boleh menjalankan ulang langkah COPY . . terakhir. Hal ini menyebabkan peningkatan kecepatan build karena langkah tersebut hanya menyalin konten sumber ke lapisan di registry image container.

FROM node:8                # no change -> cached!
COPY package*.json ./      # no change -> cached!
RUN npm install            # no change -> cached!
COPY . .                   # changed, must re-run
CMD [ "npm", "start" ]     # metadata, nothing to do

Mengonfigurasi waktu habis masa berlaku cache

Flag --cache-ttl mengarahkan Kaniko untuk mengabaikan lapisan dalam cache yang belum didorong dalam waktu habis masa berlaku tertentu.

Sintaksisnya adalah --cache-ttl=XXh dengan XX adalah waktu dalam jam. Misalnya, --cache-ttl=6h menetapkan masa berlaku cache ke 6 jam. Jika Anda menjalankan build menggunakan perintah gcloud builds submit --tag [IMAGE], nilai default flag --cache-ttl adalah 6 jam. Jika Anda menggunakan image eksekutor Kaniko secara langsung, nilai defaultnya adalah 2 minggu.

Waktu habis masa berlaku yang lebih lama memastikan build yang lebih cepat jika Anda tidak mengantisipasi dependensi sering berubah, sementara waktu habis masa berlaku yang lebih pendek memastikan bahwa build Anda mengambil dependensi yang telah diupdate (seperti paket Maven atau modul Node.js) dengan lebih cepat dengan mengorbankan penggunaan lapisan yang di-cache yang dikurangi.

Untuk menetapkan waktu habis masa berlaku cache dari command line, jalankan perintah berikut:

gcloud config set builds/kaniko_cache_ttl XX

dengan XX adalah waktu habis masa berlaku cache dalam jam.

Dalam contoh Node.js, karena output perintah RUN npm install tidak berubah, kita perlu menjalankannya kembali secara berkala, meskipun perintah tersebut telah di-cache. Menetapkan parameter --cache-ttl ke 6 jam adalah kompromi yang baik, karena memastikan Cloud Build menjalankan perintah minimal sekali per hari kerja, tetapi tidak setiap kali build berjalan, terlepas dari apakah konten perintah tersebut telah berubah atau tidak.