Referenz zu gehosteten Zielen

Sie lesen die Dokumentation zu Apigee Edge.
Sehen Sie sich die Apigee X-Dokumentation an. info

Limits für Umgebungsvariablen

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

  • 1.000: 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.

In der Anwendungslaufzeit festgelegte Umgebungsvariablen

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 Instanz von Hosted Targets 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 des Edge-Kontos skaliert werden.
  • Eine Testversion von Apigee Edge ist auf eine Instanz von „Gehostete Ziele“ pro Proxy beschränkt.
  • Bei kostenpflichtigen Apigee Edge-Konten erfolgt die automatische Skalierung auf der Grundlage von Anfragerate, Antwortlatenz und anderen Anwendungsmesswerten pro Proxy.
  • Apps mit gehosteten Zielen, die sowohl in der kostenpflichtigen als auch in der Testversion von Apigee Edge bereitgestellt werden, werden bei Inaktivität auf null skaliert. In diesem Fall kann es für einen kurzen Zeitraum zu längeren Antwortzeiten kommen. Weitere Informationen finden Sie im Hilfeartikel Bekannte Probleme.

Die Manifestdatei

Um Laufzeitinformationen zum Erstellen und Bereitstellen der gehosteten Anwendung zu erfassen, 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.

Verwaltete Dateisyntax

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 Manifestdatei app.yaml enthält folgende Elemente:

  • runtime (erforderlich): Gibt die Art der Anwendung an, die Sie bereitstellen. Sie müssen node angeben.
  • runtimeVersion: (Optional) Die Version der Laufzeit, die von Ihrer Anwendung verwendet wird. 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 angeben, mit dem Ihre Anwendung gestartet wird. Standard: Node.js=npm
  • args – (optional) Array von Befehlszeilenargumenten, die an die Anwendung übergeben werden sollen (in der Standard-YAML-Array-Syntax angegeben). In der Regel werden diese dem Standardbefehl hinzugefügt. Der Standardwert ist start. Beispielsweise wird der Node.js-Anwendung standardmäßig der Befehl npm start übergeben.
  • env – Optional: Ein Array von Umgebungsvariablen (Name/Wert-Paare), die in der Laufzeitumgebung der gehosteten Ziele festgelegt werden sollen. Diese Variablen sind für die bereitgestellte Anwendung „Gehostete Ziele“ verfügbar.
    • name: Der Variablenname.
    • Wert | WertRef – Sie haben zwei Möglichkeiten. 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) angeben, die Sie zuvor in Edge erstellt haben, und einen Schlüssel. Beispiel: 
        runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password

    Beispielmanifestdateien

    Dieser Abschnitt enthält Beispielmanifestdateien für Node.js-Anwendungen. Zum Bereitstellen einer gehosteten Targets-Anwendung ist eine Manifestdatei im Verzeichnis apiproxy/resources/hosted erforderlich. Der Dateiname muss app.yaml lauten.

    Hier sehen Sie app.yaml-Beispieldateien (Manifestdateien) für Node.js-Apps.

    Beispiel für eine Umgebungsvariable mit einem Literal: 

     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 für eine KVM-Referenz (Schlüssel/Wert-Zuordnung):

    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 Ziele auf GitHub

    Apigee stellt auf GitHub Beispielproxies mit Hosted Targets-Anwendungen bereit, die in Node.js geschrieben wurden. Sie können dieses Repository klonen und der README-Anleitung zum Bereitstellen der Proxys folgen.

    Vorbereitung

    Zum Bereitstellen der Beispiele müssen zwei Tools auf Ihrem System installiert sein:

    • apigeetool: Befehlszeilentool zum Bereitstellen von Edge-Proxys.
    • get_token: Befehlszeilentool zum Abrufen eines Autorisierungstokens, das von apigeetool benötigt wird.

    Wenn Sie Beispiele lokal testen möchten, muss außerdem 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. 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 README-Anleitung folgen, um einen Beispielproxy in Edge bereitzustellen. Der Bereitstellungsbefehl wird unten gezeigt. Ersetzen Sie einfach die angegebenen Parameter durch die 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

    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 ein Bereitstellungsfehler auftritt, führen Sie den Befehl „deploy“ 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 Multi-Prozess-Managers ausgeführt wird, gibt es jetzt einen Netzwerk-Hop zwischen dem Multi-Prozess-Manager und der Bereitstellung. Natürlich ist das mit Kosten verbunden, aber erste Benchmarks zeigen, dass sie im Rahmen eines angemessenen Betrags liegen.
    • Langsame API-Antworten: Die Infrastruktur, auf der Ihre Anwendungen ausgeführt werden, wird bedarfsgerecht automatisch 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 normale API-Anfragen, da die Infrastruktur die Instanzen zur Verarbeitung der Anfragen startet.
    • 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 die Bereitstellung eine Zeitüberschreitung verursachen. Wenn Sie sie noch einmal bereitstellen, wird das Problem von selbst behoben.