Vorgangs- und Konfigurationsreferenz für Edge Microgateway

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

Edge Microgateway v. 2.5.x

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

Edge Microgateway aktualisieren, wenn Sie eine Internetverbindung haben

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

   npm upgrade edgemicro -g

   Wenn Sie ein Upgrade auf eine bestimmte Version von Edge Microgateway ausführen möchten, müssen Sie die Versionsnummer im Upgrade-Befehl angeben. Wenn Sie die Versionsnummer nicht angeben, wird die aktuelle Version installiert. Verwenden Sie beispielsweise den folgenden Befehl, um ein Upgrade auf Version 2.5.26 durchzuführen:

   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 aktuelle Version des edgemicro-auth-Proxys durch:

   edgemicro upgradeauth -o org_name -e env_name -u username

Konfigurationsänderungen vornehmen

Zu den Konfigurationsdateien, die Sie kennen sollten, gehören:

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

In diesem Abschnitt werden diese Dateien und die Änderungen daran erläutert.

Standard-Systemkonfigurationsdatei

Wenn Sie Edge Microgateway installieren, wird hier eine Standard-Systemkonfigurationsdatei abgelegt:

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

Dabei ist prefix das Präfixverzeichnis npm. 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 laufende Instanzen

Wenn Sie edgemicro configure [params] ausführen, wird in ~/.edgemicro eine dynamische Konfigurationsdatei erstellt. Die Datei wird nach folgendem Muster benannt: org-env-config.yaml, wobei org und env die Namen Ihrer Apigee Edge-Organisation und -Umgebung sind. Sie können diese Datei verwenden, um Konfigurationsänderungen vorzunehmen und sie dann ohne Ausfallzeiten neu zu laden. Wenn Sie beispielsweise ein Plug-in hinzufügen und konfigurieren, können Sie die Konfiguration ohne Ausfallzeiten neu laden, wie unten erläutert.

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

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 Administrator der Organisation 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 wurde:

1. Starten Sie Edge Microgateway neu:

   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 Administrator der Organisation 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 eine Beispielkonfigurationsdatei. Weitere Informationen zu den Einstellungen der Konfigurationsdatei finden Sie in der Edge Microgateway-Konfigurationsreferenz.

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 Befehle der Befehlszeile, die Werte für Ihre Edge-Organisation und -Umgebung erfordern, sowie der Schlüssel und das Secret, die zum Starten von Edge Microgateway erforderlich sind, 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 Befehlszeile (CLI) verwenden, um Edge Microgateway zu konfigurieren und zu starten.

SSL auf dem Edge Microgateway-Server konfigurieren

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

https://localhost:8000/myapi

So konfigurieren Sie SSL auf dem Microgateway-Server:

1. Generieren oder rufen Sie ein SSL-Zertifikat und einen Schlüssel mit dem Dienstprogramm openssl oder einer anderen Methode ab.
2. Fügen Sie das Attribut edgemicro:ssl zur Edge Microgateway-Konfigurationsdatei 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. Führen Sie die Schritte unter Konfigurationsänderungen vornehmen aus, je nachdem, welche Konfigurationsdatei Sie bearbeitet haben: die Standarddatei oder die Laufzeitkonfigurationsdatei.

Hier sehen Sie ein Beispiel für den Abschnitt edgemicro der Konfigurationsdatei mit konfiguriertem SSL:

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:

SSL/TLS-Optionen für Clients verwenden

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

In diesem Beispiel werden Einstellungen bereitgestellt, 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 auf Apigee Edge bereitgestellten Proxy für die OAuth2-Authentifizierung. 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 Anforderungen zu einem JSON Web Token (JWT) hinzuzufügen, den Tokenablauf zu konfigurieren und Aktualisierungstokens zu generieren. Weitere Informationen finden Sie auf der GitHub-Seite edgemicro-auth.

Benutzerdefinierten Authentifizierungsdienst verwenden

Standardmäßig verwendet Edge Microgateway einen auf Apigee Edge bereitgestellten Proxy für die OAuth2-Authentifizierung. 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 so, dass er auf Ihren Dienst verweist. Beispielsweise haben Sie möglicherweise einen Dienst, der LDAP zur Identitätsprüfung verwendet.

Logdateien verwalten

