Best practice per l'accelerazione di build

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

Creazione di container più snelli

Quando containerizziamo un'applicazione, i file che non sono necessari in fase di runtime, ad esempio le dipendenze in fase di build e i file intermedi, possono essere inavvertitamente inclusi nell'immagine container. Questi file non necessari possono aumentare le dimensioni dell'immagine del container e aumentare il tempo e i costi mentre l'immagine si sposta tra il registro di immagini dei container e il runtime del container.

Per ridurre le dimensioni dell'immagine container, separa la creazione dell'applicazione e gli strumenti utilizzati per crearla dall'assemblaggio del container di runtime.

Per ulteriori informazioni, consulta la sezione Creare container più snelli.

Utilizzo della cache di Kaniko

La cache di Kaniko è una funzionalità di Cloud Build che memorizza nella cache gli artefatti di build dei container archiviando e indicizzando i livelli intermedi all'interno di un registro di immagini container, ad esempio il Container Registry di Google, dove sono disponibili per l'utilizzo da parte di build successive. Per ulteriori informazioni, vedi Utilizzo della cache di Kaniko.

Utilizzo di un'immagine Docker memorizzata nella cache

Il modo più semplice per aumentare la velocità della build 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 build, che indica a Docker di creare utilizzando quell'immagine come origine della cache.

Ogni immagine Docker è composta da livelli impilati. L'utilizzo di --cache-from ricostruisce tutti i livelli dal livello modificato fino alla fine della build; pertanto, l'utilizzo di --cache-from non è utile se modifichi un livello nelle fasi precedenti della build Docker.

È consigliabile usare sempre --cache-from per le build, ma tieni presente le seguenti avvertenze:

Ti serve un'immagine Docker creata in precedenza da cui memorizzare nella cache.
Puoi utilizzare --cache-from solo per le build Docker; non puoi usarlo per i builder che creano altri tipi di artefatti.
L'immagine memorizzata nella cache deve essere recuperata da un registro, il che può aumentare il tempo necessario per la creazione.

I seguenti passaggi spiegano come creare utilizzando un'immagine precedentemente memorizzata nella cache:

YAML

Nella configurazione della build, aggiungi istruzioni per:
- Esegui il pull dell'immagine memorizzata nella cache da Container Registry. Nota che il passaggio di build docker pull riportato di seguito imposta entrypoint su bash, in modo da eseguire il comando e ignorare l'errore restituito. Questa operazione è necessaria quando crei un'immagine per la prima volta e docker pull non ha un'immagine esistente 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.
Crea l'immagine utilizzando la configurazione di build riportata sopra:
```
gcloud builds submit --config cloudbuild.yaml .
```

JSON

Nella configurazione della build, aggiungi istruzioni per:
- Esegui il pull dell'immagine memorizzata nella cache da Container Registry. Tieni presente che il passaggio di build docker pull riportato di seguito imposta entrypoint su bash, in modo da eseguire il comando e ignorare gli eventuali errori restituiti. Questa operazione è necessaria quando crei un'immagine per la prima volta e docker pull non ha un'immagine esistente 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.
Crea l'immagine utilizzando la configurazione di build riportata sopra:
```
gcloud builds submit --config cloudbuild.json .
```

Memorizzazione delle directory nella cache con Google Cloud Storage

Per aumentare la velocità di una build, riutilizza i risultati di una build precedente. Puoi copiare i risultati di una build precedente in un bucket Google Cloud Storage, utilizzare i risultati per un calcolo più rapido e poi copiare i nuovi risultati nel bucket. Utilizza questo metodo quando la tua build richiede molto tempo e produce un numero ridotto di file che non richiede tempo per essere copiati 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 le directory nella cache utilizzando Google Cloud Storage:

YAML

Nel file di configurazione della build, aggiungi le istruzioni per:

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

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

Crea il codice utilizzando la configurazione di build riportata sopra:
```
gcloud builds submit --config cloudbuild.yaml .
```

JSON

Nel file di configurazione della build, aggiungi le istruzioni per:

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

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"]
    }
    ]
}

Crea il codice utilizzando la configurazione di build riportata sopra:
```
gcloud builds submit --config cloudbuild.json .
```

Evitare il caricamento di file superflui

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

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

Ecco alcuni esempi di file comunemente esclusi:

Documentazione e codice campione per gli sviluppatori di progetti
Codice scaffolding generato, programmi binari, file *.jar o asset web compilati utilizzati per lo sviluppo.
Dipendenze di terze parti fornite da fornitori per lo sviluppo locale

Per preparare un file .gcloudignore per la gestione di questi casi, crea un file nella directory principale del progetto con contenuti quali:

.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

Scopri come aumentare la vCPU per le build.