Il runtime Node.js è lo stack software responsabile dell'installazione il codice e le sue dipendenze ed eseguire il servizio.
Il runtime Node.js per App Engine nell'ambiente standard è
dichiarato in: app.yaml
file:
runtime: nodejsVERSION
Dove VERSION è il numero di versione di Node.js MAJOR
. Per
Ad esempio, per utilizzare la versione più recente di Node.js, Node.js 22 (anteprima), specifica
22
.
Per le altre versioni di Node.js supportate e la versione Ubuntu corrispondente per il tuo Per la versione Node.js, consulta la pianificazione del supporto del runtime.
Versione Node.js
Il runtime Node.js utilizza l'ultima release stabile della versione
specificato nel file app.yaml
. App Engine si aggiorna automaticamente
alle nuove patch e alle versioni di release secondarie, ma non si aggiornerà automaticamente
la versione principale.
Ad esempio, il deployment dell'applicazione potrebbe essere eseguito su Node.js 10.9.4 e versioni successive. automaticamente alla versione 10.10.0, ma non verrà aggiornato a Node.js 12.x.x.
Poiché le versioni secondarie e patch vengono aggiornate automaticamente, se presente
Proprietà engines.node
nel tuo file package.json
può
specificare solo la versione principale ed essere compatibile con la versione Node.js
specificato nel file app.yaml
.
Ad esempio per 22 (anteprima):
22.x.x
^22.0.0
~22
>=6
Se specifichi una versione Node.js incompatibile nel file package.json
,
il deployment avrà esito negativo con un messaggio di errore.
Dipendenze
Durante il deployment, il runtime installa le dipendenze utilizzando
Comando npm install
. Anche il runtime
supporta i gestori di pacchetti Yarn (yarn.lock
) e Pnpm (pnpm-lock.yaml
).
Per ulteriori informazioni, vedi
Specifica delle dipendenze.
Poiché il runtime esegue una nuova installazione, non è necessario caricare
node_modules
cartella.
Per supportare i pacchetti Node.js che richiedono estensioni native, il runtime include pacchetti di sistema che consentono di utilizzare strumenti come ImageMagick, FFmpeg e Chrome headless. Consulta l'elenco completo dei pacchetti alla pagina Pacchetti di sistema inclusi. Per richiedere un pacco, segnalare un problema in Issue Tracker.
Script di build Gestione dei partner di rete
Per impostazione predefinita, il runtime Node.js esegue npm run build
se uno script build
è stato rilevato in package.json
. Se hai bisogno di un controllo aggiuntivo sulla build
passaggi prima di avviare l'applicazione, puoi fornire un passaggio di build personalizzato
aggiungendo uno script gcp-build
al tuo file package.json
.
Per impedire alla build di eseguire lo script npm run build
, devi:
- Aggiungi uno script
gcp-build
con un valore vuoto nel filepackage.json
:"gcp-build":""
. Per maggiori dettagli sulla configurazione dell'package.json
, consulta Configurazioni buildpacks di Node.js. Aggiungi la
GOOGLE_NODE_RUN_SCRIPTS
con un valore vuoto nel fileapp.yaml
.build_env_variables: GOOGLE_NODE_RUN_SCRIPTS: ''
build_env_variables
nel file app.yaml
.
Avvio dell'applicazione
Per impostazione predefinita, il runtime avvia l'applicazione eseguendo node server.js
.
Se specifichi uno script start
nel file package.json
, il tempo di esecuzione
esegue invece lo script di avvio specificato. Ad esempio:
"scripts": {
"start": "node app.js"
}
Affinché la tua app riceva richieste HTTP, lo script start
deve avviare un server web in ascolto sull'host 0.0.0.0
e sulla porta specificata dalla PORT
variabile di ambiente, accessibile in Node.js come process.env.PORT
.
Per ottenere prestazioni ottimali, lo script start
deve essere leggero ed escludere
perché viene eseguita ogni volta che viene una nuova istanza dell'applicazione
è stato creato.
Puoi ignorare questo comportamento specificando uno script nel
Campo entrypoint
tra app.yaml
. Invece di eseguire node server.js
o uno script di avvio,
Il runtime avvia l'applicazione con il comando specificato
nel mese di entrypoint
.
Variabili di ambiente
Le seguenti variabili di ambiente sono impostate dal runtime:
Variabile di ambiente | Descrizione |
---|---|
GAE_APPLICATION
|
L'ID della tua applicazione App Engine. Questo ID è preceduto dal prefisso "region code~" ad esempio "e~" per le applicazioni distribuite in Europa. |
GAE_DEPLOYMENT_ID |
L'ID del deployment attuale. |
GAE_ENV |
L'ambiente App Engine. Impostata su standard . |
GAE_INSTANCE |
L'ID dell'istanza su cui è attualmente in esecuzione il servizio. |
GAE_MEMORY_MB |
La quantità di memoria disponibile per il processo di richiesta, in MB. |
GAE_RUNTIME |
Il tempo di esecuzione specificato nel file app.yaml . |
GAE_SERVICE |
Il nome del servizio specificato nel file app.yaml . Se non viene specificato alcun nome di servizio, viene impostato su default . |
GAE_VERSION |
L'etichetta della versione corrente del servizio. |
GOOGLE_CLOUD_PROJECT |
L'ID progetto Google Cloud associato alla tua applicazione. |
PORT |
La porta che riceve le richieste HTTP. |
NODE_ENV (disponibile solo nel runtime Node.js) |
Imposta su production quando viene eseguito il deployment del servizio. |
Puoi
definisci altre variabili di ambiente nel file app.yaml
,
ma non è possibile eseguire l'override dei valori precedenti, ad eccezione di NODE_ENV
.
Proxy HTTPS e di forwarding
App Engine termina le connessioni HTTPS al bilanciatore del carico
inoltra le richieste alla tua applicazione. Alcune applicazioni devono determinare
l'IP e il protocollo della richiesta originale. L'indirizzo IP dell'utente è disponibile in
l'intestazione X-Forwarded-For
standard. Applicazioni che lo richiedono
le informazioni devono configurare il framework web per considerare attendibile il proxy.
Con Express.js, utilizza l'impostazione trust proxy
:
app.set('trust proxy', true);
Filesystem
Il runtime include un file system completo. Il file system è di sola lettura, ad eccezione di
la località /tmp
, ovvero un disco virtuale per l'archiviazione di dati
la RAM dell'istanza di App Engine.
Server metadati
Ogni istanza dell'applicazione può utilizzare il server di metadati di App Engine per eseguire query sulle informazioni sull'istanza e sul tuo progetto.
Puoi accedere al server di metadati tramite i seguenti endpoint:
http://metadata
http://metadata.google.internal
Le richieste inviate al server dei metadati devono includere l'intestazione della richiesta
Metadata-Flavor: Google
. Questa intestazione indica che la richiesta è stata inviata con
l'intenzione di recuperare i valori dei metadati.
La tabella seguente elenca gli endpoint per i quali è possibile effettuare richieste HTTP metadati specifici:
Endpoint metadati | Descrizione |
---|---|
/computeMetadata/v1/project/numeric-project-id |
Il numero del progetto assegnato al tuo progetto. |
/computeMetadata/v1/project/project-id |
L'ID progetto assegnato al progetto. |
/computeMetadata/v1/instance/region |
La regione in cui è in esecuzione l'istanza. |
/computeMetadata/v1/instance/service-accounts/default/aliases |
|
/computeMetadata/v1/instance/service-accounts/default/email |
L'indirizzo email dell'account di servizio predefinito assegnato al progetto. |
/computeMetadata/v1/instance/service-accounts/default/ |
Elenca tutti gli account di servizio predefiniti per il tuo progetto. |
/computeMetadata/v1/instance/service-accounts/default/scopes |
Elenca tutti gli ambiti supportati per gli account di servizio predefiniti. |
/computeMetadata/v1/instance/service-accounts/default/token |
Restituisce il token di autenticazione che può essere utilizzato per autenticare l'applicazione in altre API Google Cloud. |
Ad esempio, per recuperare l'ID progetto, invia una richiesta a
http://metadata.google.internal/computeMetadata/v1/project/project-id
.