Referenz zu gehosteten Zielen

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

<ph type="x-smartling-placeholder">

Limits für Umgebungsvariablen

Gehostete Ziele schränkt die Größe und Anzahl von Umgebungsvariablen ein die Sie in der Laufzeitumgebung gehosteter 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 Die Manifestdatei.

In der Anwendungslaufzeit festgelegte Umgebungsvariablen

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

  • 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 Anwendungen gehosteter Ziele je nach Typ des Edge-Kontos skalieren. die Sie haben.
  • Eine Testversion von Apigee Edge ist auf eine Instanz gehosteter Ziele pro Proxy beschränkt.
  • Kostenpflichtige Apigee Edge-Konten erhalten eine automatische Skalierung auf der Grundlage von Anforderungsrate, Antwortlatenzen, und andere Anwendungsmesswerte pro Proxy.
  • Gehostete Ziele-Apps, die sowohl in kostenpflichtigen Versionen als auch in Testversionen von Apigee Edge bereitgestellt werden, können bei Inaktivität auf null skaliert werden. In diesem Fall kann es für einen kurzen Zeitraum zu längeren Antwortzeiten kommen. Siehe auch Bekannte Probleme

Die Manifestdatei

Um Laufzeitinformationen zum Erstellen und Bereitstellen der gehosteten Anwendung zu erfassen, sucht Edge nach Eine Manifestdatei mit dem Namen app.yaml im Verzeichnis resources/hosted. Diese Datei enthält Informationen, die zum Erstellen und Bereitstellen der Anwendung „Gehostete Ziele“ 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

Die Manifestdatei app.yaml 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 die Ihre Anwendung nutzt. Standardeinstellung: Node.js LTS (v10.x). Weitere Informationen finden Sie im offiziellen Docker-Repository für Node. für weitere Optionen.
  • command (optional): Hiermit können Sie einen anderen Befehl als den Standardbefehl zum Starten Ihrer Anwendung. Standard: Node.js=npm
  • args – (optional) Array von Befehlszeilenargumenten, die an die (in der standardmäßigen YAML-Array-Syntax angegeben). In der Regel werden diese dem Standardbefehl hinzugefügt. Der Standardwert ist start. Standardmäßig wird der Node.js-App beispielsweise der Befehl npm start
  • env (optional) Ein Array von Umgebungsvariablen (Name/Wert-Paare). die in der Laufzeitumgebung von gehosteten Zielen festgelegt wird. Diese Variablen sind für Ihre Gehostete Zielanwendung bereitgestellt. <ph type="x-smartling-placeholder">
    • name: Der Variablenname.
    • Wert | 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üsselwertzuordnung muss bereits in Ihrer Edge-Umgebung vorhanden sind. Siehe Mit Schlüssel/Wert-Zuordnungen arbeiten <ph type="x-smartling-placeholder">
        </ph>
      • 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, Anschließend müssen Sie den Namen einer Schlüssel/Wert-Zuordnung (KVM), die Sie zuvor in Edge erstellt haben, sowie 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 gehosteten Targets-App ist eine Manifestdatei erforderlich, die sich in einem Verzeichnis im Verzeichnis apiproxy/resources/hosted und der Dateiname muss app.yaml sein.

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

    Beispiel, das eine literale Umgebungsvariable angibt: 

     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, das eine KVM-Referenz (Key Value Map) angibt:

    Weitere Informationen zum KVM-Zugriff finden Sie unter Die 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 Beispiel-Proxys auf GitHub mit gehosteten Zielanwendungen zur Verfügung in Node.js erstellen. Sie können dieses Repository klonen und der README-Anleitung folgen, einen der Proxys bereitstellen.

    Vorbereitung

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

    • apigeetool: Eine Befehlszeile 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.

    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 laden Sie das Repository mithilfe der Ihre bevorzugte Methode.
    3. cd zu <your install dir>/api-platform-samples/doc-samples/hosted-targets
    4. Sobald das Repository heruntergeladen ist, können Sie mit cd in eines der Beispielverzeichnisse klicken und der README-Anleitung zum Bereitstellen eines Beispielproxys in Edge. Der Bereitstellungsbefehl wird unten gezeigt. Simply Ersetzen Sie die angegebenen Parameter durch diejenigen 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 Sie einen Bereitstellungsfehler erhalten, führen Sie den folgenden Befehl aus: und wiederholen Sie den Bereitstellungsbefehl.

    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 ausgeführt wird, In der JVM des MP gibt es jetzt einen Netzwerk-Hop zwischen dem MP und dem Deployment. Natürlich Dies hat zwar Kosten, aber erste Benchmarks zeigen, dass es innerhalb eines angemessenen Betrags liegt.
    • Langsame API-Antworten: Die Infrastruktur, auf der Ihre Anwendungen ausgeführt werden automatisch skaliert wird. Das bedeutet, dass Ihre Anwendung keine Instanzen vorhanden sind. In diesem Fall dauert die nächste API-Anfrage etwas länger als typische API-Anfragen, da die Infrastruktur die Instanzen hochfährt, um Anfrage(n).
    • Bereitstellungsfehler: Wenn Sie beim Bereitstellen einer Gehosteter Targets-Proxy. Stellen Sie den Proxy noch einmal bereit. In einigen Fällen kann es bei der Bereitstellung zu einer Zeitüberschreitung kommen. Wenn Sie sie erneut bereitstellen, löst sich das Problem von selbst.