Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Vorgangs- und Konfigurationsreferenz für Edge Microgateway

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

Edge Microgateway v. 3.3.x

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

Edge Microgateway aktualisieren, wenn Sie eine Internetverbindung haben

In diesem Abschnitt wird erläutert, wie Sie eine vorhandene Installation von Edge Microgateway aktualisieren. Wenn Sie ohne Internetverbindung arbeiten, lesen Sie den Abschnitt Kann ich Edge Microgateway ohne Internetverbindung installieren?.

Apigee empfiehlt, die vorhandene Konfiguration mit der neuen Version zu testen, bevor Sie ein Upgrade Ihrer Produktionsumgebung durchführen.

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 eine bestimmte Version von Edge Microgateway installieren möchten, müssen Sie im Installationsbefehl die Versionsnummer angeben. Wenn Sie beispielsweise Version 3.2.3 installieren möchten, verwenden Sie den folgenden Befehl:
```
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 aktuelle Version des edgemicro-auth-Proxys durch:
```
edgemicro upgradeauth -o $ORG -e $ENV -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):

Laden Sie die Edge Microgateway-Konfiguration neu:
```
edgemicro reload -o $ORG -e $ENV -k $KEY -s $SECRET
```
Wobei:
- $ORG ist der Name Ihrer Edge-Organisation (Sie müssen ein Administrator der Organisation sein).
- $ENV 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:

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 Administrator der Organisation sein).
- $ENV 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

In den folgenden Videos erfahren Sie, wie Sie TLS in Apigee Edge Microgateway konfigurieren:

Video	Beschreibung
One-Way-Northbound-TLS konfigurieren	Informationen zum Konfigurieren von TLS in Apigee Edge Microgateway. In diesem Video erhalten Sie einen Überblick über TLS und seine Bedeutung, eine Einführung in TLS in Edge Microgateway und eine Anleitung zum Konfigurieren von Northbound-One-Way-TLS.
2-Way-Northbound-TLS konfigurieren	Dies ist das zweite Video zur Konfiguration von TLS in Apigee Edge Microgateway. In diesem Video wird erläutert, wie Sie die bidirektionale TLS-Verbindung für die Northbound-Verbindung konfigurieren.
One-Way- und Two-Way-Southbound-TLS konfigurieren	In diesem dritten Video zur Konfiguration von TLS in Apigee Edge Microgateway wird erläutert, wie Sie Southbound-1-Way- und 2-Way-TLS 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:

Generieren oder rufen Sie ein SSL-Zertifikat und einen Schlüssel mit dem Dienstprogramm openssl oder einer anderen Methode ab.
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
```
Der in der referenzierten SSL-Schlüsseldatei angegebene Schlüssel darf nicht verschlüsselt sein.
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:

Option	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 die PFX-Datei enthält.
`ca`	Pfad zu einer Datei, die eine Liste vertrauenswürdiger Zertifikate im PEM-Format enthält.
`ciphers`	Ein String, der die zu verwendenden Chiffren beschreibt, getrennt durch einen Doppelpunkt („:“).
`rejectUnauthorized`	Wenn „true“, wird das Serverzertifikat mit der Liste der bereitgestellten Zertifizierungsstellen abgeglichen. 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 bidirektionales SSL; false für unidirektionales SSL

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. Sie können mehrere spezifische Ziele angeben. Unten finden Sie ein Beispiel mit mehreren Zielen.

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

Wenn Sie TLS/SSL-Einstellungen auf mehrere bestimmte Ziele anwenden möchten, müssen Sie den ersten Host in der Konfiguration als „leer“ angeben, wodurch universelle Anfragen aktiviert werden, und dann bestimmte Hosts in beliebiger Reihenfolge angeben. 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

Hier finden Sie eine Liste aller unterstützten Clientoptionen:

Option	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 die PFX-Datei enthält.
`cert`	Pfad zu einer `ca.cert`-Datei (im PEM-Format).
`ca`	Pfad zu einer Datei, die eine Liste vertrauenswürdiger Zertifikate im PEM-Format enthält.
`ciphers`	Ein String, der die zu verwendenden Chiffren beschreibt, getrennt durch einen Doppelpunkt („:“).
`rejectUnauthorized`	Wenn „true“, wird das Serverzertifikat mit der Liste der bereitgestellten Zertifizierungsstellen abgeglichen. 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 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

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.

Wichtig: Wenn Sie den Standard-Authentifizierungsproxy überschreiben, muss der neue Proxy oder Dienst ein Antwortformat zurückgeben, das mit dem Standard-edgemicro-auth-Proxy identisch ist.

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 geben die zu verwendende Logebene in der edgemicro-Konfiguration an. Eine vollständige Liste der Logebenen und ihrer Beschreibungen finden Sie unter edgemicro-Attribute.

In der folgenden Konfiguration wird beispielsweise die Logging-Stufe auf debug festgelegt:

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

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

Strenge Dateiberechtigungen für Protokolldateien lockern

Standardmäßig generiert Edge Microgateway die Anwendungslogdatei (api-log.log) mit der Dateiberechtigungsebene 0600. Mit dieser Berechtigungsstufe können externe Anwendungen oder Nutzer die Logdatei nicht lesen. Wenn Sie diese strenge Berechtigungsstufe lockern möchten, setzen Sie logging:disableStrictLogFile auf true. Wenn dieses Attribut true ist, wird die Protokolldatei mit der Dateiberechtigung 0755 erstellt. Wenn false oder das Attribut nicht angegeben ist, wird die Berechtigung standardmäßig auf 0600 gesetzt.

In Version 3.2.3 hinzugefügt.

Beispiel:

edgemicro:
 logging:
   disableStrictLogFile: true

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 eine Protokolldatei mit der Erweiterung .log. Die Namenskonvention für Logdateien lautet so:

edgemicro-HOST_NAME-INSTANCE_ID-api.log

Beispiel:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.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 der Konsole 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

Verwenden Sie unter Windows SET DEBUG=*

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: die Protokollierungsebene. Dieser Wert hängt vom Kontext der Transaktion und der in der edgemicro-Konfiguration festgelegten Logging-Ebene ab. Weitere Informationen finden Sie unter Protokollierungsstufe festlegen. Für Statistikdatensätze ist die Ebene auf stats festgelegt. Statistikdatensätze werden in regelmäßigen Abständen gemeldet, die mit der Konfiguration stats_log_interval festgelegt werden. Weitere Informationen finden Sie unter Protokollintervalle ändern.
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: die Protokollierungsebene. Dieser Wert hängt vom Kontext der Transaktion und der in der edgemicro-Konfiguration festgelegten Logging-Ebene ab. Weitere Informationen finden Sie unter Protokollierungsstufe festlegen. Für Statistikdatensätze ist die Ebene auf stats festgelegt. Statistikdatensätze werden in regelmäßigen Abständen gemeldet, die mit der Konfiguration stats_log_interval festgelegt werden. Weitere Informationen finden Sie unter Protokollintervalle ändern.
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: die Protokollierungsebene. Dieser Wert hängt vom Kontext der Transaktion und der in der edgemicro-Konfiguration festgelegten Logging-Ebene ab. Weitere Informationen finden Sie unter Protokollierungsstufe festlegen. Für Statistikdatensätze ist die Ebene auf stats festgelegt. Statistikdatensätze werden in regelmäßigen Abständen gemeldet, die mit der Konfiguration stats_log_interval festgelegt werden. Weitere Informationen finden Sie unter Protokollintervalle ändern.
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: die Protokollierungsebene. Dieser Wert hängt vom Kontext der Transaktion und der in der edgemicro-Konfiguration festgelegten Logging-Ebene ab. Weitere Informationen finden Sie unter Protokollierungsstufe festlegen. Für Statistikdatensätze ist die Ebene auf stats festgelegt. Statistikdatensätze werden in regelmäßigen Abständen gemeldet, die mit der Konfiguration stats_log_interval festgelegt werden. Weitere Informationen finden Sie unter Protokollintervalle ändern.
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.
quotaUri: Legen Sie diese Konfigurations-Property fest, wenn Sie Kontingente über den Proxy edgemicro-auth verwalten möchten, der in Ihrer Organisation bereitgestellt wird. Wenn dieses Attribut nicht festgelegt ist, wird der Kontingentendpunkt standardmäßig auf den internen Edge Microgateway-Endpunkt gesetzt.
```
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, 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 – (Empfohlen) Protokolliert alle Anfragen und Antworten, die über eine Edge Microgateway-Instanz laufen.
  - warn: Es werden nur Warnmeldungen protokolliert.
  - error: Es werden nur Fehlermeldungen protokolliert.
  - debug: Protokolliert Debug-Nachrichten sowie Info-, Warn- und Fehlermeldungen.
  - trace: Trace-Informationen für Fehler sowie Informations-, Warn- und Fehlermeldungen werden protokolliert.
  - none: Es wird keine Protokolldatei erstellt.