Edge Microgateway protokolliert Informationen zu jeder Anfrage und Antwort. Logdateien enthalten nützliche Informationen zur Fehlerbehebung und zum Debugging.

Speicherort von Protokolldateien

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 Verzeichnis für die Protokolldatei anzugeben.

Logs an die Konsole senden

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

edgemicro:
  logging:
    to_console: true

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

Protokollierungsebene festlegen

Sie können die folgenden Logebenen festlegen: info, warn und error. Die Info-Stufe wird empfohlen. Es werden alle API-Anfragen und -Antworten 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

Best Practices für die Wartung von Protokolldateien

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

• Da Protokolldateien sehr groß werden können, muss im Verzeichnis der Protokolldateien ausreichend Speicherplatz vorhanden sein. Weitere Informationen finden Sie in den folgenden Abschnitten: Wo Logdateien gespeichert werden und Standardverzeichnis für Logdateien ändern.
• Löschen Sie Protokolldateien mindestens einmal pro Woche oder verschieben Sie sie in ein separates Archivverzeichnis.
• Wenn Ihre Richtlinie das Löschen von Logs vorsieht, können Sie den CLI-Befehl edgemicro log -c verwenden, um ältere Logs zu entfernen (zu bereinigen).

Namenskonvention für Logdateien

Jede Edge Microgateway-Instanz erzeugt drei Arten von Protokolldateien:

• api: Protokolliert alle Anfragen und Antworten, die über Edge Microgateway fließen. 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.

Dies 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: v2.3.3

Standardmäßig werden im Logging-Dienst die JSON-Dateien heruntergeladener Proxys und Produkte sowie das JSON Web Token (JWT) weggelassen. Wenn Sie diese Objekte in die Logdateien 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 Ablauf von Anfragen und Antworten über Edge Microgateway. Die „api“-Logdateien sind so benannt:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

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

• Eingehende Anfrage vom Client
• 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 Beispieleinträge, die jeweils eines der vier Ereignisse darstellen. 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 einen Statistikdatensatz, „warn“ für Warnungen oder „error“ für Fehler sein.
• req: Identifiziert das Ereignis. In diesem Fall die Anfrage vom Client.
• m: Das in der Anfrage verwendete HTTP-Verb.
• u: Der Teil der URL, der auf den Basispfad folgt.
• h: Der Host und die Portnummer, auf denen Edge Microgateway überwacht wird.
• r: Der Remote-Host und der 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. Die Korrelation von Logeinträgen nach Anfrage-ID kann wertvolle Einblicke in die Latenz des Ziels liefern.
• d: Die Dauer in Millisekunden, seit die Anfrage von Edge Microgateway empfangen wurde. Im obigen Beispiel wurde die Antwort des Ziels für Anfrage 0 nach 7 Millisekunden empfangen (Zeile 3) und die Antwort wurde nach weiteren 4 Millisekunden an den Client gesendet (Zeile 4). Mit anderen Worten: Die Gesamtlatenz der Anfrage betrug 11 Millisekunden, davon 7 Millisekunden für das Ziel und 4 Millisekunden für Edge Microgateway selbst.

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 einen Statistikdatensatz, „warn“ für Warnungen oder „error“ für Fehler sein.
• treq: Identifiziert das Ereignis. In diesem Fall „target request“.
• m: Das in der Zielanfrage verwendete HTTP-Verb.
• u: Der Teil der URL, der auf den Basispfad folgt.
• h: Der Host und die Portnummer des Backend-Ziels.
• i: Die ID des Logeintrags. Alle vier Ereigniseinträge haben diese 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 einen Statistikdatensatz, „warn“ für Warnungen oder „error“ für Fehler sein.
• tres: Identifiziert das Ereignis. In diesem Fall ist das die 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 diese ID.

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

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

1436403888651: Unix-Zeitstempel

• info: hängt vom Kontext ab. Kann je nach Logebene „info“, „warn“ oder „error“ sein. Kann „stats“ für einen Statistikdatensatz, „warn“ für Warnungen oder „error“ für Fehler sein.
• res: Identifiziert das Ereignis. In diesem Fall die Antwort an den Client.
• 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 für die Ziel-API und für Edge Microgateway selbst benötigt wird.
• i: Die ID des Logeintrags. Alle vier Ereigniseinträge haben diese ID.

