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 menggantiPROJECT_ID
dari project yang berisi Dockerfile.LOCATION
,REPOSITORY
, danIMAGE
adalah substitusi yang ditentukan pengguna.LOCATION
adalah lokasi regional atau multi-regional repositori tempat gambar disimpan, misalnyaus-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, denganXX
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:
Menginstal aplikasi Node.js berdasarkan praktik terbaik Node.js.
Menjalankan aplikasi saat gambar dijalankan.
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:
Selama pengoperasian pertama, Cloud Build menjalankan setiap langkah dan setiap perintah menulis lapisan ke registry image container.
Kaniko memberi tag pada setiap lapisan dengan kunci cache yang berasal dari konten perintah yang menghasilkan lapisan tersebut dan semua perintah sebelumnya.
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.