Automatizzare i tentativi di esecuzione delle attività

Questa pagina descrive come riprovare automaticamente le attività dopo tutti o alcuni errori.

Un job batch non riesce quando almeno una delle relative attività non riesce, il che può accadere per vari motivi. Per impostazione predefinita, ogni attività in un job viene eseguita una sola volta. Se un'attività non va a buon fine, non viene eseguito alcun nuovo tentativo. Tuttavia, alcuni problemi che causano il fallimento di un'attività possono essere facilmente risolti semplicemente riprovando. In questi casi, configurare il job in modo che riprovi automaticamente le attività può contribuire notevolmente a ridurre la complessità della risoluzione dei problemi e il tempo di esecuzione complessivo dei job.

I tentativi automatici sono adatti per le attività indipendenti (a accoppiamento lasco) e possono essere utili per una serie di problemi. Ad esempio, i tentativi automatici di attività possono risolvere problemi urgenti come i seguenti:

Quando crei un job, puoi configurare i tentativi automatici per ogni attività. Nello specifico, per ogni attività puoi utilizzare una delle seguenti opzioni di configurazione:

  • Per impostazione predefinita, non viene eseguito alcun nuovo tentativo per ogni attività in caso di errore.
  • Riprova le attività per tutti gli errori: puoi configurare il numero massimo di volte per riprovare automaticamente le attività non riuscite. Puoi specificare un numero di tentativi compreso tra 0 (valore predefinito) e 10.
  • Riprova le attività per alcuni errori: puoi configurare diverse azioni per le attività, come il nuovo tentativo automatico o l'errore senza nuovo tentativo, per errori specifici. Per tutti gli errori non specificati viene eseguita l'azione opposta. Ogni errore specifico può essere identificato da un codice di uscita definito dall'applicazione o dal batch.

Prima di iniziare

  1. Se non hai mai utilizzato Batch, consulta la guida introduttiva all'utilizzo di Batch e attivalo completando i prerequisiti per progetti e utenti.

  2. Per ottenere le autorizzazioni necessarie per creare un job, chiedi all'amministratore di concederti i seguenti ruoli IAM:

    Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

    Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Riprova le attività per tutti gli errori

Puoi definire il numero massimo di nuovi tentativi automatici (campo maxRetryCount) per le attività non riuscite di un job utilizzando l'interfaccia a riga di comando gcloud o l'API Batch.

gcloud

  1. Crea un file JSON che specifichi i dettagli di configurazione del job e il campo maxRetryCount.

    Ad esempio, per creare un job di script di base che specifichi il numero massimo di tentativi per le attività non riuscite, crea un file JSON con i seguenti contenuti:

    {
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
            }
          }
        ],
        
        "maxRetryCount": MAX_RETRY_COUNT
        
      },
      "taskCount": 3
    }
  ],
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

    Sostituisci MAX_RETRY_COUNT con il numero massimo di tentativi per ogni attività. Affinché un job possa riprovare le attività non riuscite, questo valore deve essere impostato su un numero intero compreso tra 1 e 10. Se il campo maxRetryCount non è specificato, il valore predefinito è 0, ovvero non ripetere nessuna attività.

  2. Per creare ed eseguire il job, utilizza il comando gcloud batch jobs submit:

    gcloud batch jobs submit JOB_NAME \
  --location LOCATION \
  --config JSON_CONFIGURATION_FILE

    Sostituisci quanto segue:

    • JOB_NAME: il nome del job.

    • LOCATION: la località del lavoro.

    • JSON_CONFIGURATION_FILE: il percorso di un file JSON con i dettagli di configurazione del job.

API

Invia una richiesta POST al metodo jobs.create che specifica il campo maxRetryCount.

Ad esempio, per creare un job di script di base che specifichi il numero massimo di tentativi per le attività non riuscite, effettua la seguente richiesta:

POST https://batch.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/jobs?job_id=JOB_NAME

{
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
            }
          }
        ],
        
        "maxRetryCount": MAX_RETRY_COUNT
        
      },
      "taskCount": 3
    }
  ],
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

