Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Riferimento per le destinazioni ospitate

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Limiti delle variabili di ambiente

I target ospitati limitano le dimensioni e il numero di variabili di ambiente che puoi impostare nell'ambiente di runtime dei target ospitati.

1000: lunghezza massima di una singola variabile di ambiente.
100: numero massimo di variabili di ambiente che puoi impostare.

Per informazioni sull'impostazione delle variabili di ambiente, consulta Il file manifest.

Variabili di ambiente impostate nel runtime dell'applicazione

Quando esegui il deployment di un'applicazione di target ospitati, vengono impostate le seguenti variabili di ambiente e sono disponibili per l'applicazione in fase di runtime:

APIGEE_ENVIRONMENT : l'ambiente in cui viene eseguito il deployment del proxy di target ospitati.
APIGEE_ORGANIZATION : l'organizzazione in cui viene eseguito il deployment del proxy di destinazione ospitato.
PORT : la porta su cui l'applicazione di target ospitati deve rimanere in ascolto.

Allocazione delle risorse di sistema

Ogni istanza di target ospitati riceve le seguenti risorse:

256 MB di memoria
CPU da 1,2 GHz

Scalabilità

Questa sezione descrive come scalare le applicazioni di target ospitati, a seconda del tipo di account Edge che hai.

Una versione di prova di Apigee Edge è limitata a un'istanza di target ospitati per proxy.
Gli account Apigee Edge a pagamento ricevono la scalabilità automatica in base al tasso di richieste, alle latenze di risposta, e ad altre metriche dell'applicazione per proxy.
Le app di target ospitati di cui è stato eseguito il deployment sia nelle versioni di prova che in quelle a pagamento di Apigee Edge vengono scalate a zero nei periodi di inattività. In questo caso, potresti notare tempi di risposta più lenti per un breve periodo. Vedi anche Problemi noti

Il file manifest

Per raccogliere informazioni di runtime per la creazione e il deployment dell'applicazione ospitata, Edge cerca un file manifest denominato app.yaml nella directory resources/hosted. Questo file contiene le informazioni necessarie per creare ed eseguire il deployment dell'applicazione di target ospitati.

Sintassi del file manifest

runtime: node
runtimeVersion: version_number
command: command_name
args: argument_array
env:
  - name: variable_name
    value: literal_value
  - name: variable_name
    valueRef:
      name: kvm_name
      key: kvm_value

Elementi del file manifest

Un file manifest app.yaml include questi elementi:

runtime : (obbligatorio) specifica il tipo di applicazione di cui stai eseguendo il deployment. Devi specificare node.
runtimeVersion : (facoltativo) la versione del runtime utilizzata dall'applicazione. Impostazione predefinita: Node.js LTS (v10.x). Per altre opzioni, consulta il repository ufficiale di Docker per Node.
command : (facoltativo) ti consente di specificare un comando da eseguire diverso dal comando predefinito utilizzato per avviare l'applicazione. Impostazione predefinita: Node.js=npm
args : (facoltativo) array di argomenti della riga di comando da passare all' applicazione (specificati nella sintassi standard dell'array YAML). In genere, questi vengono aggiunti al comando predefinito. Il valore predefinito è start. Ad esempio, per impostazione predefinita all'app Node.js verrà passato il comando npm start.
env : (facoltativo) un array di variabili di ambiente (coppie nome/valore) da impostare nell'ambiente di runtime di target ospitati. Queste variabili sono disponibili per l'app di target ospitati di cui hai eseguito il deployment.
I target ospitati limitano le dimensioni e il numero di variabili di ambiente che puoi impostare. Vedi Limiti

name : il nome della variabile.
value | valueRef : hai due opzioni. Puoi impostare un valore letterale o fare riferimento a un valore archiviato in una mappa chiave-valore. La mappa chiave-valore deve già esistere nel tuo ambiente Edge. Vedi Utilizzo delle mappe chiave-valore
- Se utilizzi value, devi specificare una variabile name e un letterale value. Ad esempio:
```
runtime: node
env:
 - name: NODE_ENV
   value: production
```
- Se utilizzi valueRef, devi fornire il name di una mappa chiave-valore (KVM) che hai creato in precedenza in Edge e una key. Ad esempio:
```
runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password
```
  La ricerca KVM è limitata all'ambiente. L'ambito dell'organizzazione e dell'applicazione/del proxy KVM non è supportato. I valori KVM vengono inseriti nel KVM una sola volta all'avvio dell'app Node.js. La modifica successiva del KVM non avrà alcun effetto. L'opzione KVM ti consente di archiviare informazioni sensibili nel KVM criptato di Edge, anziché inserirle nel bundle del proxy stesso. Vedi Utilizzo delle mappe chiave-valore.