- 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)
keep_alive_timeout: Mit diesem Attribut können Sie das Edge Microgateway-Zeitlimit (in Millisekunden) festlegen. (Standardwert: 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. (Standard: 5 Sekunden mehr als die mit edgemicro.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 erforderliche Aktion (Zugriff erlauben oder ablehnen), wenn die im accesscontrol-Plug-in angegebene Regel nicht aufgelöst wird (keine Übereinstimmung). Gültige Werte: ALLOW oder DENY. Standard: ALLOW (Hinzugefügt: v3.1.7)
enableAnalytics: (Standard: true) Setzen Sie das Attribut auf false, um zu verhindern, dass das Analyse-Plug-in geladen wird. In diesem Fall werden keine Aufrufe an Apigee Edge Analytics gesendet. Wenn das Attribut auf true gesetzt ist oder nicht angegeben wird, 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
```
Wenn enableAnalytics auf false gesetzt ist, Edge Microgateway aber mit dem Messwert-Plug-in gestartet wird, funktioniert das Analyse-Plug-in wie gewohnt, da das Messwert-Plug-in das Analyse-Plug-in benötigt, um zu funktionieren. Informationen zum Messwert-Plug-in finden Sie in den Versionshinweisen zu Edge Microgateway v1.3.6.

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 beendet wird.

Wert	Beschreibung
Standard	Wenn `on_target_response_abort` nicht angegeben ist, wird die Antwort standardmäßig ohne Fehlermeldung gekürzt. In Logdateien wird eine Warnmeldung mit `targetResponse aborted` und dem Antwortcode 502 angezeigt.
`appendErrorToClientResponseBody`	Der benutzerdefinierte Fehler `TargetResponseAborted` wird an den Client zurückgegeben. In Logdateien wird eine Warnmeldung mit `targetResponse aborted` und dem Antwortcode 502 angezeigt. Außerdem wird der Fehler `TargetResponseAborted` mit der Meldung `Target response ended prematurely.` protokolliert.
`abortClientRequest`	Edge Microgateway bricht die Anfrage ab und eine Warnung wird in die Logdateien geschrieben: `TargetResponseAborted` mit dem Anfrage-Statuscode 502.

Beispiel:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

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)
Legen Sie nicht sowohl allowOAuthOnly als auch allowAPIKeyOnly auf „true“ fest. Standardmäßig sind beide Flags auf „false“ gesetzt (für Abwärtskompatibilität).
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:

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

Produkte nach Name filtern

Verwenden Sie die folgende Konfiguration, um die Anzahl der API-Produkte zu begrenzen, die Edge Microgateway herunterlädt und verarbeitet. Wenn Sie heruntergeladene Produkte filtern möchten, fügen Sie den Suchparameter productnamefilter der /products-API hinzu, die in der Edge Microgateway-Datei *.config.yaml aufgeführt ist. 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 Suchparameters muss im Format eines regulären Ausdrucks angegeben und URL-codiert sein. Beispiel: Der reguläre Ausdruck ^[Ee]dgemicro.*$ erfasst Namen wie „edgemicro-test-1“, „edgemicro_demo“ und „Edgemicro_New_Demo“. Der URL-codierte Wert, der für die Verwendung im Suchparameter 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 Tab „Entwickeln“ die JavaCallout-Richtlinie im Editor.
Fügen Sie ein benutzerdefiniertes Attribut mit dem Schlüssel products.filter.attributes und einer durch Kommas getrennten Liste von Attributnamen hinzu. Nur Produkte, die einen der benutzerdefinierten Attributnamen enthalten, werden an Edge Microgateway zurückgegeben.
Sie können die Prüfung, ob das Produkt für die aktuelle Umgebung aktiviert ist, optional deaktivieren, indem Sie das benutzerdefinierte Attribut products.filter.env.enable auf false setzen. (Der Standardwert ist „true“.)
(Nur Private Cloud) Wenn Sie Edge for Private Cloud verwenden, setzen Sie das Attribut org.noncps auf true, 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>

Produkte nach Widerrufsstatus filtern

API-Produkte haben drei Statuscodes: „Ausstehend“, „Genehmigt“ und „Widerrufen“. Der Richtlinie JWT-Variablen festlegen im Proxy edgemicro-auth wurde eine neue Property namens allowProductStatus hinzugefügt. So verwenden Sie dieses Attribut, um im JWT aufgeführte API-Produkte zu filtern:

Öffnen Sie den Proxy edgemicro-auth im Apigee-Proxy-Editor.

Fügen Sie das Attribut allowProductStatus zur XML der Richtlinie SetJWTVariables hinzu und geben Sie eine durch Kommas getrennte Liste von Statuscodes an, nach denen gefiltert werden soll. So filtern Sie beispielsweise nach dem Status Ausstehend und Widerrufen:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Javascript timeLimit="20000" async="false" continueOnError="false"
    enabled="true" name="Set-JWT-Variables">
    <DisplayName>Set JWT Variables</DisplayName>
    <FaultRules/>
    <Properties>
        <Property name="allowProductStatus">Pending,Revoked</Property>
    </Properties>
    <ResourceURL>jsc://set-jwt-variables.js</ResourceURL>
</Javascript>

Wenn Sie nur genehmigte Produkte auflisten möchten, legen Sie die Property so fest:

<Property name="allowProductStatus">Approved</Property>

Speichern Sie den Proxy.
Wenn das Tag Property nicht vorhanden ist, werden Produkte mit allen Statuscodes im JWT aufgeführt.

Wenn Sie dieses neue Attribut verwenden möchten, müssen Sie den Proxy edgemicro-auth aktualisieren.

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

HTTP-Proxy für die Kommunikation mit Apigee Edge verwenden

In Version 3.1.2 hinzugefügt.

So verwenden Sie einen HTTP-Proxy für die Kommunikation zwischen Edge Microgateway und Apigee Edge:

Legen Sie die Umgebungsvariablen HTTP_PROXY, HTTPS_PROXY und NO_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 verarbeiten sollen. Beispiel:
```
export HTTP_PROXY='http://localhost:3786'
export HTTPS_PROXY='https://localhost:3786'
export NO_PROXY='localhost,localhost:8080'
```
NO_PROXY kann eine durch Kommas getrennte Liste von Domains sein, an die Edge Microgateway nicht weiterleiten 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

In Version 3.1.2 hinzugefügt.

So verwenden Sie einen HTTP-Proxy für die Kommunikation zwischen Edge Microgateway und Backend-Zielen:

Fügen Sie der Microgateway-Konfigurationsdatei 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 „true“, verwendet Edge Microgateway die HTTP CONNECT-Methode, um HTTP-Anfragen über eine einzelne TCP-Verbindung zu tunneln. (Das Gleiche gilt, wenn die unten genannten Umgebungsvariablen zum Konfigurieren des Proxys TLS-fähig 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, wird der Wert proxy.url für den HTTP-Proxy verwendet. Wenn „true“ und proxy.url nicht festgelegt ist, verwenden Sie die Proxys, die in den HTTP-Proxy-Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY angegeben sind, 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
```
HINWEIS: Hinweis: Wenn edgemicro.proxy in der Konfigurationsdatei weggelassen wird oder wenn edgemicro.proxy.enabled „false“ ist, verwendet Edge Microgateway keinen HTTP-Proxy für die Zielkommunikation.
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-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

So verwendet Edge Microgateway JWTs

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.

Sie können ein JWT über die Befehlszeile generieren und es im Autorisierungsheader von API-Aufrufen anstelle eines API-Schlüssels 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 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 das JWT abläuft (nach dem token_expiry*-Intervall, standardmäßig 30 Minuten). So können Sie Schlüssel „rotieren“, ohne den API-Traffic sofort zu unterbrechen.

Schlüsselrotation durchführen

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

Verwenden Sie den Befehl edgemicro upgradekvm, um die KVM zu aktualisieren. Weitere Informationen zum Ausführen dieses Befehls finden Sie unter KVM aktualisieren. 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 edgemicro-auth-Proxy aktualisieren. Sie müssen diesen Schritt nur einmal ausführen.
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 -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. 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"
    }
  ]
}

