Vorgangs- und Konfigurationsreferenz für Edge Microgateway

Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen info

Edge Microgateway v. 2.5.x

In diesem Thema wird erläutert, wie Sie Edge Microgateway verwalten und konfigurieren.

Edge Microgateway aktualisieren, wenn eine Internetverbindung besteht

1. Führen Sie den folgenden npm-Befehl aus, um ein Upgrade auf die neueste Version von Edge Microgateway durchzuführen:

   npm upgrade edgemicro -g

   Wenn Sie ein Upgrade auf eine bestimmte Version von Edge Microgateway durchführen möchten, müssen Sie die Versionsnummer im Upgrade-Befehl angeben. Wenn Sie die Versionsnummer nicht angeben, wird die neueste Version installiert. Wenn Sie beispielsweise auf Version 2.5.26 aktualisieren möchten, verwenden Sie den folgenden Befehl:

   npm upgrade edgemicro@2.5.26 -g

2. Prüfen Sie die Versionsnummer. Wenn Sie beispielsweise Version 2.5.26 installiert haben,

   edgemicro --version
   current nodejs version is v8.9.0
   current edgemicro version is 2.5.26
       

3. Führen Sie schließlich ein Upgrade auf die neueste Version des edgemicro-auth-Proxys durch:

   edgemicro upgradeauth -o org_name -e env_name -u username

Konfigurationsänderungen vornehmen

Die Konfigurationsdateien, die Sie kennen sollten, sind:

• Standard-Systemkonfigurationsdatei
• Standardkonfigurationsdatei für eine neu initialisierte Edge Microgateway-Instanz
• Dynamische Konfigurationsdatei für ausgeführte Instanzen

In diesem Abschnitt werden diese Dateien und die Änderungen, die Sie daran vornehmen können, beschrieben.

Standard-Systemkonfigurationsdatei

Wenn Sie Edge Microgateway installieren, wird hier eine Standardkonfigurationsdatei für das System abgelegt:

prefix/lib/node_modules/edgemicro/config/default.yaml

Dabei ist prefix das npm-Präfixverzeichnis. Wenn Sie dieses Verzeichnis nicht finden können, lesen Sie den Abschnitt Wo ist Edge Microgateway installiert?.

Wenn Sie die Systemkonfigurationsdatei ändern, müssen Sie Edge Microgateway neu initialisieren, neu konfigurieren und neu starten:

edgemicro init
edgemicro configure [params]
edgemicro start [params]

Standardkonfigurationsdatei für neu initialisierte Edge Microgateway-Instanzen

Wenn Sie edgemicro init ausführen, wird die oben beschriebene Systemkonfigurationsdatei default.yaml im Verzeichnis ~/.edgemicro abgelegt.

Wenn Sie die Konfigurationsdatei in ~/.edgemicro ändern, müssen Sie Edge Microgateway neu konfigurieren und neu starten:

edgemicro stop
edgemicro configure [params]
edgemicro start [params]

Dynamische Konfigurationsdatei für ausgeführte Instanzen

Wenn Sie edgemicro configure [params] ausführen, wird in ~/.edgemicro eine dynamische Konfigurationsdatei erstellt. Die Datei wird nach diesem Muster benannt: org-env-config.yaml, wobei org und env die Namen Ihrer Apigee Edge-Organisation und -Umgebung sind. Mit dieser Datei können Sie Konfigurationsänderungen vornehmen und sie dann ohne Ausfallzeit neu laden. Wenn Sie beispielsweise ein Plug-in hinzufügen und konfigurieren, können Sie die Konfiguration neu laden, ohne dass es zu Ausfallzeiten kommt.

Wenn Edge Microgateway ausgeführt wird (Option ohne Ausfallzeiten):

1. Laden Sie die Edge Microgateway-Konfiguration neu:

   edgemicro reload -o org_name -e env_name -k key -s secret

   Wobei:

   • org_name ist der Name Ihrer Edge-Organisation (Sie müssen ein Organisationsadministrator sein).
   • env_name ist eine Umgebung in Ihrer Organisation, z. B. „test“ oder „prod“.
   • key ist der Schlüssel, der zuvor vom Befehl „configure“ zurückgegeben wurde.
   • secret ist der Schlüssel, der zuvor vom Befehl „configure“ zurückgegeben wurde.

   Beispiel:

   edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \
     -s 05c14356e42ed1...4e34ab0cc824

Wenn Edge Microgateway beendet wird:

1. Edge Microgateway neu starten:

   edgemicro start -o org_name -e env_name -k key -s secret

   Wobei:

   • org_name ist der Name Ihrer Edge-Organisation (Sie müssen ein Organisationsadministrator sein).
   • env_name ist eine Umgebung in Ihrer Organisation, z. B. „test“ oder „prod“.
   • key ist der Schlüssel, der zuvor vom Befehl „configure“ zurückgegeben wurde.
   • secret ist der Schlüssel, der zuvor vom Befehl „configure“ zurückgegeben wurde.

   Beispiel:

   edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \
     -s 05c1435...e34ab0cc824

Hier sehen Sie ein Beispiel für eine Konfigurationsdatei. Weitere Informationen zu den Einstellungen der Konfigurationsdatei finden Sie in der Konfigurationsreferenz für Edge Microgateway.

edge_config:
  bootstrap: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/bootstrap/organization/docs/environment/test
  jwt_public_key: 'https://docs-test.apigee.net/edgemicro-auth/publicKey'
  managementUri: 'https://api.enterprise.apigee.com'
  vaultName: microgateway
  authUri: 'https://%s-%s.apigee.net/edgemicro-auth'
  baseUri: >-
    https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s
  bootstrapMessage: Please copy the following property to the edge micro agent config
  keySecretMessage: The following credentials are required to start edge micro
  products: 'https://docs-test.apigee.net/edgemicro-auth/products'
edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  verify_api_key_url: 'https://docs-test.apigee.net/edgemicro-auth/verifyApiKey'
analytics:
  uri: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/axpublisher/organization/docs/environment/test

Umgebungsvariablen festlegen

Die Befehlszeilenschnittstellenbefehle, für die Werte für Ihre Edge-Organisation und -Umgebung erforderlich sind, sowie der Schlüssel und das Secret, die zum Starten von Edge Microgateway benötigt werden, können in diesen Umgebungsvariablen gespeichert werden:

• EDGEMICRO_ORG
• EDGEMICRO_ENV
• EDGEMICRO_KEY
• EDGEMICRO_SECRET

Das Festlegen dieser Variablen ist optional. Wenn Sie sie festlegen, müssen Sie ihre Werte nicht angeben, wenn Sie die Befehlszeilenschnittstelle (Command-Line Interface, CLI) zum Konfigurieren und Starten von Edge Microgateway verwenden.

SSL auf dem Edge Microgateway-Server konfigurieren

Sie können den Microgateway-Server so konfigurieren, dass SSL verwendet wird. Wenn SSL konfiguriert ist, können Sie APIs über Edge Microgateway mit dem Protokoll „https“ aufrufen, z. B. so:

https://localhost:8000/myapi

So konfigurieren Sie SSL auf dem Microgateway-Server:

1. Generieren oder beziehen Sie ein SSL-Zertifikat und einen Schlüssel mit dem openssl-Tool oder einer anderen Methode Ihrer Wahl.
2. Fügen Sie der Edge Microgateway-Konfigurationsdatei das Attribut edgemicro:ssl hinzu. Eine vollständige Liste der Optionen finden Sie in der Tabelle unten. Beispiel:
   

   edgemicro:
     ssl:
      key: <absolute path to the SSL key file>
      cert: <absolute path to the SSL cert file>
      passphrase: admin123 #option added in v2.2.2
      rejectUnauthorized: true #option added in v2.2.2
      requestCert: true

3. Starten Sie Edge Microgateway neu. Folgen Sie der Anleitung unter Konfigurationsänderungen vornehmen, je nachdem, welche Konfigurationsdatei Sie bearbeitet haben: die Standarddatei oder die Laufzeitkonfigurationsdatei.

Hier sehen Sie ein Beispiel für den edgemicro-Abschnitt der Konfigurationsdatei mit konfigurierter SSL-Verschlüsselung:

edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
  ssl:
    key: /MyHome/SSL/em-ssl-keys/server.key
    cert: /MyHome/SSL/em-ssl-keys/server.crt
    passphrase: admin123 #option added in v2.2.2
    rejectUnauthorized: true #option added in v2.2.2

Hier finden Sie eine Liste aller unterstützten Serveroptionen:

Client-SSL/TLS-Optionen verwenden

Sie können Edge Microgateway so konfigurieren, dass es beim Herstellen einer Verbindung zu Zielendpunkten als TLS- oder SSL-Client fungiert. Verwenden Sie in der Microgateway-Konfigurationsdatei das Element „targets“, um SSL/TLS-Optionen festzulegen.

In diesem Beispiel werden Einstellungen angegeben, die auf alle Hosts angewendet werden:

edgemicro:
...
targets:
  ssl:
    client:
      key: /Users/jdoe/nodecellar/twowayssl/ssl/client.key
      cert: /Users/jdoe/nodecellar/twowayssl/ssl/ca.crt
      passphrase: admin123
      rejectUnauthorized: true

