Referenz zu gehosteten Zielen

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Limits für Umgebungsvariablen

Gehostete Ziele begrenzen die Größe und Anzahl der Umgebungsvariablen, die Sie in der Laufzeitumgebung für gehostete Ziele festlegen können.

  • 1000: Maximale Länge einer einzelnen Umgebungsvariablen.
  • 100: Maximale Anzahl von Umgebungsvariablen, die Sie festlegen können.

Informationen zum Festlegen von Umgebungsvariablen finden Sie unter Manifestdatei.

Umgebungsvariablen, die in der Anwendungslaufzeit festgelegt sind

Wenn Sie eine gehostete Zielanwendung bereitstellen, werden die folgenden Umgebungsvariablen festgelegt und stehen Ihrer Anwendung zur Laufzeit zur Verfügung:

  • APIGEE_ENVIRONMENT: Die Umgebung, in der der gehostete Zielproxy bereitgestellt wird.
  • APIGEE_ORGANIZATION: Die Organisation, in der der gehostete Zielproxy bereitgestellt wird.
  • PORT: Der Port, den die gehostete Zielanwendung überwachen muss.

Zuweisung von Systemressourcen

Jede gehostete Zielinstanz erhält die folgenden Ressourcen:

  • 256 MB Arbeitsspeicher
  • 1,2-GHz-CPU

Skalierung

In diesem Abschnitt wird beschrieben, wie gehostete Zielanwendungen je nach Art Ihres Edge-Kontos skaliert werden.
  • Eine Testversion von Apigee Edge ist auf eine gehostete Zielinstanz pro Proxy beschränkt.
  • Kostenpflichtige Apigee Edge-Konten erhalten Autoscaling auf der Grundlage von Anfragerate, Antwortlatenzen und anderen Anwendungsmesswerten pro Proxy.
  • Gehostete Ziel-Apps, die sowohl für die kostenpflichtige Version als auch für die Testversionen von Apigee Edge bereitgestellt werden, skalieren bei Inaktivität auf null. In diesem Fall kann es für kurze Zeit zu längeren Antwortzeiten kommen. Siehe auch Bekannte Probleme

Die Manifestdatei

Zum Erfassen von Laufzeitinformationen zum Erstellen und Bereitstellen der gehosteten Anwendung sucht Edge im Verzeichnis resources/hosted nach einer Manifestdatei mit dem Namen app.yaml. Diese Datei enthält Informationen, die zum Erstellen und Bereitstellen der Anwendung "Hosted Targets" erforderlich sind.

Syntax von Manfiest-Dateien

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

Elemente der Manifestdatei

Die Manifestdatei app.yaml enthält folgende Elemente:

  • runtime: (Erforderlich) Gibt den Anwendungstyp an, den Sie bereitstellen. Sie müssen node angeben.
  • runtimeVersion: (Optional) Die Version der Laufzeit, die Ihre Anwendung verwendet. Standardeinstellung: Node.js LTS (v10.x) Weitere Optionen finden Sie im offiziellen Docker-Repository für Node.
  • command (optional): Hier können Sie einen anderen Befehl als den Standardbefehl zum Starten der Anwendung angeben. Standard: Node.js=npm
  • args – (Optional) Array von Befehlszeilenargumenten, die an die Anwendung übergeben werden (in der Standard-YAML-Array-Syntax angegeben). In der Regel werden diese dem Standardbefehl hinzugefügt. Der Standardwert ist start. Der Node.js-Anwendung wird beispielsweise standardmäßig der Befehl npm start übergeben.
  • env – (optional) ein Array von Umgebungsvariablen (Name/Wert-Paare), die in der Laufzeitumgebung für gehostete Ziele festgelegt werden sollen. Diese Variablen stehen für die bereitgestellte gehostete Zielanwendung zur Verfügung.
    • name: Der Variablenname.
    • value | valueRef: Sie haben zwei Optionen. Sie können einen Literalwert festlegen oder auf einen Wert verweisen, der in einer Schlüssel/Wert-Zuordnung gespeichert ist. Die Schlüssel/Wert-Zuordnung muss bereits in Ihrer Edge-Umgebung vorhanden sein. Weitere Informationen finden Sie unter Mit Schlüssel/Wert-Zuordnungen arbeiten.
      • Wenn Sie value verwenden, müssen Sie eine Variable name und ein Literal value angeben. Beispiel: 
        runtime: node
