Sie sehen die Dokumentation zu Apigee Edge.
Rufen Sie die Apigee X-Dokumentation auf. weitere Informationen
Edge Microgateway Version 3.3.x
In diesem Thema wird beschrieben, wie Sie Edge Microgateway verwalten und konfigurieren.
Upgrade für Edge Microgateway durchführen, wenn Sie eine Internetverbindung haben
In diesem Abschnitt wird erläutert, wie Sie eine vorhandene Installation von Edge Microgateway upgraden. Wenn Sie ohne Internetverbindung arbeiten, lesen Sie Kann ich Edge Microgateway ohne Internetverbindung installieren?.
Apigee empfiehlt, dass Sie Ihre vorhandene Konfiguration mit der neuen Version testen, bevor Sie ein Upgrade der Produktionsumgebung ausführen.
- 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 eine bestimmte Version von Edge Microgateway installieren, müssen Sie im Installationsbefehl die Versionsnummer angeben. Verwenden Sie beispielsweise den folgenden Befehl, um auf Version 3.2.3 zu installieren:
npm install edgemicro@3.2.3 -g
- Prüfen Sie die Versionsnummer. Wenn Sie beispielsweise Version 3.2.3 installiert haben:
edgemicro --version current nodejs version is v12.5.0 current edgemicro version is 3.2.3
- Führen Sie schließlich ein Upgrade auf die neueste Version des Proxys edgemicro-auth durch:
edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME
Konfigurationsänderungen vornehmen
Zu den Konfigurationsdateien, die Sie kennen müssen, gehören:
- Standardsystemkonfigurationsdatei
- Standardkonfigurationsdatei für eine neu initialisierte Edge Microgateway-Instanz
- Dynamische Konfigurationsdatei zum Ausführen von Instanzen
In diesem Abschnitt werden diese Dateien und was Sie wissen müssen, um sie zu ändern.
Standardsystemkonfigurationsdatei
Wenn Sie Edge Microgateway installieren, wird hier eine Standardsystemkonfigurationsdatei platziert:
prefix/lib/node_modules/edgemicro/config/default.yaml
Dabei ist prefix das Präfixverzeichnis für npm
. Wenn Sie dieses Verzeichnis nicht finden können, lesen Sie
Wo ist Edge Microgateway installiert.
Wenn Sie die Systemkonfigurationsdatei ändern, müssen Sie Edge Microgateway neu initialisieren, neu konfigurieren und neu starten:
edgemicro initedgemicro 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
platziert.
Wenn Sie die Konfigurationsdatei in ~/.edgemicro
ändern, müssen Sie Edge Microgateway neu konfigurieren und neu starten:
edgemicro stopedgemicro configure [params]
edgemicro start [params]
Dynamische Konfigurationsdatei zum Ausführen von 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 Ihre Apigee Edge-Organisations- und Umgebungsnamen 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 neu laden, ohne Ausfallzeiten zu verursachen, wie unten erläutert.
Wenn Edge Microgateway ausgeführt wird (Option ohne Ausfallzeiten):
- Aktualisieren Sie die Edge Microgateway-Konfiguration:
edgemicro reload -o $ORG -e $ENV -k $KEY -s $SECRET
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“).
- $KEY ist der Schlüssel, der zuvor vom Befehl „config“ zurückgegeben wurde.
- $SECRET ist der Schlüssel, der zuvor vom Befehl „config“ zurückgegeben wurde.
Beispiel:
edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \ -s 05c14356e42ed1...4e34ab0cc824
Wenn Edge Microgateway beendet ist:
- Starten Sie Edge Microgateway neu:
edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
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“).
- $KEY ist der Schlüssel, der zuvor vom Befehl „config“ zurückgegeben wurde.
- $SECRET ist der Schlüssel, der zuvor vom Befehl „config“ zurückgegeben wurde.
Beispiel:
edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \ -s 05c1435...e34ab0cc824
Hier ist ein Beispiel für eine Konfigurationsdatei. Weitere Informationen zu den Einstellungen für die 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 Befehlszeilenbefehle, die Werte für Ihre Edge-Organisation und -Umgebung erfordern, 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 Edge Microgateway über die Befehlszeile konfigurieren und starten.
SSL auf dem Edge Microgateway-Server konfigurieren
In den folgenden Videos erfahren Sie mehr über das Konfigurieren von TLS in Apigee Edge Microgateway:
Video | Beschreibung |
---|---|
1-Wege-TLS nach Norden konfigurieren | Informationen zum Konfigurieren von TLS in Apigee Edge Microgateway. In diesem Video erhalten Sie einen Überblick über TLS und seine Bedeutung. Außerdem wird TLS in Edge Microgateway vorgestellt und es wird gezeigt, wie Northbound One-Way TLS konfiguriert wird. |
2-Wege-TLS nach Norden konfigurieren | Dies ist das zweite Video zum Konfigurieren von TLS in Apigee Edge Microgateway. In diesem Video wird erläutert, wie Sie die Zwei-Wege-TLS-Verbindung nach Norden konfigurieren. |
1-Wege- und 2-Wege-TLS nach Süden konfigurieren | In diesem dritten Video zum Konfigurieren von TLS in Apigee Edge Microgateway wird erläutert, wie 1-Wege-TLS und 2-Wege-TLS nach Süden konfiguriert werden. |
Sie können den Microgateway-Server für die Verwendung von SSL konfigurieren. Wenn SSL beispielsweise konfiguriert ist, können Sie APIs über Edge Microgateway mit dem HTTPS-Protokoll wie folgt aufrufen:
https://localhost:8000/myapi
So konfigurieren Sie SSL auf dem Microgateway-Server:
- Generieren oder erhalten Sie ein SSL-Zertifikat und einen SSL-Schlüssel mit dem Dienstprogramm openssl oder einer anderen Methode.
- 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
- Starten Sie Edge Microgateway neu. Folgen Sie den Schritten unter Konfigurationsänderungen vornehmen, 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
Im Folgenden finden Sie eine Liste aller unterstützten Serveroptionen:
Wahltaste | Beschreibung |
---|---|
key |
Pfad zu einer ca.key -Datei im PEM-Format. |
cert |
Pfad zu einer ca.cert -Datei im PEM-Format. |
pfx |
Pfad zu einer pfx -Datei, die den privaten Schlüssel, das Zertifikat und die CA-Zertifikate des Clients im PFX-Format enthält. |
passphrase |
Ein String, der die Passphrase für den privaten Schlüssel oder PFX enthält. |
ca |
Pfad zu einer Datei mit einer Liste vertrauenswürdiger Zertifikate im PEM-Format. |
ciphers |
Ein String, der die zu verwendenden Chiffren beschreibt, getrennt durch ein ":". |
rejectUnauthorized |
Bei „true“ wird das Serverzertifikat anhand der Liste der bereitgestellten Zertifizierungsstellen überprüft. Wenn die Überprüfung fehlschlägt, wird ein Fehler zurückgegeben. |
secureProtocol |
Die zu verwendende SSL-Methode. Beispiel: SSLv3_method, um SSL auf Version 3 zu erzwingen. |
servername |
Der Servername für die TLS-Erweiterung (SNI (Server Name Indication)). |
requestCert |
TRUE für 2-Wege-SSL; false für 1-Wege-SSL |
Client-SSL/TLS-Optionen verwenden
Sie können Edge Microgateway beim Herstellen einer Verbindung zu Zielendpunkten als TLS- oder SSL-Client konfigurieren. Verwenden Sie in der Microgateway-Konfigurationsdatei das Zielelement, um SSL/TLS-Optionen festzulegen. Sie können mehrere spezifische Ziele angeben. Unten sehen Sie ein Beispiel für mehrere Ziele.
Dieses Beispiel enthält Einstellungen, 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
Wenn Sie TLS/SSL-Einstellungen auf mehrere bestimmte Ziele anwenden möchten, müssen Sie den ersten Host in der Konfiguration als „leer“ angeben. Dadurch sind universelle Anfragen möglich. Die jeweiligen Hosts müssen in beliebiger Reihenfolge angegeben werden. In diesem Beispiel werden die Einstellungen auf mehrere bestimmte Hosts angewendet:
targets: - host: ## Note that this value must be "empty" ssl: client: key: /Users/myname/twowayssl/ssl/client.key cert: /Users/myname/twowayssl/ssl/ca.crt passphrase: admin123 rejectUnauthorized: true - host: 'myserver1.example.com' ssl: client: key: /Users/myname/twowayssl/ssl/client.key cert: /Users/myname/twowayssl/ssl/ca.crt rejectUnauthorized: true - host: 'myserver2.example.com' ssl: client: key: /Users/myname/twowayssl/ssl/client.key cert: /Users/myname/twowayssl/ssl/ca.crt rejectUnauthorized: true
Im Folgenden finden Sie eine Liste aller unterstützten Clientoptionen:
Wahltaste | Beschreibung |
---|---|
pfx |
Pfad zu einer pfx -Datei, die den privaten Schlüssel, das Zertifikat und die CA-Zertifikate des Clients im PFX-Format enthält. |
key |
Pfad zu einer ca.key -Datei im PEM-Format. |
passphrase |
Ein String, der die Passphrase für den privaten Schlüssel oder PFX enthält. |
cert |
Pfad zu einer ca.cert -Datei im PEM-Format. |
ca |
Pfad zu einer Datei mit einer Liste vertrauenswürdiger Zertifikate im PEM-Format. |
ciphers |
Ein String, der die zu verwendenden Chiffren beschreibt, getrennt durch ein ":". |
rejectUnauthorized |
Bei „true“ wird das Serverzertifikat anhand der Liste der bereitgestellten Zertifizierungsstellen überprüft. Wenn die Überprüfung fehlschlägt, wird ein Fehler zurückgegeben. |
secureProtocol |
Die zu verwendende SSL-Methode. Beispiel: SSLv3_method, um SSL auf Version 3 zu erzwingen. |
servername |
Der Servername für die TLS-Erweiterung (SNI (Server Name Indication)). |
Edgemicro-auth-Proxy anpassen
Standardmäßig verwendet Edge Microgateway einen Proxy, der auf 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 einem JSON Web Token (JWT) Unterstützung für benutzerdefinierte Anforderungen hinzuzufügen, den Tokenablauf zu konfigurieren und Aktualisierungstokens zu generieren. Weitere Informationen finden Sie auf der Seite edgemicro-auth in GitHub.
Benutzerdefinierten Authentifizierungsdienst verwenden
Standardmäßig verwendet Edge Microgateway einen Proxy, der auf 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 Ihren 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. Angenommen, Sie haben einen Dienst, der LDAP zur Bestätigung der Identität verwendet.
Protokolldateien verwalten
Edge Microgateway protokolliert Informationen zu jeder Anfrage und Antwort. Protokolldateien enthalten nützliche Informationen für die Fehlerbehebung.
Speicherort der Protokolldateien
Standardmäßig werden Protokolldateien in /var/tmp
gespeichert.
Standardverzeichnis für Logdateien ändern
Das Verzeichnis, in dem Logdateien gespeichert sind, wird in der Konfigurationsdatei von Edge Microgateway angegeben. Siehe auch 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 von dir, um ein anderes Logdateiverzeichnis anzugeben.
Logs an die Console 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 Protokolle an die Standardausgabe gesendet. Derzeit können Logs nicht gleichzeitig an stdout und an eine Logdatei gesendet werden.
Protokollierungsebene festlegen
Sie geben die Logebene an, die in der edgemicro
-Konfiguration verwendet werden soll. Eine vollständige Liste der Logebenen und deren Beschreibungen finden Sie unter edgemicro-Attribute.
Die folgende Konfiguration legt beispielsweise die Logging-Ebene auf debug
fest:
edgemicro: home: ../gateway port: 8000 max_connections: -1 max_connections_hard: -1 logging: level: debug dir: /var/tmp stats_log_interval: 60 rotate_interval: 24
Protokollintervalle ändern
Sie können diese Intervalle in der Edge Microgateway-Konfigurationsdatei konfigurieren. Siehe auch Konfigurationsänderungen vornehmen.
Folgende konfigurierbare Attribute sind verfügbar:
- stats_log_interval: (Standardwert: 60) Intervall in Sekunden, wenn der Statistikeintrag in die API-Logdatei geschrieben wird.
- rotate_interval: (Standardeinstellung: 24) Intervall in Stunden, wenn 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
Lockern von strengen Berechtigungen für Logdateien
Standardmäßig generiert Edge Microgateway die Anwendungslogdatei (api-log.log
), wobei die Dateiberechtigungsebene auf 0600 gesetzt ist. Mit dieser Berechtigungsstufe können externe Anwendungen oder Nutzer die Logdatei nicht lesen. Legen Sie logging:disableStrictLogFile
auf true
fest, um diese strikte Berechtigungsstufe zu lockern. Wenn dieses Attribut true
ist, wird die Logdatei mit der Dateiberechtigung „0755“ erstellt. Wenn false
oder das Attribut nicht angegeben ist, wird standardmäßig 0600 für die Berechtigung verwendet.
Hinzugefügt in Version 3.2.3.
Beispiel:
edgemicro: logging: disableStrictLogFile: true
Gute Verfahren für die Verwaltung von Logdateien
Da sich Logdateidaten im Laufe der Zeit ansammeln, empfiehlt Apigee die folgenden Vorgehensweisen:
- Da Logdateien sehr groß werden können, muss das Logdateiverzeichnis genügend Speicherplatz haben. Weitere Informationen finden Sie in den folgenden Abschnitten unter Speicherorte von Logdateien und Standardverzeichnis für Logdateien ändern.
- Löschen Sie die Protokolldateien mindestens einmal pro Woche oder verschieben Sie sie in ein separates Archivverzeichnis.
- Wenn Ihre Richtlinie zum Löschen von Logs vorgesehen ist, können Sie ältere Logs mit dem Befehl
edgemicro log -c
der Befehlszeile entfernen.
Namenskonvention für Logdateien
Jede Edge Microgateway-Instanz erzeugt eine Logdatei mit der Erweiterung .log
. Die Namenskonvention für Logdateien lautet:
edgemicro-HOST_NAME-INSTANCE_ID-api.log
Beispiel:
edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log
Inhalt der Protokolldatei
Hinzugefügt in: Version 2.3.3
Standardmäßig lässt der Logging-Dienst den JSON-Code heruntergeladener Proxys, Produkte und das JSON-Web-Token (JWT) weg. Wenn Sie diese Objekte an die Console ausgeben möchten, legen Sie beim Starten von Edge Microgateway das Befehlszeilen-Flag DEBUG=*
fest. Beispiel:
DEBUG=* edgemicro start -o docs -e test -k abc123 -s xyz456
Inhalt der „api“-Protokolldatei
Die Logdatei „api“ enthält detaillierte Informationen zum Fluss von Anfragen und Antworten über Edge Microgateway. Die „api“-Protokolldateien heißen so:
edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log
Für jede Anfrage an Edge Microgateway werden vier Ereignisse in der Logdatei „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 sehen Sie vier Beispieleinträge, die für jedes der vier Ereignisse stehen. In der Logdatei sehen sie so aus (die Zeilennummern dienen im Dokument nur als Referenz und sind in der Logdatei nicht enthalten).
(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 sie uns im Einzelnen an:
1. Beispiel für eine vom Client eingehende Anfrage:
1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0
- 1436403888651 – Unix-Datumsstempel
- info – Die Protokollierungsebene. Dieser Wert hängt vom Kontext der Transaktion und der in der Konfiguration
edgemicro
festgelegten Logging-Ebene ab. Weitere Informationen finden Sie unter Logging-Ebene festlegen. Bei Statistikeinträgen ist das Level aufstats
festgelegt. Statistikeinträge werden in regelmäßigen Abständen gemeldet, die in derstats_log_interval
-Konfiguration festgelegt sind. Weitere Informationen finden Sie unter Protokollintervalle ändern. - req: Kennzeichnet das Ereignis. eine 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, die Edge Microgateway überwacht.
- r – Der Remote-Host und Port, von dem die Clientanfrage stammt.
- i – Die Anfrage-ID. Alle vier Ereigniseinträge haben diese ID. Jeder Anfrage wird eine eindeutige Anfrage-ID zugewiesen. Durch die Korrelation von Logeinträgen nach Anfrage-ID erhalten Sie wertvolle Informationen zur Latenz des Ziels.
- d – Die Dauer in Millisekunden, seit die Anfrage von Edge Microgateway empfangen wurde. Im Beispiel oben wurde die Antwort des Ziels für Anfrage 0 nach 7 Millisekunden (Zeile 3) empfangen und die Antwort wurde nach weiteren 4 Millisekunden an den Client gesendet (Zeile 4). Mit anderen Worten, die gesamte Anfragelatenz betrug 11 Millisekunden, davon wurden 7 Millisekunden vom Ziel und 4 Millisekunden vom Edge Microgateway selbst verwendet.
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-Datumsstempel
- info – Die Protokollierungsebene. Dieser Wert hängt vom Kontext der Transaktion und der in der Konfiguration
edgemicro
festgelegten Logging-Ebene ab. Weitere Informationen finden Sie unter Logging-Ebene festlegen. Bei Statistikeinträgen ist das Level aufstats
festgelegt. Statistikeinträge werden in regelmäßigen Abständen gemeldet, die in derstats_log_interval
-Konfiguration festgelegt sind. Weitere Informationen finden Sie unter Protokollintervalle ändern. - treq: Kennzeichnet das Ereignis. In diesem Fall Zielanfrage.
- m – Das in der Zielanfrage verwendete HTTP-Verb.
- u – Der Teil der URL, der auf den Basispfad folgt.
- h – Host und Portnummer des Back-End-Ziels.
- i – ID des Logeintrags. Alle vier Ereigniseinträge haben diese ID.
3. Beispiel für eingehende Antwort vom Ziel
1436403888672 info tres s=200, d=7, i=0
1436403888651 – Unix-Datumsstempel
- info – Die Protokollierungsebene. Dieser Wert hängt vom Kontext der Transaktion und der in der Konfiguration
edgemicro
festgelegten Logging-Ebene ab. Weitere Informationen finden Sie unter Logging-Ebene festlegen. Bei Statistikeinträgen ist das Level aufstats
festgelegt. Statistikeinträge werden in regelmäßigen Abständen gemeldet, die in derstats_log_interval
-Konfiguration festgelegt sind. Weitere Informationen finden Sie unter Protokollintervalle ändern. - tres – Kennzeichnet das Ereignis. In diesem Fall die Zielantwort.
- s – Status der HTTP-Antwort.
- d – Dauer in Millisekunden. Die vom Ziel für den API-Aufruf benötigte Zeit.
- i – 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-Datumsstempel
- info – Die Protokollierungsebene. Dieser Wert hängt vom Kontext der Transaktion und der in der Konfiguration
edgemicro
festgelegten Logging-Ebene ab. Weitere Informationen finden Sie unter Logging-Ebene festlegen. Bei Statistikeinträgen ist das Level aufstats
festgelegt. Statistikeinträge werden in regelmäßigen Abständen gemeldet, die in derstats_log_interval
-Konfiguration festgelegt sind. Weitere Informationen finden Sie unter Protokollintervalle ändern. - res – Kennzeichnet das Ereignis. Antworten Sie in diesem Fall an den Client.
- s – Status der HTTP-Antwort.
- d – Dauer in Millisekunden. Dies ist die Gesamtzeit des API-Aufrufs, einschließlich der Zeit, die die Ziel-API benötigt, und die Zeit, die Edge Microgateway selbst benötigt.
- i – ID des Logeintrags. Alle vier Ereigniseinträge haben diese ID.
Zeitplan für Protokolldatei
Logdateien werden in dem Intervall rotiert, das im Konfigurationsattribut rotate_interval angegeben ist. Einträge werden weiterhin derselben Logdatei hinzugefügt, bis das Rotationsintervall abgelaufen ist. Bei jedem Neustart von Edge Microgateway erhält es jedoch eine neue UID und erstellt einen neuen Satz von Logdateien mit dieser UID. Weitere Informationen finden Sie unter Gute Verwaltung von Logdateien.
Fehlermeldungen
Einige Logeinträge enthalten Fehlermeldungen. Informationen dazu, wo und warum die Fehler auftreten, finden Sie in der Fehlerreferenz zu Edge Microgateway.
Edge Microgateway-Konfigurationsreferenz
Speicherort der Konfigurationsdatei
Die in diesem Abschnitt beschriebenen Konfigurationsattribute befinden sich in der Konfigurationsdatei von Edge Microgateway. Siehe auch Konfigurationsänderungen vornehmen.
Attribute für „edge_config“
Diese Einstellungen werden verwendet, um die Interaktion zwischen der Edge Microgateway-Instanz und Apigee Edge zu konfigurieren.
- bootstrap: (Standard: keine) Eine URL, die auf einen Edge Microgateway-spezifischen Dienst verweist, der auf 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: keiner) Eine URL, die auf den Edge Microgateway-Proxy verweist, der auf Apigee Edge bereitgestellt wird. Dieser Proxy dient als Authentifizierungsendpunkt für die Ausstellung signierter Zugriffstokens an Clients. Diese URL wird zurückgegeben, wenn Sie den Befehl edgemicro konfigurieren ausführen, um den Proxy bereitzustellen. Weitere Informationen finden Sie unter Edge Microgateway einrichten und konfigurieren.
- quotaUri: Legen Sie dieses Konfigurationsattribut fest, wenn Sie Kontingente über den in Ihrer Organisation bereitgestellten
edgemicro-auth
-Proxy verwalten möchten. Wenn dieses Attribut nicht festgelegt ist, wird als Kontingentendpunkt standardmäßig der interne Edge Microgateway-Endpunkt verwendet.edge_config: quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
Edgemicro-Attribute
Mit diesen Einstellungen wird der Edge Microgateway-Prozess konfiguriert.
- port: (Standard: 8000) Die Portnummer, die der Edge Microgateway-Prozess überwacht.
- max_connections: (Standard: -1) Gibt die maximale Anzahl gleichzeitiger eingehender Verbindungen an, die Edge Microgateway empfangen kann. Wird diese Zahl überschritten, 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 heruntergefahren wird. Diese Einstellung dient zur Verhinderung von Denial-of-Service-Angriffen. Geben Sie dafür in der Regel eine Zahl an, die größer als „max_connections“ ist.
-
logging:
-
level: (Standard: Fehler)
- info – (empfohlen) Protokolliert alle Anfragen und Antworten, die durch eine Edge Microgateway-Instanz fließen.
- warn: Protokolliert nur Warnmeldungen.
- error – protokolliert nur Fehlermeldungen.
- debug: Debug-Meldungen werden zusammen mit Informationen, Warnungen und Fehlermeldungen protokolliert.
- trace: Protokolliert Trace-Informationen für Fehler zusammen mit Informationen, Warnungen und Fehlermeldungen.
- none: Es wird keine Protokolldatei erstellt.
- dir: (Standard: /var/tmp) Das Verzeichnis, in dem die Logdateien gespeichert sind.
- stats_log_interval: (Standardwert: 60) Intervall in Sekunden, wenn der Statistikeintrag in die API-Logdatei geschrieben wird.
- rotate_interval: (Standardeinstellung: 24) Intervall in Stunden, wenn Logdateien rotiert werden.
-
level: (Standard: Fehler)
- plugins: Plug-ins fügen Funktionen zu Edge Microgateway 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 der 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, die überwacht werden soll. Legen Sie beispielsweise fest, dass Ihr IDE-Debugger 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 eine Aktualisierung aus, wenn sich etwas geändert hat. Das Polling erfasst alle in Edge vorgenommenen Änderungen (Änderungen an Produkten, Proxys, die auf Mikrogateways reagieren usw.) sowie an der lokalen Konfigurationsdatei.
- disable_config_poll_interval: (Standard: false) Setzen Sie diesen Wert auf true, um das automatische Ändern von Abfragen 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 einem 504-Statuscode. (Version 2.4.x hinzugefügt)
- keep_alive_timeout: Mit dieser Eigenschaft können Sie das Edge Microgateway-Zeitlimit (in Millisekunden) festlegen. (Standardeinstellung: 5 Sekunden) (Version 3.0.6 hinzugefügt)
- headers_timeout: Dieses Attribut begrenzt die Zeit (in Millisekunden), die der HTTP-Parser auf den Empfang der vollständigen HTTP-Header wartet.
Beispiel:
edgemicro: keep_alive_timeout: 6000 headers_timeout: 12000
Intern legt der Parameter das Node.js-Attribut
Server.headersTimeout
für Anfragen fest. (Standardeinstellung: 5 Sekunden mehr als die mitedgemicro.keep_alive_timeout
festgelegte Zeit. Diese Standardeinstellung verhindert, dass Load-Balancer oder Proxys die Verbindung fälschlicherweise trennen.) (Version 3.1.1 hinzugefügt) - noRuleMatchAction: (String) Die auszuführende Aktion (Zugriff zulassen oder ablehnen), wenn die im Plug-in
accesscontrol
angegebene Übereinstimmungsregel nicht erkannt wird (keine Übereinstimmung). Gültige Werte:ALLOW
oderDENY
. Standardwert:ALLOW
(Hinzugefügt: Version 3.1.7) - enableAnalytics: (Standardeinstellung: true) Setzen Sie das Attribut auf false, um zu verhindern, dass das Analyse-Plug-in geladen wird. In diesem Fall erfolgen keine Aufrufe der Apigee Edge-Analyse. Wenn true festgelegt oder dieses Attribut nicht angegeben ist, funktioniert das Analyse-Plug-in wie gewohnt. Weitere Informationen finden Sie unter edgemicro-Attribute. (Version 3.1.8 hinzugefügt).
Beispiel:
edgemicro enableAnalytics=false|true
- on_target_response_abort: Mit diesem Attribut können Sie steuern, wie sich Edge Microgateway verhält, wenn die Verbindung zwischen dem Client (Edge Microgateway) und dem Zielserver vorzeitig geschlossen wird.
Wert Beschreibung Standard Wenn on_target_response_abort
nicht angegeben ist, wird die Antwort standardmäßig ohne Fehlermeldung abgeschnitten. In Protokolldateien wird eine Warnmeldung mittargetResponse aborted
und dem Antwortcode 502 angezeigt.appendErrorToClientResponseBody
Der benutzerdefinierte Fehler TargetResponseAborted
wird an den Client zurückgegeben. In Protokolldateien wird eine Warnmeldung mittargetResponse aborted
und dem Antwortcode 502 angezeigt. Darüber hinaus wird der FehlerTargetResponseAborted
mit der MeldungTarget response ended prematurely.
protokolliert.abortClientRequest
Edge Microgateway bricht die Anfrage ab und es wird eine Warnung in die Logdateien geschrieben: TargetResponseAborted
mit dem Statuscode 502 der Anfrage.
Beispiel:
edgemicro: on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest
Headerattribute
Mit diesen Einstellungen wird festgelegt, wie bestimmte HTTP-Header behandelt werden.
- x-forwarded-for: (Standard: true) Legen Sie diesen Wert auf "false" fest, um zu verhindern, dass x-forwarded-for-Header an das Ziel weitergegeben werden. Wenn sich ein x-forwarded-for-Header in der Anfrage befindet, wird sein Wert in Edge Analytics auf den Client-IP-Wert festgelegt.
- x-forwarded-host: (Standardeinstellung: true) Legen Sie diesen Wert auf "false" fest, um zu verhindern, dass x-forwarded-host-Header an das Ziel weitergegeben werden.
- x-request-id: (Standard: true) Auf "false" setzen, um zu verhindern, dass x-request-id-Header an das Ziel weitergegeben werden.
- x-response-time: (Standard: true) Legen Sie diesen Wert auf "false" fest, um zu verhindern, dass x-response-time-Header an das Ziel weitergegeben werden.
- via: (Standard: true) Auf "false" setzen, um zu verhindern, dass via Header an das Ziel übergeben werden.
OAuth-Attribute
Diese Einstellungen konfigurieren, wie die Clientauthentifizierung von Edge Microgateway erzwungen wird.
- allowNoAuthorization: (Standard: false) Wenn auf „true“ gesetzt, dürfen API-Aufrufe Edge Microgateway ohne Autorisierungsheader passieren. Setzen Sie diesen Wert auf „false“, um einen Autorisierungsheader anzufordern (Standard).
- allowInvalidAuthorization: (Standardeinstellung: false) Bei Einstellung auf „true“ dürfen API-Aufrufe übergeben werden, wenn das im Autorisierungsheader übergebene Token ungültig oder abgelaufen ist. Setzen Sie diesen Wert auf „false“, damit gültige Tokens erforderlich sind (Standardeinstellung).
- authorization-header: (Standard: Authorization: Bearer) Der Header, der zum Senden des Zugriffstokens an Edge Microgateway verwendet wird. Sie können die Standardeinstellung in Fällen ändern, in denen 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. Weitere Informationen finden Sie unter API-Schlüssel verwenden.
- keep-authorization-header: (Standard: false) Bei Einstellung auf "true" wird der in der Anfrage gesendete Autorisierungsheader an das Ziel übergeben und bleibt erhalten.
- allowOAuthOnly: Wenn diese Richtlinie auf "true" gesetzt ist, muss jede API einen Autorisierungsheader mit einem Inhaberzugriffstoken enthalten. Ermöglicht es Ihnen, nur das OAuth-Sicherheitsmodell zuzulassen (unter Aufrechterhaltung der Abwärtskompatibilität). (2.4.x hinzugefügt)
- allowAPIKeyOnly: Wenn diese Richtlinie auf „true“ gesetzt ist, muss jede API einen x-api-key-Header (oder einen benutzerdefinierten Speicherort) mit einem API-Schlüssel enthalten.Damit können Sie unter Aufrechterhaltung der Abwärtskompatibilität nur das Sicherheitsmodell des API-Schlüssels zulassen. (2.4.x hinzugefügt)
- gracePeriod: Mit diesem Parameter werden Fehler verhindert, die durch geringfügige Abweichungen zwischen der Systemuhr und den Zeiten „Nicht vor“ (nbf) oder „Ausgestellt um“ (iat) verursacht werden, die im JWT-Autorisierungstoken angegeben sind. Legen Sie für diesen Parameter die Anzahl von Sekunden fest, um solche Abweichungen zu berücksichtigen. (2.5.7 hinzugefügt)
Plug-in-spezifische Attribute
Weitere Informationen zu konfigurierbaren Attributen für jedes Plug-in finden Sie unter „Plug-ins verwenden“.
Proxys filtern
Sie können filtern, welche Microgateway-fähigen Proxys eine Edge Microgateway-Instanz verarbeiten.
Beim Start von Edge Microgateway werden alle Proxys, die auf Mikrogateways reagieren, in der Organisation heruntergeladen, der es zugeordnet ist. Mit der folgenden Konfiguration können Sie einschränken, welche Proxys das Mikrogateway verarbeitet. Diese Konfiguration beschränkt die Proxys, die das Mikrogateway verarbeitet, auf drei: edgemicro_proxy-1
, edgemicro_proxy-2
und edgemicro_proxy-3
:
edgemicro: proxies: - edgemicro_proxy-1 - edgemicro_proxy-2 - edgemicro_proxy-3
Produkte nach Namen filtern
Verwenden Sie die folgende Konfiguration, um die Anzahl der API-Produkte zu begrenzen, die Edge Microgateway herunterlädt und verarbeitet. Fügen Sie der /products
API, die in der Edge Microgateway-Datei *.config.yaml
aufgeführt ist, den productnamefilter
-Abfrageparameter hinzu, um heruntergeladene Produkte zu filtern. Beispiel:
edge_config: bootstrap: >- https://edgemicroservices.apigee.net/edgemicro/bootstrap/organization/willwitman/environment/test jwt_public_key: 'https://myorg-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://myorg-test.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24'
Der Wert des Abfrageparameters muss im Format für reguläre Ausdrücke angegeben und URL-codiert sein. Der reguläre Ausdruck ^[Ee]dgemicro.*$
erfasst beispielsweise Namen wie „edgemicro-test-1“, „edgemicro_demo“ und „Edgemicro_New_Demo“. Der URL-codierte Wert, der für die Verwendung im Abfrageparameter geeignet ist, lautet: %5E%5BEe%5Ddgemicro.%2A%24
.
Die folgende Debug-Ausgabe zeigt, dass nur die gefilterten Produkte heruntergeladen wurden:
... 2020-05-27T03:13:50.087Z [76060] [microgateway-config network] products download from https://gsc-demo-prod.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24 returned 200 OK ... .... .... { "apiProduct":[ { "apiResources":[ ], "approvalType":"auto", "attributes":[ { "name":"access", "value":"public" } ], "createdAt":1590549037549, "createdBy":"k***@g********m", "displayName":"test upper case in name", "environments":[ "prod", "test" ], "lastModifiedAt":1590549037549, "lastModifiedBy":"k***@g********m", "name":"Edgemicro_New_Demo", "proxies":[ "catchall" ], "quota":"null", "quotaInterval":"null", "quotaTimeUnit":"null", "scopes":[ ] }, { "apiResources":[ ], "approvalType":"auto", "attributes":[ { "name":"access", "value":"public" } ], "createdAt":1590548328998, "createdBy":"k***@g********m", "displayName":"edgemicro test 1", "environments":[ "prod", "test" ], "lastModifiedAt":1590548328998, "lastModifiedBy":"k***@g********m", "name":"edgemicro-test-1", "proxies":[ "Lets-Encrypt-Validation-DoNotDelete" ], "quota":"null", "quotaInterval":"null", "quotaTimeUnit":"null", "scopes":[ ] }, { "apiResources":[ "/", "/**" ], "approvalType":"auto", "attributes":[ { "name":"access", "value":"public" } ], "createdAt":1558182193472, "createdBy":"m*********@g********m", "displayName":"Edge microgateway demo product", "environments":[ "prod", "test" ], "lastModifiedAt":1569077897465, "lastModifiedBy":"m*********@g********m", "name":"edgemicro_demo", "proxies":[ "edgemicro-auth", "edgemicro_hello" ], "quota":"600", "quotaInterval":"1", "quotaTimeUnit":"minute", "scopes":[ ] } ] }
Produkte nach benutzerdefinierten Attributen filtern
So filtern Sie Produkte anhand von benutzerdefinierten Attributen:
- Wählen Sie in der Edge-Benutzeroberfläche den Proxy edgemicro_auth in der Organisation/Umgebung aus, in der Sie Edge Microgateway konfiguriert haben.
- Öffnen Sie im Editor "Entwickeln" die JavaCallout-Richtlinie.
- Fügen Sie ein benutzerdefiniertes Attribut mit dem Schlüssel
products.filter.attributes
mit einer durch Kommas getrennten Liste von Attributnamen hinzu. Nur Produkte, die einen der benutzerdefinierten Attributnamen enthalten, werden an Edge Microgateway zurückgegeben. - Optional können Sie die Prüfung deaktivieren, um zu sehen, ob das Produkt für die aktuelle Umgebung aktiviert ist. Dazu setzen Sie das benutzerdefinierte Attribut
products.filter.env.enable
auffalse
. Die Standardeinstellung ist „true“. - (Nur Private Cloud) Wenn Sie Edge für Private Cloud verwenden, legen Sie das Attribut
org.noncps
auftrue
fest, um Produkte für Nicht-CPS-Umgebungen abzurufen.
Beispiel:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <JavaCallout async="false" continueOnError="false" enabled="true" name="JavaCallout"> <DisplayName>JavaCallout</DisplayName> <FaultRules/> <Properties> <Property name="products.filter.attributes">attrib.one, attrib.two</Property> <Property name="products.filter.env.enable">false</Property> <Property name="org.noncps">true</Property> </Properties> <ClassName>io.apigee.microgateway.javacallout.Callout</ClassName> <ResourceURL>java://micro-gateway-products-javacallout-2.0.0.jar</ResourceURL> </JavaCallout>
Push-Frequenz für Analysen 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 Analysedatensätzen, die der Zwischenspeicher enthalten kann, bevor mit dem Löschen der ältesten Datensätze begonnen wird. Standardeinstellung: 10.000
- batchSize (optional): Die maximale Größe eines Batches von Analysedatensätzen, das an Apigee gesendet wird. Standardeinstellung: 500
- flushInterval (optional): Die Anzahl der Millisekunden zwischen den einzelnen Leerungen eines Batches von Analysedatensätzen, die an Apigee gesendet werden. Standardeinstellung: 5.000
Beispiel:
analytics: bufferSize: 15000 batchSize: 1000 flushInterval: 6000
Analysedaten maskieren
Die folgende Konfiguration verhindert, dass Anfragepfadinformationen in Edge-Analysen angezeigt werden. Fügen Sie der Mikrogateway-Konfiguration Folgendes hinzu, um den Anfrage-URI und/oder den Anfragepfad zu maskieren. Der URI besteht aus dem Hostnamen und dem Pfadteil 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 verwirren. Im Analytics-Dashboard folgen getrennte Proxys diesem Benennungsmuster:
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 zum Trennen im Analytics-Dashboard an. Wenn Sie beispielsweise
/healthcheck
angeben, werden alle API-Aufrufe, die den Pfad/healthcheck
enthalten, im Dashboard alsedgemicro_proxyname-health
angezeigt. Beachten Sie, dass dieses Flag den Proxy-Basispfad ignoriert. Verwenden Sie das FlagproxyPath
, um basierend auf einem vollständigen Pfad, einschließlich Basispfad, zu trennen. - proxyPath (optional): Gibt einen vollständigen API-Proxy-Pfad, einschließlich des Proxy-Basispfads, an, 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 alsedgemicro_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
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
als separater Proxy namens edgemicro_proxyname-health
im Analyse-Dashboard getrennt aufgeführt.
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
HTTP-Proxy für die Kommunikation mit Apigee Edge verwenden
Hinzugefügt in Version 3.1.2.
So verwenden Sie einen HTTP-Proxy für die Kommunikation zwischen Edge Microgateway und Apigee Edge:
- Legen Sie die Umgebungsvariablen
HTTP_PROXY
,HTTPS_PROXY
undNO_PROXY
fest. Diese Variablen steuern die Hosts für jeden HTTP-Proxy, den Sie für die Kommunikation mit Apigee Edge verwenden möchten oder welche Hosts die Kommunikation mit Apigee Edge nicht übernehmen sollen. Beispiel:export HTTP_PROXY='http://localhost:3786' export HTTPS_PROXY='https://localhost:3786' export NO_PROXY='localhost,localhost:8080'
Beachten Sie, dass
NO_PROXY
eine durch Kommas getrennte Liste von Domains sein kann, an die Edge Microgateway nicht weitergeleitet werden soll.Weitere Informationen zu diesen Variablen finden Sie unter https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables.
- Starten Sie Edge Microgateway neu.
HTTP-Proxy für die Zielkommunikation verwenden
Hinzugefügt in Version 3.1.2.
So verwenden Sie einen HTTP-Proxy für die Kommunikation zwischen Edge Microgateway und Back-End-Zielen:
- Fügen Sie der Konfigurationsdatei des Microgateways die folgende Konfiguration hinzu:
edgemicro: proxy: tunnel: true | false url: proxy_url bypass: target_host # target hosts to bypass the proxy. enabled: true | false
Wobei:
- tunnel: (optional) Wenn dieser Wert auf "true" gesetzt ist, verwendet Edge Microgateway die Methode HTTP CONNECT, um HTTP-Anfragen über eine einzelne TCP-Verbindung zutunneln. (Das Gleiche gilt, wenn die Umgebungsvariablen zum Konfigurieren des Proxys, wie unten erwähnt, TLS aktiviert sind.) Standard:
false
- url: Die HTTP-Proxy-URL.
- bypass: (optional) Gibt eine oder mehrere kommagetrennte Zielhost-URLs an, die den HTTP-Proxy umgehen sollen. Wenn dieses Attribut nicht festgelegt ist, verwenden Sie die Umgebungsvariable NO_PROXY, um anzugeben, welche Ziel-URLs umgangen werden sollen.
- enabled: Wenn „true“ und
proxy.url
festgelegt ist, verwenden Sie den Wertproxy.url
für den HTTP-Proxy. Wenn „true“ undproxy.url
nicht festgelegt ist, verwenden Sie die in den HTTP-Proxy-UmgebungsvariablenHTTP_PROXY
undHTTPS_PROXY
angegebenen Proxys, wie unter HTTP-Proxy für die Kommunikation mit Apigee Edge verwenden beschrieben.
Beispiel:
edgemicro: proxy: tunnel: true url: 'http://localhost:3786' bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy. enabled: true
- tunnel: (optional) Wenn dieser Wert auf "true" gesetzt ist, verwendet Edge Microgateway die Methode HTTP CONNECT, um HTTP-Anfragen über eine einzelne TCP-Verbindung zutunneln. (Das Gleiche gilt, wenn die Umgebungsvariablen zum Konfigurieren des Proxys, wie unten erwähnt, TLS aktiviert sind.) Standard:
- Starten Sie Edge Microgateway neu.
Platzhalter in Microgateway-fähigen Proxys verwenden
Sie können einen oder mehrere „*“-Platzhalter im Basispfad eines edgemicro_*-Proxys (Microgateway-aware) verwenden. Der Basispfad /team/*/members ermöglicht es Clients beispielsweise, https://[host]/team/blue/members und https://[host]/team/green/members aufzurufen, ohne neue API-Proxys zur Unterstützung neuer Teams erstellen zu müssen. Beachten Sie, dass /**/
nicht unterstützt wird.
Wichtig: Apigee unterstützt NICHT die Verwendung eines Platzhalters „*“ als erstes Element eines Basispfads. Folgendes wird beispielsweise NICHT unterstützt: /*/
-Suche.
JWT-Schlüssel rotieren
Nachdem Sie ein JWT zum ersten Mal generiert haben, müssen Sie möglicherweise das Paar aus öffentlichem und privatem Schlüssel ändern, das in der Edge-verschlüsselten KVM gespeichert ist. Dieser Vorgang zum Generieren eines neuen Schlüsselpaars wird als Schlüsselrotation bezeichnet.
So verwendet Edge Microgateway JWTs
JSON Web Token (JWT) ist ein Tokenstandard, der in RFC7519 beschrieben wird. JWT bietet eine Möglichkeit zum Signieren einer Reihe von Anforderungen, die vom Empfänger des JWT zuverlässig verifiziert werden können.
Sie können ein JWT über die Befehlszeile generieren und anstelle eines API-Schlüssels im Autorisierungsheader von API-Aufrufen verwenden. Beispiel:
curl -i http://localhost:8000/hello -H "Authorization: Bearer eyJhbGciOiJ..dXDefZEA"
Informationen zum Generieren von JWTs mit der Befehlszeile finden Sie unter Token generieren.
Was ist Schlüsselrotation?
Nachdem Sie ein JWT zum ersten Mal generiert haben, müssen Sie möglicherweise das Paar aus öffentlichem und privatem Schlüssel ändern, das in der Edge-verschlüsselten KVM gespeichert ist. Dieser Vorgang zum Generieren eines neuen Schlüsselpaars wird als Schlüsselrotation bezeichnet. Wenn Sie Schlüssel rotieren, wird ein neues Paar aus privatem und öffentlichem Schlüssel generiert und in der KVM „Microgateway“ in Ihrer Apigee Edge-Organisation/Umgebung gespeichert. Darüber hinaus 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. Eine KVM mit dem Namen microgateway
wurde erstellt und mit Schlüsseln gefüllt, als Sie Edge Microgateway zum ersten Mal eingerichtet (konfiguriert) haben. Die Schlüssel in der KVM werden zum Signieren und Verschlüsseln eines JWT verwendet.
Zu den KVM-Schlüsseln gehören:
-
private_key – Der neueste (zuletzt erstellte) private RSA-Schlüssel zum Signieren von JWTs.
-
public_key: Das neueste (zuletzt erstellte) Zertifikat zur Überprüfung der mit dem privaten_key signierten JWTs.
-
private_key_kid – Die neueste (zuletzt erstellte) private Schlüssel-ID. Diese Schlüssel-ID ist dem Wert „private_key“ zugeordnet und wird zur Unterstützung der Schlüsselrotation verwendet.
-
public_key1_kid – Die neueste (zuletzt erstellte) öffentliche Schlüssel-ID. Dieser Schlüssel ist dem Wert „public_key1“ zugeordnet und wird zur Unterstützung der Schlüsselrotation verwendet. Dieser Wert ist mit dem untergeordneten Wert des privaten Schlüssels identisch.
-
public_key1 – der neueste (zuletzt erstellte) öffentliche Schlüssel.
Wenn Sie eine Schlüsselrotation ausführen, werden vorhandene Schlüssel/Wert-Paare in der Zuordnung ersetzt und neue Schlüssel hinzugefügt, um die alten öffentlichen Schlüssel beizubehalten. Beispiel:
-
public_key2_kid – Die alte öffentliche Schlüssel-ID. Dieser Schlüssel ist dem Wert „public_key2“ zugeordnet und wird zur Unterstützung der Schlüsselrotation verwendet.
-
public_key2 – Der alte öffentliche Schlüssel.
Zur Bestätigung vorgelegte JWTs werden mit dem neuen öffentlichen Schlüssel verifiziert. Wenn die Überprüfung fehlschlägt, wird der alte öffentliche Schlüssel verwendet, bis das JWT abläuft (nach dem Intervall „token_expiry*“, standardmäßig 30 Minuten). Auf diese Weise können Sie Schlüssel „rotieren“, ohne den API-Traffic sofort zu unterbrechen.
So führen Sie eine Schlüsselrotation aus
In diesem Abschnitt wird erläutert, wie eine Schlüsselrotation ausgeführt wird.
- Verwenden Sie den Befehl
edgemicro upgradekvm
, um ein Upgrade der KVM durchzuführen. Weitere Informationen zum Ausführen dieses Befehls finden Sie unter Upgrade der KVM ausführen. Sie müssen diesen Schritt nur einmal ausführen. - Verwenden Sie den Befehl
edgemicro upgradeauth
, um den Proxy edgemicro-oauth zu aktualisieren. Weitere Informationen zum Ausführen dieses Befehls finden Sie unter Grading des Edgemicro-auth-Proxys. Sie müssen diesen Schritt nur einmal ausführen. - Fügen Sie der Datei
~/.edgemicro/org-env-config.yaml
die folgende Zeile hinzu. Dabei müssen Sie dieselbe Organisation und Umgebung angeben, die Sie für das Mikrogateway konfiguriert haben:jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'
Führen Sie den Schlüsselrotationsbefehl aus, um die Schlüssel zu rotieren. Weitere Informationen zu diesem Befehl finden Sie unter Schlüssel rotieren.
edgemicro rotatekey -o $ORG -e $ENV -k $KEY -s $SECRET
Beispiel:
edgemicro rotatekey -o docs -e test \ -k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \ -s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47
Nach der Schlüsselrotation gibt Edge mehrere Schlüssel an Edge Microgateway zurück. Hinweis: Im folgenden Beispiel hat jeder Schlüssel einen eindeutigen Wert für „kid“ (Schlüssel-ID). Das Mikrogateway verwendet diese Schlüssel dann, um Autorisierungstokens zu validieren. Wenn die Tokenvalidierung fehlschlägt, prüft das Mikrogateway, ob der Schlüsselsatz einen älteren Schlüssel enthält, und versucht, diesen Schlüssel auszuführen. Das Format der zurückgegebenen Schlüssel ist der JSON Web Key (JWK). 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" } ] }
„Nicht vor“-Verzögerung konfigurieren
Ab Version 3.1.5 ist der neue private Schlüssel, der vom Befehl rotatekey
generiert wurde, sofort wirksam. Die neu generierten Tokens wurden mit dem neuen privaten Schlüssel signiert. Der neue öffentliche Schlüssel wurde Edge Microgateway-Instanzen jedoch standardmäßig nur alle zehn Minuten zur Verfügung gestellt, als die Mikrogateway-Konfiguration aktualisiert wurde. Aufgrund dieser Verzögerung zwischen der Tokensignatur und der Aktualisierung der Mikrogateway-Instanz werden Tokens, die mit dem neuesten Schlüssel signiert sind, so lange abgelehnt, bis alle Instanzen den öffentlichen neuesten Schlüssel erhalten haben.
In Fällen, in denen mehrere Mikrogateway-Instanzen vorhanden sind, führte die Verzögerung des öffentlichen Schlüssels manchmal zu vorübergehenden Laufzeitfehlern mit dem Status 403, da die Tokenvalidierung auf einer Instanz bestanden, auf einer anderen Instanz jedoch fehlschlagen würde, bis alle Instanzen aktualisiert wurden.
Ab Version 3.1.6 können Sie mit einem neuen Flag für den Befehl rotatekey
eine Verzögerung angeben, bis der neue private Schlüssel wirksam wird. So können alle Mikrogateway-Instanzen aktualisiert werden und den neuen öffentlichen Schlüssel erhalten. Das neue Flag ist --nbf
und steht für „not before“ (nicht davor).
Dieses Flag verwendet einen ganzzahligen Wert, d. h. die Anzahl der Minuten, die verzögert werden sollen.
Im folgenden Beispiel ist die Verzögerung auf 15 Minuten eingestellt:
edgemicro rotatekey -o docs -e test \ -k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \ -s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47 \ --nbf 15
Es empfiehlt sich, die Verzögerung auf einen größeren Wert als die Konfigurationseinstellung config_change_poll_internal
festzulegen, die standardmäßig 10 Minuten beträgt. Weitere Informationen finden Sie unter edgemicro-Attribute.
Heruntergeladene Proxys filtern
Edge Microgateway lädt standardmäßig 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.
- Öffnen Sie die Edge Micro-Konfigurationsdatei:
~/.edgemicro/org-env-config.yaml
- 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. Bei dieser Produktkonfiguration kann ein mit diesem Produkt verknüpfter API-Schlüssel mit jedem Proxy verwendet werden, der in Ihrer Organisation bereitgestellt wird. 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 bei der Fehlerbehebung und Fehlerbehebung für benutzerdefinierte Plug-ins hilfreich.
- Starten Sie Edge Microgateway im Debug-Modus neu. Fügen Sie dazu
DEBUG=*
am Anfang des Befehlsstart
ein:DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
.Mit dem folgenden Befehl können Sie die Debug-Ausgabe an eine Datei weiterleiten:
export DEBUG=* nohup edgemicro start \ -o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log
- Starten Sie den Debugger und richten Sie ihn so ein, dass der Debugging-Prozess auf die Portnummer überwacht wird.
- Sie können jetzt Schritt für Schritt den Edge Microgateway-Code durchgehen, Haltepunkte, Überwachungsausdrücke usw. festlegen.
Sie können Node.js-Standard-Flags für den Debug-Modus angeben. Mit --nolazy
wird beispielsweise das Debugging von asynchronem Code unterstützt.
Protokolldateien überprüfen
Prüfen Sie bei Problemen die Protokolldateien, um Details zur Ausführung und Fehlerinformationen zu erhalten. Weitere Informationen finden Sie unter Protokolldateien verwalten.
API-Schlüsselsicherheit verwenden
API-Schlüssel bieten einen einfachen Mechanismus zum Authentifizieren von Clients, die Anfragen an Edge Microgateway stellen. Sie können einen API-Schlüssel abrufen, indem Sie den Wert des Consumer-Schlüssels (auch Client-ID genannt) aus einem Apigee Edge-Produkt kopieren, das den Edge Microgateway-Authentifizierungs-Proxy 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 Cache-Control: no-cache
-Header bei eingehenden 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 der Name des Headers und 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"
Name des API-Schlüssels 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 erläutert. So ändern Sie beispielsweise den Namen 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 Secure Edge Microgateway.
Upstream-Antwortcodes aktivieren
Standardmäßig gibt das Plug-in oauth
nur 4xx-Fehlerstatuscodes zurück, wenn die Antwort nicht den Status 200 hat. Sie können dieses Verhalten so ändern, dass je nach Fehler immer der exakte 4xx- oder 5xx-Code zurückgegeben wird.
Fügen Sie der Edge Microgateway-Konfiguration das Attribut oauth.useUpstreamResponse: true
hinzu, um dieses Feature zu aktivieren. Beispiel:
oauth: allowNoAuthorization: false allowInvalidAuthorization: false gracePeriod: 10 useUpstreamResponse: true
OAuth2-Tokensicherheit verwenden
In diesem Abschnitt wird erläutert, wie Sie OAuth2-Zugriffstokens und Aktualisierungstokens erhalten. Zugriffstokens werden verwendet, um sichere API-Aufrufe über das Mikrogateway durchzuführen. Aktualisierungstokens werden verwendet, um neue Zugriffstokens abzurufen.
So erhalten Sie ein Zugriffstoken
In diesem Abschnitt wird erläutert, wie Sie mit dem edgemicro-auth
-Proxy ein Zugriffstoken abrufen.
Mit dem Befehl edgemicro token
in der Befehlszeile können Sie auch ein Zugriffstoken abrufen.
Weitere Informationen zur Befehlszeile finden Sie unter Tokens verwalten.
API 1: Anmeldedaten als Textparameter senden
Ersetzen Sie die Namen Ihrer Organisation und Umgebung in der URL und ersetzen Sie die Textparameter client_id und client_secret durch die Werte für Nutzer-ID und Consumer Secret, die Sie von einer Entwickleranwendung in Apigee Edge erhalten haben:
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: Anmeldedaten in einem Basic Auth-Header senden
Senden Sie die Clientanmeldedaten als Basisauthentifizierungsheader und grant_type
als Formularparameter. Dieses Befehlsformular wird auch in RFC 6749: Das OAuth 2.0-Autorisierungs-Framework behandelt.
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
Die API gibt eine JSON-Antwort zurück. Zwischen den Attributentoken
und access_token
gibt es keinen Unterschied. Beides ist möglich. Beachten Sie, dass expires_in
eine Ganzzahl in Sekunden ist.
{ "token": "eyJraWQiOiIxIiwidHlwIjoi", "access_token": "eyJraWQiOiIxIiwid", "token_type": "bearer", "expires_in": 1799 }
Aktualisierungstoken abrufen
Führen Sie einen API-Aufruf an den Endpunkt /token
des Proxys edgemicro-auth
aus, um ein Aktualisierungstoken abzurufen. Sie MÜSSEN diesen API-Aufruf mit dem Berechtigungstyp password
ausführen. Führen Sie dazu die folgenden Schritte aus.
- Fordern Sie mit der
/token
API ein Zugriffs- und Aktualisierungstoken an. Der Berechtigungstyp istpassword
: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: Beachten Sie, dass
expires_in
ganze Zahlen sind und in Sekunden angegeben werden.{ "token": "your-access-token", "access_token": "your-access-token", "token_type": "bearer", "expires_in": 108, "refresh_token": "your-refresh-token", "refresh_token_expires_in": 431, "refresh_token_issued_at": "1562087304302", "refresh_token_status": "approved" }
- Sie können jetzt mit dem Aktualisierungstoken ein neues Zugriffstoken abrufen. Dazu rufen Sie 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 in etwa so aus:
{ "token": "your-new-access-token" }
Dauerhaftes Monitoring
Endpunkt für Konfigurationsdatei angeben
Wenn Sie mehrere Edge Microgateway-Instanzen ausführen, möchten Sie möglicherweise deren Konfigurationen von einem einzigen Standort aus verwalten. Dazu können Sie einen HTTP-Endpunkt angeben, von dem Edge Micro seine Konfigurationsdatei herunterladen kann. Sie können diesen Endpunkt beim Starten von Edge Micro mit dem Flag -u angeben.
Beispiel:
edgemicro start -o jdoe -e test -u http://mylocalserver/mgconfig -k public_key -s secret_key
Der Endpunkt „mgconfig“ gibt den Inhalt Ihrer Konfigurationsdatei zurück. Dies ist die Datei, die sich standardmäßig in ~/.edgemicro
befindet und die Namenskonvention org-env-config.yaml
hat.
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 bei jedem Aufruf von socket.write()
sofort durch Daten ausgelöst. Weitere Informationen finden Sie in der Node.js-Dokumentation.
Um nodelay
zu aktivieren, 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 eigenständigen Modus ausführen
Sie können Edge Microgateway vollständig von jeder Apigee Edge-Abhängigkeit getrennt ausführen. Mit diesem Szenario, das als eigenständiger Modus bezeichnet wird, 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 benötigen:
- OAuth und API-Schlüssel
- Kontingent
- Analysen
Andererseits funktionieren benutzerdefinierte Plug-ins und Spike Arrest normal, da sie keine Verbindung zu Apigee Edge benötigen. Darüber hinaus können Sie mit dem neuen Plug-in extauth
im eigenständigen Modus API-Aufrufe an das Mikrogateway mit einem JWT autorisieren.
Gateway konfigurieren und starten
So führen Sie Edge Microgateway im eigenständigen Modus aus:
- Erstellen Sie eine Konfigurationsdatei mit folgendem Namen:
$HOME/.edgemicro/$ORG
-
$ENV-config.yamlBeispiel:
vi $HOME/.edgemicro/foo-bar-config.yaml
- Fügen Sie den 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
- Exportieren Sie die folgende Umgebungsvariable mit dem Wert „1“:
export EDGEMICRO_LOCAL=1
- Führen Sie den folgenden
start
-Befehl aus, wobei Sie Werte zum Instanziieren des lokalen Proxys angeben:edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \ -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH
Wobei:
- $ORG ist der Name der Organisation, den Sie im Namen der Konfigurationsdatei verwendet haben.
- $ENV ist der Name der Umgebung, 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 Stammpfad einfach einen Schrägstrich an, z. B. „/“.
Beispiel:
edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
- Die Konfiguration testen.
curl http://localhost:8000/echo { "error" : "missing_authorization" }
Da sich das Plug-in
extauth
in der Dateifoo-bar-config.yaml
befindet, wird der Fehler „missing_authorization“ ausgegeben. Dieses Plug-in validiert ein JWT, das im Autorisierungsheader des API-Aufrufs vorhanden sein muss. Im nächsten Abschnitt erhältst du ein JWT, 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 auf Apigee Edge (edgemicro-auth/jwkPublicKeys
) abrufen. Dieser Endpunkt wird bereitgestellt, wenn Sie eine Standardeinrichtung und -konfiguration von Edge Microgateway ausführen.
Damit Sie das JWT vom Apigee-Endpunkt abrufen können, müssen Sie zuerst das standardmäßige Edge Microgateway einrichten und mit dem Internet verbunden sein. Der Apigee-Endpunkt wird hier nur zu Beispielzwecken verwendet und ist nicht erforderlich. Sie können bei Bedarf einen anderen JWT-Tokenendpunkt verwenden. In diesem Fall musst du das JWT mithilfe der für diesen Endpunkt bereitgestellten API abrufen.
In den folgenden Schritten wird erläutert, wie Sie ein Token über den Endpunkt edgemicro-auth/jwkPublicKeys
abrufen:
- Sie müssen eine Standardeinrichtung und -konfiguration von Edge Microgateway ausführen, um den
edgemicro-auth
-Proxy in Ihrer Organisation/Umgebung auf Apigee Edge bereitzustellen. Wenn Sie diesen Schritt zuvor ausgeführt haben, müssen Sie ihn nicht wiederholen. - Wenn Sie Edge Microgateway in Apigee Cloud bereitgestellt haben, müssen Sie mit dem Internet verbunden sein, damit Sie ein JWT von diesem Endpunkt abrufen können.
-
Beenden Sie Edge Microgateway:
edgemicro stop
- Verweisen Sie in der zuvor erstellten Konfigurationsdatei (
$HOME/.edgemicro
/org-env-config.yaml
) das Attributextauth:publickey_url
auf den Endpunktedgemicro-auth/jwkPublicKeys
in Ihrer Apigee Edge-Organisation/Umgebung. Beispiel:extauth: publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
-
Starten Sie Edge Microgateway wie zuvor unter Verwendung der Organisations-/Umgebungsnamen, die Sie im Namen der Konfigurationsdatei verwendet haben, neu starten. Beispiel:
edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
-
Rufe ein JWT-Token vom Autorisierungsendpunkt ab. Da Sie den Endpunkt
edgemicro-auth/jwkPublicKeys
verwenden, können Sie diesen Befehl über die Befehlszeile 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 der Apigee-Organisation, für die Sie zuvor Edge Microgateway konfiguriert haben.
- your_env ist eine Umgebung in der Organisation.
- Die Option
i
gibt den Consumer-Key aus einer Entwickler-App an, deren Produkt denedgemicro-auth
-Proxy enthält. - Die Option
s
gibt das Consumer Secret aus einer Entwickler-App an, deren Produkt denedgemicro-auth
-Proxy enthält.
Mit diesem Befehl wird Apigee Edge aufgefordert, ein JWT zu generieren, das dann zur Überprüfung von API-Aufrufen verwendet werden kann.
Siehe auch Token generieren.Eigenständige Konfiguration testen
Um die Konfiguration zu testen, rufen Sie wie folgt die API mit dem Token auf, das dem Autorisierungsheader hinzugefügt wurde:
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":"" }
Lokaler Proxymodus verwenden
Im lokalen Proxymodus muss für Edge Microgateway kein Microgateway-kompatibler Proxy auf Apigee Edge bereitgestellt werden. Stattdessen konfigurieren Sie einen "lokalen Proxy", indem Sie beim Starten des Mikrogateways einen lokalen Proxynamen, einen Basispfad und eine Ziel-URL angeben. Anschließend werden API-Aufrufe an das Mikrogateway an die Ziel-URL des lokalen Proxys gesendet. Ansonsten funktioniert der lokale Proxymodus genauso wie das Ausführen von Edge Microgateway im normalen Modus. Die Authentifizierung funktioniert auf die gleiche Weise wie die Spike Arrest und Kontingenterzwingung, benutzerdefinierte Plug-ins usw.
Anwendungsfall und Beispiel
Der lokale Proxymodus ist nützlich, wenn Sie nur einen einzelnen Proxy mit einer Edge Microgateway-Instanz verknüpfen müssen. Beispielsweise können Sie Edge Microgateway als Sidecar-Proxy in Kubernetes einfügen, wobei ein Mikrogateway und ein Dienst jeweils in einem einzelnen Pod ausgeführt werden und das Mikrogateway den Traffic zu und vom Begleitdienst verwaltet. Die folgende Abbildung zeigt diese Architektur, bei der Edge Microgateway als Sidecar-Proxy in einem Kubernetes-Cluster funktioniert. Jede Mikrogateway-Instanz kommuniziert nur mit einem einzelnen Endpunkt auf ihrem Begleitdienst:
Ein Vorteil dieses Architekturstils besteht darin, dass Edge Microgateway API-Verwaltung für einzelne Dienste bietet, die in einer Containerumgebung wie einem Kubernetes-Cluster bereitgestellt werden.
Lokaler Proxymodus wird konfiguriert
Gehen Sie folgendermaßen vor, um Edge Microgateway für die Ausführung im lokalen Proxymodus zu konfigurieren:
- Führen Sie
edgemicro init
aus, um Ihre lokale Konfigurationsumgebung genau wie bei einer typischen Edge Microgateway-Einrichtung einzurichten. Weitere Informationen finden Sie unter Edge Microgateway konfigurieren. - Führen Sie
edgemicro configure
wie bei einem typischen Einrichtungsverfahren für Edge Microgateway aus. Beispiel:edgemicro configure -o your_org -e your_env -u your_apigee_username
Dieser Befehl stellt die Richtlinie edgemicro-auth in Edge bereit und gibt einen Schlüssel und ein Secret zurück, die Sie zum Starten des Mikrogateways benötigen. Weitere Informationen finden Sie unter Edge Microgateway konfigurieren.
- Erstellen Sie in Apigee Edge ein API-Produkt und die folgenden obligatorischen Konfigurationsanforderungen (Sie können alle anderen Konfigurationen nach Bedarf verwalten):
- Sie müssen dem Produkt den Proxy edgemicro-auth hinzufügen. Dieser Proxy wurde bei der Ausführung von
edgemicro configure
automatisch bereitgestellt. - Sie müssen einen Ressourcenpfad angeben. Apigee empfiehlt, dem Produkt folgenden Pfad hinzuzufügen:
/**
. Weitere Informationen finden Sie unter Verhalten des Ressourcenpfads konfigurieren. Weitere Informationen finden Sie unter API-Produkte erstellen in der Edge-Dokumentation.
- Sie müssen dem Produkt den Proxy edgemicro-auth hinzufügen. Dieser Proxy wurde bei der Ausführung von
Erstellen Sie in Apigee Edge einen Entwickler oder verwenden Sie einen vorhandenen Entwickler, wenn Sie möchten. Weitere Informationen finden Sie unter Entwickler über die Edge-Verwaltungs-UI hinzufügen.
- Erstellen Sie in Apigee Edge eine Entwickler-App. Sie müssen das soeben erstellte API-Produkt zur App hinzufügen. Weitere Informationen finden Sie unter App in der Edge-Verwaltungs-UI registrieren.
- Exportieren Sie auf der Maschine, auf der Edge Microgateway installiert ist, die folgende Umgebungsvariable mit dem Wert „1“.
export EDGEMICRO_LOCAL_PROXY=1
- Führen Sie den 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 bei der Ausführung von
edgemicro configure
zurückgegeben wurde. - your_secret ist das Secret, das bei der Ausführung 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 Stammpfad einfach 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 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" }
Bei diesem ersten API-Aufruf ist ein Fehler aufgetreten, da 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 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":"" }
Synchronisierer verwenden
In diesem Abschnitt wird erläutert, wie Sie die Synchronisierung verwenden. Diese optionale Funktion verbessert die Ausfallsicherheit von Edge Microgteway, da damit Konfigurationsdaten von Apigee Edge abgerufen und in eine lokale Redis-Datenbank geschrieben werden können. Wenn eine Synchronisierungsinstanz ausgeführt wird, können andere Edge Microgateway-Instanzen, die auf verschiedenen Knoten ausgeführt werden, ihre Konfiguration direkt aus dieser Datenbank abrufen.
Die Synchronisierungsfunktion wird derzeit für Redis 5.0.x unterstützt.
Was ist der Synchronisierer?
Der Synchronisierer bietet ein Grad an Ausfallsicherheit für Edge Microgateway. So wird sichergestellt, dass jede Instanz von Edge Microgateway die gleiche Konfiguration verwendet und dass Edge Microgateway-Instanzen bei einer Internetunterbrechung ordnungsgemäß gestartet und ausgeführt werden können.
Standardmäßig müssen Edge Microgateway-Instanzen mit Apigee Edge kommunizieren können, um ihre Konfigurationsdaten wie API-Proxy- und API-Produktkonfigurationen abzurufen und zu aktualisieren. Wenn die Internetverbindung mit Edge unterbrochen ist, können Mikrogateway-Instanzen weiterhin funktionieren, da die neuesten Konfigurationsdaten im Cache gespeichert werden. Neue Mikrogateway-Instanzen können jedoch nicht ohne eine klare Verbindung gestartet werden. Außerdem kann eine Internetunterbrechung dazu führen, dass eine oder mehrere Mikrogateway-Instanzen mit Konfigurationsinformationen ausgeführt werden, die mit anderen Instanzen nicht synchron sind.
Der Edge Microgateway-Synchronisierer bietet einen alternativen Mechanismus für Edge Microgateway-Instanzen, um Konfigurationsdaten abzurufen, die sie zum Starten und Verarbeiten von API-Proxy-Traffic benötigen.
Zu den Konfigurationsdaten, die aus Aufrufen von Apigee Edge abgerufen werden, gehören der Aufruf jwk_public_keys
, der jwt_public_key
, der Bootstrap-Aufruf und der Aufruf der API-Produkte.
Der Synchronisierer ermöglicht es allen Edge Microgateway-Instanzen, die auf verschiedenen Knoten ausgeführt werden, ordnungsgemäß zu starten und synchron zu bleiben, selbst wenn die Internetverbindung zwischen Edge Microgateway und Apigee Edge unterbrochen ist.
Die Synchronisierung ist eine speziell konfigurierte Instanz von Edge Microgateway. Sein einziger Zweck besteht darin, Apigee Edge abzufragen (der Zeitpunkt ist konfigurierbar), Konfigurationsdaten abzurufen und in eine lokale Redis-Datenbank zu schreiben. Die Synchronisierungsinstanz selbst kann keinen API-Proxy-Traffic verarbeiten. Andere Instanzen von Edge Microgateway, die auf verschiedenen Knoten ausgeführt werden, können so konfiguriert werden, dass Konfigurationsdaten aus der Redis-Datenbank statt von Apigee Edge abgerufen werden. Da alle Mikrogateway-Instanzen ihre Konfigurationsdaten aus der lokalen Datenbank abrufen, können sie API-Anfragen auch bei einer Internetunterbrechung starten und verarbeiten.
Synchronisierungsinstanz konfigurieren
Fügen Sie der Datei org-env/config.yaml
für die Edge Microgateway-Installation die folgende Konfiguration hinzu, die Sie als Synchronisierung verwenden möchten:
edgemicro: redisHost: host_IP redisPort: host_port redisDb: database_index redisPassword: password edge_config: synchronizerMode: 1 redisBasedConfigCache: true
Beispiel:
edgemicro: redisHost: 192.168.4.77 redisPort: 6379 redisDb: 0 redisPassword: codemaster edge_config: synchronizerMode: 1 redisBasedConfigCache: true
Wahltaste | Beschreibung |
---|---|
redisHost |
Der Host, auf dem Ihre Redis-Instanz ausgeführt wird. Standardeinstellung: 127.0.0.1 |
redisPort |
Der Port der Redis-Instanz. Standardeinstellung: 6379 |
redisDb |
Die zu verwendende Redis-Datenbank. Standardwert: 0 |
redisPassword |
Ihr Datenbankpasswort. |
Speichern Sie abschließend die Konfigurationsdatei und starten Sie die Edge Microgateway-Instanz. Er beginnt damit, Apigee Edge abzufragen und heruntergeladene Konfigurationsdaten in der Redis-Datenbank zu speichern.
Reguläre Edge Microgateway-Instanzen konfigurieren
Während die Synchronisierung ausgeführt wird, können Sie zusätzliche Edge Microgateway-Knoten konfigurieren, um reguläre Mikrogateway-Instanzen auszuführen, die API-Proxy-Traffic verarbeiten. Sie konfigurieren diese Instanzen jedoch so, dass ihre Konfigurationsdaten aus der Redis-Datenbank und nicht von Apigee Edge abgerufen werden.
Fügen Sie der Datei org-env/config.yaml
jedes zusätzlichen Edge Microgateway-Knotens die folgende Konfiguration hinzu. Das Attribut synchronizerMode
ist auf 0
festgelegt. Dieses Attribut legt fest, dass die Instanz als normale Edge Microgateway-Instanz ausgeführt wird, die API-Proxy-Traffic verarbeitet. Die Instanz erhält ihre Konfigurationsdaten von der Redis-Datenbank.
edgemicro: redisHost: host_IP redisPort: host_port redisDb: database_index redisPassword: password edge_config: synchronizerMode: 0 redisBasedConfigCache: true
Beispiel:
edgemicro: redisHost: 192.168.4.77 redisPort: 6379 redisDb: 0 redisPassword: codemaster edge_config: synchronizerMode: 0 redisBasedConfigCache: true
Konfigurationsattribute
Die folgenden Konfigurationseigenschaften wurden hinzugefügt, um die Verwendung des Synchronisers zu unterstützen:
Attribut | Werte | Beschreibung |
---|---|---|
edge_config.synchronizerMode |
„0“ oder „1“ | Wenn 0 (Standardeinstellung) wird Edge Microgateway im Standardmodus ausgeführt. Wenn 1, starten Sie die Edge Microgateway-Instanz, um als Synchronisierung zu arbeiten. In diesem Modus ruft die Instanz Konfigurationsdaten aus Apigee Edge ab und speichert sie in einer lokalen Redis-Datenbank. Diese Instanz kann keine API-Proxy-Anfragen verarbeiten. Sie dient nur dazu, Konfigurationsdaten von Apigee Edge abzufragen und in die lokale Datenbank zu schreiben. Anschließend müssen Sie andere Mikrogateway-Instanzen so konfigurieren, dass sie aus der Datenbank lesen. |
edge_config.redisBasedConfigCache |
True oder false? | Bei „true“ ruft die Edge Microgateway-Instanz ihre Konfigurationsdaten aus der Redis-Datenbank und nicht von Apigee Edge ab. Die Redis-Datenbank muss mit derjenigen übereinstimmen, die der Synchronisierungsdienst für das Schreiben konfiguriert ist. Wenn die Redis-Datenbank nicht verfügbar oder leer ist, sucht das Mikrogateway nach einer vorhandenen cache-config.yaml -Datei für ihre Konfiguration.
Bei „false“ (Standardeinstellung) ruft die Edge Microgateway-Instanz wie gewohnt Konfigurationsdaten von Apigee Edge ab. |
edgemicro.config_change_poll_interval |
Zeitintervall in Sekunden | Gibt das Abfrageintervall für den Synchronisierer an, um Daten aus Apigee Edge abzurufen. |
Ausschluss-URLs für Plug-ins konfigurieren
Sie können das Mikrogateway so konfigurieren, dass die Verarbeitung von Plug-ins für bestimmte URLs übersprungen wird. Sie können diese "Ausschließen"-URLs global (für alle Plug-ins) oder für bestimmte Plug-ins konfigurieren.
Beispiel:
... edgemicro: ... plugins: excludeUrls: '/hello,/proxy_one' # global exclude urls sequence: - oauth - json2xml - quota json2xml: excludeUrls: '/hello/xml' # plugin level exclude urls ...
In diesem Beispiel verarbeiten Plug-ins keine eingehenden API-Proxy-Aufrufe mit den Pfaden /hello
oder /proxy_one
. Außerdem wird das json2xml
-Plug-in bei APIs mit /hello/xml
im Pfad übersprungen.
Konfigurationsattribute mit Werten für Umgebungsvariablen festlegen
Sie können Umgebungsvariablen mithilfe von Tags in der Konfigurationsdatei angeben. Die angegebenen Tags der Umgebungsvariablen werden durch die tatsächlichen Werte der Umgebungsvariablen ersetzt. Ersetzungen werden nur im Arbeitsspeicher und nicht in den ursprünglichen Konfigurations- oder Cache-Dateien gespeichert.
In diesem Beispiel wird das Attribut key
durch den Wert der Umgebungsvariablen TARGETS_SSL_CLIENT_KEY
ersetzt usw.
targets: - ssl: client: key: <E>TARGETS_SSL_CLIENT_KEY</E> cert: <E>TARGETS_SSL_CLIENT_CERT</E> passphrase: <E>TARGETS_SSL_CLIENT_PASSPHRASE</E>
In diesem Beispiel wird das Tag <n>
verwendet, um einen ganzzahligen Wert anzugeben. Es werden nur positive Ganzzahlen unterstützt.
edgemicro: port: <E><n>EMG_PORT</n></E>
In diesem Beispiel wird das Tag <b>
verwendet, um einen booleschen Wert (wahr oder falsch) anzugeben.
quotas: useRedis: <E><b>EMG_USE_REDIS</b></E>