Sostituisci quanto segue:

  • PROJECT_ID: il ID progetto del tuo progetto.

  • LOCATION: la località del lavoro.

  • JOB_NAME: il nome del job.

  • MAX_RETRY_COUNT: il numero massimo di nuovi tentativi per ogni attività. Affinché un job possa riprovare le attività non riuscite, questo valore deve essere impostato su un numero intero compreso tra 1 e 10. Se il campo maxRetryCount non è specificato, il valore predefinito è 0, ovvero non ripetere nessuna attività.

Riprovare le attività per alcuni errori

Puoi definire il modo in cui un job deve gestire diversi errori di attività utilizzando i criteri del ciclo di vita (campo lifecyclePolicies[]).

Un criterio del ciclo di vita è costituito da un'azione (campo action), da una condizione di azione (campo actionCondition) e da un codice di uscita (campo exitCodes[]). L'azione specificata viene eseguita ogni volta che si verifica la condizione di azione, ovvero un codice di uscita specifico. Puoi specificare una delle seguenti azioni:

  • RETRY_TASK: riprova le attività che non riescono con i codici di uscita specificati nel exitCodes[] campo. Le attività che non riescono con codici di uscita non specificati non vengono ripetute.
  • FAIL_TASK: non riprovare le attività che non riescono con i codici di uscita specificati nel exitCodes[] campo. Le attività che non riescono con codici di uscita non specificati vengono ripetute.

In particolare, tutte le attività che non riescono con codici di uscita non specificati eseguono l'azione opposta: alcuni codici di uscita vengono riprovati e altri non riescono. Di conseguenza, affinché il criterio del ciclo di vita funzioni come previsto, devi anche definire il numero massimo di nuovi tentativi automatici (campo maxRetryCount) per consentire al job di riprovare automaticamente le attività non riuscite almeno una volta.

Ogni codice di uscita rappresenta un errore specifico definito dall'applicazione o da Batch. I codici di uscita da 50001 a 59999 sono riservati e definiti da Batch. Per ulteriori informazioni sui codici di uscita riservati, consulta la sezione Risoluzione dei problemi.

Puoi specificare che un job debba riprovare o non riuscire a completare le attività dopo errori specifici utilizzando gcloud CLI o l'API Batch.

gcloud

  1. Crea un file JSON che specifichi i dettagli di configurazione del job, il campo maxRetryCount e i campi secondari lifecyclePolicies[].

    Per creare un job di script di base che riprova le attività non riuscite solo per alcuni codici di uscita, crea un file JSON con i seguenti contenuti:

    {
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
            }
          }
        ],
        
        "maxRetryCount": MAX_RETRY_COUNT,
        "lifecyclePolicies": [
          {
            "action": "ACTION",
            "actionCondition": {
               "exitCodes": [EXIT_CODES]
            }
          }
        ]
      }
    }
  ],
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

    Sostituisci quanto segue:

    • MAX_RETRY_COUNT: il numero massimo di nuovi tentativi per ogni attività. Affinché un job possa riprovare le attività non riuscite, questo valore deve essere impostato su un numero intero compreso tra 1 e 10. Se il campo maxRetryCount non è specificato, il valore predefinito è 0, ovvero non ripetere nessuna attività.

    • ACTION: l'azione, RETRY_TASK o FAIL_TASK, che vuoi per le attività che non riescono con i codici di uscita specificati. Le attività che non vanno a buon fine con codici di uscita non specificati eseguono l'altra azione.

    • EXIT_CODES: un elenco separato da virgole di uno o più codici di uscita per attivare l'azione specificata, ad esempio 50001, 50002.

      Ogni codice di uscita può essere definito dall'applicazione o dal batch. I codici di uscita da 50001 a 59999 sono riservati a Batch. Per ulteriori informazioni sui codici di uscita riservati, consulta la sezione Risoluzione dei problemi.

    Ad esempio, il seguente job riprova solo le attività che non riescono a causa della preemption delle VM spot.

    {
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "sleep 30"
            }
          }
        ],
        "maxRetryCount": 3,
        "lifecyclePolicies": [
          {
             "action": "RETRY_TASK",
             "actionCondition": {
               "exitCodes": [50001]
            }
          }
        ]
      }
    }
  ],
  "allocationPolicy": {
    "instances": [
      {
        "policy": {
          "machineType": "e2-standard-4",
          "provisioningModel": "SPOT"
        }
      }
    ]
  }
}

  2. Per creare ed eseguire il job, utilizza il comando gcloud batch jobs submit:

    gcloud batch jobs submit JOB_NAME \
  --location LOCATION \
  --config JSON_CONFIGURATION_FILE

    Sostituisci quanto segue:

    • JOB_NAME: il nome del job.

    • LOCATION: la località del lavoro.

    • JSON_CONFIGURATION_FILE: il percorso di un file JSON con i dettagli di configurazione del job.

