Utilizzo della cache di Kaniko

Panoramica

La cache di Kaniko memorizza gli artefatti delle build dei container archiviando e indicizzando i livelli intermedi all'interno di un registry di immagini container, come Artifact Registry di Google. Per scoprire altri casi d'uso, consulta il repository Kaniko su GitHub.

La cache di Kaniko funziona nel seguente modo:

  • Cloud Build carica i livelli delle immagini container direttamente nel registry man mano che vengono creati, quindi non è previsto un passaggio di push esplicito. Se tutti i livelli vengono compilati correttamente, un manifest dell'immagine contenente questi livelli viene scritto nel registry.

  • Kaniko memorizza nella cache ogni livello in base ai contenuti della direttiva Dockerfile che lo ha creato, oltre a tutte le direttive che lo hanno preceduto, fino al digest dell'immagine nella riga FROM.

Attivazione della cache di Kaniko nelle build

Puoi attivare la cache Kaniko in una build Docker sostituendo i worker cloud-builders/docker con i worker kaniko-project/executor nel file cloudbuild.yaml come segue:

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

Docker Build 

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}'

dove:

  • --destination=${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE} è l'immagine container di destinazione. Cloud Build sostituisce automaticamente PROJECT_ID dal progetto contenente il Dockerfile. LOCATION, REPOSITORY e IMAGE sono sostituzioni definite dall'utente.
  • LOCATION è la località regionale o multiregionale del repository in cui è archiviata l'immagine, ad esempio us-east1.
  • REPOSITORY è il nome del repository in cui è archiviata l'immagine.
  • IMAGE è il nome dell'immagine.
  • --cache=true attiva la cache di Kaniko.
  • --cache-ttl=XXh imposta la data e l'ora di scadenza della cache, dove XX indica il numero di ore prima della scadenza della cache. Consulta Configurare la data e l'ora di scadenza della cache.

Se esegui le build utilizzando il comando gcloud builds submit --tag [IMAGE], puoi attivare la cache di Kaniko impostando la proprietà builds/use_kaniko su True come mostrato di seguito:

gcloud config set builds/use_kaniko True

Esempio: utilizzo della cache di Kaniko in una build Node.js

Questo esempio mostra come eseguire build incrementali per le app Node.js utilizzando le best practice generali per i file Dockerfile. Le pratiche descritte si applicano alle build in tutte le altre lingue supportate.

Qui sposti le direttive che difficilmente cambiano tra una build e l'altra nella parte superiore del Dockerfile e quelle che potrebbero cambiare nella parte inferiore. In questo modo, il processo di compilazione diventa più incrementale e può aumentare le velocità di compilazione.

Considera il seguente Dockerfile:

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

Questo Dockerfile esegue le seguenti operazioni:

Quando esegui questa build, Cloud Build deve eseguire ogni passaggio ogni volta che viene eseguita la build, in quanto non è presente una cache dei livelli di immagine tra build in Cloud Build. Tuttavia, quando esegui questa compilazione con la cache Kaniko abilitata, accade quanto segue:

  1. Durante la prima esecuzione, Cloud Build esegue ogni passaggio e ogni direttiva scrive un livello nel registry delle immagini del contenitore.

  2. Kaniko contrassegna ogni livello con una chiave della cache ricavata dai contenuti della direttiva che ha prodotto quel livello, oltre a tutte le direttive precedenti.

  3. La volta successiva che Cloud Build esegue la compilazione dallo stesso Dockerfile, controlla se il file è stato modificato. In caso contrario, Cloud Build utilizza i livelli memorizzati nella cache nel registry per completare la build, il che consente di completare la build più velocemente. Vedi di seguito:

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

Se modifichi il file package.json, Cloud Build non deve eseguire le direttive prima del passaggio COPY, poiché i relativi contenuti non sono cambiati. Tuttavia, poiché la modifica del file package.json modifica il passaggio COPY, Cloud Build deve eseguire di nuovo tutti i passaggi dopo il passaggio COPY. Vedi di seguito:

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

Se cambiano solo i contenuti dell'app, ma non le dipendenze (lo scenario più comune), il file package.json rimane invariato e Cloud Build deve solo eseguire nuovamente il passaggio COPY . . finale. Ciò comporta un aumento della velocità di compilazione, poiché il passaggio copia semplicemente i contenuti di origine in un livello del registry delle immagini dei contenitori.

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

Configurazione della scadenza della cache

Il flag --cache-ttl indica a Kaniko di ignorare i livelli nella cache che non sono stati inviati entro un determinato periodo di tempo di scadenza.

La sintassi è --cache-ttl=XXh, dove XX è il tempo in ore. Ad esempio, --cache-ttl=6h imposta la scadenza della cache su 6 ore. Se esegui le build utilizzando il comando gcloud builds submit --tag [IMAGE], il valore predefinito del flag --cache-ttl è 6 ore. Se utilizzi direttamente l'immagine dell'eseguitore Kaniko, il valore predefinito è 2 settimane.

Un tempo di scadenza più lungo garantisce build più rapide se non prevedi che le dipendenze cambino spesso, mentre un tempo di scadenza più breve garantisce che la build rileve più rapidamente le dipendenze aggiornate (ad esempio i pacchetti Maven o i moduli Node.js) a scapito di un utilizzo ridotto dei livelli memorizzati nella cache.

Per impostare la data e l'ora di scadenza della cache dalla riga di comando, esegui il seguente comando:

gcloud config set builds/kaniko_cache_ttl XX

dove XX è il tempo di scadenza della cache in ore.

Nel nostro esempio di Node.js, poiché l'output della direttiva RUN npm install rimane invariato, dobbiamo eseguirla di nuovo periodicamente, anche se è stata memorizzata nella cache. Impostare il parametro --cache-ttl su 6 ore è un buon compromesso, in quanto garantisce che Cloud Build esegua la direttiva almeno una volta al giorno lavorativo, ma non ogni volta che viene eseguita la build, indipendentemente dal fatto che i contenuti della direttiva siano cambiati.