In diesem Beispiel werden die Einstellungen nur auf den angegebenen Host angewendet:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    ssl:
      client:
        key: /Users/myname/twowayssl/ssl/client.key
        cert: /Users/myname/twowayssl/ssl/ca.crt
        passphrase: admin123
        rejectUnauthorized: true

Hier ein Beispiel für TLS:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    tls:
      client:
        pfx: /Users/myname/twowayssl/ssl/client.pfx
        passphrase: admin123
        rejectUnauthorized: true

Hier finden Sie eine Liste aller unterstützten Clientoptionen:

„edgemicro-auth“-Proxy anpassen

Standardmäßig verwendet Edge Microgateway einen Proxy, der in Apigee Edge für die OAuth2-Authentifizierung bereitgestellt wird. Dieser Proxy wird bereitgestellt, wenn Sie edgemicro configure zum ersten Mal ausführen. Sie können die Standardkonfiguration dieses Proxys ändern, um Unterstützung für benutzerdefinierte Ansprüche in einem JSON Web Token (JWT) hinzuzufügen, das Ablaufdatum des Tokens zu konfigurieren und Aktualisierungstokens zu generieren. Weitere Informationen finden Sie auf der edgemicro-auth-Seite auf GitHub.

Benutzerdefinierten Authentifizierungsdienst verwenden

Standardmäßig verwendet Edge Microgateway einen Proxy, der in Apigee Edge für die OAuth2-Authentifizierung bereitgestellt wird. Dieser Proxy wird bereitgestellt, wenn Sie edgemicro configure zum ersten Mal ausführen. Standardmäßig wird die URL dieses Proxys in der Edge Microgateway-Konfigurationsdatei so angegeben:

authUri: https://myorg-myenv.apigee.net/edgemicro-auth

Wenn Sie einen eigenen benutzerdefinierten Dienst für die Authentifizierung verwenden möchten, ändern Sie den Wert authUri in der Konfigurationsdatei, sodass er auf Ihren Dienst verweist. Sie haben beispielsweise einen Dienst, der LDAP zur Identitätsbestätigung verwendet.

Logdateien verwalten

Edge Microgateway protokolliert Informationen zu jeder Anfrage und Antwort. Logdateien enthalten nützliche Informationen für das Debugging und die Fehlerbehebung.

Wo werden Logdateien gespeichert?

Standardmäßig werden Logdateien in /var/tmp gespeichert.

Standardverzeichnis für Logdateien ändern

Das Verzeichnis, in dem Logdateien gespeichert werden, wird in der Edge Microgateway-Konfigurationsdatei angegeben. Weitere Informationen finden Sie unter Konfigurationsänderungen vornehmen.

edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Ändern Sie den Wert dir, um ein anderes Logdateiverzeichnis anzugeben.

Logs an die Konsole senden

Sie können das Logging so konfigurieren, dass Loginformationen an die Standardausgabe gesendet werden, anstatt in eine Logdatei. Setzen Sie das Flag to_console so auf „true“:

edgemicro:
  logging:
    to_console: true

Mit dieser Einstellung werden Logs an die Standardausgabe gesendet. Derzeit können Sie Protokolle nicht sowohl an stdout als auch an eine Protokolldatei senden.

Logebene festlegen

Sie können die folgenden Logebenen festlegen: info, warn und error. Die INFO-Ebene wird empfohlen. Alle API-Anfragen und ‑Antworten werden protokolliert. Dies ist die Standardeinstellung.

Protokollierungsintervalle ändern

Sie können diese Intervalle in der Edge Microgateway-Konfigurationsdatei konfigurieren. Weitere Informationen finden Sie unter Konfigurationsänderungen vornehmen.

Die konfigurierbaren Attribute sind:

• stats_log_interval: (Standard: 60) Intervall in Sekunden, in dem der Statistikdatensatz in die API-Logdatei geschrieben wird.
• rotate_interval: (Standard: 24) Intervall in Stunden, in dem Logdateien rotiert werden. Beispiel:

edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Bewährte Vorgehensweisen für die Wartung von Protokolldateien

Da sich im Laufe der Zeit immer mehr Protokolldateidaten ansammeln, empfiehlt Apigee die folgenden Vorgehensweisen:

• Da Protokolldateien recht groß werden können, sollte das Protokolldateiverzeichnis ausreichend Speicherplatz haben. Weitere Informationen finden Sie in den Abschnitten Speicherort von Logdateien und Standardverzeichnis für Logdateien ändern.
• Löschen oder verschieben Sie Protokolldateien mindestens einmal pro Woche in ein separates Archivverzeichnis.
• Wenn Sie Logs gemäß Ihrer Richtlinie löschen möchten, können Sie den CLI-Befehl edgemicro log -c verwenden, um ältere Logs zu entfernen (bereinigen).

Namenskonvention für Logdateien

Jede Edge Microgateway-Instanz erzeugt drei Arten von Protokolldateien:

• api: Loggt alle Anfragen und Antworten, die über Edge Microgateway laufen. API-Zähler (Statistiken) und Fehler werden ebenfalls in dieser Datei protokolliert.
• err: Protokolliert alles, was an stderr gesendet wird.
• out: Protokolliert alles, was an stdout gesendet wird.

Das ist die Namenskonvention:

edgemicro-<Host Name>-<Instance ID>-<Log Type>.log

Beispiel:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log
edgemicro-mymachine-local-MTQzNTg1NDMODAyMQ-err.log
edgemicro-mymachine-local-mtqzntgndmxodaymq-out.log

Inhalt von Logdateien

Hinzugefügt in Version 2.3.3

Standardmäßig werden im Protokollierungsdienst das JSON der heruntergeladenen Proxys, Produkte und das JSON Web Token (JWT) ausgelassen. Wenn Sie diese Objekte in die Protokolldateien ausgeben möchten, legen Sie beim Starten von Edge Microgateway DEBUG=* fest. Beispiel:

DEBUG=* edgemicro start -o docs -e test -k abc123 -s xyz456

Inhalt der Logdatei „api“

Die Logdatei „api“ enthält detaillierte Informationen zum Fluss von Anfragen und Antworten durch Edge Microgateway. Die Logdateien für die API haben folgende Namen:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Für jede Anfrage an Edge Microgateway werden vier Ereignisse in der Logdatei „api“ erfasst:

• Eingehende Anfrage vom Kunden
• Ausgehende Anfrage an das Ziel
• Eingehende Antwort vom Ziel
• Ausgehende Antwort an den Client

Jeder dieser separaten Einträge wird in einer Kurzschreibweise dargestellt, um die Logdateien kompakter zu machen. Hier sind vier Beispiel-Einträge, die die vier Ereignisse repräsentieren. In der Protokolldatei sehen sie so aus (die Zeilennummern dienen nur als Referenz im Dokument und werden nicht in der Protokolldatei angezeigt).

(1) 1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0
(2) 1436403888665 info treq m=GET, u=/, h=127.0.0.18080, i=0
(3) 1436403888672 info tres s=200, d=7, i=0
(4) 1436403888676 info res s=200, d=11, i=0

Sehen wir uns die einzelnen Optionen an:

1. Beispiel für eine eingehende Anfrage vom Client:

1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0

• 1436403888651 – Unix-Zeitstempel
• info: Hängt vom Kontext ab. Kann je nach Logebene „info“, „warn“ oder „error“ sein. Kann „stats“ für Statistiken, „warn“ für Warnungen oder „error“ für Fehler sein.
• req: Kennzeichnet das Ereignis. In diesem Fall eine Anfrage vom Client.
• m: Das in der Anfrage verwendete HTTP-Verb.
• u: Der Teil der URL nach dem Basispfad.
• h: Der Host und die Portnummer, die von Edge Microgateway überwacht werden.
• r: Der Remote-Host und -Port, von dem die Clientanfrage stammt.
• i: Die Anfrage-ID. Alle vier Ereigniseinträge haben dieselbe ID. Jeder Anfrage wird eine eindeutige Anfrage-ID zugewiesen. Wenn Sie Logdatensätze anhand der Anfrage-ID korrelieren, erhalten Sie wertvolle Informationen zur Latenz des Ziels.
• d: Die Dauer in Millisekunden seit dem Empfang der Anfrage durch Edge Microgateway. Im obigen Beispiel wurde die Antwort des Ziels auf Anfrage 0 nach 7 Millisekunden empfangen (Zeile 3) und nach weiteren 4 Millisekunden an den Client gesendet (Zeile 4). Die Gesamtlatenz der Anfrage betrug also 11 Millisekunden, von denen 7 Millisekunden auf das Ziel und 4 Millisekunden auf Edge Microgateway selbst entfielen.

2. Beispiel für eine ausgehende Anfrage an das Ziel:

1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0

• 1436403888651 – Unix-Zeitstempel
• info: Hängt vom Kontext ab. Kann je nach Logebene „info“, „warn“ oder „error“ sein. Kann „stats“ für Statistiken, „warn“ für Warnungen oder „error“ für Fehler sein.
• treq: Gibt das Ereignis an. In diesem Fall die Zielanfrage.
• m: Das in der Zielanfrage verwendete HTTP-Verb.
• u: Der Teil der URL nach dem Basispfad.
• h: Der Host und die Portnummer des Backend-Ziels.
• i: Die ID des Logeintrags. Alle vier Ereigniseinträge haben dieselbe ID.

