Best practice per velocizzare le build

Questa pagina fornisce le best practice per accelerare le build di Cloud Build.

Creazione di container più snelli

Quando esegui il containerizzazione di un'applicazione, i file non necessari in fase di esecuzione, come le dipendenze di compilazione e i file intermedi, possono essere inclusi inavvertitamente nell'immagine del contenitore. Questi file non necessari possono aumentare la dimensione dell'immagine container e aggiungere tempo e costi aggiuntivi quando l'immagine si sposta tra Container Image Registry e il runtime del container.

Per contribuire a ridurre le dimensioni dell'immagine del container, separa la compilazione dell'applicazione, insieme agli strumenti utilizzati per compilarla, dall'assemblaggio del container di runtime.

Per ulteriori informazioni, vedi Creare contenitori più snelli.

Utilizzo della cache di Kaniko

La cache di Kaniko è una funzionalità di Cloud Build che memorizza nella cache gli artefatti delle build dei container archiviando e indicizzando i livelli intermedi all'interno di un registry di immagini container, come il Container Registry di Google, dove sono disponibili per essere utilizzati dalle build successive. Per ulteriori informazioni, consulta la sezione Utilizzare la cache di Kaniko.

Utilizzo di un'immagine Docker memorizzata nella cache

Il modo più semplice per aumentare la velocità della tua build di immagine Docker è specifica un'immagine memorizzata nella cache da utilizzare per le build successive. Puoi specifica l'immagine memorizzata nella cache aggiungendo l'argomento --cache-from nella tua build di configurazione del deployment, che istruisce Docker a creare usando l'immagine come cache sorgente.

Ogni immagine Docker è composta da livelli impilati. L'utilizzo di --cache-from consente di ricostruire tutti i livelli dal livello modificato fino alla fine della compilazione. Pertanto, l'utilizzo di --cache-from non è vantaggioso se modifichi un livello nelle fasi iniziali della compilazione di Docker.

È consigliabile utilizzare sempre --cache-from per le build, ma mantieni tieni a mente le seguenti avvertenze:

  • È necessaria un'immagine Docker creata in precedenza da cui creare la cache.
  • Puoi utilizzare --cache-from solo per le build Docker; non puoi utilizzarlo che creano altri tipi di artefatti.
  • L'immagine memorizzata nella cache deve essere recuperata da un registry, il che potrebbe aumentare il tempo necessario per la compilazione.

I passaggi riportati di seguito spiegano come eseguire la compilazione utilizzando un'immagine memorizzata nella cache in precedenza:

YAML

  1. Nella configurazione build, aggiungi istruzioni per:

    • Esegui il pull dell'immagine memorizzata nella cache da Container Registry. Tieni presente che il passaggio di compilazione docker pull riportato di seguito imposta entrypoint su bash, il che ti consente di eseguire il comando e ignorare l'errore restituito. Questo è richiesta quando crei un'immagine per la prima volta e docker pull non dispone di un'immagine di cui eseguire il pull.

    • Aggiungi un argomento --cache-from per utilizzare l'immagine per le ricostruzioni.

      steps:
- name: 'gcr.io/cloud-builders/docker'
  entrypoint: 'bash'
  args: ['-c', 'docker pull gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest || exit 0']
- name: 'gcr.io/cloud-builders/docker'
  args: [
            'build',
            '-t', 'gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest',
            '--cache-from', 'gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest',
            '.'
        ]
images: ['gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest']

      dove [IMAGE_NAME] è il nome dell'immagine.

  2. Crea la tua immagine utilizzando la configurazione di compilazione riportata sopra:

    gcloud builds submit --config cloudbuild.yaml .