„Nicht vor“-Verzögerung konfigurieren

Bei Versionen bis 3.1.5 wurde der neue private Schlüssel, der mit dem Befehl rotatekey generiert wurde, sofort wirksam und neue generierte Tokens wurden mit dem neuen privaten Schlüssel signiert. Der neue öffentliche Schlüssel wurde jedoch nur alle 10 Minuten (standardmäßig) für Edge Microgateway-Instanzen verfügbar gemacht, wenn die Microgateway-Konfiguration aktualisiert wurde. Aufgrund dieser Verzögerung zwischen der Tokensignierung und der Aktualisierung der Microgateway-Instanz werden mit dem neuesten Schlüssel signierte Tokens abgelehnt, bis alle Instanzen den neuesten öffentlichen Schlüssel erhalten haben.

Wenn mehrere Microgateway-Instanzen vorhanden sind, führte die Verzögerung des öffentlichen Schlüssels manchmal zu zeitweiligen Laufzeitfehlern mit dem Status 403, da die Tokenvalidierung auf einer Instanz erfolgreich war, auf einer anderen Instanz jedoch fehlschlug, bis alle Instanzen aktualisiert wurden.

Ab Version 3.1.6 können Sie mit einem neuen Flag im Befehl rotatekey eine Verzögerung für das Inkrafttreten des neuen privaten Schlüssels angeben. So bleibt Zeit, alle Microgateway-Instanzen zu aktualisieren und den neuen öffentlichen Schlüssel zu erhalten. Das neue Flag ist --nbf, was für „not before“ (nicht vor) steht. Dieses Flag akzeptiert einen ganzzahligen Wert, die Anzahl der Minuten, um die die Ausführung verzögert werden soll.

