Referenz zu gehosteten Zielen

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu Apigee X. info

Grenzwerte für Umgebungsvariablen

Bei gehosteten Zielen sind die Größe und Anzahl der Umgebungsvariablen begrenzt, die Sie in der Laufzeitumgebung für gehostete Ziele festlegen können.

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

Informationen zum Festlegen von Umgebungsvariablen finden Sie unter Manifestdatei.

In der Anwendungslaufzeit festgelegte Umgebungsvariablen

Wenn Sie eine Anwendung mit gehosteten Zielen bereitstellen, werden die folgenden Umgebungsvariablen festgelegt und sind zur Laufzeit für Ihre Anwendung verfügbar:

  • APIGEE_ENVIRONMENT - Die Umgebung, in der der gehostete Ziel-Proxy bereitgestellt wird.
  • APIGEE_ORGANIZATION - Die Organisation, in der der Proxy für gehostete Ziele bereitgestellt wird.
  • PORT - Der Port, den die Anwendung für gehostete Ziele überwachen muss.

Zuweisung von Systemressourcen

Jede Instanz für gehostete Ziele erhält die folgenden Ressourcen:

  • 256 MB Arbeitsspeicher
  • 1,2 GHz CPU

Skalierung

In diesem Abschnitt wird beschrieben, wie Anwendungen mit gehosteten Zielen je nach Art Ihres Edge-Kontos skaliert werden.
  • Eine Testversion von Apigee Edge ist auf eine Instanz für gehostete Ziele pro Proxy beschränkt.
  • Bei kostenpflichtigen Apigee Edge-Konten erfolgt die automatische Skalierung basierend auf der Anforderungsrate, den Antwortlatenzen und anderen Anwendungsmesswerten pro Proxy.
  • Anwendungen mit gehosteten Zielen, die sowohl in kostenpflichtigen als auch in Testversionen von Apigee Edge bereitgestellt werden, werden in Phasen der Inaktivität auf null skaliert. In diesem Fall kann es für kurze Zeit zu langsameren Reaktionszeiten kommen. Weitere Informationen finden Sie unter Bekannte Probleme.

Manifestdatei

Um Laufzeitinformationen zum Erstellen und Bereitstellen der gehosteten Anwendung zu erfassen, sucht Edge nach einer Manifestdatei mit dem Namen app.yaml im Verzeichnis resources/hosted. Diese Datei enthält Informationen, die zum Erstellen und Bereitstellen der Anwendung für gehostete Ziele erforderlich sind.

Syntax der Manifestdatei

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

Eine app.yaml -Manifestdatei enthält die folgenden Elemente:

  • runtime - (Erforderlich) Gibt den Typ der Anwendung an, die Sie bereitstellen. Sie müssen node angeben.
  • runtimeVersion - (Optional) Die Version der Laufzeit, die von Ihrer Anwendung verwendet wird. Standard: Node.js LTS (v10.x). Weitere Optionen finden Sie im offiziellen Docker-Repository für Node.
  • command - (Optional) Hiermit können Sie einen anderen Befehl als den Standardbefehl zum Starten Ihrer Anwendung angeben. Standard: Node.js=npm
  • args - (Optional) Ein Array von Befehlszeilenargumenten, die an die Anwendung übergeben werden sollen (in der Standard-YAML-Arraysyntax angegeben). In der Regel werden diese dem Standardbefehl hinzugefügt. Der Standardwert ist start. Standardmäßig wird beispielsweise der Node.js-Anwendung 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 sind für Ihre bereitgestellte Anwendung für gehostete Ziele verfügbar.
    • name - Der Variablenname.
    • value | valueRef - Sie haben zwei Möglichkeiten. Sie können einen Literalwert 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 einen Variablennamen (name) und einen Literalwert (value) angeben. Beispiel: 
        runtime: node
env:
 - name: NODE_ENV
   value: production
      • Wenn Sie valueRef, dann müssen Sie den Namen einer Schlüssel/Wert-Zuordnung (KVM) angeben, die Sie zuvor in Edge erstellt haben, sowie einen Schlüssel. Beispiel: 
        runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password

    Beispiel 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 apiproxy/resources/hosted Verzeichnis befinden und der Dateiname muss app.yaml lauten.

    Im Folgenden finden Sie Beispiele für app.yaml-Dateien (Manifestdateien) für Node.js-Anwendungen.

    Beispiel, in dem eine Literal-Umgebungsvariable angegeben wird: 

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

    Beispiel mit einem Startbefehl, Befehlszeilenargumenten und einer Umgebungsvariablen.

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


    Beispiel, in dem ein Verweis auf eine Schlüssel/Wert-Zuordnung (KVM) angegeben wird:

    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

    Beispielanwendungen für gehostete Ziele auf GitHub

    Apigee bietet Beispielproxys auf GitHub mit Anwendungen für gehostete Ziele, die in Node.js geschrieben wurden. Sie können dieses Repository klonen und der Anleitung in der README-Datei folgen, um einen der Proxys bereitzustellen.

    Vorbereitung

    Zum Bereitstellen 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 Autorisierungstokens, das von apigeetool benötigt wird.

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

    Beispielrepository abrufen

    1. Rufen Sie in einem Browser https://github.com/apigee/api-platform-samples auf.
    2. Klicken Sie auf Clone or download (Klonen oder herunterladen) und rufen Sie das Repository mit der gewünschten Methode auf Ihr lokales System ab.
    3. Wechseln Sie mit cd zu <Ihr Installationsverzeichnis>/api-platform-samples/doc-samples/hosted-targets
    4. Nachdem das Repository heruntergeladen wurde, können Sie zu einem der Beispielverzeichnisse wechseln und der Anleitung in der README-Datei folgen, um einen Beispielproxy in Edge bereitzustellen. Der Bereitstellungsbefehl wird unten angezeigt. 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: Beispielanwendung ausführen

    Beispielrepository 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 ein Bereitstellungsfehler auftritt, 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 nicht mehr in der JVM des Message Processors (MP) ausgeführt wird, gibt es jetzt einen Netzwerksprung zwischen dem MP und der Bereitstellung. Das ist natürlich mit Kosten verbunden, aber erste Benchmarks zeigen, dass diese im Rahmen liegen.
    • Langsamer API-Antworten : Die Infrastruktur, auf der Ihre Anwendungen ausgeführt werden, wird automatisch nach Bedarf skaliert. Das bedeutet, dass Ihre Anwendung auf null Instanzen herunterskaliert werden kann. In diesem Fall dauert die nächste API-Anfrage etwas länger als üblich, da die Infrastruktur die Instanzen hochfährt, um die Anfrage(n) zu verarbeiten.
    • Bereitstellungsfehler : Wenn beim Bereitstellen eines Proxys für gehostete Ziele ein Bereitstellungsfehler auftritt, versuchen Sie, den Proxy noch einmal bereitzustellen. In einigen Fällen kann es zu einem Timeout bei der Bereitstellung kommen. Wenn Sie die Bereitstellung noch einmal ausführen, wird das Problem behoben.