Zeitplan für Logdatei

Logdateien werden in dem Intervall rotiert, das durch das Konfigurationsattribut rotate_interval angegeben wird. Einträge werden weiterhin derselben Logdatei hinzugefügt, bis das Rotationsintervall abläuft. Bei jedem Neustart von Edge Microgateway erhält es jedoch eine neue UID und erstellt einen neuen Satz von Logdateien mit dieser UID. Siehe auch Best Practices für die Logdateipflege.

Fehlermeldungen

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

Edge Microgateway-Konfigurationsreferenz

Speicherort der Konfigurationsdatei

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

edge_config-Attribute

Diese Einstellungen werden verwendet, um die Interaktion zwischen der Edge Microgateway-Instanz und Apigee Edge zu konfigurieren.

• bootstrap: (Standard: none) Eine URL, die auf einen Edge Microgateway-spezifischen Dienst verweist, der auf Apigee Edge ausgeführt wird. Edge Microgateway verwendet diesen Dienst, um mit Apigee Edge zu kommunizieren. 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: keiner) Eine URL, die auf den Edge Microgateway-Proxy verweist, der in Apigee Edge bereitgestellt wird. Dieser Proxy dient als Authentifizierungsendpunkt für die Ausgabe signierter Zugriffstokens an 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, auf der der Edge Microgateway-Prozess überwacht wird.
• max_connections: (Standard: -1) Gibt die maximale Anzahl gleichzeitiger eingehender Verbindungen an, die Edge Microgateway empfangen kann. Wenn diese Anzahl ü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 beendet wird. Diese Einstellung soll Denial-of-Service-Angriffe verhindern. In der Regel wird hier ein Wert festgelegt, der 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 zur Entwicklung 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 Remote-Debugging hinzu.
  • port: Die Portnummer, auf der gelauscht werden soll. Sie können beispielsweise den IDE-Debugger so einstellen, dass er diesen Port überwacht.
  • args: Argumente für den Debug-Prozess. Beispiel: args --nolazy
    
• config_change_poll_interval: (Standard: 600 Sekunden) Edge Microgateway lädt regelmäßig eine neue Konfiguration und führt ein erneutes Laden aus, wenn sich etwas geändert hat. Bei der Abfrage werden alle in Edge vorgenommenen Änderungen (Änderungen an Produkten, Microgateway-fähigen Proxys usw.) sowie Änderungen an der lokalen Konfigurationsdatei erfasst.
  
• disable_config_poll_interval: (Standard: false) Setzen Sie diesen Wert auf true, um die automatische Abfrage von Änderungen zu deaktivieren.
• request_timeout: Legt ein Zeitlimit für Zielanfragen fest. Das Zeitlimit wird in Sekunden festgelegt. Wenn eine Zeitüberschreitung auftritt, antwortet Edge Microgateway mit dem Statuscode 504. (Version 2.4.x hinzugefügt)

headers-Attribute

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