3. Beispiel für eine eingehende Antwort vom Ziel

1436403888672 info tres s=200, d=7, i=0

1436403888651 – Unix-Zeitstempel

• info: Hängt vom Kontext ab. Kann je nach Logebene „info“, „warn“ oder „error“ sein. Kann „stats“ für Statistiken, „warn“ für Warnungen oder „error“ für Fehler sein.
• tres: Gibt das Ereignis an. In diesem Fall „Ziel-Antwort“.
• s: Der HTTP-Antwortstatus.
• d: Die Dauer in Millisekunden. Die Zeit, die das Ziel für den API-Aufruf benötigt hat.
• i: Die ID des Logeintrags. Alle vier Ereigniseinträge haben dieselbe ID.

4. Beispiel für eine ausgehende Antwort an den Kunden

1436403888676 info res s=200, d=11, i=0

1436403888651 – Unix-Zeitstempel

• info: Hängt vom Kontext ab. Kann je nach Protokollebene „info“, „warn“ oder „error“ sein. Kann „stats“ für Statistiken, „warn“ für Warnungen oder „error“ für Fehler sein.
• res: Gibt das Ereignis an. In diesem Fall antworten Sie dem Kunden.
• s: Der HTTP-Antwortstatus.
• d: Die Dauer in Millisekunden. Dies ist die Gesamtzeit, die für den API-Aufruf benötigt wird, einschließlich der Zeit, die von der Ziel-API und von Edge Microgateway selbst benötigt wird.
• i: Die ID des Logeintrags. Alle vier Ereigniseinträge haben dieselbe ID.

Zeitplan für Protokolldateien

Logdateien werden in dem Intervall rotiert, das durch das Konfigurationsattribut rotate_interval angegeben wird. Einträge werden weiterhin in dieselbe Logdatei aufgenommen, bis das Rotationsintervall abläuft. Bei jedem Neustart von Edge Microgateway wird jedoch eine neue UID zugewiesen und es wird ein neuer Satz von Logdateien mit dieser UID erstellt. Weitere Informationen finden Sie unter Best Practices für die Wartung von Logdateien.

Fehlermeldungen

Einige Logeinträge enthalten Fehlermeldungen. Informationen dazu, wo und warum die Fehler auftreten, finden Sie in der Edge Microgateway-Fehlerreferenz.

Edge Microgateway-Konfigurationsreferenz

Speicherort der Konfigurationsdatei

Die in diesem Abschnitt beschriebenen Konfigurationsattribute befinden sich in der Konfigurationsdatei von Edge Microgateway. Weitere Informationen finden Sie unter Konfigurationsänderungen vornehmen.

edge_config-Attribute

Mit diesen Einstellungen wird die Interaktion zwischen der Edge Microgateway-Instanz und Apigee Edge konfiguriert.

• bootstrap: (Standard: none) Eine URL, die auf einen Edge Microgateway-spezifischen Dienst verweist, der in Apigee Edge ausgeführt wird. Edge Microgateway verwendet diesen Dienst für die Kommunikation mit Apigee Edge. Diese URL wird zurückgegeben, wenn Sie den Befehl zum Generieren des öffentlichen/privaten Schlüsselpaars ausführen: edgemicro genkeys. Weitere Informationen finden Sie unter Edge Microgateway einrichten und konfigurieren.
• jwt_public_key: (Standard: none) Eine URL, die auf den Edge Microgateway-Proxy verweist, der in Apigee Edge bereitgestellt wird. Dieser Proxy dient als Authentifizierungsendpunkt für die Ausstellung signierter Zugriffstokens für Clients. Diese URL wird zurückgegeben, wenn Sie den Befehl zum Bereitstellen des Proxys ausführen: edgemicro configure. Weitere Informationen finden Sie unter Edge Microgateway einrichten und konfigurieren.

edgemicro-Attribute

Mit diesen Einstellungen wird der Edge Microgateway-Prozess konfiguriert.

• port: (Standard: 8000) Die Portnummer, die vom Edge Microgateway-Prozess überwacht wird.
• max_connections: (Standard: -1) Gibt die maximale Anzahl gleichzeitiger eingehender Verbindungen an, die Edge Microgateway empfangen kann. Wenn diese Zahl überschritten wird, wird der folgende Status zurückgegeben:
  
  res.statusCode = 429; // Too many requests
  
• max_connections_hard: (Standard: -1) Die maximale Anzahl gleichzeitiger Anfragen, die Edge Microgateway empfangen kann, bevor die Verbindung geschlossen wird. Diese Einstellung soll Denial-of-Service-Angriffe verhindern. In der Regel legen Sie dafür eine Zahl fest, die größer als „max_connections“ ist.
• Logging:
  • level: (Standard: error)
    • info: Protokolliert alle Anfragen und Antworten, die über eine Edge Microgateway-Instanz laufen.
    • warn: Es werden nur Warnmeldungen protokolliert.
    • error: Es werden nur Fehlermeldungen protokolliert.
  • dir: (Standard: /var/tmp) Das Verzeichnis, in dem Logdateien gespeichert werden.
  • stats_log_interval: (Standard: 60) Intervall in Sekunden, in dem der Statistikdatensatz in die API-Logdatei geschrieben wird.
  • rotate_interval: (Standard: 24) Intervall in Stunden, in dem Logdateien rotiert werden.

• Plug-ins: Plug-ins fügen Edge Microgateway Funktionen hinzu. Weitere Informationen zum Entwickeln von Plug-ins finden Sie unter Benutzerdefinierte Plug-ins entwickeln.

• dir: Ein relativer Pfad vom Verzeichnis „./gateway“ zum Verzeichnis „./plugins“ oder ein absoluter Pfad.
• sequence: Eine Liste von Plug‑in-Modulen, die Ihrer Edge Microgateway-Instanz hinzugefügt werden sollen. Die Module werden in der hier angegebenen Reihenfolge ausgeführt.

• debug : Fügt dem Edge Microgateway-Prozess das Remote-Debugging hinzu.
  • port: Die Portnummer, die überwacht werden soll. Legen Sie beispielsweise den IDE-Debugger so fest, dass er auf diesem Port wartet.
  • args: Argumente für den Debugging-Prozess. Beispiel: args --nolazy
    
• config_change_poll_interval: (Standard:600 Sekunden): Edge Microgateway lädt regelmäßig eine neue Konfiguration und führt einen Reload aus, wenn sich etwas geändert hat. Beim Polling werden alle Änderungen, die in Edge vorgenommen wurden (Änderungen an Produkten, Microgateway-kompatiblen Proxys usw.), sowie Änderungen an der lokalen Konfigurationsdatei erfasst.
  
• disable_config_poll_interval (Standard: „false“): Auf true setzen, um das automatische Abrufen von Änderungen zu deaktivieren.
• request_timeout: Legt ein Zeitlimit für Zielanfragen fest. Das Zeitlimit wird in Sekunden festgelegt. Wenn ein Zeitlimit auftritt, antwortet Edge Microgateway mit dem Statuscode 504. (Version 2.4.x hinzugefügt)

Headerattribute

Mit diesen Einstellungen wird konfiguriert, wie bestimmte HTTP-Header behandelt werden.

• x-forwarded-for: (Standard: „true“) Auf „false“ setzen, um zu verhindern, dass x-forwarded-for-Header an das Ziel übergeben werden. Wenn in der Anfrage ein „x-forwarded-for“-Header vorhanden ist, wird sein Wert in Edge Analytics auf den „client-ip“-Wert festgelegt.
• x-forwarded-host: (Standard: true) Auf „false“ setzen, um zu verhindern, dass x-forwarded-host-Header an das Ziel übergeben werden.
• x-request-id: (Standard: „true“) Auf „false“ setzen, um zu verhindern, dass x-request-id-Header an das Ziel übergeben werden.
• x-response-time: (Standardwert: „true“) Auf „false“ setzen, um zu verhindern, dass x-response-time-Header an das Ziel übergeben werden.
• via: (Standardwert: „true“) Auf „false“ setzen, um zu verhindern, dass „via“-Header an das Ziel übergeben werden.

oauth-Attribute

Mit diesen Einstellungen wird konfiguriert, wie die Clientauthentifizierung von Edge Microgateway erzwungen wird.