JSON

  1. Nella configurazione build, aggiungi istruzioni per:

    • Esegui il pull dell'immagine memorizzata nella cache da Container Registry. Tieni presente che il passaggio di compilazione docker pull riportato di seguito imposta entrypoint su bash, il che ti consente di eseguire il comando e ignorare eventuali errori restituiti. Questo è obbligatorio quando crei un'immagine per la prima volta e docker pull non ha un'immagine esistente da estrarre.

    • Aggiungi un argomento --cache-from per utilizzare l'immagine per le ricostruzioni.

      {
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "entrypoint": "bash",
        "args": ["-c", "docker pull gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest || exit 0"]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest",
            "--cache-from",
            "gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest",
            "."
        ]
    }
    ],
    "images": ["gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest"]
}

      dove [IMAGE_NAME] è il nome dell'immagine.

  2. Crea la tua immagine utilizzando la configurazione di compilazione riportata sopra:

    gcloud builds submit --config cloudbuild.json .

Memorizzare le directory nella cache con Google Cloud Storage

Per aumentare la velocità di una compilazione, riutilizza i risultati di una compilazione precedente. Puoi copiare i risultati di una compilazione precedente in un bucket Google Cloud Storage, utilizzarli per calcoli più rapidi e poi copiare i nuovi risultati nel bucket. Utilizza questo metodo quando la build richiede molto tempo e produce un numero di file la cui copia da e verso Google Cloud non richiede tempo spazio di archiviazione.

A differenza di --cache-from, che è solo per le build Docker, la memorizzazione nella cache di Cloud Storage può essere utilizzata per qualsiasi builder supportato da Cloud Build.

Segui questi passaggi per memorizzare nella cache le directory utilizzando Google Cloud Storage:

YAML

  1. Nel file di configurazione di compilazione, aggiungi istruzioni per:

    • Copia i risultati di una build precedente dal bucket Google Cloud Storage.
    • Utilizza i risultati per la build attuale.

    • Copia i nuovi risultati nel bucket.

      steps:
- name: gcr.io/cloud-builders/gsutil
  args: ['cp', 'gs://mybucket/results.zip', 'previous_results.zip']
# operations that use previous_results.zip and produce new_results.zip
- name: gcr.io/cloud-builders/gsutil
  args: ['cp', 'new_results.zip', 'gs://mybucket/results.zip']

  2. Compila il codice utilizzando la configurazione della build riportata sopra:

    gcloud builds submit --config cloudbuild.yaml .

JSON

  1. Nel file di configurazione della build, aggiungi istruzioni a:

    • Copia i risultati di una build precedente dal bucket Google Cloud Storage.
    • Utilizza i risultati per la build attuale.

    • Copia i nuovi risultati nel bucket.

      {
    "steps": [
    {
        "name": "gcr.io/cloud-builders/gsutil",
        "args": ["cp", "gs://mybucket/results.zip", "previous_results.zip"]
    },
    {
        // operations that use previous_results.zip and produce new_results.zip
    },
    {
        "name": "gcr.io/cloud-builders/gsutil",
        "args": ["cp", "new_results.zip", "gs://mybucket/results.zip"]
    }
    ]
}

  2. Compila il codice utilizzando la configurazione della build riportata sopra:

    gcloud builds submit --config cloudbuild.json .

Evitare il caricamento di file non necessari

Quando viene attivata una build, la directory del codice viene caricata per essere utilizzata da Cloud Build.

Puoi escludere i file non necessari per la compilazione con un file .gcloudignore per ottimizzare il tempo di caricamento.

Ecco alcuni esempi di file comunemente esclusi:

  • Documentazione e codice campione per gli sviluppatori dei progetti
  • Codice di struttura generato, file binari, file *.jar o risorse web compilate utilizzate per lo sviluppo.
  • Dipendenze di terze parti fornite da fornitori per lo sviluppo locale

Per preparare un file .gcloudignore per risolvere questi casi, crea un file nella directory principale del progetto con contenuti come:

.git
dist
node_modules
vendor
*.jar

L'esclusione del codice compilato e delle dipendenze di terze parti comporta anche un aumento coerente e un rischio ridotto di deployment accidentale del codice ancora in fase di sviluppo attivo.

Passaggi successivi