Best practice per velocizzare le build

Questa pagina fornisce le best practice per l'accelerazione delle 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 le dimensioni dell'immagine del contenitore e aggiungere tempo e costi aggiuntivi durante il trasferimento dell'immagine tra il registry delle immagini del contenitore e il runtime del contenitore.

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, consulta Creare container 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à di creazione dell'immagine Docker è specificare un'immagine memorizzata nella cache che può essere utilizzata per le build successive. Puoi specificare l'immagine memorizzata nella cache aggiungendo l'argomento --cache-from nel file di configurazione della compilazione, che indicherà a Docker di eseguire la compilazione utilizzando l'immagine come origine della cache.

Ogni immagine Docker è costituita da livelli sovrapposti. 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.

Ti consigliamo di utilizzare sempre --cache-from per le tue build, ma tieni presente i seguenti accorgimenti:

  • È necessaria un'immagine Docker creata in precedenza da cui creare la cache.
  • Puoi utilizzare --cache-from solo per le build Docker; non puoi utilizzarlo per i compilatori che creano altri tipi di elementi.
  • 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 di compilazione, aggiungi istruzioni per:

    • Estrai l'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 è 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 l'immagine utilizzando la configurazione della build riportata sopra:

    gcloud builds submit --config cloudbuild.yaml .

JSON

  1. Nella configurazione di compilazione, aggiungi istruzioni per:

    • Estrai l'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 l'immagine utilizzando la configurazione della build riportata sopra:

    gcloud builds submit --config cloudbuild.json .

Memorizzazione nella cache delle directory 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 compilazione richiede molto tempo e produce un numero ridotto di file che non richiedono tempo per la copia da e verso Google Cloud Storage.

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

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 corrente.

    • Ripristina 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 di compilazione, aggiungi istruzioni per:

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

    • Ripristina 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 ed codice campione per gli sviluppatori di progetti
  • Codice di struttura generato, file binari, file *.jar o risorse web compilate utilizzate per lo sviluppo.
  • Dipendenze di terze parti fornite dal fornitore 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 processo di compilazione più coerente e un rischio ridotto di deployment accidentale di codice ancora in fase di sviluppo attivo.

Passaggi successivi