• allowNoAuthorization: (Standard: „false“) Wenn diese Option auf „true“ gesetzt ist, dürfen API-Aufrufe Edge Microgateway ohne Autorisierungsheader durchlaufen. Setzen Sie diesen Wert auf „false“, um einen Autorisierungsheader zu erzwingen (Standard).
• allowInvalidAuthorization: (Standard: „false“) Wenn auf „true“ gesetzt, dürfen API-Aufrufe durchgelassen werden, wenn das im Autorisierungsheader übergebene Token ungültig oder abgelaufen ist. Setzen Sie diesen Wert auf „false“, um gültige Tokens zu erzwingen (Standard).
• authorization-header: (Standard: Authorization: Bearer) Der Header, der zum Senden des Zugriffstokens an Edge Microgateway verwendet wird. Sie können den Standard ändern, wenn das Ziel den Autorisierungsheader für einen anderen Zweck verwenden muss.
• api-key-header (Standard: x-api-key): Der Name des Headers oder Abfrageparameters, der zum Übergeben eines API-Schlüssels an Edge Microgateway verwendet wird. Siehe auch API-Schlüssel verwenden.
• keep-authorization-header: (Standard: „false“) Wenn dieser Wert auf „true“ gesetzt ist, wird der in der Anfrage gesendete Authorization-Header an das Ziel weitergeleitet (er bleibt erhalten).
• allowOAuthOnly: Wenn auf „true“ gesetzt, muss jede API einen Autorisierungs-Header mit einem Bearer-Zugriffstoken enthalten. Damit können Sie nur das OAuth-Sicherheitsmodell zulassen (bei gleichzeitiger Abwärtskompatibilität). (Version 2.4.x hinzugefügt)
• allowAPIKeyOnly: Wenn auf „true“ gesetzt, muss jede API einen x-api-key-Header (oder einen benutzerdefinierten Speicherort) mit einem API-Schlüssel enthalten.So können Sie nur das API-Schlüssel-Sicherheitsmodell zulassen (wobei die Abwärtskompatibilität erhalten bleibt). (Hinzugefügt in Version 2.4.x)
• gracePeriod: Mit diesem Parameter lassen sich Fehler vermeiden, die durch geringfügige Abweichungen zwischen der Systemuhr und den im JWT-Autorisierungstoken angegebenen Zeiten „Not Before“ (nbf) oder „Issued At“ (iat) verursacht werden. Legen Sie diesen Parameter auf die Anzahl der Sekunden fest, die für solche Abweichungen zulässig sind. (Version 2.5.7 hinzugefügt)

Plug-in-spezifische Attribute

Weitere Informationen zu konfigurierbaren Attributen für die einzelnen Plug-ins finden Sie unter „Plug-ins verwenden“.

Proxys filtern

Sie können filtern, welche Microgateway-kompatiblen Proxys von einer Edge Microgateway-Instanz verarbeitet werden. Wenn Edge Microgateway gestartet wird, werden alle Microgateway-kompatiblen Proxys in der Organisation heruntergeladen, mit der es verknüpft ist. Verwenden Sie die folgende Konfiguration, um einzuschränken, welche Proxys vom Microgateway verarbeitet werden. Diese Konfiguration beschränkt die Proxys, die vom Microgateway verarbeitet werden, auf drei: edgemicro_proxy-1, edgemicro_proxy-2 und edgemicro_proxy-3:

proxies:
  - edgemicro_proxy-1
  - edgemicro_proxy-2
  - edgemicro_proxy-3

Häufigkeit des Analytics-Push konfigurieren

Mit diesen Konfigurationsparametern können Sie die Häufigkeit steuern, mit der Edge Microgateway Analysedaten an Apigee sendet:

• bufferSize (Optional): Die maximale Anzahl von Analytics-Datensätzen, die der Puffer aufnehmen kann, bevor die ältesten Datensätze gelöscht werden. Standard: 10.000
• batchSize (Optional): Die maximale Größe eines Batches von Analysedatensätzen, die an Apigee gesendet werden. Standard: 500
• flushInterval (Optional): Die Anzahl der Millisekunden zwischen den einzelnen Flushes eines Batches von Analysedatensätzen, die an Apigee gesendet werden. Standard: 5.000

Beispiel:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Analysedaten maskieren

Die folgende Konfiguration verhindert, dass Informationen zum Anfragepfad in Edge-Analysen angezeigt werden. Fügen Sie der Microgateway-Konfiguration Folgendes hinzu, um den Anfrage-URI und/oder den Anfragepfad zu maskieren. Der URI besteht aus dem Hostnamen und den Pfadteilen der Anfrage.

analytics:
  mask_request_uri: 'string_to_mask'
  mask_request_path: 'string_to_mask'

API-Aufrufe in Edge Analytics trennen

Sie können das Analytics-Plug-in so konfigurieren, dass ein bestimmter API-Pfad als separater Proxy in den Edge Analytics-Dashboards angezeigt wird. Sie können beispielsweise eine Systemdiagnose-API im Dashboard trennen, um Verwechslungen mit tatsächlichen API-Proxy-Aufrufen zu vermeiden. Im Analytics-Dashboard folgen getrennte Proxys diesem Namensmuster:

edgemicro_proxyname-health

Die folgende Abbildung zeigt zwei separate Proxys im Analytics-Dashboard: edgemicro_hello-health und edgemicro_mock-health:

Mit diesen Parametern können Sie relative und absolute Pfade im Analytics-Dashboard als separate Proxys trennen:

• relativePath (Optional): Gibt einen relativen Pfad an, der im Analytics-Dashboard getrennt werden soll. Wenn Sie beispielsweise /healthcheck angeben, werden alle API-Aufrufe, die den Pfad /healthcheck enthalten, im Dashboard als edgemicro_proxyname-health angezeigt. Beachten Sie, dass bei diesem Flag der Proxy-Basispfad ignoriert wird. Wenn Sie die Trennung anhand eines vollständigen Pfads, einschließlich des Basispfads, vornehmen möchten, verwenden Sie das Flag proxyPath.
• proxyPath (Optional): Gibt einen vollständigen API-Proxy-Pfad an, einschließlich des Proxy-Basispfads, der im Analysedashboard getrennt werden soll. Wenn Sie beispielsweise /mocktarget/healthcheck angeben, wobei /mocktarget der Proxy-Basispfad ist, werden alle API-Aufrufe mit dem Pfad /mocktarget/healthcheck im Dashboard als edgemicro_proxyname-health angezeigt.

In der folgenden Konfiguration wird beispielsweise jeder API-Pfad, der /healthcheck enthält, vom Analyse-Plug-in getrennt. Das bedeutet, dass /foo/healthcheck und /foo/bar/healthcheck im Analysedashboard als separater Proxy namens edgemicro_proxyname-health dargestellt werden.

analytics:
  uri: >-
    https://xx/edgemicro/ax/org/docs/environment/test
  bufferSize: 100
  batchSize: 50
  flushInterval: 500
  relativePath: /healthcheck

In der folgenden Konfiguration wird jede API mit dem Proxy-Pfad /mocktarget/healthcheck im Analysedashboard als separater Proxy namens edgemicro_proxyname-health dargestellt.

analytics:
  uri: >-
    https://xx/edgemicro/ax/org/docs/environment/test
  bufferSize: 100
  batchSize: 50
  flushInterval: 500
  proxyPath: /mocktarget/healthcheck

Edge Microgateway hinter einer Unternehmensfirewall einrichten

Unterstützte Version 2.4.x

Wenn Edge Microgateway hinter einer Firewall installiert ist, kann das Gateway möglicherweise nicht mit Apigee Edge kommunizieren. In diesem Fall haben Sie zwei Möglichkeiten:

Option 1:

Die erste Option besteht darin, die Option „edgemicro: proxy_tunnel“ in der Microgateway-Konfigurationsdatei auf „true“ zu setzen:

edge_config:

    proxy: http://10.224.16.85:3128
    proxy_tunnel: true

Wenn proxy_tunnel auf true gesetzt ist, verwendet Edge Microgateway die HTTP-Methode CONNECT, um HTTP-Anfragen über eine einzelne TCP-Verbindung zu tunneln. Dasselbe gilt, wenn die Umgebungsvariablen zum Konfigurieren des Proxys TLS-fähig sind.

Option 2:

Die zweite Möglichkeit besteht darin, einen Proxy anzugeben und „proxy_tunnel“ in der Microgateway-Konfigurationsdatei auf „false“ zu setzen. Beispiel:

edge_config:
     proxy: http://10.224.16.85:3128
     proxy_tunnel: false

In diesem Fall können Sie die folgenden Variablen festlegen, um die Hosts für jeden HTTP-Proxy zu steuern, den Sie verwenden möchten, oder um anzugeben, welche Hosts keine Edge Microgateway-Proxys verarbeiten sollen: HTTP_PROXY, HTTPS_PROXY und NO_PROXY.

Sie können NO_PROXY als durch Kommas getrennte Liste von Domains festlegen, für die Edge Microgateway keinen Proxy verwenden soll. Beispiel:

export NO_PROXY='localhost,localhost:8080'

Legen Sie HTTP_PROXY und HTTPS_PROXY auf den HTTP-Proxy-Endpunkt fest, an den Edge Microgateway Nachrichten senden kann. Beispiel:

export HTTP_PROXY='http://localhost:3786'

export HTTPS_PROXY='https://localhost:3786'

Weitere Informationen zu diesen Variablen finden Sie unter https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables.

Weitere Informationen

Edge Microgateway hinter einer Unternehmensfirewall einrichten in der Apigee-Community.

Platzhalter in Microgateway-kompatiblen Proxys verwenden

Sie können im Basispfad eines edgemicro_*-Proxys (Microgateway-kompatibel) einen oder mehrere „*“-Platzhalter verwenden. Mit dem Basispfad /team/*/members können Clients beispielsweise https://[host]/team/blue/members und https://[host]/team/green/members aufrufen, ohne dass Sie neue API-Proxys zur Unterstützung neuer Teams erstellen müssen. Beachten Sie, dass /**/ nicht unterstützt wird.