• x-forwarded-for: (Standard: true) Setzen Sie diesen Wert auf „false“, um zu verhindern, dass x-forwarded-for-Header an das Ziel übergeben werden. Wenn die Anfrage einen x-forwarded-for-Header enthält, wird dessen Wert in Edge Analytics auf den client-ip-Wert gesetzt.
• x-forwarded-host: (Standard: true) Setzen Sie diesen Wert auf „false“, um zu verhindern, dass x-forwarded-host-Header an das Ziel übergeben werden.
• x-request-id: (Standard: true) Legen Sie „false“ fest, um zu verhindern, dass x-request-id-Header an das Ziel übergeben werden.
• x-response-time: (Standard: true) Setzen Sie den Wert auf „false“, um zu verhindern, dass x-response-time-Header an das Ziel übergeben werden.
• via: (Standard: true) Setzen Sie diesen Wert auf „false“, 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 dieser Wert auf „true“ gesetzt ist, können API-Aufrufe ohne Autorisierungsheader über Edge Microgateway geleitet werden. Legen Sie diesen Wert auf „false“ fest, um einen Autorisierungsheader anzufordern (Standard).
• allowInvalidAuthorization: (Standard: false) Wenn dieser Wert auf „true“ gesetzt ist, werden API-Aufrufe zugelassen, 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 die Standardeinstellung ä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 verwendet wird, um einen API-Schlüssel an Edge Microgateway zu übergeben. Weitere Informationen finden Sie unter API-Schlüssel verwenden.
• keep-authorization-header: (Standard: false) Wenn dieser Wert auf „true“ gesetzt ist, wird der in der Anfrage gesendete Autorisierungsheader an das Ziel weitergeleitet (er bleibt erhalten).
• allowOAuthOnly: Wenn dieser Wert auf „true“ gesetzt ist, muss jede API einen Autorisierungsheader mit einem Bearer-Zugriffstoken enthalten. Ermöglicht es Ihnen, nur das OAuth-Sicherheitsmodell zuzulassen (unter Beibehaltung der Abwärtskompatibilität). (Version 2.4.x hinzugefügt)
• allowAPIKeyOnly: Wenn dieser Wert auf „true“ gesetzt ist, muss jede API einen x-api-key-Header (oder einen benutzerdefinierten Speicherort) mit einem API-Schlüssel enthalten.Ermöglicht es Ihnen, nur das API-Schlüssel-Sicherheitsmodell zuzulassen (unter Beibehaltung der Abwärtskompatibilität). (Hinzugefügt in 2.4.x)
• gracePeriod: Dieser Parameter hilft, Fehler zu 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 für diesen Parameter die Anzahl der Sekunden fest, die für solche Abweichungen zulässig sind. (In Version 2.5.7 hinzugefügt)

Plug-in-spezifische Attribute

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

Proxys filtern

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

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

Häufigkeit von Analytics-Push-Benachrichtigungen konfigurieren

Mit diesen Konfigurationsparametern können Sie festlegen, wie oft Edge Microgateway Analysedaten an Apigee sendet:

• bufferSize (optional): Die maximale Anzahl von Analyse-Datensätzen, die der Zwischenspeicher enthalten kann, bevor die ältesten Datensätze gelöscht werden. Standard: 10000
• batchSize (optional): Die maximale Größe eines Batches von Analysedatensätzen, die an Apigee gesendet werden. Standardwert: 500
• flushInterval (optional): Die Anzahl der Millisekunden zwischen den einzelnen Leerungen 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 Analytics 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 dem Pfad 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 Analyse-Plug-in so konfigurieren, dass ein bestimmter API-Pfad getrennt wird, sodass er in den Edge Analytics-Dashboards als separater Proxy angezeigt wird. Sie können beispielsweise eine Systemdiagnose-API im Dashboard trennen, um sie nicht mit tatsächlichen API-Proxy-Aufrufen zu verwechseln. Im Analytics-Dashboard folgen getrennte Proxys diesem Namensmuster:

edgemicro_proxyname-health

In der folgenden Abbildung sehen Sie zwei getrennte Proxys im Analytics-Dashboard: edgemicro_hello-health und edgemicro_mock-health:

Verwenden Sie diese Parameter, um relative und absolute Pfade im Analytics-Dashboard als separate Proxys zu 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 dieses Flag den Proxy-Basispfad ignoriert. 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 Analyse-Dashboard 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 Analytics-Dashboard als separater Proxy namens edgemicro_proxyname-health getrennt 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 Analytics-Dashboard als separater Proxy namens edgemicro_proxyname-health getrennt.

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 v2.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. (Das Gleiche gilt, wenn die Umgebungsvariablen zum Konfigurieren des Proxys TLS-fähig sind.)

Option 2:

Die zweite Option 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 festzulegen, 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, an die Edge Microgateway keinen Proxy senden soll. Beispiel:

export NO_PROXY='localhost,localhost:8080'

Legen Sie für HTTP_PROXY und HTTPS_PROXY 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-fähigen Proxys verwenden

Sie können einen oder mehrere „*“-Platzhalter im Basispfad eines edgemicro_*-Proxys (Microgateway-fähig) 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 erstellen müssen, um neue Teams zu unterstützen. Beachten Sie, dass /**/ nicht unterstützt wird.