API

Invia una richiesta POST al metodo jobs.create che specifica il campo maxRetryCount e i sottocampi lifecyclePolicies[].

Per creare un job di script di base che riprovi le attività non riuscite solo per alcuni codici di uscita, effettua la seguente richiesta:

POST https://batch.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/jobs?job_id=JOB_NAME

{
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
            }
          }
        ],
        
        "maxRetryCount": MAX_RETRY_COUNT,
        "lifecyclePolicies": [
          {
            "action": "ACTION",
            "actionCondition": {
                "exitCodes": [EXIT_CODES]
            }
          }
        ]
      }
    }
  ],
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

Sostituisci quanto segue:

  • PROJECT_ID: il ID progetto del tuo progetto.

  • LOCATION: la località del lavoro.

  • JOB_NAME: il nome del job.

  • MAX_RETRY_COUNT: il numero massimo di nuovi tentativi per ogni attività. Affinché un job possa riprovare le attività non riuscite, questo valore deve essere impostato su un numero intero compreso tra 1 e 10. Se il campo maxRetryCount non è specificato, il valore predefinito è 0, ovvero non ripetere nessuna attività.

  • ACTION: l'azione, RETRY_TASK o FAIL_TASK, che vuoi per le attività che non riescono con i codici di uscita specificati. Le attività che non vanno a buon fine con codici di uscita non specificati eseguono l'altra azione.

  • EXIT_CODES: un elenco separato da virgole di uno o più codici di uscita per attivare l'azione specificata, ad esempio 50001, 50002.

    Ogni codice di uscita può essere definito dall'applicazione o dal batch. I codici di uscita da 50001 a 59999 sono riservati a Batch. Per ulteriori informazioni sui codici di uscita riservati, consulta la sezione Risoluzione dei problemi.

Ad esempio, il seguente job riprova solo le attività che non riescono a causa della preemption delle VM spot.

POST https://batch.googleapis.com/v1/projects/example-project/locations/us-central1/jobs?job_id=example-job

{
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "sleep 30"
            }
          }
        ],
        "maxRetryCount": 3,
        "lifecyclePolicies": [
          {
             "action": "RETRY_TASK",
             "actionCondition": {
               "exitCodes": [50001]
            }
          }
        ]
      }
    }
  ],
  "allocationPolicy": {
    "instances": [
      {
        "policy": {
          "machineType": "e2-standard-4",
          "provisioningModel": "SPOT"
        }
      }
    ]
  }
}

Modificare il comportamento dell'attività in base al numero di tentativi

Se vuoi, dopo aver attivato i tentativi automatici per un'attività come descritto nelle sezioni precedenti di questa pagina, puoi aggiornare i file eseguibili in modo che utilizzino la variabile di ambiente predefinita BATCH_TASK_RETRY_ATTEMPT. La variabile BATCH_TASK_RETRY_ATTEMPT descrive il numero di volte che questa attività è già stata tentata. Utilizza la variabile BATCH_TASK_RETRY_ATTEMPT nei runnable se vuoi che un'attività si comporti in modo diverso in base al numero di tentativi. Ad esempio, quando viene eseguito un nuovo tentativo per un'attività, potresti voler confermare quali comandi sono già stati eseguiti correttamente nel tentativo precedente. Per ulteriori informazioni, consulta Variabili di ambiente predefinite.

Passaggi successivi