Wichtig:Apigee unterstützt NICHT die Verwendung eines Platzhalters „*“ als erstes Element eines Basispfads. Dies wird beispielsweise NICHT unterstützt: /*/-Suche.

JWT-Schlüssel rotieren

Nach der ersten Generierung eines JWT müssen Sie möglicherweise das Paar aus öffentlichen und privaten Schlüsseln ändern, das in der verschlüsselten KVM von Edge gespeichert wird. Das Generieren eines neuen Schlüsselpaars wird als Schlüsselrotation bezeichnet.

Verwendung von JWT durch Edge Microgateway

JSON Web Token (JWT) ist ein in RFC7519 beschriebener Tokenstandard. JWT bietet eine Möglichkeit, eine Reihe von Ansprüchen zu signieren, die vom Empfänger des JWT zuverlässig überprüft werden können.

Edge Microgateway verwendet JWTs als Inhabertokens für die OAuth-Sicherheit. Wenn Sie ein OAuth-Token für Edge Microgateway generieren, erhalten Sie ein JWT zurück. Sie können das JWT dann im Autorisierungsheader von API-Aufrufen verwenden. Beispiel:

curl -i http://localhost:8000/hello -H "Authorization: Bearer eyJhbGciOiJ..dXDefZEA"

Neues JWT generieren

Sie können ein JWT für Edge Microgateway mit dem Befehl edgemicro token oder einer API generieren. Beispiel:

edgemicro token get -o docs -e test -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

Mit diesem Befehl wird Apigee Edge aufgefordert, ein JWT zu generieren, das dann zum Überprüfen von API-Aufrufen verwendet werden kann. Die Parameter -i und -s sind die Consumer-ID und die Secret-Werte einer Entwickler-App in Ihrer Apigee Edge-Organisation.

Alternativ können Sie ein JWT auch mit der Management API generieren:

curl -i -X POST "http://org-env.apigee.net/edgemicro-auth/token" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "your consumer key",
    "client_secret": "your consumer secret",
    "grant_type": "client_credentials"
  }'

Wobei:

• org ist der Name Ihrer Edge-Organisation (Sie müssen ein Organisationsadministrator sein).
• env ist eine Umgebung in Ihrer Organisation, z. B. „test“ oder „prod“.
• client_id ist die Verbraucher-ID in der Entwickler-App, die Sie zuvor erstellt haben.
• client_secret ist das Consumer-Secret in der zuvor erstellten Entwickler-App.

Was ist Schlüsselrotation?

Nach der ersten Generierung eines JWT müssen Sie möglicherweise das Paar aus öffentlichen und privaten Schlüsseln ändern, das in der verschlüsselten KVM von Edge gespeichert wird. Das Generieren eines neuen Schlüsselpaars wird als Schlüsselrotation bezeichnet. Wenn Sie Schlüssel rotieren, wird ein neues privates/öffentliches Schlüsselpaar generiert und in der KVM in „microgateway“ in Ihrer Apigee Edge-Organisation/-Umgebung gespeichert. Außerdem bleibt der alte öffentliche Schlüssel mit seinem ursprünglichen Schlüssel-ID-Wert erhalten.

Zum Generieren eines JWT verwendet Edge Informationen, die in der verschlüsselten KVM gespeichert sind. Beim ersten Einrichten (Konfigurieren) von Edge Microgateway wurde ein KVM mit dem Namen microgateway erstellt und mit Schlüsseln gefüllt. Die Schlüssel in der KVM werden zum Signieren und Verschlüsseln eines JWT verwendet.

Die KVM-Schlüssel umfassen:

• private_key: Der aktuelle (zuletzt erstellte) private RSA-Schlüssel, der zum Signieren von JWTs verwendet wird.

• public_key: Das neueste (zuletzt erstellte) Zertifikat, das zum Überprüfen von JWTs verwendet wird, die mit dem „private_key“ signiert wurden.

• private_key_kid: Die ID des neuesten (zuletzt erstellten) privaten Schlüssels. Diese Schlüssel-ID ist mit dem Wert „private_key“ verknüpft und wird zur Unterstützung der Schlüsselrotation verwendet.

• public_key1_kid: Die ID des neuesten (zuletzt erstellten) öffentlichen Schlüssels. Dieser Schlüssel ist mit dem Wert „public_key1“ verknüpft und wird zur Unterstützung der Schlüsselrotation verwendet. Dieser Wert entspricht der ID des privaten Schlüssels.

• public_key1: Der neueste (zuletzt erstellte) öffentliche Schlüssel.

Wenn Sie eine Schlüsselrotation durchführen, werden vorhandene Schlüsselwerte in der Zuordnung ersetzt und neue Schlüssel hinzugefügt, um die alten öffentlichen Schlüssel beizubehalten. Beispiel:

• public_key2_kid: Die ID des alten öffentlichen Schlüssels. Dieser Schlüssel ist mit dem Wert „public_key2“ verknüpft und wird zur Unterstützung der Schlüsselrotation verwendet.

• public_key2: Der alte öffentliche Schlüssel.

Zur Überprüfung vorgelegte JWTs werden mit dem neuen öffentlichen Schlüssel überprüft. Wenn die Bestätigung fehlschlägt, wird der alte öffentliche Schlüssel verwendet, bis er abläuft (nach 30 Minuten). So können Sie Schlüssel „rotieren“, ohne den API-Traffic sofort zu unterbrechen.

Schlüsselrotation durchführen

In diesem Abschnitt wird erläutert, wie Sie eine Schlüsselrotation durchführen.

Wenn Sie Ihre Edge Microgateway-Instanz vor Version 2.5.2 konfiguriert haben

Wenn Sie Ihre Edge Microgateway-Instanz vor Version 2.5.2 konfiguriert haben, müssen Sie die folgenden beiden Befehle ausführen, um den KVM und die Authentifizierungsrichtlinie zu aktualisieren:

upgradekvm -o org -e env -u username

Weitere Informationen zu diesem Befehl finden Sie unter KVM aktualisieren.

Mit dem nächsten Befehl wird der Proxy edgemicro-oauth aktualisiert, der in Ihrer Apigee-Organisation bereitgestellt wurde, als Sie Edge Microgateway konfiguriert haben. Dieser Proxy stellt Dienste bereit, die zum Generieren von Tokens erforderlich sind.

upgradeauth -o org -e env -u username

Weitere Informationen zu diesem Befehl finden Sie unter edgemicro-auth-Proxy aktualisieren.

Schlüssel rotieren

Fügen Sie die folgende Zeile in Ihre ~/.edgemicro/org-env-config.yaml-Datei ein. Sie müssen dieselbe Organisation und Umgebung angeben, die Sie für die Verwendung durch das Microgateway konfiguriert haben:

jwk_public_keys: 'https://org-env.apigee.net/edgemicro-auth/jwkPublicKeys'

Führen Sie den Befehl zur Schlüsselrotation aus, um die Schlüssel zu rotieren. Weitere Informationen zu diesem Befehl finden Sie unter Schlüssel rotieren.

edgemicro rotatekey -o org -e env -u username -k kid_value

Beispiel:

edgemicro rotatekey -o jdoe -e test -u jdoe@google.com -k 2
current nodejs version is v6.9.1
current edgemicro version is 2.5.7
password:
Checking if private key exists in the KVM...
Checking for certificate...
Found Certificate
Generating New key/cert pair...
Extract new public key
Key Rotation successfully completed!

Der Parameter -k gibt eine Schlüssel-ID (kid) an. Diese ID wird verwendet, um einen bestimmten Schlüssel abzugleichen. Edge Microgateway verwendet diesen Wert, um bei der Schlüsselrotation zwischen einer Reihe von Schlüsseln zu wählen. Weitere Informationen finden Sie im Abschnitt 4.5 der JSON Web Key-Spezifikation.

Nach der Schlüsselrotation gibt Edge mehrere Schlüssel an Edge Microgateway zurück. Im folgenden Beispiel hat jeder Schlüssel einen eindeutigen „kid“-Wert (Schlüssel-ID). Das Microgateway verwendet diese Schlüssel dann, um Autorisierungstokens zu validieren. Wenn die Tokenvalidierung fehlschlägt, prüft das Microgateway, ob im Schlüsselset ein älterer Schlüssel vorhanden ist, und versucht es mit diesem Schlüssel. Die zurückgegebenen Schlüssel haben das Format JSON Web Key (JWK). Weitere Informationen zu diesem Format finden Sie in RFC 7517.

{
  "keys": [
    {
      "kty": "RSA",
      "n": "nSl7R_0wKLiWi6cO3n8aOJwYGBtinq723Jgg8i7KKWTSTYoszOjgGsJf_MX4JEW1YCScwpE5o4o8ccQN09iHVTlIhk8CNiMZNPipClmRVjaL_8IWvMQp1iN66qy4ldWXzXnHfivUZZogCkBNqCz7VSC5rw2Jf57pdViULVvVDGwTgf46sYveW_6h8CAGaD0KLd3vZffxIkoJubh0yMy0mQP3aDOeIGf_akeZeZ6GzF7ltbKGd954iNTiKmdm8IKhz6Y3gLpC9iwQ-kex_j0CnO_daHl1coYxUSCIdv4ziWIeM3dmjQ5_2dEvUDIGG6_Az9hTpNgPE5J1tvrOHAmunQ",
      "e": "AQAB",
      "kid": "2"
    },
    {
      "kty": "RSA",
      "n": "8BKwzx34BMUcHwTuQtmp8LFRCMxbkKg_zsWD6eOMIUTAsORexTGJsTy7z-4aH0wJ3fT-3luAAUPLBQwGcuHo0P1JnbtPrpuYjaJKSZOeIMOnlryJCspmv-1xG4qAqQ9XaZ9C97oecuj7MMoNwuaZno5MvsY-oi5B_gqED3vIHUjaWCErd4reONyFSWn047dvpE6mwRhZbcOTkAHT8ZyKkHISzopkFg8CD-Mij12unxA3ldcTV7yaviXgxd3eFSD1_Z4L7ZRsDUukCJkJ-8qY2-GWjewzoxl-mAW9D1tLK6qAdc89yFem3JHRW6L1le3YK37-bs6b2a_AqJKsKm5bWw",
      "e": "AQAB",
      "kid": "1"
    }
  ]
}

Heruntergeladene Proxys filtern

Standardmäßig lädt Edge Microgateway alle Proxys in Ihrer Edge-Organisation herunter, die mit dem Namenspräfix „edgemicro_“ beginnen. Sie können diese Standardeinstellung ändern, um Proxys herunterzuladen, deren Namen einem Muster entsprechen.

1. Öffnen Sie die Edge Micro-Konfigurationsdatei: ~/.edgemicro/org-env-config.yaml
2. Fügen Sie das Element „proxyPattern“ unter „edge_config“ hinzu. Mit dem folgenden Muster werden beispielsweise Proxys wie „edgemicro_foo“, „edgemicro_fast“ und „edgemicro_first“ heruntergeladen.

   edge_config:
   …
   proxyPattern: edgemicro_f*

Produkte ohne API-Proxys angeben

In Apigee Edge können Sie ein API-Produkt erstellen, das keine API-Proxys enthält. Mit dieser Produktkonfiguration kann ein API-Schlüssel, der mit diesem Produkt verknüpft ist, für jeden in Ihrer Organisation bereitgestellten Proxy verwendet werden. Ab Version 2.5.4 unterstützt Edge Microgateway diese Produktkonfiguration.

Debugging und Fehlerbehebung

Verbindung zu einem Debugger herstellen

Sie können Edge Microgateway mit einem Debugger wie node-inspector ausführen. Das ist nützlich für die Fehlerbehebung und das Debugging benutzerdefinierter Plugins.

1. Starten Sie Edge Microgateway im Debug-Modus neu. Fügen Sie dazu DEBUG=* am Anfang des start-Befehls ein. Beispiel:

   DEBUG=* edgemicro start -o  myorg -e test -k
         db4e9e8a95aa7fabfdeacbb1169d0a8cbe42bec19c6b98129e02 -s
         6e56af7c1b26dfe93dae78a735c8afc9796b077d105ae5618ce7ed

2. Starten Sie den Debugger und legen Sie fest, dass er die Portnummer für den Debugging-Prozess überwachen soll.
3. Sie können jetzt den Edge Microgateway-Code durchgehen, Haltepunkte festlegen, Ausdrücke beobachten usw.

Sie können Standard-Node.js-Flags für den Debugmodus angeben. --nolazy kann beispielsweise beim Debuggen von asynchronem Code helfen.

Logdateien prüfen

Wenn Probleme auftreten, sollten Sie die Logdateien auf Ausführungsdetails und Fehlerinformationen prüfen. Weitere Informationen finden Sie unter Logdateien verwalten.

API-Schlüssel sichern

API-Schlüssel bieten einen einfachen Mechanismus zur Authentifizierung von Clients, die Anfragen an Edge Microgateway senden. Sie können einen API-Schlüssel abrufen, indem Sie den Wert „Consumer Key“ (auch als „Client-ID“ bezeichnet) aus einem Apigee Edge-Produkt kopieren, das den Edge Microgateway-Authentifizierungs-Proxy enthält.

Zwischenspeichern von Schlüsseln

API-Schlüssel werden gegen Bearer-Tokens eingetauscht, die im Cache gespeichert werden. Sie können das Caching deaktivieren, indem Sie den Header Cache-Control: no-cache für eingehende Anfragen an Edge Microgateway festlegen.

API-Schlüssel verwenden

Sie können den API-Schlüssel in einer API-Anfrage entweder als Abfrageparameter oder in einem Header übergeben. Standardmäßig sind sowohl der Header- als auch der Name des Abfrageparameters x-api-key.

Beispiel für einen Abfrageparameter:

curl http://localhost:8000/foobar?x-api-key=JG616Gjz7xs4t0dvpvVsGdI49G34xGsz

Beispiel für Anzeigentitel:

curl http://localhost:8000/foobar -H "x-api-key:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

API-Schlüsselname konfigurieren

Standardmäßig wird x-api-key sowohl für den API-Schlüsselheader als auch für den Abfrageparameter verwendet. Sie können diese Standardeinstellung in der Konfigurationsdatei ändern, wie unter Konfigurationsänderungen vornehmen beschrieben. So ändern Sie den Namen beispielsweise in apiKey:

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  api-key-header: apiKey

In diesem Beispiel werden sowohl der Abfrageparameter als auch der Headername in apiKey geändert. Der Name x-api-key funktioniert in beiden Fällen nicht mehr. Siehe auch Konfigurationsänderungen vornehmen.

Beispiel:

curl http://localhost:8000/foobar -H "apiKey:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

Weitere Informationen zur Verwendung von API-Schlüsseln mit Proxyanfragen finden Sie unter Edge Microgateway sichern.

OAuth2-Tokensicherheit verwenden

In diesem Abschnitt wird beschrieben, wie Sie OAuth2-Zugriffstokens und ‑Aktualisierungstokens abrufen. Zugriffstokens werden verwendet, um sichere API-Aufrufe über das Microgateway durchzuführen. Mit Aktualisierungstokens werden neue Zugriffstokens abgerufen.

Zugriffstoken abrufen

In diesem Abschnitt wird erläutert, wie Sie mit dem edgemicro-auth-Proxy ein Zugriffstoken abrufen.

Sie können auch mit dem edgemicro token-Befehlszeilenbefehl ein Zugriffstoken abrufen. Weitere Informationen zur Befehlszeile finden Sie unter Tokens verwalten.

API 1

Ersetzen Sie in der URL die Namen Ihrer Organisation und Umgebung und ersetzen Sie die Werte für „Consumer-ID“ und „Consumer-Secret“, die Sie von einer Entwickler-App in Apigee Edge erhalten haben, durch die Body-Parameter client_id und client_secret:

curl -i -X POST "http://<org>-<test>.apigee.net/edgemicro-auth/token" \
-d '{"grant_type": "client_credentials", "client_id": "your_client_id", \
"client_secret": "your_client_secret"}' -H "Content-Type: application/json"

API 2

http://<org>-<test>.apigee.net/edgemicro-auth/token -v -u your_client_id:your_client_secret \
-d 'grant_type=client_credentials' -H "Content-Type: application/x-www-form-urlencoded"

Beispielausgabe

{
"token": "eyJraWQiOiIxIiwidHlwIjoi",
"access_token": "eyJraWQiOiIxIiwid",
"token_type": "bearer",
"expires_in": "108000"
}

Aktualisierungstoken erhalten

Wenn Sie ein Aktualisierungstoken abrufen möchten, führen Sie einen API-Aufruf an den /token-Endpunkt des edgemicro-auth-Proxys aus. Sie MÜSSEN diesen API-Aufruf mit dem password-Gewährungstyp ausführen. Die folgenden Schritte beschreiben den Prozess.

1. Zugriffs- und Aktualisierungstoken mit der /token API abrufen Beachten Sie, dass der Grant-Typ password ist:

   curl -X POST \
     https://your_organization-your_environment.apigee.net/edgemicro-auth/token \
     -H 'Content-Type: application/json' \
     -d '{
      "client_id":"mpK6l1Bx9oE5zLdifoDbF931TDnDtLq",
      "client_secret":"bUdDcFgv3nXffnU",
      "grant_type":"password",
      "username":"mpK6lBx9RoE5LiffoDbpF931TDnDtLq",
      "password":"bUdD2FvnMsXffnU"
   }'

   Die API gibt ein Zugriffstoken und ein Aktualisierungstoken zurück. Die Antwort sieht in etwa so aus:

   {
       "token": "your-access-token",
       "access_token": "your-access-token",
       "token_type": "bearer",
       "expires_in": "108000",
       "refresh_token": "your-refresh-token",
       "refresh_token_expires_in": "431999",
       "refresh_token_issued_at": "1562087304302",
       "refresh_token_status": "approved"
   }

2. Sie können das Aktualisierungstoken jetzt verwenden, um ein neues Zugriffstoken zu erhalten, indem Sie den /refresh-Endpunkt derselben API aufrufen. Beispiel:

   curl -X POST \
     https://willwitman-test.apigee.net/edgemicro-auth/refresh \
     -H 'Content-Type: application/json' \
     -d '{
      "client_id":"mpK6l1Bx9RoE5zLifoDbpF931TDnDtLq",
      "client_secret":"bUdDc2Fv3nMXffnU",
      "grant_type":"refresh_token",
      "refresh_token":"your-refresh-token"
   }'

   Die API gibt ein neues Zugriffstoken zurück. Die Antwort sieht in etwa so aus:

   {
       "token": "your-new-access-token"
       }

Dauerhaftes Monitoring

Forever ist ein Node.js-Tool, das eine Node.js-Anwendung automatisch neu startet, falls der Prozess abstürzt oder ein Fehler auftritt. Edge Microgateway hat eine forever.json-Datei, die Sie konfigurieren können, um festzulegen, wie oft und in welchen Intervallen Edge Microgateway neu gestartet werden soll. Diese Datei konfiguriert einen Forever-Dienst namens forever-monitor, der Forever programmatisch verwaltet.

Sie finden die Datei forever.json im Stammverzeichnis der Edge Microgateway-Installation. Weitere Informationen finden Sie unter Wo ist Edge Microgateway installiert?. Details zu den Konfigurationsoptionen finden Sie in der Dokumentation zu forever-monitor.

Der Befehl edgemicro forever enthält Flags, mit denen Sie den Speicherort der Datei forever.json (das Flag -f) angeben und den Forever-Überwachungsprozess starten/beenden können (das Flag -a). Beispiel:

edgemicro forever -f ~/mydir/forever.json -a start

Weitere Informationen finden Sie in der CLI-Referenz unter Forever monitoring.

Endpunkt für Konfigurationsdatei angeben

Wenn Sie mehrere Edge Microgateway-Instanzen ausführen, möchten Sie ihre Konfigurationen möglicherweise an einem zentralen Ort verwalten. Dazu geben Sie einen HTTP-Endpunkt an, von dem Edge Microgateway die Konfigurationsdatei herunterladen kann. Sie können diesen Endpunkt angeben, wenn Sie Edge Micro mit dem Flag -u starten.

Beispiel:

edgemicro start -o jdoe -e test -u http://mylocalserver/mgconfig -k public_key -s secret_key

Dabei gibt der mgconfig-Endpunkt den Inhalt Ihrer Konfigurationsdatei zurück. Diese Datei befindet sich standardmäßig in ~/.edgemicro und folgt der Namenskonvention org-env-config.yaml.

Zwischenspeichern von TCP-Verbindungsdaten deaktivieren

Mit dem Konfigurationsattribut nodelay können Sie die Datenpufferung für TCP-Verbindungen deaktivieren, die von Edge Microgateway verwendet werden.

Standardmäßig verwenden TCP-Verbindungen den Nagle-Algorithmus, um Daten zu puffern, bevor sie gesendet werden. Wenn Sie nodelay auf true festlegen, wird dieses Verhalten deaktiviert. Daten werden sofort gesendet, wenn socket.write() aufgerufen wird. Weitere Informationen finden Sie in der Node.js-Dokumentation.

So aktivieren Sie nodelay: Bearbeiten Sie die Edge Micro-Konfigurationsdatei so:

edgemicro:
  nodelay: true
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Edge Microgateway im Standalone-Modus ausführen

Sie können Edge Microgateway vollständig unabhängig von Apigee Edge ausführen. In diesem Szenario, dem sogenannten Standalone-Modus, können Sie Edge Microgateway ohne Internetverbindung ausführen und testen.

Im Standalone-Modus funktionieren die folgenden Funktionen nicht, da sie eine Verbindung zu Apigee Edge erfordern:

• OAuth und API-Schlüssel
• Kontingent
• Analytics

Benutzerdefinierte Plug-ins und die Funktion zum Unterdrücken von Spitzen funktionieren dagegen normal, da sie keine Verbindung zu Apigee Edge erfordern. Außerdem können Sie mit einem neuen Plug-in namens extauth API-Aufrufe an das Microgateway im Standalone-Modus mit einem JWT autorisieren.

Gateway konfigurieren und starten

Edge Microgateway im Standalone-Modus ausführen

1. Prüfen Sie, ob Sie Edge Microgateway-Version 2.5.25 oder höher installiert haben. Wenn nicht, müssen Sie den folgenden Befehl ausführen, um ein Upgrade auf die neueste Version durchzuführen:

   npm install -g edgemicro

   Weitere Informationen finden Sie unter Edge Microgateway installieren.

2. Erstellen Sie eine Konfigurationsdatei mit dem folgenden Namen: $HOME/.edgemicro/org_name-env_name-config.yaml

   Beispiel:

   vi $HOME/.edgemicro/foo-bar-config.yaml

3. Fügen Sie folgenden Code in die Datei ein:

   edgemicro:
     port: 8000
     max_connections: 1000
     config_change_poll_interval: 600
     logging:
       level: error
       dir: /var/tmp
       stats_log_interval: 60
       rotate_interval: 24
     plugins:
       sequence:
         - extauth
         - spikearrest
   headers:
     x-forwarded-for: true
     x-forwarded-host: true
     x-request-id: true
     x-response-time: true
     via: true
   extauth:
     publickey_url: https://www.googleapis.com/oauth2/v1/certs
   spikearrest:
     timeUnit: second
     allow: 10
     buffersize: 0

4. Exportieren Sie die folgende Umgebungsvariable mit dem Wert „1“:

   export EDGEMICRO_LOCAL=1

5. Führen Sie den folgenden start-Befehl aus und geben Sie Werte an, um den lokalen Proxy zu instanziieren:

   edgemicro start -o org_name -e environment_name -a local_proxy_name \
     -v local_proxy_version -t target_url -b base_path

   Wobei:

   • your_org ist der „org“-Name, den Sie im Namen der Konfigurationsdatei verwendet haben.
   • your_environment ist der „env“-Name, den Sie im Namen der Konfigurationsdatei verwendet haben.
   • local_proxy_name ist der Name des lokalen Proxys, der erstellt wird. Sie können einen beliebigen Namen verwenden.
   • local_proxy_version ist die Versionsnummer für den Proxy.
   • target_url ist die URL für das Ziel des Proxys. Das Ziel ist der Dienst, den der Proxy aufruft.
   • base_path ist der Basispfad des Proxys. Dieser Wert muss mit einem Schrägstrich beginnen. Geben Sie für einen Stammbasispfad nur einen Schrägstrich an, z. B. „/“.

   Beispiel:

   edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

6. Die Konfiguration testen.

   curl http://localhost:8000/echo  { "error" : "missing_authorization" }

   Da sich das extauth-Plug-in in der Datei foo-bar-config.yaml befindet, wird der Fehler „missing_authorization“ angezeigt. Dieses Plug-in validiert ein JWT, das im Autorisierungsheader des API-Aufrufs vorhanden sein muss. Im nächsten Abschnitt erhalten Sie ein JWT, mit dem API-Aufrufe ohne Fehler durchlaufen können.

Beispiel: Autorisierungstoken abrufen

Das folgende Beispiel zeigt, wie Sie ein JWT vom Edge Microgateway-JWT-Endpunkt in Apigee Edge (edgemicro-auth/jwkPublicKeys) abrufen. Dieser Endpunkt wird bereitgestellt, wenn Sie eine Standardeinrichtung und -konfiguration von Edge Microgateway durchführen. Um das JWT vom Apigee-Endpunkt abzurufen, müssen Sie zuerst die Standardeinrichtung von Edge Microgateway durchführen und mit dem Internet verbunden sein. Der Apigee-Endpunkt wird hier nur als Beispiel verwendet und ist nicht erforderlich. Sie können auch einen anderen JWT-Token-Endpunkt verwenden. Wenn Sie das tun, müssen Sie das JWT über die für diesen Endpunkt bereitgestellte API abrufen.

In den folgenden Schritten wird beschrieben, wie Sie ein Token über den edgemicro-auth/jwkPublicKeys-Endpunkt abrufen:

1. Sie müssen eine Standardeinrichtung und -konfiguration von Edge Microgateway durchführen, um den edgemicro-auth-Proxy in Ihrer Organisation/Umgebung in Apigee Edge bereitzustellen. Wenn Sie diesen Schritt bereits ausgeführt haben, müssen Sie ihn nicht wiederholen.
2. Wenn Sie Edge Microgateway in der Apigee Cloud bereitgestellt haben, müssen Sie mit dem Internet verbunden sein, damit Sie ein JWT von diesem Endpunkt abrufen können.
3. Edge Microgateway beenden:

   edgemicro stop

4. Weisen Sie in der Konfigurationsdatei, die Sie zuvor erstellt haben ($HOME/.edgemicro/org-env-config.yaml), das Attribut extauth:publickey_url dem edgemicro-auth/jwkPublicKeys-Endpunkt in Ihrer Apigee Edge-Organisation/-Umgebung zu. Beispiel:

   extauth:
     publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'

5. Starten Sie Edge Microgateway wie zuvor neu und verwenden Sie dabei die Organisations- und Umgebungsnamen, die Sie im Namen der Konfigurationsdatei verwendet haben. Beispiel:

   edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

6. Rufen Sie ein JWT-Token vom Autorisierungsendpunkt ab. Da Sie den edgemicro-auth/jwkPublicKeys-Endpunkt verwenden, können Sie diesen CLI-Befehl verwenden:

Sie können ein JWT für Edge Microgateway mit dem Befehl edgemicro token oder einer API generieren. Beispiel:

edgemicro token get -o your_org -e your_env \
  -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

Wobei:

• your_org ist der Name Ihrer Apigee-Organisation, für die Sie Edge Microgateway zuvor konfiguriert haben.
• your_env ist eine Umgebung in der Organisation.
• Mit der Option i wird der Consumer-Schlüssel einer Entwickler-App angegeben, die ein Produkt mit dem Proxy edgemicro-auth enthält.
• Mit der Option s wird der Consumer-Schlüssel einer Entwickler-App angegeben, die ein Produkt mit dem Proxy edgemicro-auth enthält.

Mit diesem Befehl wird Apigee Edge aufgefordert, ein JWT zu generieren, das dann zum Überprüfen von API-Aufrufen verwendet werden kann.

Standalone-Konfiguration testen

Rufen Sie die API mit dem im Autorisierungsheader hinzugefügten Token auf, um die Konfiguration zu testen:

curl http://localhost:8000/echo -H "Authorization: Bearer your_token

Beispiel:

curl http://localhost:8000/echo -H "Authorization: Bearer eyJraWQiOiIxIiwidHlwIjo...iryF3kwcDWNv7OQ"

Beispielausgabe:

{
   "headers":{
      "user-agent":"curl/7.54.0",
      "accept":"*/*",
      "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
      "client_received_start_timestamp":"1535134472699",
      "x-authorization-claims":"eyJhdDbiO...M1OTE5MTA1NDkifQ==",
      "target_sent_start_timestamp":"1535134472702",
      "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
      "x-forwarded-proto":"http",
      "x-forwarded-host":"localhost:8000",
      "host":"mocktarget.apigee.net",
      "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
      "via":"1.1 localhost, 1.1 google",
      "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
      "connection":"Keep-Alive"
   },
   "method":"GET",
   "url":"/",
   "body":""
}

