Questa pagina mostra come creare un gestore di attività App Engine, il
codice worker che gestisce un'attività App Engine. La coda Cloud Tasks
invia richieste HTTP al gestore delle attività. Al termine dell'elaborazione, il gestore deve inviare un codice di stato HTTP compreso tra 200
e 299
alla coda. Qualsiasi altro valore indica che l'attività non è riuscita e la coda
ritenta l'operazione.
Le richieste di App Engine Task Queue vengono inviate dall'indirizzo IP 0.1.0.2
.
Fai riferimento anche all'intervallo IP per le richieste inviate all'ambiente App Engine.
C#
Go
Java
Node.js
PHP
Python
Ruby
Timeout
I timeout delle attività App Engine dipendono dal tipo di scalabilità del servizio che le esegue.
Per i servizi di gestione dei worker in esecuzione nell'ambiente standard:
- Scalabilità automatica: l'elaborazione delle attività deve terminare in 10 minuti.
- Scalabilità manuale e di base: le richieste possono essere eseguite fino a 24 ore.
Per i servizi worker in esecuzione nell'ambiente flessibile: tutti i tipi hanno un timeout di 60 minuti.
Se il gestore non rispetta la scadenza, la coda presuppone che l'attività non sia riuscita e riprova.
Lettura delle intestazioni delle richieste di attività App Engine
Le richieste inviate al gestore App Engine da una coda Cloud Tasks hanno intestazioni speciali, che contengono informazioni specifiche dell'attività che il gestore potrebbe voler utilizzare.
Queste intestazioni vengono impostate internamente. Se una di queste intestazioni è presente in una richiesta di un utente esterno alla tua app, viene sostituita da quelle interne, a eccezione delle richieste degli amministratori dell'applicazione che hanno eseguito l'accesso, ai quali è consentito impostare le intestazioni a scopo di test.
Le richieste di attività App Engine contengono sempre le seguenti intestazioni:
Intestazione | Descrizione |
---|---|
X-AppEngine-QueueName |
Il nome della coda. |
X-AppEngine-TaskName |
Il nome "breve" dell'attività o, se non è stato specificato alcun nome al momento della creazione, un ID univoco generato dal sistema. Questo è il valore di my-task-id nel nome completo dell'attività; ad esempio, task_name = projects/my-project-id/locations/my-location/queues/my-queue-id/tasks/my-task-id . |
X-AppEngine-TaskRetryCount |
Il numero di tentativi eseguiti per l'attività. Per il primo tentativo, questo valore è 0 . Questo numero include i tentativi in cui l'attività non è riuscita a causa della mancanza di istanze disponibili e non ha mai raggiunto la fase di esecuzione. |
X-AppEngine-TaskExecutionCount |
Il numero di volte in cui l'attività è stata eseguita e ha ricevuto una risposta dal gestore. Poiché Cloud Tasks elimina l'attività una volta ricevuta una risposta riuscita, tutte le risposte precedenti del gestore non sono riuscite. Questo numero non include gli errori dovuti alla mancanza di istanze disponibili. Tieni presente che X-AppEngine-TaskExecutionCount può essere uguale a X-AppEngine-TaskRetryCount se viene aggiornato prima di tentare un'esecuzione. |
X-AppEngine-TaskETA |
L'ora di pianificazione dell'attività, specificata in secondi a partire dal 1° gennaio 1970. |
Se il gestore delle richieste trova una delle intestazioni elencate in precedenza, può presumere che la richiesta sia una richiesta Cloud Tasks.
Inoltre, le richieste di Cloud Tasks potrebbero contenere le seguenti intestazioni:
Intestazione | Descrizione |
---|---|
X-AppEngine-TaskPreviousResponse |
Il codice di risposta HTTP del precedente tentativo. |
X-AppEngine-TaskRetryReason |
Il motivo per cui viene eseguito un nuovo tentativo di esecuzione dell'attività. |
X-AppEngine-FailFast |
Indica che un'attività non va a buon fine immediatamente se un'istanza esistente non è disponibile. |
Target routing
Nelle attività App Engine, sia la coda che il gestore delle attività vengono eseguiti all'interno dello stesso progetto Google Cloud . Il traffico viene criptato durante il trasporto e non esce mai dai data center di Google. Non puoi impostare esplicitamente il protocollo (ad esempio HTTP o HTTPS). La richiesta al gestore, tuttavia, sembrerà aver utilizzato il protocollo HTTP.
Le attività possono essere inviate a gestori di attività sicuri, non sicuri e, nei runtime supportati, a URI limitati con login: admin
.
Poiché le attività non vengono eseguite come utente, non possono essere inviate a URI
limitati con login: required
.
Anche gli invii di attività non seguono i reindirizzamenti.
Passaggi successivi
- Scopri di più sulle attività nel riferimento API RPC.
- Scopri di più sulle attività nella Guida di riferimento API REST.