Im folgenden Beispiel ist die Verzögerung auf 15 Minuten festgelegt:

edgemicro rotatekey -o docs -e test \
-k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \
-s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47 \
--nbf 15

Es empfiehlt sich, die Verzögerung auf einen Wert festzulegen, der über der Konfigurationseinstellung config_change_poll_internal liegt. Diese beträgt standardmäßig 10 Minuten. Siehe auch edgemicro-Attribute.

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.

Ö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. 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.

Starten Sie Edge Microgateway im Debug-Modus neu. Fügen Sie dazu DEBUG=* am Anfang des start-Befehls hinzu:
```
DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
```
HINWEIS: Verwenden Sie unter Windows SET DEBUG=*

Mit dem folgenden Befehl können Sie die Debug-Ausgabe in eine Datei leiten:
```
export DEBUG=* nohup edgemicro start \
-o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log
```
Starten Sie den Debugger und legen Sie fest, dass er die Portnummer für den Debugging-Prozess überwacht.
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.

Upstream-Antwortcodes aktivieren

Standardmäßig gibt das oauth-Plug-in nur 4xx-Fehlerstatuscodes zurück, wenn die Antwort nicht den Statuscode „200“ hat. Sie können dieses Verhalten so ändern, dass je nach Fehler immer der genaue 4xx- oder 5xx-Code zurückgegeben wird.

Fügen Sie die Property oauth.useUpstreamResponse: true zur Edge Microgateway-Konfiguration hinzu, um diese Funktion 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 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: Anmeldedaten als Textparameter senden

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: Anmeldedaten in einem Basic Auth-Header senden

Senden Sie die Clientanmeldedaten als Basisauthentifizierungs-Header und den grant_type als Formularparameter. Diese Befehlsform wird auch in RFC 6749: The OAuth 2.0 Authorization Framework erläutert.

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. Beachten Sie, dass es keinen Unterschied zwischen den Attributen token und access_token gibt. Sie können beide verwenden. Beachten Sie, dass expires_in ein ganzzahliger Wert in Sekunden ist.

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

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.

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: Beachten Sie, dass expires_in-Werte Ganzzahlen 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 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

Entfernt: Dieses CLI-Feature wurde in Edge Microgateway Version 3.3.3 entfernt. Sie können forever-monitor durch PM2 ersetzen. Weitere Informationen finden Sie in diesem Apigee-Community-Beitrag: Edgemicro + PM2: Edgemicro als Dienst starten. Siehe auch Versionshinweise zu Edge Microgateway 3.3.3.

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:

Erstellen Sie eine Konfigurationsdatei mit dem folgenden Namen: $HOME/.edgemicro/$ORG-$ENV-config.yaml
Sie können beliebige Werte für $ORG und $ENV im Dateinamen verwenden. Die Kombination aus Organisation und Umgebung ist einfach eine Konvention, die es Edge Microgateway ermöglicht, die Datei beim Start zu finden.