Wichtig: Apigee unterstützt die Verwendung eines Platzhalters „*“ als erstes Element eines Basispfads NICHT. Beispiel: Die Suche nach /*/ wird NICHT unterstützt.

JWT-Schlüssel rotieren

Nachdem Sie ein JWT generiert haben, müssen Sie möglicherweise das in der verschlüsselten Edge-KVM gespeicherte öffentliche/private Schlüsselpaar ändern. Dieser Vorgang, bei dem ein neues Schlüsselpaar generiert wird, wird als Schlüsselrotation bezeichnet.

So verwendet Edge Microgateway JWT

JSON Web Token (JWT) ist ein Tokenstandard, der in RFC7519 beschrieben wird. JWT bietet eine Möglichkeit, eine Reihe von Anforderungen zu signieren, die vom Empfänger des JWT zuverlässig verifiziert 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 Autorisierungs-Header 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 zur Überprüfung von API-Aufrufen verwendet werden kann. Die Parameter -i und -s sind die Verbraucher-ID und die Secret-Werte einer Entwickler-App in Ihrer Apigee Edge-Organisation.

Sie können 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 der Consumer Secret in der zuvor erstellten Entwickler-App.

Was ist Schlüsselrotation?

Nachdem Sie ein JWT generiert haben, müssen Sie möglicherweise das in der verschlüsselten Edge-KVM gespeicherte öffentliche/private Schlüsselpaar ändern. Dieser Vorgang, bei dem ein neues Schlüsselpaar generiert wird, wird als Schlüsselrotation bezeichnet. Wenn Sie Schlüssel rotieren, wird ein neues privates/öffentliches Schlüsselpaar generiert und in der KVM „microgateway“ in Ihrer Apigee Edge-Organisation/-Umgebung gespeichert. Außerdem wird der alte öffentliche Schlüssel zusammen mit dem ursprünglichen Schlüssel-ID-Wert beibehalten.

Zum Generieren eines JWT verwendet Edge Informationen, die in der verschlüsselten KVM gespeichert sind. Bei der Ersteinrichtung (Konfiguration) von Edge Microgateway wurde eine 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 neueste (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 für die 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 „kid“ des privaten Schlüssels.

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

Bei der Schlüsselrotation 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 alte ID des ö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 verifiziert. Wenn die Überprüfung fehlschlägt, wird der alte öffentliche Schlüssel verwendet, bis er nach 30 Minuten abläuft. 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 die 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 bei der Konfiguration von Edge Microgateway in Ihrer Apigee-Organisation bereitgestellt wurde. 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 der Datei ~/.edgemicro/org-env-config.yaml die folgende Zeile hinzu. Geben Sie dabei dieselbe Organisation und Umgebung an, die Sie für 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 zuzuordnen. Edge Microgateway verwendet diesen Wert, um während der Schlüsselrotation einen Schlüssel aus einer Reihe von Schlüsseln auszuwählen. Weitere Informationen finden Sie in 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üsselsatz 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 unter 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 Prä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 mit diesem Produkt verknüpfter API-Schlüssel 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. Dies ist nützlich für die Fehlerbehebung und das Debugging benutzerdefinierter Plug-ins.

1. Starten Sie Edge Microgateway im Debug-Modus neu. Fügen Sie dazu DEBUG=* am Anfang des Befehls start hinzu. 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 überwacht.
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 Debug-Modus angeben. --nolazy hilft beispielsweise beim Debuggen von asynchronem Code.

Logdateien prüfen

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

API-Schlüsselsicherheit verwenden

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 des Consumer-Keys (auch Client-ID genannt) aus einem Apigee Edge-Produkt kopieren, das den Edge Microgateway-Authentifizierungsproxy enthält.

Caching von Schlüsseln

API-Schlüssel werden gegen Inhabertokens ausgetauscht, 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 Suchparameter oder in einem Header übergeben. Standardmäßig lautet der Name des Headers und des Abfrageparameters x-api-key.

Beispiel für einen Suchparameter:

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

Beispiel für Anzeigentitel:

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

Name des API-Schlüssels konfigurieren

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

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

In diesem Beispiel werden sowohl der Suchparameter 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 erläutert, wie Sie OAuth2-Zugriffstokens und Aktualisierungstokens abrufen. Zugriffstokens werden verwendet, um sichere API-Aufrufe über das Microgateway auszuführen. Aktualisierungstokens werden verwendet, um neue Zugriffstokens zu erhalten.

Zugriffstoken abrufen

In diesem Abschnitt wird erläutert, wie Sie den Proxy edgemicro-auth verwenden, um ein Zugriffstoken abzurufen.

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

API 1

Ersetzen Sie die Namen Ihrer Organisation und Umgebung in der URL und ersetzen Sie die Werte für Verbraucher-ID und Secret, die Sie von einer Entwickler-App in Apigee Edge erhalten haben, durch die Textparameter 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 abrufen

Wenn Sie ein Aktualisierungstoken abrufen möchten, senden Sie einen API-Aufruf an den Endpunkt /token des Proxys edgemicro-auth. Sie MÜSSEN diesen API-Aufruf mit dem Genehmigungstyp password ausführen. In den folgenden Schritten wird der Vorgang beschrieben.

1. Rufen Sie mit der /token API ein Zugriffs- und ein Aktualisierungstoken ab. Beachten Sie, dass der Genehmigungstyp 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 dann ungefähr 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 abzurufen. Rufen Sie dazu den Endpunkt /refresh derselben API auf. 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 dann ungefähr so aus:

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

Kontinuierliches Monitoring

Forever ist ein Node.js-Tool, das eine Node.js-Anwendung automatisch neu startet, wenn der Prozess ausfällt oder ein Fehler auftritt. Edge Microgateway hat eine forever.json-Datei, die Sie konfigurieren können, um zu steuern, wie oft und in welchen Intervallen Edge Microgateway neu gestartet werden soll. Mit dieser Datei wird ein Forever-Dienst namens forever-monitor konfiguriert, 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?. Weitere Informationen 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 (Flag -f) angeben und den Forever-Monitoring-Prozess starten/beenden können (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 deren Konfigurationen möglicherweise von einem einzigen Ort aus verwalten. Dazu können Sie einen HTTP-Endpunkt angeben, über den Edge Micro 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 hat die Namenskonvention org-env-config.yaml.

Datenpufferung für TCP-Verbindungen 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 vor dem Senden zu puffern. Wenn Sie nodelay auf true setzen, wird dieses Verhalten deaktiviert. Daten werden dann sofort gesendet, wenn socket.write() aufgerufen wird. Weitere Informationen finden Sie in der Node.js-Dokumentation.

Bearbeiten Sie die Edge Micro-Konfigurationsdatei so, um nodelay zu aktivieren:

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 eigenständigen Modus ausführen

Sie können Edge Microgateway vollständig von jeder Apigee Edge-Abhängigkeit getrennt ausführen. In diesem Szenario, dem sogenannten eigenständigen Modus, können Sie Edge Microgateway ohne Internetverbindung ausführen und testen.

Im eigenständigen Modus funktionieren die folgenden Features nicht, da sie eine Verbindung zu Apigee Edge erfordern:

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

Benutzerdefinierte Plug-ins und Spike Arrest funktionieren dagegen normal, da sie keine Verbindung zu Apigee Edge benötigen. Außerdem können Sie mit einem neuen Plug-in namens extauth API-Aufrufe an das Microgateway im eigenständigen Modus mit einem JWT autorisieren.

Gateway konfigurieren und starten

So führen Sie Edge Microgateway im eigenständigen Modus aus:

1. Prüfen Sie, ob Edge Microgateway Version 2.5.25 oder höher installiert ist. Andernfalls müssen Sie den folgenden Befehl ausführen, um ein Upgrade auf die aktuelle 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 für die Instanziierung des lokalen Proxys an:

   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 Name der Organisation, 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 des Proxys.
   • 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, erhalten Sie den Fehler „missing_authorization“. Dieses Plug-in validiert ein JWT, das im Autorisierungsheader des API-Aufrufs vorhanden sein muss. Im nächsten Abschnitt rufen Sie ein JWT ab, mit dem API-Aufrufe ohne Fehler ausgeführt werden 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 zu Beispielzwecken verwendet und ist nicht erforderlich. Sie können auch einen anderen JWT-Token-Endpunkt verwenden. In diesem Fall müssen Sie das JWT über die für diesen Endpunkt bereitgestellte API abrufen.

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

1. Sie müssen eine Standardeinrichtung und -konfiguration von Edge Microgateway durchführen, um den Proxy edgemicro-auth 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 Apigee Cloud bereitgestellt haben, müssen Sie mit dem Internet verbunden sein, um ein JWT von diesem Endpunkt abzurufen.
3. Beenden Sie Edge Microgateway:

   edgemicro stop

4. Verweisen Sie in der zuvor erstellten Konfigurationsdatei ($HOME/.edgemicro/org-env-config.yaml) mit dem Attribut extauth:publickey_url auf den Endpunkt edgemicro-auth/jwkPublicKeys in Ihrer Apigee Edge-Organisation/-Umgebung. Beispiel:

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

5. Starten Sie Edge Microgateway wie zuvor neu. Verwenden Sie dabei die Namen der Organisation/Umgebung, 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 Endpunkt edgemicro-auth/jwkPublicKeys 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 zuvor Edge Microgateway konfiguriert haben.
• your_env ist eine Umgebung in der Organisation.
• Mit der Option i wird der Consumer-Key aus einer Entwickler-App angegeben, die ein Produkt mit dem Proxy edgemicro-auth enthält.
• Mit der Option s wird der Clientschlü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 zur Überprüfung von API-Aufrufen verwendet werden kann.

Eigenständige Konfiguration testen

Rufen Sie die API mit dem im Autorisierungsheader hinzugefügten Token so 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 Proxymodus verwenden

Im lokalen Proxymodus ist für Edge Microgateway kein Microgateway-fähiger Proxy erforderlich, der in Apigee Edge bereitgestellt werden muss. 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 Belangen funktioniert der lokale Proxymodus genau wie die Ausführung von Edge Microgateway im normalen Modus. Die Authentifizierung funktioniert genauso wie die Spike-Arrest- und Kontingenterzwingung, benutzerdefinierte Plug-ins usw.

Anwendungsfall und Beispiel

Der lokale Proxymodus ist nützlich, wenn Sie nur einen einzigen Proxy mit einer Edge Microgateway-Instanz verknüpfen müssen. Sie können Edge Microgateway beispielsweise als Sidecar-Proxy in Kubernetes einfügen, wobei ein Microgateway und ein Dienst jeweils in einem einzelnen Pod ausgeführt werden und das Microgateway den Traffic zu und von seinem Begleitdienst verwaltet. Die folgende Abbildung zeigt diese Architektur, bei der Edge Microgateway als Sidecar-Proxy in einem Kubernetes-Cluster fungiert. Jede Microgateway-Instanz kommuniziert nur mit einem einzigen Endpunkt im zugehörigen Dienst:

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

Lokalen Proxymodus konfigurieren

So konfigurieren Sie Edge Microgateway für die Ausführung im lokalen Proxymodus:

1. Prüfen Sie, ob Edge Microgateway Version 2.5.25 oder höher installiert ist. Andernfalls müssen Sie den folgenden Befehl ausführen, um ein Upgrade auf die aktuelle 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 genau so einzurichten, wie Sie es in einer typischen Edge Microgateway-Einrichtung tun würden. Weitere Informationen finden Sie unter Edge Microgateway konfigurieren.
3. Führen Sie edgemicro configure aus, wie Sie es bei einem typischen Edge Microgateway-Einrichtungsverfahren tun würden. Beispiel:

   edgemicro configure -o your_org -e your_env -u your_apigee_username

   Mit diesem Befehl wird die Richtlinie edgemicro-auth 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 zum 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-Verwaltungs-UI hinzufügen.

6. Erstellen Sie in Apigee Edge eine Entwickler-App. Sie müssen das gerade erstellte API-Produkt zur App hinzufügen. Weitere Informationen finden Sie unter Anwendung 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 beim Ausführen von edgemicro configure zurückgegeben wurde.
   • your_secret ist das Secret, das beim Ausführen von edgemicro configure zurückgegeben wurde.
   • local_proxy_name ist der Name des lokalen Proxys, der erstellt wird.
   • local_proxy_version ist die Versionsnummer des Proxys.
   • 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 Proxy-Konfiguration testen, indem Sie den Proxy-Endpunkt 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 verursacht, weil Sie keinen gültigen API-Schlüssel angegeben haben. Sie finden den Schlüssel in der zuvor erstellten Entwickler-App. Öffnen Sie die App in der Edge-Benutzeroberfläche, kopieren Sie den Consumer-Key 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":""
}