Menggunakan cache Kaniko

Ringkasan

Kaniko menyimpan artefak build container dalam cache dengan menyimpan dan mengindeks lapisan perantara dalam registry image container, seperti Artifact Registry milik Google. Untuk mempelajari kasus penggunaan tambahan, 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 eksplisit. Jika semua lapisan berhasil di-build, manifes image yang berisi lapisan tersebut akan ditulis ke registry.

  • Kaniko meng-cache setiap lapisan sesuai dengan konten perintah Dockerfile yang membuatnya, ditambah semua perintah yang mendahuluinya, hingga ringkasan image di baris FROM.

Mengaktifkan cache Kaniko dalam build Anda

Anda dapat mengaktifkan cache Kaniko dalam build Docker dengan mengganti pekerja cloud-builders/docker dengan pekerja kaniko-project/executor dalam 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 image disimpan, misalnya us-east1.
  • REPOSITORY adalah nama repositori tempat gambar disimpan.
  • IMAGE adalah nama image.
  • --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 dalam 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 kemungkinan akan berubah ke bagian bawah. Hal ini membuat proses build menjadi 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 image lintas build di Cloud Build. Namun, saat Anda menjalankan build ini dengan mengaktifkan cache Kaniko, 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 direktif yang menghasilkan lapisan tersebut beserta semua perintah sebelumnya.

  3. Saat berikutnya Cloud Build menjalankan build dari Dockerfile yang sama, Cloud Build akan memeriksa apakah file telah berubah. Jika belum, Cloud Build akan menggunakan lapisan yang di-cache yang disimpan di 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 perlu menjalankan ulang langkah COPY . . akhir. Hal ini menghasilkan peningkatan kecepatan build karena langkah ini hanya menyalin konten sumber ke lapisan di registry gambar penampung.

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 menjadi 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 default-nya adalah 2 minggu.

Waktu habis masa berlaku yang lebih lama memastikan build lebih cepat jika Anda tidak mengharapkan dependensi sering berubah, sedangkan waktu habis masa berlaku yang lebih singkat memastikan build mengambil dependensi yang diperbarui (seperti paket Maven atau modul Node.js) lebih cepat dengan mengorbankan penggunaan lapisan yang di-cache yang lebih sedikit.

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 tetap tidak berubah, kita perlu menjalankannya kembali secara berkala, meskipun telah di-cache. Menetapkan parameter --cache-ttl ke 6 jam adalah kompromi yang baik, karena memastikan Cloud Build menjalankan perintah setidaknya sekali per hari kerja, tetapi tidak setiap kali build berjalan, terlepas dari apakah konten perintah tersebut telah berubah.