Riferimento per le destinazioni ospitate

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Limiti delle variabili di ambiente

Le destinazioni ospitate limita la dimensione e il numero di variabili di ambiente che puoi impostare nell'ambiente di runtime dei target ospitati.

  • 1000: la 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 destinazione ospitata, le seguenti variabili di ambiente vengono impostate e sono disponibili per l'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 è implementato il proxy di destinazione ospitato.
  • PORT: la porta su cui deve rimanere in ascolto l'applicazione target ospitata.

Allocazione delle risorse di sistema

Ogni istanza di Destinazioni ospitate riceve le seguenti risorse:

  • 256 MB di memoria
  • CPU da 1,2 GHz

Scalabilità

Questa sezione descrive la scalabilità delle applicazioni di Destinazioni ospitate, a seconda del tipo di account Edge di cui disponi.
  • 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 ad altre metriche delle applicazioni per proxy.
  • Le app di destinazione ospitate di cui è stato eseguito il deployment sia nelle versioni a pagamento che di prova 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 sul 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 compilare ed eseguire il deployment dell'applicazione 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 i seguenti 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. Valore predefinito: Node.js LTS (v10.x). Per altre opzioni, consulta il repository ufficiale Docker per Node.
  • command: (facoltativo) consente di specificare un comando da eseguire diverso da quello predefinito utilizzato per avviare l'applicazione. Predefinita: Node.js=npm
  • args: (facoltativo) array di argomenti della riga di comando da passare all'applicazione (specificati nella sintassi dell'array YAML standard). In genere, 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 dei target ospitati. Queste variabili sono disponibili per la tua app Destinatari ospitati di cui è stato eseguito il deployment.
    • 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 dei valori chiave. La mappa chiave-valore deve già esistere nel tuo ambiente Edge. Consulta l'articolo Utilizzo delle mappe chiave-valore
      • Se utilizzi value, devi specificare 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

    File manifest di esempio

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

    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 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, consulta File manifest.

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

    Esempi di applicazioni di destinazione ospitate su GitHub

    Apigee fornisce proxy di esempio su GitHub con applicazioni con 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 aver installato due strumenti nel sistema:

    • apigeetool: uno strumento a riga di comando per il deployment di 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

    1. In un browser, vai alla pagina https://github.com/apigee/api-platform-samples.
    2. Fai clic su Clona o scarica e importa il repository nel tuo sistema locale utilizzando il metodo che preferisci.
    3. cd a <your install dir>/api-platform-samples/doc-samples/hosted-targets
    4. Una volta scaricato il repository, puoi eseguire il cd in qualsiasi directory di esempio e seguire le istruzioni README per eseguire il deployment di un proxy di esempio su Edge. Il comando di deployment è mostrato di seguito. Basta sostituire i parametri indicati con quelli del tuo account Apigee:
      5. 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 localmente

    Per eseguire questo test locale, devi avere 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 si verifica un errore di deployment, esegui di nuovo il comando deploy.

    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 del MP, esiste un hop di rete tra il MP e il deployment. Ovviamente ciò ha un costo, ma i benchmark iniziali dimostrano che si tratta di un importo ragionevole
    • Risposte API lente: l'infrastruttura che esegue le tue applicazioni scala automaticamente in base alle esigenze. Ciò significa che la tua applicazione può effettivamente fare lo scale down a zero istanze e, in questo caso, la successiva richiesta API 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 destinazione ospitata, prova a eseguire nuovamente il deployment del proxy. In alcuni casi, il deployment può scadere e se esegui nuovamente il deployment, il problema si risolverà da solo.