Esempi di file manifest

Questa sezione contiene esempi di file manifest per le applicazioni Node.js applicazioni. È necessario un file manifest per eseguire il deployment di un'app di target ospitati, che deve trovarsi nella directory apiproxy/resources/hosted e il cui nome deve essere app.yaml.

Tieni presente che non devi includere una directory node_modules con un'app Node.js di target ospitati. Al momento del deployment, i target ospitati eseguono npm install per recuperare le dipendenze specificate nel file package.json.

Di seguito sono riportati esempi di file app.yaml (manifest) per le app Node.js.

Esempio che specifica una variabile di ambiente letterale:

 runtime: node
 env:
   - name: NODE_ENV
     value: production

Esempio con un comando di avvio, argomenti della riga di comando e una variabile di ambiente.

 runtime: node
 command: ./node_modules/pm2/bin/pm2
 env:
   - name: NODE_ENV
     value: production
 args:
   - app.js

Esempio che specifica un riferimento alla mappa chiave-valore (KVM):

Per saperne di più sull'accesso KVM, consulta Il file manifest.

runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password

Esempi di applicazioni di target ospitati su GitHub

Apigee fornisce proxy di esempio su GitHub con applicazioni di target ospitati scritte in Node.js. Puoi clonare questo repository e seguire le istruzioni del file README per eseguire il deployment di uno dei proxy.

Prerequisiti

Per eseguire il deployment degli esempi, devi avere due strumenti installati sul tuo sistema:

apigeetool : uno strumento a riga di comando per il deployment dei proxy Edge.
get_token : uno strumento a riga di comando per ottenere un token di autorizzazione richiesto da apigeetool.

Se vuoi testare gli esempi localmente, devi anche aver installato Node.js.

Ottenere il repository di esempio

In un browser, vai all'indirizzo https://github.com/apigee/api-platform-samples.
Fai clic su Clona o scarica ed esegui il pull del repository nel tuo sistema locale utilizzando il metodo che preferisci.
Esegui cd in <your install dir>/api-platform-samples/doc-samples/hosted-targets
Una volta scaricato il repository, puoi eseguire cd in una delle directory di esempio e seguire le istruzioni del file README per eseguire il deployment di un proxy di esempio in Edge. Il comando di deployment è mostrato di seguito. Basta sostituire i parametri indicati con quelli del tuo account Apigee:

get_token && apigeetool deployproxy \
  -o YOUR_ORGANIZATION \
  -e YOUR_ENVIRONMENT \
  --json \
  --token "$(< ~/.sso-cli/valid_token.dat)"\
  --api NAME_OF_THE_PROXY \
  --directory .

Esempio: esecuzione di un'app di esempio

Clona il repository degli esempi

cd ~/myhome
git clone https://github.com/apigee/api-platform-samples.git
cd ~/myhome/api-platform-samples/doc-samples/hosted-targets
cd node-hosted-hello

Testa l'applicazione localmente

Per eseguire questo test locale, devi aver installato Node.js.

 PORT=8081 node apiproxy/resources/hosted/index.js
 curl http://localhost:8081

Output di esempio:

{"date":"2018-03-12T21:45:22.161Z","msg":"Hello, World!"}

Esegui il deployment del proxy

 get_token && apigeetool deployproxy \
   -o myorg \
   -e test \
   --json \
   --token "$(< ~/.sso-cli/valid_token.dat)"\
   --api node-hosted-hello \
   --directory .

Testa il deployment

Il completamento del deployment potrebbe richiedere alcuni minuti. Se ricevi un errore di deployment, esegui di nuovo il comando di deployment.

curl http://myorg-test.apigee.net/node-hosted-hello

Output di esempio:

{"date":"2018-03-23T18:59:18.668Z","msg":"Hello, World!"

Problemi noti

Latenze di rete : ora che l'applicazione Node.js non viene più eseguita nella JVM di MP, è presente un hop di rete tra MP e il deployment. Naturalmente, questo ha un costo, ma i benchmark iniziali dimostrano che rientra in un importo ragionevole
Risposte API lente - L'infrastruttura che esegue le tue applicazioni viene scalata automaticamente in base alle esigenze. Ciò significa che la tua applicazione può fare lo scale down a zero istanze e, in questo caso, la richiesta API successiva richiederà un po' più di tempo rispetto alle richieste API tipiche, poiché l'infrastruttura sta avviando le istanze per elaborare le richieste.
Errore di deployment : se ricevi un errore di deployment durante il deployment di un proxy di target ospitati, prova a eseguire di nuovo il deployment del proxy. In alcuni casi, il deployment può andare in timeout e, se esegui di nuovo il deployment, il problema si risolverà da solo.