Lokalen Proxy-Modus verwenden

Im lokalen Proxymodus ist für Edge Microgateway kein microgateway-fähiger Proxy erforderlich, der in Apigee Edge bereitgestellt wird. Stattdessen konfigurieren Sie einen „lokalen Proxy“, indem Sie beim Starten des Microgateways einen lokalen Proxynamen, einen Basispfad und eine Ziel-URL angeben. API-Aufrufe an das Microgateway werden dann an die Ziel-URL des lokalen Proxys gesendet. In allen anderen Punkten funktioniert der lokale Proxymodus genau wie der normale Modus von Edge Microgateway. Die Authentifizierung funktioniert genauso wie die Begrenzung von Spitzen, die Durchsetzung von Kontingenten und die Verwendung benutzerdefinierter Plug-ins.

Anwendungsfall und Beispiel

Der lokale Proxy-Modus ist nützlich, wenn Sie nur einen einzelnen Proxy mit einer Edge Microgateway-Instanz verknüpfen müssen. Sie können Edge Microgateway beispielsweise als Sidecar-Proxy in Kubernetes einfügen. Dabei werden ein Microgateway und ein Dienst jeweils in einem einzelnen Pod ausgeführt und das Microgateway verwaltet den Traffic zum und vom zugehörigen Dienst. Die folgende Abbildung veranschaulicht diese Architektur, in der Edge Microgateway als Sidecar-Proxy in einem Kubernetes-Cluster fungiert. Jede Microgateway-Instanz kommuniziert nur mit einem einzelnen Endpunkt des zugehörigen Dienstes:

Ein Vorteil dieser Architektur ist, dass Edge Microgateway die API-Verwaltung für einzelne Dienste übernimmt, die in einer Containerumgebung wie einem Kubernetes-Cluster bereitgestellt werden.

Lokalen Proxymodus konfigurieren

So konfigurieren Sie Edge Microgateway für den lokalen Proxymodus:

1. Prüfen Sie, ob Sie Edge Microgateway-Version 2.5.25 oder höher installiert haben. Wenn nicht, müssen Sie den folgenden Befehl ausführen, um ein Upgrade auf die neueste Version durchzuführen:

   npm install -g edgemicro

   Weitere Informationen finden Sie unter Edge Microgateway installieren.

2. Führen Sie edgemicro init aus, um Ihre lokale Konfigurationsumgebung einzurichten, genau wie bei einer typischen Edge Microgateway-Einrichtung. Siehe auch Edge Microgateway konfigurieren.
3. Führen Sie edgemicro configure wie bei einer typischen Edge Microgateway-Einrichtung aus. Beispiel:

   edgemicro configure -o your_org -e your_env -u your_apigee_username

   Mit diesem Befehl wird die edgemicro-auth-Richtlinie in Edge bereitgestellt und ein Schlüssel und ein Secret zurückgegeben, die Sie zum Starten des Microgateways benötigen. Weitere Informationen finden Sie unter Edge Microgateway konfigurieren.