Beispiel:
```
vi $HOME/.edgemicro/foo-bar-config.yaml
```
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
```
Die Konfigurationsdatei enthält ein spezielles, optionales Plug-in namens extauth. Dieses Plug-in prüft, ob ein gültiges JWT-Token an das Microgateway übergeben wurde. In einem späteren Schritt erfahren Sie, wie Sie das Token abrufen und verwenden. Beachten Sie auch, dass das spikearrest-Plug-in enthalten ist, da es nicht von der Verbindung mit Edge abhängt. Die Plug-ins quota, oauth und analytics sind ausgeschlossen, da sie eine Verbindung zu Edge benötigen und im getrennten Modus nicht funktionieren. Benutzerdefinierte Plug-ins sind zulässig und funktionieren wie erwartet.
Exportieren Sie die folgende Umgebungsvariable mit dem Wert „1“:
```
export EDGEMICRO_LOCAL=1
```
Führen Sie den folgenden start-Befehl aus und geben Sie Werte für die Instanziierung des lokalen Proxys an:
```
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 „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 /
```
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.

Das Einbinden des extauth-Plug-ins in Ihre Microgateway-Konfiguration ist optional. Wenn Sie es jedoch einbinden, müssen Sie für API-Aufrufe ein gültiges JWT-Token im Autorisierungsheader angeben.

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 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.
Wenn Sie Edge Microgateway in Apigee Cloud bereitgestellt haben, müssen Sie mit dem Internet verbunden sein, um ein JWT von diesem Endpunkt abzurufen.
Beenden Sie Edge Microgateway:
```
edgemicro stop
```
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'
```
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 /
```
Rufen Sie ein JWT-Token vom Autorisierungsendpunkt ab. Da Sie den Endpunkt edgemicro-auth/jwkPublicKeys verwenden, können Sie diesen CLI-Befehl verwenden:
Für diesen Schritt benötigen Sie eine Internetverbindung. Mit dem folgenden Befehl wird ein Token von Apigee Edge abgerufen. Für diesen Schritt benötigen Sie eine Apigee-Organisation, in der Sie eine standardmäßige Einrichtung und Konfiguration von Edge Microgateway durchgeführt haben. Nachdem Sie diesen Schritt ausgeführt haben, müssen Sie nicht mehr mit dem Internet verbunden sein. Das Token funktioniert im eigenständigen Modus, bis es abläuft.

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.

Weitere Informationen finden Sie unter Token generieren.

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.

Die beiden wichtigen Unterschiede zwischen dem lokalen Modus und der regulären Edge Microgateway-Konfiguration sind: (1) Im lokalen Modus müssen Sie keinen Microgateway-fähigen Proxy in Apigee Edge erstellen und (2) wenn Sie ein API-Produkt in Edge erstellen, müssen Sie ihm nur einen Proxy hinzufügen, den edgemicro-auth-Proxy. Sie müssen dem Produkt keine weiteren Proxys hinzufügen.

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:

Edgemicro als Sidecar

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:

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.
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.
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.
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.
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.
Exportieren Sie auf dem Computer, auf dem Edge Microgateway installiert ist, die folgende Umgebungsvariable mit dem Wert „1“.
```
export EDGEMICRO_LOCAL_PROXY=1
```
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":""
}

Synchronizer verwenden

In diesem Abschnitt wird erläutert, wie Sie den Synchronizer verwenden, ein optionales Feature, das die Ausfallsicherheit von Edge Microgateway verbessert, indem es Konfigurationsdaten von Apigee Edge abrufen und in eine lokale Redis-Datenbank schreiben kann. Wenn eine Synchronizer-Instanz 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 Synchronizer?

Der Synchronizer bietet ein gewisses Maß an Ausfallsicherheit für Edge Microgateway. So wird sichergestellt, dass jede Instanz von Edge Microgateway dieselbe Konfiguration verwendet und dass Edge Microgateway-Instanzen im Falle einer Internetstörung 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 wird, können Microgateway-Instanzen weiterhin funktionieren, da die neuesten Konfigurationsdaten im Cache gespeichert sind. Neue Microgateway-Instanzen können jedoch nicht ohne eine klare Verbindung gestartet werden. Darüber hinaus kann eine Internetstörung dazu führen, dass eine oder mehrere Microgateway-Instanzen mit Konfigurationsinformationen ausgeführt werden, die nicht mit anderen Instanzen synchronisiert sind.

Der Edge Microgateway-Synchronizer bietet einen alternativen Mechanismus für Edge Microgateway-Instanzen, um Konfigurationsdaten abzurufen, die sie zum Starten und Verarbeiten von API-Proxy-Traffic benötigen. Die Konfigurationsdaten, die aus Aufrufen von Apigee Edge abgerufen werden, umfassen den Aufruf jwk_public_keys, den Aufruf jwt_public_key, den Bootstrap-Aufruf und den Aufruf von API-Produkten. Der Synchronizer ermöglicht es, dass alle Edge Microgateway-Instanzen, die auf verschiedenen Knoten ausgeführt werden, ordnungsgemäß gestartet und synchronisiert werden, auch wenn die Internetverbindung zwischen Edge Microgateway und Apigee Edge unterbrochen ist.

Der Synchronizer ist eine speziell konfigurierte Instanz von Edge Microgateway. Der einzige Zweck besteht darin, Apigee Edge abzufragen (das Timing ist konfigurierbar), Konfigurationsdaten abzurufen und in eine lokale Redis-Datenbank zu schreiben. Die Synchronizer-Instanz selbst kann keinen API-Proxy-Traffic verarbeiten. Andere Instanzen von Edge Microgateway, die auf anderen Knoten ausgeführt werden, können so konfiguriert werden, dass sie Konfigurationsdaten aus der Redis-Datenbank und nicht aus Apigee Edge abrufen. Da alle Microgateway-Instanzen ihre Konfigurationsdaten aus der lokalen Datenbank abrufen, können sie auch bei einer Internetstörung gestartet werden und API-Anfragen verarbeiten.

Synchronizer-Instanz konfigurieren

Fügen Sie der Datei org-env/config.yaml für die Edge Microgateway-Installation, die Sie als Synchronizer verwenden möchten, die folgende Konfiguration hinzu:

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

Option	Beschreibung
`redisHost`	Der Host, auf dem Ihre Redis-Instanz ausgeführt wird. Standard: 127.0.0.1
`redisPort`	Der Port der Redis-Instanz. Standard: 6379
`redisDb`	Die zu verwendende Redis-Datenbank. Standardwert: 0
`redisPassword`	Ihr Datenbankpasswort.

Sie können die Umgebungsvariable EDGEMICRO_REDIS_PASSWORD verwenden, um den Parameter edgemicro.redisPassword zu überschreiben. Siehe auch Konfigurationsattribute mit Umgebungsvariablenwerten festlegen.

Speichern Sie schließlich die Konfigurationsdatei und starten Sie die Edge Microgateway-Instanz. Es beginnt mit dem Abfragen von Apigee Edge und dem Speichern heruntergeladener Konfigurationsdaten in der Redis-Datenbank.

Reguläre Edge Microgateway-Instanzen konfigurieren

Wenn der Synchronizer ausgeführt wird, können Sie zusätzliche Edge Microgateway-Knoten konfigurieren, um reguläre Microgateway-Instanzen auszuführen, die API-Proxy-Traffic verarbeiten. Sie konfigurieren diese Instanzen jedoch so, dass sie ihre Konfigurationsdaten aus der Redis-Datenbank und nicht aus Apigee Edge abrufen.

Fügen Sie der Datei org-env/config.yaml jedes zusätzlichen Edge Microgateway-Knotens die folgende Konfiguration hinzu. Beachten Sie, dass das Attribut synchronizerMode auf 0 gesetzt ist. Mit diesem Attribut wird die Instanz so konfiguriert, dass sie als normale Edge Microgateway-Instanz fungiert, die API-Proxy-Traffic verarbeitet. Die Instanz bezieht ihre Konfigurationsdaten aus 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 Konfigurationsattribute wurden hinzugefügt, um die Verwendung des Synchronizers zu unterstützen:

Attribut Werte Beschreibung

Attribut	Werte	Beschreibung
`edge_config.synchronizerMode`	0 oder 1	Wenn der Wert 0 (Standard) ist, wird Edge Microgateway im Standardmodus ausgeführt. Wenn der Wert „1“ ist, starten Sie die Edge Microgateway-Instanz, damit sie als Synchronizer fungiert. In diesem Modus ruft die Instanz Konfigurationsdaten von Apigee Edge ab und speichert sie in einer lokalen Redis-Datenbank. Diese Instanz kann keine API-Proxy-Anfragen verarbeiten. Ihr einziger Zweck besteht darin, Apigee Edge nach Konfigurationsdaten abzufragen und diese in die lokale Datenbank zu schreiben. Anschließend müssen Sie andere Microgateway-Instanzen so konfigurieren, dass sie aus der Datenbank lesen.
`edge_config.redisBasedConfigCache`	"true" oder "false"	Wenn „true“, ruft die Edge Microgateway-Instanz ihre Konfigurationsdaten aus der Redis-Datenbank anstelle von Apigee Edge ab. Die Redis-Datenbank muss dieselbe sein, in die der Synchronizer schreiben soll. Wenn die Redis-Datenbank nicht verfügbar oder leer ist, sucht das Microgateway nach einer vorhandenen `cache-config.yaml`-Datei für die Konfiguration. Wenn „false“ (Standardeinstellung) festgelegt ist, ruft die Edge Microgateway-Instanz Konfigurationsdaten wie gewohnt von Apigee Edge ab.
`edgemicro.config_change_poll_interval`	Zeitintervall in Sekunden	Gibt das Abfrageintervall für den Synchronizer an, um Daten aus Apigee Edge abzurufen.

edge_config.synchronizerMode

0 oder 1

Wenn der Wert 0 (Standard) ist, wird Edge Microgateway im Standardmodus ausgeführt.

Wenn der Wert „1“ ist, starten Sie die Edge Microgateway-Instanz, damit sie als Synchronizer fungiert. In diesem Modus ruft die Instanz Konfigurationsdaten von Apigee Edge ab und speichert sie in einer lokalen Redis-Datenbank. Diese Instanz kann keine API-Proxy-Anfragen verarbeiten. Ihr einziger Zweck besteht darin, Apigee Edge nach Konfigurationsdaten abzufragen und diese in die lokale Datenbank zu schreiben. Anschließend müssen Sie andere Microgateway-Instanzen so konfigurieren, dass sie aus der Datenbank lesen.

edge_config.redisBasedConfigCache

"true" oder "false"

Wenn „true“, ruft die Edge Microgateway-Instanz ihre Konfigurationsdaten aus der Redis-Datenbank anstelle von Apigee Edge ab. Die Redis-Datenbank muss dieselbe sein, in die der Synchronizer schreiben soll. Wenn die Redis-Datenbank nicht verfügbar oder leer ist, sucht das Microgateway nach einer vorhandenen cache-config.yaml-Datei für die Konfiguration.

Wenn „false“ (Standardeinstellung) festgelegt ist, ruft die Edge Microgateway-Instanz Konfigurationsdaten wie gewohnt von Apigee Edge ab.

edgemicro.config_change_poll_interval Zeitintervall in Sekunden Gibt das Abfrageintervall für den Synchronizer an, um Daten aus Apigee Edge abzurufen.

Ausschluss-URLs für Plug-ins konfigurieren

Sie können das Microgateway so konfigurieren, dass die Verarbeitung von Plug-ins für bestimmte URLs übersprungen wird. Sie können diese „Ausschluss-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 für APIs mit /hello/xml im Pfad übersprungen.

Das Plug-in analytics kann nicht ausgeschlossen werden.

Konfigurationsattribute mit Umgebungsvariablenwerten festlegen

Sie können Umgebungsvariablen mithilfe von Tags in der Konfigurationsdatei angeben. Die angegebenen Umgebungsvariablen-Tags werden durch die tatsächlichen Umgebungsvariablenwerte ersetzt. Ersetzungen werden nur im Arbeitsspeicher und nicht in den ursprünglichen Konfigurations- oder Cache-Dateien gespeichert.

Hinweis: Standardmäßig werden Variablenwerte im Tag <E> als Strings geparst. Verwenden Sie die inneren Tags <n> und <b>, um positive Ganzzahl- und boolesche Werte anzugeben, wie in den Beispielen unten gezeigt.

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 Ganzzahlwert 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 (d. h. „true“ oder „false“) anzugeben.

quotas:
  useRedis: <E><b>EMG_USE_REDIS</b></E>