env:
 - name: NODE_ENV
   value: production
      • Wenn Sie valueRef verwenden, müssen Sie den Namen einer Schlüssel/Wert-Zuordnung (KVM), die Sie zuvor in Edge erstellt haben, und einen Schlüssel angeben. Beispiel: 
        runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password

    Beispiele für Manifestdateien

    Dieser Abschnitt enthält Beispielmanifestdateien für Node.js-Anwendungen. Zum Bereitstellen einer Anwendung für gehostete Ziele ist eine Manifestdatei erforderlich. Sie muss sich im Verzeichnis apiproxy/resources/hosted befinden und der Dateiname muss app.yaml lauten.

    Es folgen Beispieldateien (app.yaml) (Manifest) für Node.js-Apps.

    Beispiel mit einer literalen Umgebungsvariable: 

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

    Beispiel mit einem Startbefehl, Befehlszeilenargumenten und einer Umgebungsvariable.

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


    Beispiel mit einer KVM-Referenz (Key Value Map):

    Weitere Informationen zum KVM-Zugriff finden Sie unter Manifestdatei.

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

    Beispiele für gehostete Zielanwendungen auf GitHub

    Apigee bietet auf GitHub Beispiel-Proxys mit in Node.js geschriebenen gehosteten Zielanwendungen. Sie können dieses Repository klonen und der Readme-Anleitung folgen, um einen der Proxys bereitzustellen.

    Voraussetzungen

    Zur Bereitstellung der Beispiele müssen zwei Tools auf Ihrem System installiert sein:

    • apigeetool: Ein Befehlszeilentool zum Bereitstellen von Edge-Proxys.
    • get_token – Ein Befehlszeilentool zum Abrufen eines für Apigeetool erforderlichen Autorisierungstokens.

    Wenn Sie Beispiele lokal testen möchten, muss Node.js installiert sein.

    Beispiel-Repository abrufen

    1. Rufen Sie in einem Browser https://github.com/apigee/api-platform-samples auf.
    2. Klicken Sie auf Klonen oder herunterladen und rufen Sie das Repository mit Ihrer bevorzugten Methode auf Ihr lokales System ab.
    3. cd in <your install dir>/api-platform-samples/doc-samples/hosted-targets.
    4. Nachdem das Repository heruntergeladen wurde, können Sie mit „cd“ in ein beliebiges Beispielverzeichnis klicken und der Readme-Anleitung folgen, um einen Beispielproxy in Edge bereitzustellen. Der Bereitstellungsbefehl wird unten gezeigt. Ersetzen Sie einfach die angegebenen Parameter durch die Parameter für Ihr Apigee-Konto:
      5. get_token && apigeetool deployproxy \
  -o YOUR_ORGANIZATION \
  -e YOUR_ENVIRONMENT \
  --json \
  --token "$(< ~/.sso-cli/valid_token.dat)"\
  --api NAME_OF_THE_PROXY \
  --directory .

    Beispiel: Beispiel-App ausführen

    Beispiel-Repository klonen

    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

    Anwendung lokal testen

    Für diesen lokalen Test muss Node.js installiert sein.

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

    Beispielausgabe:

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

    Proxy bereitstellen

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

    Deployment testen

    Die Bereitstellung kann einige Minuten dauern. Wenn Sie einen Bereitstellungsfehler erhalten, führen Sie den Bereitstellungsbefehl noch einmal aus.

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

    Beispielausgabe:

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

    Bekannte Probleme

    • Netzwerklatenzen: Da die Node.js-Anwendung jetzt nicht mehr in der JVM des MP ausgeführt wird, gibt es jetzt einen Netzwerk-Hop zwischen der MP und der Bereitstellung. Dies ist natürlich teuer, aber erste Benchmarks zeigen, dass dies innerhalb eines angemessenen Rahmens liegt.
    • Langsame API-Antworten – Die Infrastruktur, auf der Ihre Anwendungen ausgeführt werden, wird je nach Bedarf automatisch skaliert. Das bedeutet, dass Ihre Anwendung tatsächlich auf null Instanzen herunterskalieren kann. In diesem Fall dauert die nächste API-Anfrage etwas länger als typische API-Anfragen, da die Infrastruktur die Instanz(en) hochfährt, um die Anfrage(n) zu verarbeiten.
    • Bereitstellungsfehler: Wenn Sie bei der Bereitstellung eines gehosteten Ziel-Proxys einen Bereitstellungsfehler erhalten, versuchen Sie, den Proxy noch einmal bereitzustellen. In einigen Fällen kann es zu einer Zeitüberschreitung bei der Bereitstellung kommen. Wenn Sie sie neu bereitstellen, löst sich das Problem von selbst.