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, ad esempio Artifact Registry di Google. Per scoprire casi d'uso aggiuntivi, consulta il repository Kaaniko su GitHub.

La cache di Kaniko funziona nel seguente modo:

  • Cloud Build carica i livelli delle immagini container direttamente nel registry così come vengono creati, in modo che non c'è 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.

Abilitazione 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

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

dove:

  • --destination=${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE} è l'immagine container di destinazione. Cloud Build automaticamente sostituisce il valore PROJECT_ID del progetto contenente il Dockerfile. LOCATION, REPOSITORY e IMAGE sono sostituzioni definite dall'utente.
  • LOCATION è la località a una o più regioni 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 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 informazioni generali le best practice per Dockerfile. Queste pratiche 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 build con la cache di Kaniko abilitata, quanto segue si verifica quanto segue:

  1. Durante la prima esecuzione, Cloud Build esegue ogni passaggio scrive un livello nel registro delle immagini container.

  2. Kaniko tagga ogni livello con una chiave cache che deriva dai contenuti la direttiva che ha prodotto quel livello più tutte le istruzioni 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 esegui queste istruzioni prima del passaggio COPY perché i relativi contenuti non sono stati modificati. Tuttavia, poiché la modifica del file package.json cambia anche il passaggio COPY, Cloud Build deve eseguire nuovamente tutti i passaggi dopo il passaggio COPY. Vedi sotto:

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

Configurare la scadenza della cache

Il flag --cache-ttl indica a Kaniko di ignorare i livelli nella cache che sono non sia stato inviato entro un certo periodo 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 build utilizzando il comando gcloud builds submit --tag [IMAGE], il valore predefinito Il flag --cache-ttl è impostato su 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 quando 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 Node.js, poiché l'output del RUN npm install rimane invariata, dobbiamo eseguirla periodicamente, anche se ed è stato memorizzato 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.