4. Erstellen Sie in Apigee Edge ein API-Produkt mit den folgenden obligatorischen Konfigurationsanforderungen (alle anderen Konfigurationen können Sie nach Belieben verwalten):
   • Sie müssen dem Produkt den Proxy edgemicro-auth hinzufügen. Dieser Proxy wurde automatisch bereitgestellt, als Sie edgemicro configure ausgeführt haben.
   • Sie müssen einen Ressourcenpfad angeben. Apigee empfiehlt, diesen Pfad dem Produkt hinzuzufügen: /**. Weitere Informationen finden Sie unter Verhalten des Ressourcenpfads konfigurieren. Weitere Informationen finden Sie unter API-Produkte erstellen in der Edge-Dokumentation.

5. Erstellen Sie in Apigee Edge einen Entwickler oder verwenden Sie einen vorhandenen Entwickler. Weitere Informationen finden Sie unter Entwickler über die Edge-Verwaltungsoberfläche hinzufügen.

6. Erstellen Sie in Apigee Edge eine Entwickler-App. Sie müssen das gerade erstellte API-Produkt der App hinzufügen. Weitere Informationen finden Sie unter Apps in der Edge-Verwaltungs-UI registrieren.
7. Exportieren Sie auf dem Computer, auf dem Edge Microgateway installiert ist, die folgende Umgebungsvariable mit dem Wert „1“.

   export EDGEMICRO_LOCAL_PROXY=1

8. Führen Sie folgenden start-Befehl aus:

   edgemicro start -o your_org -e your_environment -k your_key -s your_secret \
       -a local_proxy_name -v local_proxy_version -t target_url -b base_path

   Wobei:

   • your_org ist Ihre Apigee-Organisation.
   • your_environment ist eine Umgebung in Ihrer Organisation.
   • your_key ist der Schlüssel, der zurückgegeben wurde, als Sie edgemicro configure ausgeführt haben.
   • your_secret ist das Secret, das zurückgegeben wurde, als Sie edgemicro configure ausgeführt haben.
   • local_proxy_name ist der Name des lokalen Proxys, der erstellt wird.
   • local_proxy_version ist die Versionsnummer für den Proxy.
   • target_url ist die URL für das Ziel des Proxys (der Dienst, den der Proxy aufruft).
   • base_path ist der Basispfad des Proxys. Dieser Wert muss mit einem Schrägstrich beginnen. Geben Sie für einen Stammbasispfad nur einen Schrägstrich an, z. B. „/“.

   Beispiel:

   edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
     -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
     -t http://mocktarget.apigee.net -b /echo

Konfiguration testen

Sie können die lokale Proxykonfiguration testen, indem Sie den Proxyendpunkt aufrufen. Wenn Sie beispielsweise den Basispfad /echo angegeben haben, können Sie den Proxy so aufrufen:

curl  http://localhost:8000/echo
{
  "error" : "missing_authorization",
  "error_description" : "Missing Authorization header"
}

Dieser erste API-Aufruf hat einen Fehler zurückgegeben, weil Sie keinen gültigen API-Schlüssel angegeben haben. Sie finden den Schlüssel in der Entwickler-App, die Sie zuvor erstellt haben. Öffnen Sie die App in der Edge-Benutzeroberfläche, kopieren Sie den Verbraucherschlüssel und verwenden Sie ihn so:

curl  http://localhost:8000/echo -H 'x-api-key:your_api_key'

Beispiel:

curl  http://localhost:8000/echo -H "x-api-key:DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP"

Beispielausgabe:

{
  "headers":{
    "user-agent":"curl/7.54.0",
    "accept":"*/*",
    "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
    "client_received_start_timestamp":"1535134472699",
    "x-authorization-claims":"eyJhdWQiOi...TQ0YmUtOWNlOS05YzM1OTE5MTA1NDkifQ==",
    "target_sent_start_timestamp":"1535134472702",
    "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
    "x-forwarded-proto":"http",
    "x-forwarded-host":"localhost:8000",
    "host":"mocktarget.apigee.net",
    "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
    "via":"1.1 localhost, 1.1 google",
    "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
    "connection":"Keep-Alive"
  },
  "method":"GET",
  "url":"/",
  "body":""
}