Questa pagina è stata tradotta dall'API Cloud Translation.

Riferimento per le destinazioni ospitate

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Limiti delle variabili di ambiente

Le destinazioni ospitate limitano la dimensione 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 con destinazioni ospitate, vengono impostate le seguenti variabili di ambiente e disponibili per la tua applicazione in fase di runtime:

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

Allocazione delle risorse di sistema

Ogni istanza di Hosted Destinazioni riceve le seguenti risorse:

256 MB di memoria
CPU da 1,2 GHz

Scalabilità

Questa sezione descrive la scalabilità delle applicazioni Hosted Destinazioni, 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 scalabilità automatica in base al tasso di richieste, alle latenze di risposta e altre metriche dell'applicazione per proxy.
Hosting ha come target le app di cui è stato eseguito il deployment in versioni di prova e a pagamento di Apigee Edge, che vengono scalate fino a zero durante i 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 sul runtime per la creazione e il deployment dell'applicazione in hosting, Edge cerca in un file manifest denominato app.yaml nella directory resources/hosted. Questo file contiene le informazioni necessarie per la creazione e il deployment dell'applicazione Hosted Destinazioni.

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 i seguenti elementi:

runtime - (Obbligatorio) Specifica il tipo di applicazione di cui viene eseguito il deployment. Devi specificare node.
runtimeVersion: (facoltativo) la versione del runtime che utilizzati dalla tua applicazione. Valore predefinito: Node.js LTS (v10.x). Consulta il repository ufficiale Docker per Node per visualizzare altre opzioni.
command - (Facoltativo) Consente di specificare un comando da eseguire diverso da il comando predefinito usato per avviare l'applicazione. Predefinita: Node.js=npm
args - (Facoltativo) array di argomenti della riga di comando da passare all'argomento dell'applicazione (specificata nella sintassi standard dell'array YAML). In genere, vengono aggiunti al comando predefinito. Il valore predefinito è start. Ad esempio, per impostazione predefinita, l'app Node.js riceverà il comando npm start.
env: (facoltativo) un array di variabili di ambiente (coppie nome/valore) da impostare nell'ambiente di runtime dei target ospitati. Queste variabili sono disponibili di cui è stato eseguito il deployment dell'app Hosted Destinazioni.
Le destinazioni ospitate limitano la dimensione e il numero di variabili di ambiente che puoi impostare. Vedi Limiti

name: il nome della variabile.
valore | valueRef - Hai due opzioni. Puoi impostare un valore letterale o fare riferimento a un valore archiviato in una Key Value Map. La mappa chiave-valore deve esistono già nel tuo ambiente Edge. Consulta Utilizzo delle mappe chiave-valore.
- Se utilizzi value, devi specifica una variabile name e un valore letterale value. Ad esempio:
```
runtime: node
env:
 - name: NODE_ENV
   value: production
```
- Se utilizzi valueRef, devi fornire il nome di una mappa chiave-valore (KVM) creata in precedenza in Edge e una chiave. Ad esempio:
```
runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password
```
  La ricerca KVM ha come ambito l'ambiente. Organizzazione KVM e applicazione/proxy non sono supportati. I valori KVM vengono inseriti nella KVM una volta sola all'avvio dell'app Node.js. La modifica successiva della KVM non avrà alcun effetto. L'opzione KVM consente di archiviare informazioni sensibili nella KVM con crittografia perimetrale, invece di posizionarla nel bundle proxy stesso. Consulta Utilizzo delle mappe chiave-valore.

File manifest di esempio

Questa sezione contiene file manifest di esempio per Node.js diverse applicazioni. È necessario un file manifest per implementare un'app per i target ospitati e deve trovarsi nella directory apiproxy/resources/hosted e il nome del file deve essere app.yaml.

Ricorda che non è necessario includere una directory node_modules con destinazioni ospitate Node.js. Al momento del deployment, le destinazioni ospitate eseguono npm install per estrarre eventuali dipendenze specificato nel file package.json.

Di seguito sono riportati dei file app.yaml (manifest) di esempio 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 start, 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 di una mappa chiave-valore (KVM):

Per ulteriori informazioni sull'accesso KVM, vedi Il file manifest.

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

Esempi di applicazioni con target ospitati su GitHub

Apigee fornisce proxy di esempio su GitHub con applicazioni per destinazioni ospitate in Node.js. Puoi clonare questo repository e seguire le istruzioni README per per il deployment di uno qualsiasi dei proxy.

Prerequisiti

Per eseguire il deployment degli esempi, devi aver installato due strumenti nel sistema:

apigeetool: una 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 avere installato Node.js.

Ottenere il repository di esempio

In un browser, vai a https://github.com/apigee/api-platform-samples.
Fai clic su Clona o scarica ed esegui il pull del repository sul tuo sistema locale utilizzando il tuo metodo preferito.
cd a <your install dir>/api-platform-samples/doc-samples/hosted-targets
Una volta scaricato il repository, puoi eseguire il cd in una qualsiasi delle directory di esempio e seguire Istruzioni README per eseguire il deployment di un proxy di esempio su Edge. Il comando di deployment è mostrato di seguito. Simply sostituisci 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 di 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 in locale

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 il comando 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 è più in esecuzione nella JVM di MP, c'è ora un hop di rete tra quest'ultimo e il deployment. Naturalmente, ciò ha un costo, ma i benchmark iniziali dimostrano che si tratta bene entro un limite ragionevole
Risposte lente delle API: l'infrastruttura che esegue le tue applicazioni la scalabilità automatica in base alle esigenze. Ciò significa che la tua applicazione può effettivamente fare lo scale down con 0 istanze e, in questo caso, la prossima richiesta API richiederà un po' più di tempo richieste API tipiche, poiché l'infrastruttura sta avviando le istanze per elaborare richieste.
Errore di deployment: se ricevi un errore durante il deployment di Proxy per gli obiettivi ospitati, prova a eseguire nuovamente il deployment del proxy. In alcuni casi, il deployment può scadere in timeout e se esegui nuovamente il deployment, il problema si risolverà da solo.