Informazioni sui target ospitati

Stai visualizzando la documentazione di Apigee Edge.
Visualizza la documentazione di Apigee X.

Limiti per le variabili di ambiente

I target ospitati limitano la dimensione e il numero di variabili di ambiente che è possibile 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, che saranno disponibili per l'applicazione in fase di esecuzione:

  • APIGEE_ENVIRONMENT: l'ambiente in cui viene eseguito il deployment del proxy di destinazione in hosting.
  • APIGEE_ORGANIZATION: l'organizzazione in cui viene eseguito il deployment del proxy di destinazione in hosting.
  • PORT: la porta in cui l'applicazione Target ospitata deve rimanere in ascolto.

Allocazione delle risorse di sistema

Ogni istanza di Target ospitata riceve le seguenti risorse:

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

Scalabilità

Questa sezione descrive come le applicazioni dei target ospitati vengono scalate, a seconda del tipo di account Edge che possiedi.
  • 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 destinazione ospitate di cui è stato eseguito il deployment nelle versioni a pagamento e 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 di tempo. Consulta anche i 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 creare l'applicazione Targeted con hosting e eseguirne il deployment.

Sintassi del file manfiest

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. Valore predefinito: Node.js LTS (v10.x). Fai riferimento al repository ufficiale del Docker per il nodo per altre opzioni.
  • command - (facoltativo) ti 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. L'impostazione predefinita è start. Ad esempio, per impostazione predefinita, l'app Node.js trasmette il comando npm start.
  • (Facoltativo) env: un array di variabili di ambiente (coppie nome/valore) da impostare nell'ambiente di runtime Target ospitati. Queste variabili sono disponibili per la tua app di destinazione ospitata da te.
    • nome: il nome della variabile.
    • value | valueRef: 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 esistere già nel tuo ambiente Edge. Consulta 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, oltre a 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 i file manifest di esempio per le applicazioni Node.js. Un file manifest è necessario per eseguire il deployment di un'app Target ospitata, deve trovarsi nella directory apiproxy/resources/hosted e il nome file deve essere app.yaml.

    Di seguito sono riportati i 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 a una mappa chiave-valore (KVM):

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

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

    Applicazioni di esempio con target ospitati su GitHub

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

    Prerequisiti

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

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

    Ottenere il repository di esempio

    1. In un browser, vai a https://github.com/apigee/api-platform-samples.
    2. Fai clic su Clona o scarica ed esegui il repository sul 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 una qualsiasi delle directory di esempio e seguire le istruzioni README per eseguire il deployment di un proxy di esempio in Edge. Il comando deployment è mostrato di seguito. È sufficiente sostituire i parametri indicati con quelli per il 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 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 in locale

    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 deployment potrebbe richiedere alcuni minuti. Se viene visualizzato un messaggio di errore relativo al 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 è più in esecuzione nella JVM del MP, ora è presente un hop di rete tra il MP e il deployment. Naturalmente ciò ha un costo, ma i benchmark iniziali dimostrano che è abbastanza ragionevole
    • Risposte lente dell'API: l'infrastruttura che esegue le tue applicazioni scala automaticamente in base alle esigenze. Ciò significa che la tua applicazione può fare lo scale down fino 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 avvia le istanze per elaborare le richieste.
    • Errore di deployment: se ricevi un errore di deployment durante il deployment di un proxy di destinazione ospitato, prova a eseguire nuovamente il deployment del proxy. In alcuni casi, il deployment può scadere e, se riesegui il deployment, il problema si risolverà da solo.