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 limitano le dimensioni e il numero di variabili di ambiente che puoi impostare nell'ambiente di runtime delle destinazioni ospitate.

  • 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 destinazioni ospitate, vengono impostate le seguenti variabili di ambiente che sono 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 è stato 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 destinazioni ospitate riceve le seguenti risorse:

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

Scalabilità

Questa sezione descrive come le applicazioni delle destinazioni ospitate vengono scalate, a seconda del tipo di account Edge di cui disponi.
  • Una versione di prova di Apigee Edge è limitata a un'istanza di destinazioni ospitate 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 delle applicazioni per proxy.
  • Le app in hosting hanno come target le app di cui è stato eseguito il deployment in versioni a pagamento e di prova di Apigee Edge scala fino a zero in caso 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 destinazioni ospitate.

Sintassi dei file più accurata

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 dei 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 utilizzato dall'applicazione. Valore predefinito: LTS Node.js (v10.x). Fai riferimento al repository ufficiale Docker per il nodo per altre opzioni.
  • command - (Facoltativo) Consente di specificare un comando da eseguire diverso dal comando predefinito utilizzato per avviare l'applicazione. Valore predefinito: 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 Destinazioni ospitate. Queste variabili sono disponibili per l'app Hosted Target di cui hai eseguito il deployment.
    • name: il nome della variabile.
    • valore | valoreRef - Hai due opzioni. Puoi impostare un valore letterale o fare riferimento a un valore memorizzato in una mappa chiave-valore. La mappa chiave-valore deve già esistere nel tuo ambiente Edge. Consulta la sezione 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 si utilizza valueRef, è necessario 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 Target ospitati è necessario un file manifest, che deve trovarsi nella directory apiproxy/resources/hosted e il nome file deve essere app.yaml.

    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 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 di Key Value Map (KVM):

    Per ulteriori informazioni sull'accesso KVM, consulta la sezione File manifest.

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

    Applicazioni di destinazione in hosting di esempio su GitHub

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

    Prerequisiti

    Per eseguire il deployment degli esempi, devi avere installato due strumenti nel 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 aver installato Node.js.

    Recupero del repository di esempio

    1. In un browser, vai ad https://github.com/apigee/api-platform-samples.
    2. Fai clic su Clona o scarica ed esegui il pull del repository sul tuo sistema locale, utilizzando il metodo che preferisci.
    3. cd in <dir di installazione>/api-platform-samples/doc-samples/hosted-targets
    4. Dopo aver scaricato il repository, puoi accedere a qualsiasi directory di esempio tramite CD e seguire le istruzioni README per eseguire il deployment di un proxy di esempio su Edge. Il comando di deployment è mostrato di seguito. Devi solo 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 esempio

    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 deployment potrebbe richiedere alcuni minuti. Se si verifica 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 del file MP, è presente un hop di rete tra l'MP e il deployment. Ovviamente questo ha un costo, ma i benchmark iniziali dimostrano che rientra entro un importo ragionevole
    • Risposte lente delle API: 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 fino a zero istanze e, in questo caso, la richiesta API successiva richiederà un po' più tempo delle richieste API tipiche poiché l'infrastruttura avvia le istanze per elaborare le richieste.
    • Errore di deployment: se ricevi un errore di deployment durante il deployment di un proxy di destinazioni ospitate, prova a eseguire nuovamente il deployment del proxy. In alcuni casi il deployment può scadere e, se esegui di nuovo il deployment, il problema si risolve da solo.