Diese Seite wurde von der Cloud Translation API übersetzt.

Vorgangs- und Konfigurationsreferenz für Edge Microgateway

Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info

Edge Microgateway Version 3.3.x

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

Edge Microgateway aktualisieren, wenn Sie eine Internetverbindung haben

In diesem Abschnitt wird beschrieben, wie Sie eine vorhandene Installation von Edge Microgateway aktualisieren. Wenn Sie ohne Internetverbindung arbeiten, lesen Sie den Hilfeartikel Kann ich das Edge-Mikrogateway ohne Internetverbindung installieren?.

Apigee empfiehlt, Ihre vorhandene Konfiguration mit der neuen Version zu testen, bevor Sie Ihre Produktionsumgebung aktualisieren.

Führen Sie den folgenden npm-Befehl aus, um ein Upgrade auf die neueste Version von Edge Microgateway durchzuführen:
```
npm upgrade edgemicro -g
```
Wenn Sie eine bestimmte Version von Edge Microgateway installieren möchten, müssen Sie die Versionsnummer im Installationsbefehl 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, gehen Sie so vor:
```
edgemicro --version
current nodejs version is v12.5.0
current edgemicro version is 3.2.3
    
```
Führen Sie abschließend ein Upgrade auf die neueste Version des edgemicro-auth-Proxy durch:
```
edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME
```

Konfigurationsänderungen vornehmen

Die wichtigsten Konfigurationsdateien sind:

Standardsystemkonfigurationsdatei
Standardkonfigurationsdatei für eine neu initialisierte Edge Microgateway-Instanz
Dynamische Konfigurationsdatei für laufende Instanzen

In diesem Abschnitt werden diese Dateien und die wichtigsten Informationen zu ihrer Änderung beschrieben.

Standardsystemkonfigurationsdatei

Wenn Sie Edge Microgateway installieren, wird hier eine Standardsystemkonfigurationsdatei abgelegt:

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

Dabei ist prefix das Verzeichnis mit dem Präfix npm. Wenn Sie dieses Verzeichnis nicht finden können, lesen Sie den Hilfeartikel Wo ist Edge Microgateway installiert?.

Wenn Sie die Systemkonfigurationsdatei ändern, müssen Sie das 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 das 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 diesem Muster benannt: org-env-config.yaml, wobei org und env die Namen Ihrer Apigee Edge-Organisation und ‑Umgebung sind. Sie können mit dieser Datei Konfigurationsänderungen vornehmen und sie dann ohne Ausfallzeit neu laden. Wenn Sie beispielsweise ein Plug-in hinzufügen und konfigurieren, können Sie die Konfiguration wie unten beschrieben neu laden, ohne dass es zu Ausfallzeiten kommt.

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 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 angehalten ist:

Starten Sie das Edge Microgateway neu:
```
edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
```
Wobei:
- $ORG ist der Name Ihrer Edge-Organisation. Sie müssen 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 ist eine Beispielkonfigurationsdatei. Weitere Informationen zu den Einstellungen in der Konfigurationsdatei finden Sie in der Referenz zur Edge Microgateway-Konfiguration.

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, für die Werte für Ihre Edge-Organisation und ‑Umgebung erforderlich sind, sowie der Schlüssel und das Geheimnis, die zum Starten des Edge-Microgateways erforderlich sind, können in den folgenden 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 das Edge-Mikrogateway über die Befehlszeile konfigurieren und starten.

SSL auf dem Edge Microgateway-Server konfigurieren

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

Video	Beschreibung
Einseitiges Northbound-TLS konfigurieren	Informationen zum Konfigurieren von TLS im Apigee Edge Microgateway In diesem Video erhalten Sie einen Überblick über TLS und seine Bedeutung, werden mit TLS im Edge-Microgateway vertraut gemacht und sehen, wie Sie One-Way-TLS für ausgehende Verbindungen konfigurieren.
Zwei-Wege-Northbound-TLS konfigurieren	Dies ist das zweite Video zur Konfiguration von TLS im Apigee Edge Microgateway. In diesem Video wird erläutert, wie Sie TLS für den bidirektionalen Traffic in Richtung Norden konfigurieren.
Ein- und Zweiwege-TLS-Verbindungen nach Süden konfigurieren	In diesem dritten Video zur Konfiguration von TLS im Apigee Edge Microgateway wird erläutert, wie Sie unidirektionale und bidirektionale TLS-Verbindungen konfigurieren.

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

https://localhost:8000/myapi

So konfigurieren Sie SSL auf dem Microgateway-Server:

Generieren oder fordern Sie ein SSL-Zertifikat und einen Schlüssel mit dem Dienstprogramm openssl oder einer anderen Methode an.

Fügen Sie das Attribut edgemicro:ssl der 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

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 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 mit der Passphrase für den privaten Schlüssel oder die PFX-Datei.
`ca`	Pfad zu einer Datei mit einer Liste vertrauenswürdiger Zertifikate im PEM-Format.
`ciphers`	Ein String, der die zu verwendenden Chiffren beschreibt, getrennt durch ein „:“.
`rejectUnauthorized`	Wenn „wahr“ festgelegt ist, wird das Serverzertifikat mit der Liste der angegebenen Zertifizierungsstellen verglichen. 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`	„wahr“ für 2-Wege-SSL; „falsch“ für 1-Wege-SSL

SSL/TLS-Optionen für Clients verwenden

Sie können das Edge Microgateway als TLS- oder SSL-Client konfigurieren, 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 für mehrere Ziele.

In diesem Beispiel werden Einstellungen für alle Hosts verwendet:

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. Geben Sie dann bestimmte Hosts in beliebiger Reihenfolge an. 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 mit dem privaten Schlüssel, dem Zertifikat und den CA-Zertifikaten des Clients im PFX-Format.
`key`	Pfad zu einer `ca.key`-Datei (im PEM-Format).
`passphrase`	Ein String mit der Passphrase für den privaten Schlüssel oder die PFX-Datei.
`cert`	Pfad zu einer `ca.cert`-Datei (im PEM-Format).
`ca`	Pfad zu einer Datei mit einer Liste vertrauenswürdiger Zertifikate im PEM-Format.
`ciphers`	Ein String, der die zu verwendenden Chiffren beschreibt, getrennt durch ein „:“.
`rejectUnauthorized`	Wenn „wahr“ festgelegt ist, wird das Serverzertifikat mit der Liste der angegebenen Zertifizierungsstellen verglichen. Wenn die Überprüfung fehlschlägt, wird ein Fehler zurückgegeben.
`secureProtocol`	Die zu verwendende SSL-Methode. Beispiel: SSLv3_method, um SSL auf Version 3 zu erzwingen.
`servername`	Der Servername für die TLS-Erweiterung SNI (Server Name Indication).

Edgemicro-Auth-Proxy anpassen

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

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. Möglicherweise haben Sie beispielsweise einen Dienst, der die Identität mit LDAP überprüft.

Wichtig:Wenn Sie den Standardauthentifizierungsproxy überschreiben, muss der neue Proxy oder Dienst ein Antwortformat zurückgeben, das mit dem des Standardedgemicro-auth-Proxys identisch ist.

Logdateien verwalten

Edge Microgateway protokolliert Informationen zu jeder Anfrage und Antwort. Logdateien enthalten hilfreiche Informationen zur Fehlerbehebung.

Speicherort von Protokolldateien

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

Standardverzeichnis für Protokolldateien ändern

Das Verzeichnis, in dem Protokolldateien 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 Protokolldateien anzugeben.

Protokolle an die Console senden

Sie können das Logging so konfigurieren, dass Protokollinformationen an die Standardausgabe und nicht an eine Protokolldatei gesendet werden. Legen Sie das Flag to_console so auf „true“ fest:

edgemicro:
  logging:
    to_console: true

Bei dieser Einstellung werden Protokolle an Standard Out gesendet. Derzeit können Sie Protokolle nicht sowohl an stdout als auch an eine Protokolldatei senden.

Protokollierungsebene festlegen

Sie geben die zu verwendende Protokollebene in der edgemicro-Konfiguration an. Eine vollständige Liste der Protokollebenen und ihrer Beschreibungen finden Sie unter edgemicro-Attribute.

In der folgenden Konfiguration wird beispielsweise die Logging-Ebene 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

Protokollintervalle ändern

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

Die konfigurierbaren Attribute sind:

stats_log_interval: (Standard: 60) Intervall in Sekunden, nach dem der Statistikeintrag in die API-Protokolldatei geschrieben wird.
rotate_interval: (Standard: 24) Intervall in Stunden, nach 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 Berechtigungen für Protokolldateien lockern

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

In Version 3.2.3 hinzugefügt.

Beispiel:

edgemicro:
 logging:
   disableStrictLogFile: true

Best Practices für die Protokolldateiverwaltung

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

Da Protokolldateien recht groß werden können, muss im Verzeichnis für Protokolldateien ausreichend Speicherplatz vorhanden sein. Weitere Informationen finden Sie in den folgenden Abschnitten: Speicherort von Protokolldateien und Standardverzeichnis für Protokolldateien ändern.
Löschen oder verschieben Sie Protokolldateien mindestens einmal pro Woche in ein separates Archivverzeichnis.
Wenn Sie Logs gemäß Ihrer Richtlinie löschen möchten, können Sie mit dem Befehl edgemicro log -c ältere Logs entfernen (bereinigen).

Namenskonvention für Protokolldateien

Jede Edge Microgateway-Instanz generiert eine Protokolldatei mit der Erweiterung .log. Die Namenskonvention für Logdateien lautet:

edgemicro-HOST_NAME-INSTANCE_ID-api.log

Beispiel:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log

Inhalt von Protokolldateien

In Version 2.3.3 hinzugefügt

Standardmäßig lässt der Logging-Dienst die JSON-Dateien der heruntergeladenen Proxys, Produkte und das JSON Web Token (JWT) aus. Wenn Sie diese Objekte in der Konsole ausgeben möchten, legen Sie das Befehlszeilenflag DEBUG=* fest, wenn Sie das Edge-Microgateway starten. Beispiel:

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

Unter Windows: SET DEBUG=*

Inhalt der Logdatei „api“

Die Logdatei „api“ enthält detaillierte Informationen zum Fluss von Anfragen und Antworten über das Edge Microgateway. Die „api“-Logdateien haben folgende Namen:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

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

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

Jeder dieser separaten Einträge wird in einer Kurzschreibweise dargestellt, um die Logdateien kompakter zu gestalten. Hier sind vier Beispieleinträge für die vier Ereignisse. In der Protokolldatei sehen sie so aus (die Zeilennummern dienen nur der Referenz im Dokument, sie 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 diese im Einzelnen 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 Logging-Ebene. Dieser Wert hängt vom Kontext der Transaktion und der in der edgemicro-Konfiguration festgelegten Protokollierungsebene ab. Weitere Informationen finden Sie unter Protokollierungsebene festlegen. Für Statistikdatensätze ist die Ebene auf stats festgelegt. Statistikeinträge werden in regelmäßigen Abständen erfasst, die in der stats_log_interval-Konfiguration festgelegt sind. Weitere Informationen finden Sie unter Protokollintervalle ändern.
req: Identifiziert das Ereignis. In diesem Fall vom Kunden anfordern.
m: Das in der Anfrage verwendete HTTP-Verb.
u: Der Teil der URL nach dem Basispfad.
h: Der Host und die Portnummer, auf die das Edge Microgateway wartet.
r: Der Remote-Host und der Port, von dem die Clientanfrage stammt.
i: Die Anfrage-ID. Alle vier Ereigniseinträge teilen sich diese ID. Jede Anfrage erhält eine eindeutige Anfrage-ID. Wenn Sie Protokolleinträge nach Anfrage-ID abgleichen, können Sie wertvolle Informationen zur Latenz des Ziels erhalten.
d: Die Dauer in Millisekunden, seit die Anfrage vom Edge Microgateway empfangen wurde. Im obigen Beispiel wurde die Antwort des Ziels für Anfrage 0 nach 7 Millisekunden (Zeile 3) empfangen und nach weiteren 4 Millisekunden (Zeile 4) an den Client gesendet. Mit anderen Worten: Die Gesamtlatenz der Anfrage betrug 11 Millisekunden, von denen 7 Millisekunden auf das Ziel und 4 Millisekunden auf das Edge-Mikrogateway selbst entfallen.

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 Logging-Ebene. Dieser Wert hängt vom Kontext der Transaktion und der in der edgemicro-Konfiguration festgelegten Protokollierungsebene ab. Weitere Informationen finden Sie unter Protokollierungsebene festlegen. Für Statistikdatensätze ist die Ebene auf stats festgelegt. Statistikeinträge werden in regelmäßigen Abständen erfasst, die in der stats_log_interval-Konfiguration festgelegt sind. Weitere Informationen finden Sie unter Protokollintervalle ändern.
treq: Identifiziert das Ereignis. In diesem Fall „Zielanfrage“.
m: Das in der Zielanfrage verwendete HTTP-Verb.
u: Der Teil der URL nach dem Basispfad.
h: Host und Portnummer des Backend-Ziels.
i: Die ID des Protokolleintrags. Alle vier Ereigniseinträge teilen sich 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 Logging-Ebene. Dieser Wert hängt vom Kontext der Transaktion und der in der edgemicro-Konfiguration festgelegten Protokollierungsebene ab. Weitere Informationen finden Sie unter Protokollierungsebene festlegen. Für Statistikdatensätze ist die Ebene auf stats festgelegt. Statistikeinträge werden in regelmäßigen Abständen erfasst, die in der stats_log_interval-Konfiguration festgelegt sind. Weitere Informationen finden Sie unter Protokollintervalle ändern.
tres: Identifiziert das Ereignis. In diesem Fall „Ziel-Antwort“.
s: Der HTTP-Antwortstatus.
d: Dauer in Millisekunden. Die Zeit, die für den API-Aufruf vom Ziel benötigt wird.
i: Die ID des Protokolleintrags. Alle vier Ereigniseinträge teilen sich 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 Logging-Ebene. Dieser Wert hängt vom Kontext der Transaktion und der in der edgemicro-Konfiguration festgelegten Protokollierungsebene ab. Weitere Informationen finden Sie unter Protokollierungsebene festlegen. Für Statistikdatensätze ist die Ebene auf stats festgelegt. Statistikeinträge werden in regelmäßigen Abständen erfasst, die in der stats_log_interval-Konfiguration festgelegt sind. Weitere Informationen finden Sie unter Protokollintervalle ändern.
res: Identifiziert das Ereignis. In diesem Fall antworten Sie dem Kunden.
s: Der HTTP-Antwortstatus.
d: Dauer in Millisekunden. Dies ist die Gesamtzeit, die für den API-Aufruf benötigt wird, einschließlich der Zeit, die von der Ziel-API und dem Edge Microgateway selbst beansprucht wird.
i: Die ID des Protokolleintrags. Alle vier Ereigniseinträge teilen sich diese ID.

Zeitplan für Protokolldateien

Protokolldateien werden im Intervall rotiert, das durch das Konfigurationsattribut rotate_interval angegeben ist. Der selben Protokolldatei werden weiterhin Einträge hinzugefügt, bis das Rotationsintervall abläuft. Jedes Mal, wenn das Edge Microgateway neu gestartet wird, erhält es jedoch eine neue UID und erstellt eine neue Reihe von Protokolldateien mit dieser UID. Siehe auch Best Practices für die Wartung von Protokolldateien.

Fehlermeldungen

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

Edge Microgateway-Konfigurationsreferenz

Speicherort der Konfigurationsdatei

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

edge_config-Attribute

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

bootstrap: (Standard: keine) 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: keine) Eine URL, die auf den Edge Microgateway-Proxy verweist, der in Apigee Edge bereitgestellt wird. Dieser Proxy dient als Authentifizierungsendpunkt für die Ausstellung signierter Zugriffstokens für Clients. Diese URL wird zurückgegeben, wenn Sie den Befehl zum Bereitstellen des Proxys ausführen: edgemicro configure. Weitere Informationen finden Sie unter Edge Microgateway einrichten und konfigurieren.
quotaUri: Legen Sie diese Konfigurationseigenschaft fest, wenn Sie Kontingente über den edgemicro-auth-Proxy verwalten möchten, der in Ihrer Organisation bereitgestellt wird. Wenn diese Eigenschaft nicht festgelegt ist, wird als Kontingentendpunkt standardmäßig der interne Edge Microgateway-Endpunkt verwendet.
```
edge_config:
  quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
```

edgemicro-Attribute

Mit diesen Einstellungen wird der Edge Microgateway-Prozess konfiguriert.

port: (Standard: 8000) Die Portnummer, auf der der Edge Microgateway-Prozess überwacht wird.
max_connections: (Standard: -1) Gibt die maximale Anzahl gleichzeitiger eingehender Verbindungen an, die das Edge-Microgateway empfangen kann. Wird diese Anzahl überschritten, wird der folgende Status zurückgegeben:

res.statusCode = 429; // Too many requests
max_connections_hard: (Standard: -1) Die maximale Anzahl gleichzeitiger Anfragen, die das Edge-Mikrogateway empfangen kann, bevor die Verbindung geschlossen wird. Diese Einstellung soll Denial-of-Service-Angriffe verhindern. Legen Sie in der Regel einen Wert fest, der größer als „max_connections“ ist.
Logging:
- level: (Standard: error)
  - info – (empfohlen) Hier werden alle Anfragen und Antworten protokolliert, die über eine Edge Microgateway-Instanz geleitet werden.
  - warn: Es werden nur Warnmeldungen protokolliert.
  - error: Es werden nur Fehlermeldungen protokolliert.
  - debug: Hiermit werden Debug-Nachrichten sowie Informations-, Warn- und Fehlermeldungen protokolliert.
  - trace: Protokolliert Informationen zu Fehlern sowie Informations-, Warn- und Fehlermeldungen.
  - none: Es wird keine Protokolldatei erstellt.
- dir: (Standard: /var/tmp) Das Verzeichnis, in dem Protokolldateien gespeichert werden.
- stats_log_interval: (Standard: 60) Intervall in Sekunden, nach dem der Statistikeintrag in die API-Protokolldatei geschrieben wird.
- rotate_interval: (Standard: 24) Intervall in Stunden, nach dem Logdateien rotiert werden.

Plug-ins: Mit Plug-ins können Sie Edge Microgateway um zusätzliche Funktionen erweitern. Weitere Informationen zum Entwickeln von Plug-ins finden Sie unter Benutzerdefinierte Plug-ins entwickeln.

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

debug : Fügt dem Edge Microgateway-Prozess Remote-Debugging hinzu.
- port: Die Portnummer, die überwacht werden soll. Legen Sie beispielsweise den Debugger Ihrer IDE so fest, dass er auf diesem Port wartet.
- args: Argumente für den Debug-Prozess. Beispiel: args --nolazy
config_change_poll_interval: (Standard:600 Sekunden): Das Edge-Microgateway lädt regelmäßig eine neue Konfiguration herunter und führt einen Neustart aus, wenn sich etwas geändert hat. Bei der Abfrage werden alle Änderungen an Edge (Änderungen an Produkten, Microgateway-kompatible Proxys usw.) sowie Änderungen an der lokalen Konfigurationsdatei berücksichtigt.
disable_config_poll_interval (Standardeinstellung: „false“): Legen Sie diese Einstellung auf true fest, um die automatische Abfrage von Änderungen deaktivieren zu lassen.
request_timeout: Hiermit wird eine Zeitüberschreitung für Zielanfragen festgelegt. Das Zeitlimit wird in Sekunden festgelegt. Wenn ein Zeitlimit auftritt, antwortet das Edge Microgateway mit dem Statuscode 504. (Version 2.4.x hinzugefügt)
keep_alive_timeout: Mit dieser Eigenschaft können Sie das Zeitlimit für das Edge Microgateway in Millisekunden festlegen. (Standard: 5 Sekunden) (in Version 3.0.6 hinzugefügt)
headers_timeout: Mit diesem Attribut wird die Zeit (in Millisekunden) begrenzt, die der HTTP-Parser wartet, bis er die vollständigen HTTP-Header empfängt.
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 länger 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 Abgleichsregel nicht aufgelöst wird (keine Übereinstimmung). Gültige Werte: ALLOW oder DENY. Standardwert: ALLOW (Hinzugefügt in Version 3.1.7)
enableAnalytics (Standardeinstellung: „true“): Legen Sie das Attribut auf false fest, um das Laden des Analytics-Plug-ins zu verhindern. In diesem Fall werden keine Aufrufe an Apigee Edge-Analysen ausgeführt. 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, das 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 zum Funktionieren benötigt. 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 geschlossen wird.

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

Beispiel:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

Header-Attribute

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

x-forwarded-for: (Standard: „wahr“) Legen Sie diesen Wert auf „falsch“ fest, um zu verhindern, dass X-Forwarded-For-Header an das Ziel übergeben werden. Wenn die Anfrage einen X-Forwarded-For-Header enthält, wird sein Wert in Edge Analytics auf den Client-IP-Wert festgelegt.
x-forwarded-host: (Standard: „wahr“) Legen Sie „false“ fest, um zu verhindern, dass X-Forwarded-Host-Header an das Ziel übergeben werden.
x-request-id: (Standard: „wahr“) Legen Sie „falsch“ fest, um zu verhindern, dass x-request-id-Header an das Ziel übergeben werden.
x-response-time: (Standard: „wahr“) Legen Sie „falsch“ fest, um zu verhindern, dass x-response-time-Header an das Ziel übergeben werden.
via: (Standard: „wahr“) Legen Sie „falsch“ fest, um zu verhindern, dass „via“-Header an das Ziel übergeben werden.

OAuth-Attribute

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

allowNoAuthorization: (Standard: „false“) Wenn diese Option auf „true“ gesetzt ist, dürfen API-Aufrufe das Edge Microgateway ohne Autorisierungsheader passieren. Legen Sie diesen Wert auf „false“ fest, um einen Autorisierungsheader zu erzwingen (Standard).
allowInvalidAuthorization: (Standard: „false“) Wenn diese Option auf „true“ gesetzt ist, dürfen API-Aufrufe auch dann weitergeleitet werden, wenn das im Autorisierungsheader übergebene Token ungültig oder abgelaufen ist. Legen Sie diesen Wert auf „false“ fest, um gültige Tokens zu verlangen (Standard).
authorization-header: (Standard: Authorization: Bearer) Der Header, über den das Zugriffstoken an Edge Microgateway gesendet wird. Sie können den Standard ändern, wenn der Autorisierungsheader für das Ziel zu einem anderen Zweck verwendet werden muss.
api-key-header: (Standard: x-api-key) Der Name des Headers oder Abfrageparameters, mit dem ein API-Schlüssel an Edge Microgateway übergeben wird. Weitere Informationen finden Sie unter API-Schlüssel verwenden.
keep-authorization-header: (Standard: „false“) Wenn dieser Parameter auf „true“ gesetzt ist, wird der Autorisierungsheader, der in der Anfrage gesendet wurde, an das Ziel weitergeleitet (er wird beibehalten).
allowOAuthOnly: Wenn diese Option auf „wahr“ gesetzt ist, muss jede API einen Autorisierungsheader mit einem Bearer-Zugriffstoken enthalten. Sie können nur das OAuth-Sicherheitsmodell zulassen und gleichzeitig die Abwärtskompatibilität beibehalten. (2.4.x hinzugefügt)
allowAPIKeyOnly: Wenn diese Option auf „wahr“ gesetzt ist, muss jede API einen x-api-key-Header (oder einen benutzerdefinierten Speicherort) mit einem API-Schlüssel enthalten.Sie können dann nur das API-Schlüssel-Sicherheitsmodell zulassen und gleichzeitig die Abwärtskompatibilität beibehalten. (2.4.x hinzugefügt)
Legen Sie weder allowOAuthOnly noch allowAPIKeyOnly auf „wahr“ fest. Standardmäßig sind beide Flags auf „false“ gesetzt (für Abwärtskompatibilität).
gracePeriod: Mit diesem Parameter lassen sich Fehler vermeiden, die durch geringfügige Abweichungen zwischen Ihrer 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. (2.5.7 hinzugefügt)

Plug-in-spezifische Attribute

Weitere Informationen zu den konfigurierbaren Attributen der einzelnen Plug-ins finden Sie im Hilfeartikel „Plug-ins verwenden“.

Proxys filtern

Sie können filtern, welche Microgateway-kompatiblen Proxys von einer Edge Microgateway-Instanz verarbeitet werden. Beim Starten von Edge Microgateway werden alle Microgateway-kompatiblen Proxys in der zugehörigen Organisation heruntergeladen. Mit der folgenden Konfiguration können Sie einschränken, welche Proxys vom Microgateway verarbeitet werden. Mit dieser Konfiguration werden beispielsweise die Proxys, die vom Microgateway verarbeitet werden, auf drei beschränkt: 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

Mit der folgenden Konfiguration können Sie die Anzahl der API-Produkte begrenzen, die das Edge Microgateway herunterlädt und verarbeitet. Wenn du heruntergeladene Produkte filtern möchtest, füge der /products API, die in der *.config.yaml-Datei des Edge-Microgateways aufgeführt ist, den Abfrageparameter productnamefilter hinzu. Beispiel:

edge_config:
  bootstrap: >-
    https://edgemicroservices.apigee.net/edgemicro/bootstrap/organization/willwitman/environment/test
  jwt_public_key: 'https://myorg-test.apigee.net/edgemicro-auth/publicKey'
  managementUri: 'https://api.enterprise.apigee.com'
  vaultName: microgateway
  authUri: 'https://%s-%s.apigee.net/edgemicro-auth'
  baseUri: >-
    https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s
  bootstrapMessage: Please copy the following property to the edge micro agent config
  keySecretMessage: The following credentials are required to start edge micro
  products: 'https://myorg-test.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24'

Der Wert des Abfrageparameters muss im regulären Ausdrucksformat angegeben und URL-codiert sein. Mit dem regulären Ausdruck ^[Ee]dgemicro.*$ werden beispielsweise Namen wie „edgemicro-test-1“, „edgemicro_demo“ und „Edgemicro_New_Demo“ erfasst. Der URL-codierte Wert, der für die Verwendung im Abfrageparameter geeignet ist, lautet %5E%5BEe%5Ddgemicro.%2A%24.

Die folgende Debug-Ausgabe zeigt, dass nur die gefilterten Produkte heruntergeladen wurden:

...
2020-05-27T03:13:50.087Z [76060] [microgateway-config network] products download from https://gsc-demo-prod.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24 returned 200 OK
...
....
....
{
   "apiProduct":[
      {
         "apiResources":[

         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1590549037549,
         "createdBy":"k***@g********m",
         "displayName":"test upper case in name",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1590549037549,
         "lastModifiedBy":"k***@g********m",
         "name":"Edgemicro_New_Demo",
         "proxies":[
            "catchall"
         ],
         "quota":"null",
         "quotaInterval":"null",
         "quotaTimeUnit":"null",
         "scopes":[

         ]
      },
      {
         "apiResources":[

         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1590548328998,
         "createdBy":"k***@g********m",
         "displayName":"edgemicro test 1",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1590548328998,
         "lastModifiedBy":"k***@g********m",
         "name":"edgemicro-test-1",
         "proxies":[
            "Lets-Encrypt-Validation-DoNotDelete"
         ],
         "quota":"null",
         "quotaInterval":"null",
         "quotaTimeUnit":"null",
         "scopes":[

         ]
      },
      {
         "apiResources":[
            "/",
            "/**"
         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1558182193472,
         "createdBy":"m*********@g********m",
         "displayName":"Edge microgateway demo product",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1569077897465,
         "lastModifiedBy":"m*********@g********m",
         "name":"edgemicro_demo",
         "proxies":[
            "edgemicro-auth",
            "edgemicro_hello"
         ],
         "quota":"600",
         "quotaInterval":"1",
         "quotaTimeUnit":"minute",
         "scopes":[

         ]
      }
   ]
}

Produkte nach benutzerdefinierten Attributen filtern

So filtern Sie Produkte anhand von benutzerdefinierten Attributen:

Wählen Sie in der Edge-Benutzeroberfläche den Proxy edgemicro_auth in der Organisation/Umgebung aus, in der Sie Edge Microgateway konfiguriert haben.
Öffnen Sie auf dem 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 Namen der benutzerdefinierten Attribute enthalten, werden an das Edge Microgateway zurückgegeben.
Sie können die Prüfung optional deaktivieren, um zu sehen, ob das Produkt für die aktuelle Umgebung aktiviert ist. Dazu setzen Sie das benutzerdefinierte Attribut products.filter.env.enable auf false. Der Standardwert ist „true“.
(Nur Private Cloud) Wenn Sie Edge für Private Cloud verwenden, legen Sie für die Property org.noncps auf true fest, um Produkte für Umgebungen abzurufen, die keine CPS-Umgebungen sind.

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 zum Festlegen von JWT-Variablen im Proxy edgemicro-auth wurde das neue Attribut allowProductStatus hinzugefügt. So filtern Sie mit dieser Eigenschaft API-Produkte, die im JWT aufgeführt sind:

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

Fügen Sie der XML-Datei der Richtlinie SetJWTVariables die Eigenschaft allowProductStatus hinzu und geben Sie eine kommagetrennte Liste der 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 nur genehmigte Produkte aufgeführt werden sollen, legen Sie die Property so fest:

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

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

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

Push-Häufigkeit für Analytics konfigurieren

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

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

Beispiel:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Analysedaten maskieren

Mit der folgenden Konfiguration wird verhindert, dass Informationen zum Anfragepfad in Edge-Analysen angezeigt werden. Fügen Sie der Microgateway-Konfiguration Folgendes hinzu, um den Anfrage-URI und/oder den Anfragepfad zu maskieren. Der URI besteht aus dem Hostnamen und 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 so getrennt wird, dass er in den Edge Analytics-Dashboards als separater Proxy angezeigt wird. Sie können beispielsweise eine Systemdiagnose-API im Dashboard trennen, um Verwechslungen mit tatsächlichen API-Proxy-Aufrufen zu vermeiden. Im Analytics-Dashboard folgen getrennte Proxys diesem Benennungsmuster:

edgemicro_proxyname-health

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

Mit diesen Parametern können Sie relative und absolute Pfade im Analytics-Dashboard als separate Proxys voneinander 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. Hinweis: Bei diesem Flag wird der Basispfad des Proxys ignoriert. Wenn Sie eine Segmentierung nach einem vollständigen Pfad, einschließlich des Basispfads, vornehmen möchten, verwenden Sie das Flag proxyPath.
proxyPath (optional): Gibt einen vollständigen API-Proxy-Pfad an, einschließlich des Proxy-Basispfads, der im Analysedashboard getrennt werden soll. Wenn Sie beispielsweise /mocktarget/healthcheck angeben, wobei /mocktarget der Basispfad des Proxys ist, werden alle API-Aufrufe mit dem Pfad /mocktarget/healthcheck im Dashboard als edgemicro_proxyname-health angezeigt.

In der folgenden Konfiguration wird beispielsweise jeder API-Pfad, der /healthcheck enthält, vom Analyse-Plug-in getrennt. Das bedeutet, dass /foo/healthcheck und /foo/bar/healthcheck im Analysedashboard als separater Proxy namens edgemicro_proxyname-health 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 Proxypfad /mocktarget/healthcheck im Analysedashboard als separater Proxy namens edgemicro_proxyname-health behandelt.

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

Edge Microgateway hinter einer Unternehmens-Firewall 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. Mit diesen Variablen steuern Sie die Hosts für jeden HTTP-Proxy, den Sie für die Kommunikation mit Apigee Edge verwenden möchten, oder die Hosts, die 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'
```
Hinweis: NO_PROXY kann eine durch Kommas getrennte Liste von Domains sein, für die das Edge Microgateway keinen Proxy verwenden 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 dem Edge-Microgateway und den 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 diese Option aktiviert ist, verwendet das Edge-Microgateway die HTTP-CONNECT-Methode, um HTTP-Anfragen über eine einzelne TCP-Verbindung zu tunneln. Das gilt auch, wenn die Umgebungsvariablen, die unten zur Konfiguration des Proxys erwähnt werden, TLS-fähig sind. Standard: false
- url: Die HTTP-Proxy-URL.
- bypass: (Optional) Gibt eine oder mehrere durch Kommas getrennte Zielhost-URLs an, die den HTTP-Proxy umgehen sollen. Wenn diese Eigenschaft 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 in den HTTP-Proxy-Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY angegebenen Proxys, wie unter HTTP-Proxy für die Kommunikation mit Apigee Edge verwenden beschrieben.
Beispiel:
```
edgemicro:
  proxy:
    tunnel: true
    url: 'http://localhost:3786'
    bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
    enabled: true
```
HINWEIS : Wenn edgemicro.proxy aus der Konfigurationsdatei fehlt oder edgemicro.proxy.enabled auf „false“ gesetzt ist, verwendet das Edge-Microgateway keinen HTTP-Proxy für die Zielkommunikation.
Starten Sie Edge Microgateway neu.

Platzhalter in Microgateway-kompatiblen Proxys verwenden

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

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

JWT-Schlüssel rotieren

Verwendung von JWTs in Edge Microgateway

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

Sie können ein JWT mit der Befehlszeile generieren und anstelle eines API-Schlüssels im Autorisierungsheader von API-Aufrufen verwenden. Beispiel:

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

Informationen zum Generieren von JWTs mit der Befehlszeile finden Sie unter Token generieren.

Was ist die Schlüsselrotation?

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

Zum Generieren eines JWT verwendet Edge Informationen, die in der verschlüsselten KVM gespeichert sind. Beim ersten Einrichten (Konfigurieren) des Edge Microgateways 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.

Zu den KVM-Schlüsseln gehören:

private_key: Der neueste (zuletzt erstellte) RSA-private Schlüssel, der zum Signieren von JWTs verwendet wird.
public_key: Das neueste (kürzlich erstellte) Zertifikat, das zum Verifizieren von JWTs verwendet wird, die mit dem privaten Schlüssel signiert wurden.
private_key_kid: Die ID des neuesten (kürzlich 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 (kürzlich erstellten) öffentlichen Schlüssels. Dieser Schlüssel ist mit dem Wert „public_key1“ verknüpft und wird für die Schlüsselrotation verwendet. Dieser Wert entspricht dem KID des privaten Schlüssels.
public_key1: Der neueste (kürzlichste 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 für die Schlüsselrotation verwendet.
public_key2: Der alte öffentliche Schlüssel.

JWTs, die zur Überprüfung vorgelegt werden, werden mit dem neuen öffentlichen Schlüssel verifiziert. Wenn die Überprüfung fehlschlägt, wird der alte öffentliche Schlüssel verwendet, bis das JWT abläuft (nach dem Intervall „token_expiry*“, standardmäßig 30 Minuten). So können Sie Schlüssel „rotieren“, ohne den API-Traffic sofort zu unterbrechen.

Schlüsselrotation

In diesem Abschnitt wird erläutert, wie eine Schlüsselrotation durchgeführt wird.

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. Dabei müssen Sie dieselbe Organisation und Umgebung angeben, für die Sie 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 das Edge Microgateway zurück. Beachten Sie im folgenden Beispiel, dass jeder Schlüssel einen eindeutigen „kid“-Wert (Schlüssel-ID) hat. Das Microgateway verwendet diese Schlüssel dann, um Autorisierungstokens zu validieren. Wenn die Tokenbestätigung fehlschlägt, sucht das Microgateway nach einem älteren Schlüssel im Schlüsselsatz und versucht, diesen zu verwenden. Das Format der zurückgegebenen Schlüssel ist JSON Web Key (JWK). Weitere Informationen zu diesem Format finden Sie in RFC 7517.

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

Verzögerung vom Typ „nicht vor“ konfigurieren

Bei Versionen 3.1.5 und niedriger trat der mit dem Befehl rotatekey generierte neue private Schlüssel sofort in Kraft und neue generierte Tokens wurden mit dem neuen privaten Schlüssel signiert. Der neue öffentliche Schlüssel wurde jedoch standardmäßig nur alle 10 Minuten für Edge-Microgateway-Instanzen verfügbar gemacht, wenn die Microgateway-Konfiguration aktualisiert wurde. Aufgrund dieser Verzögerung zwischen der Tokensignatur 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 beim öffentlichen Schlüssel manchmal zu sporadischen Laufzeitfehlern mit dem Status 403, da die Tokenbestätigung in einer Instanz bestanden, in einer anderen jedoch fehlgeschlagen ist, bis alle Instanzen aktualisiert wurden.

Ab Version 3.1.6 können Sie mit einem neuen Flag beim Befehl rotatekey eine Verzögerung für die Wirksamkeit des neuen privaten Schlüssels angeben. So haben alle Microgateway-Instanzen Zeit, aktualisiert zu werden und den neuen öffentlichen Schlüssel zu empfangen. Das neue Flag ist --nbf, was für „nicht vor“ steht. Dieses Flag nimmt einen Ganzzahlwert an, die Anzahl der Minuten, um die die Auslieferung 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 länger als die config_change_poll_internal-Konfigurationseinstellung zu wählen, die standardmäßig 10 Minuten beträgt. Siehe auch Edgemicro-Attribute.

Heruntergeladene Proxys filtern

Standardmäßig lädt Edge Microgateway alle Proxys in Ihrer Edge-Organisation herunter, deren Name mit dem Präfix „edgemicro_“ beginnt. Sie können diese Standardeinstellung ändern, um Proxys herunterzuladen, deren Namen einem bestimmten 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. Das ist nützlich für die Fehlerbehebung bei benutzerdefinierten Plug-ins.

Starten Sie das Edge Microgateway im Debug-Modus neu. Fügen Sie dazu DEBUG=* an den Anfang des start-Befehls ein:
```
DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
```
HINWEIS : Unter Windows verwenden Sie SET DEBUG=*.

Mit diesem Befehl können Sie die Debugausgabe an eine Datei weiterleiten:
```
export DEBUG=* nohup edgemicro start \
-o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log
```
Starten Sie den Debugger und legen Sie fest, dass er für den Debug-Prozess die Portnummer überwachen soll.
Sie können jetzt den Edge Microgateway-Code durchgehen, Haltepunkte festlegen, Ausdrucke beobachten usw.

Sie können standardmäßige 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 Protokolldateien 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-Schlüssels (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 Bearer-Tokens ausgetauscht, die im Cache gespeichert werden. Sie können das Caching deaktivieren, indem Sie den Cache-Control: no-cache-Header für eingehende Anfragen an Edge Microgateway festlegen.

API-Schlüssel verwenden

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

Beispiel für einen Abfrageparameter:

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

Beispiel für Anzeigentitel:

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

Namen des API-Schlüssels konfigurieren

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

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

In diesem Beispiel werden sowohl der Abfrageparameter als auch der Headername in apiKey geändert. Der Name x-api-key funktioniert in beiden Fällen nicht mehr. Weitere Informationen finden Sie unter 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 Status 200 hat. Sie können dieses Verhalten so ändern, dass je nach Fehler immer der genaue 4xx- oder 5xx-Code zurückgegeben wird.

Wenn Sie diese Funktion aktivieren möchten, fügen Sie der Edge Microgateway-Konfiguration die Eigenschaft oauth.useUpstreamResponse: true hinzu. Beispiel:

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  gracePeriod: 10
  useUpstreamResponse: true

OAuth2-Tokensicherheit verwenden

In diesem Abschnitt wird erläutert, wie du OAuth2-Zugriffs- und Aktualisierungstokens abrufen kannst. Mit Zugriffstokens werden sichere API-Aufrufe über das Microgateway ausgeführt. Mit Aktualisierungstokens werden neue Zugriffstoken abgerufen.

Zugriffstoken abrufen

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

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

API 1: Anmeldedaten als Body-Parameter senden

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

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

API 2: Anmeldedaten in einem Basic Auth-Header senden

Senden Sie die Clientanmeldedaten als Basis-Authentifizierungsheader und grant_type als Formularparameter. Diese Befehlsform wird auch in RFC 6749: The OAuth 2.0 Authorization Framework (OAuth 2.0-Autorisierungs-Framework) beschrieben.

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. Die Eigenschaften token und access_token unterscheiden sich nicht. Sie können beide verwenden. Hinweis: expires_in ist ein Ganzzahlwert, der in Sekunden angegeben wird.

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

Aktualisierungstoken abrufen

Rufe zum Abrufen eines Aktualisierungstokens den /token-Endpunkt des edgemicro-auth-Proxys über eine API auf. Dieser API-Aufruf MUSS mit dem Typ password erfolgen. Die folgenden Schritte führen Sie durch den Prozess.

Rufe mit der /token API ein Zugriffs- und Aktualisierungstoken ab. Der Grant-Typ ist password:

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 Zugriffs- und ein Aktualisierungstoken zurück. Die Antwort sieht in etwa so aus: Die Werte für expires_in sind Ganzzahlen und werden in Sekunden angegeben.

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

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

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

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

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

Dauerhaftes Monitoring

Entfernt: Diese Befehlszeilenfunktion wurde in Edge Microgateway Version 3.3.3 entfernt. Sie können forever-monitor durch PM2 ersetzen. Weitere Informationen finden Sie in diesem Beitrag der Apigee-Community: Edgemicro + PM2: edgemicro als Dienst starten. Weitere Informationen finden Sie in den Versionshinweisen für Edge Microgateway 3.3.3.

Endpunkt einer Konfigurationsdatei angeben

Wenn Sie mehrere Edge Microgateway-Instanzen ausführen, können Sie ihre Konfigurationen an einem zentralen Ort verwalten. Dazu geben Sie einen HTTP-Endpunkt an, von dem Edge Micro seine 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 unter ~/.edgemicro und folgt der 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 festlegen, wird dieses Verhalten deaktiviert. Die Daten werden dann jedes Mal sofort gesendet, wenn socket.write() aufgerufen wird. Weitere Informationen finden Sie auch 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 ohne Apigee Edge-Abhängigkeiten ausführen. In diesem Szenario, dem sogenannten Standalone-Modus, können Sie das Edge-Microgateway ohne Internetverbindung ausführen und testen.

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

OAuth und API-Schlüssel
Kontingent
Analytics

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

Gateway konfigurieren und starten

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

Erstellen Sie eine Konfigurationsdatei mit dem Namen $HOME/.edgemicro/$ORG-$ENV-config.yaml.
Sie können beliebige Werte für $ORG und $ENV im Dateinamen verwenden. Die Kombination „org/env“ ist einfach eine Konvention, mit der das Edge Microgateway die Datei beim Starten finden kann.

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 überprüft ein gültiges JWT-Token, das an das Microgateway übergeben wird. In einem späteren Schritt erfahren Sie, wie Sie das Token abrufen und verwenden. Das Plug-in spikearrest ist ebenfalls enthalten, da es keine Verbindung zum Edge erfordert. Die Plug-ins quota, oauth und analytics sind ausgeschlossen, da sie eine Verbindung mit Edge erfordern und im Modus ohne Verbindung 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 „org“-Name, 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 zu erstellenden lokalen Proxys. 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, wird der Fehler „missing_authorization“ ausgegeben. Dieses Plug-in validiert ein JWT, das im Autorisierungsheader des API-Aufrufs vorhanden sein muss. Im nächsten Abschnitt erhalten Sie ein JWT, mit dem API-Aufrufe ohne Fehler ausgeführt werden können.

Beispiel: Autorisierungstoken abrufen

Das folgende Beispiel zeigt, wie Sie ein JWT vom JWT-Endpunkt des Edge Microgateways auf Apigee Edge (edgemicro-auth/jwkPublicKeys) abrufen. Dieser Endpunkt wird bereitgestellt, wenn Sie eine standardmäßige Einrichtung und Konfiguration des Edge Microgateways ausführen. Wenn Sie das JWT vom Apigee-Endpunkt abrufen möchten, müssen Sie zuerst die Standardeinrichtung des Edge-Microgateways vornehmen 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 mit der für diesen Endpunkt bereitgestellten API abrufen.

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

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

Sie müssen eine standardmäßige Einrichtung und Konfiguration von Edge Microgateway ausführen, um den edgemicro-auth-Proxy in Ihrer Organisation/Umgebung in Apigee Edge bereitzustellen. Wenn Sie diesen Schritt bereits ausgeführt haben, müssen Sie ihn nicht wiederholen.
Wenn Sie das Edge Microgateway in Apigee Cloud bereitgestellt haben, müssen Sie mit dem Internet verbunden sein, damit Sie ein JWT von diesem Endpunkt abrufen können.
So beenden Sie Edge Microgateway:
```
edgemicro stop
```
Weisen Sie in der zuvor erstellten Konfigurationsdatei ($HOME/.edgemicro/org-env-config.yaml) dem extauth:publickey_url-Attribut den edgemicro-auth/jwkPublicKeys-Endpunkt in Ihrer Apigee Edge-Organisation/-Umgebung zu. Beispiel:
```
extauth:
  publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
```
Starten Sie Edge Microgateway wie zuvor mit den Namen für Organisation und 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 /
```
Rufe ein JWT-Token vom Autorisierungsendpunkt ab. Da Sie den edgemicro-auth/jwkPublicKeys-Endpunkt verwenden, können Sie diesen Befehlszeilenbefehl 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 Standardeinrichtung und -konfiguration von Edge Microgateway durchgeführt haben. Danach ist keine Internetverbindung mehr erforderlich. Das Token funktioniert weiterhin im Standalone-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 einer Entwickler-App angegeben, die ein Produkt mit dem Proxy edgemicro-auth enthält.
Mit der Option s wird das Consumer Secret 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 auf, um die Konfiguration zu testen:

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

Beispiel:

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

Beispielausgabe:

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

Lokalen Proxy-Modus verwenden

Im lokalen Proxy-Modus ist für Edge Microgateway kein Microgateway-kompatibler Proxy erforderlich, der auf Apigee Edge bereitgestellt wird. Stattdessen konfigurieren Sie einen „lokalen Proxy“, indem Sie beim Starten des Microgateways einen lokalen Proxynamen, einen Basispfad und eine Ziel-URL angeben. API-Aufrufe an das Microgateway werden dann an die Ziel-URL des lokalen Proxys gesendet. In allen anderen Aspekten funktioniert der lokale Proxy-Modus genau wie das Ausführen des Edge Microgateways im Normalmodus. Die Authentifizierung funktioniert genauso wie die Unterbrechung von Spitzen und die 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 auf Apigee Edge erstellen. (2) Wenn Sie ein API-Produkt auf 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 Proxy-Modus ist nützlich, wenn Sie nur einen 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 Companion-Dienst verwaltet. Die folgende Abbildung veranschaulicht diese Architektur, in der Edge Microgateway als Sidecar-Proxy in einem Kubernetes-Cluster dient. Jede Microgateway-Instanz kommuniziert nur mit einem einzelnen Endpunkt des zugehörigen Dienstes:

Edgemicro als Sidecar

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

Lokalen Proxy-Modus konfigurieren

So konfigurieren Sie das Edge Microgateway für den lokalen Proxy-Modus:

Führen Sie edgemicro init aus, um Ihre lokale Konfigurationsumgebung einzurichten, genau wie bei einer typischen Edge Microgateway-Einrichtung. Weitere Informationen finden Sie unter Edge Microgateway konfigurieren.
Führen Sie edgemicro configure aus, wie Sie es bei einer typischen Edge Microgateway-Einrichtung tun würden. Beispiel:
```
edgemicro configure -o your_org -e your_env -u your_apigee_username
```
Mit diesem Befehl wird die Richtlinie edgemicro-auth auf Edge bereitgestellt und ein Schlüssel und ein Secret zurückgegeben, die zum Starten des Microgateways erforderlich sind. 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, dem Produkt diesen Pfad hinzuzufügen: /**. Weitere Informationen finden Sie unter Verhalten des Ressourcenpfads konfigurieren. Weitere Informationen finden Sie in der Edge-Dokumentation unter API-Produkte erstellen.
Erstellen Sie in Apigee Edge einen Entwickler oder verwenden Sie einen vorhandenen Entwickler. Weitere Informationen finden Sie unter Entwickler über die Edge-Verwaltungsoberfläche hinzufügen.
Erstellen Sie in Apigee Edge eine Entwickler-App. Sie müssen der App das gerade erstellte API-Produkt hinzufügen. Weitere Informationen finden Sie unter App in der Edge-Verwaltungs-UI registrieren.
Exportieren Sie auf dem Computer, auf dem das 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 zurückgegeben wurde, als Sie edgemicro configure ausgeführt haben.
- your_secret ist das Secret, das zurückgegeben wurde, als Sie edgemicro configure ausgeführt haben.
- local_proxy_name ist der Name des zu erstellenden lokalen Proxys.
- local_proxy_version ist die Versionsnummer des Proxys.
- target_url ist die URL für das Ziel des Proxys (den Dienst, den der Proxy aufruft).
- base_path ist der Basispfad des Proxys. Dieser Wert muss mit einem Schrägstrich beginnen. Geben Sie für einen Stammpfad nur einen Schrägstrich an, z. B. „/“.
Beispiel:
```
edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
  -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
  -t http://mocktarget.apigee.net -b /echo
```

Konfiguration testen

Sie können die lokale Proxykonfiguration testen, indem Sie den Proxyendpunkt aufrufen. Wenn Sie beispielsweise /echo als Basispfad 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, da Sie keinen gültigen API-Schlüssel angegeben haben. Sie finden den Schlüssel in der zuvor erstellten Entwickler-App. Öffne die App in der Edge-Benutzeroberfläche, kopiere den Consumer Key und verwende ihn so:

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

Beispiel:

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

Beispielausgabe:

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

Synchronisierer verwenden

In diesem Abschnitt wird die Verwendung des Synchronizers beschrieben. Diese optionale Funktion verbessert die Resilienz von Edge Microgateway, da damit Konfigurationsdaten aus Apigee Edge abgerufen und in eine lokale Redis-Datenbank geschrieben werden können. Wenn eine Synchronisierer-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 mit Redis 5.0.x unterstützt.

Was ist der Synchronisierer?

Der Synchronisierer bietet eine gewisse Ausfallsicherheit für Edge Microgateway. So wird sichergestellt, dass jede Instanz von Edge Microgateway dieselbe Konfiguration verwendet und dass Edge Microgateway-Instanzen bei einer Internetunterbrechung gestartet und ordnungsgemäß 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 weiter funktionieren, da die neuesten Konfigurationsdaten im Cache gespeichert sind. Neue Microgateway-Instanzen können jedoch nicht ohne eine eindeutige Verbindung gestartet werden. Außerdem kann eine Internetunterbrechung dazu führen, dass eine oder mehrere Microgateway-Instanzen mit Konfigurationsinformationen ausgeführt werden, die nicht mit anderen Instanzen synchronisiert sind.

Der Edge Microgateway-Synchronisierer bietet einen alternativen Mechanismus für Edge Microgateway-Instanzen zum Abrufen von Konfigurationsdaten, die zum Starten und Verarbeiten von API-Proxy-Traffic erforderlich sind. Zu den Konfigurationsdaten, die über Aufrufe von Apigee Edge abgerufen werden, gehören der jwk_public_keys-Aufruf, der jwt_public_key-Aufruf, der Bootstrap-Aufruf und der API-Produktaufruf. Mit dem Synchronisierer können alle Edge Microgateway-Instanzen, die auf verschiedenen Knoten ausgeführt werden, ordnungsgemäß gestartet werden und bleiben auch dann synchronisiert, wenn die Internetverbindung zwischen Edge Microgateway und Apigee Edge unterbrochen wird.

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

Synchronisierer-Instanz konfigurieren

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

edgemicro:
  redisHost: host_IP
  redisPort: host_port
  redisDb: database_index
  redisPassword: password
edge_config:
  synchronizerMode: 1
  redisBasedConfigCache: true

Beispiel:

edgemicro:
  redisHost: 192.168.4.77
  redisPort: 6379
  redisDb: 0
  redisPassword: codemaster
edge_config:
  synchronizerMode: 1
  redisBasedConfigCache: true

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`	Das Datenbankpasswort.

Mit der Umgebungsvariablen EDGEMICRO_REDIS_PASSWORD können Sie den Parameter edgemicro.redisPassword überschreiben. Weitere Informationen finden Sie unter Konfigurationsattribute mit Umgebungsvariablenwerten festlegen.

Speichern Sie abschließend die Konfigurationsdatei und starten Sie die Edge Microgateway-Instanz. Es beginnt, Apigee Edge abzufragen und heruntergeladene Konfigurationsdaten in der Redis-Datenbank zu speichern.

Regelmäßige Edge Microgateway-Instanzen konfigurieren

Wenn der Synchronisierer 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 org-env/config.yaml-Datei jedes zusätzlichen Edge Microgateway-Knotens die folgende Konfiguration hinzu. Beachten Sie, dass das Attribut synchronizerMode auf 0 festgelegt ist. Mit dieser Eigenschaft wird die Instanz so konfiguriert, dass sie als normale Edge Microgateway-Instanz ausgeführt wird, die API-Proxy-Traffic verarbeitet. Die Instanz ruft ihre Konfigurationsdaten aus der Redis-Datenbank ab.

edgemicro:
  redisHost: host_IP
  redisPort: host_port
  redisDb: database_index
  redisPassword: password
edge_config:
  synchronizerMode: 0
  redisBasedConfigCache: true

Beispiel:

edgemicro:
  redisHost: 192.168.4.77
  redisPort: 6379
  redisDb: 0
  redisPassword: codemaster
edge_config:
  synchronizerMode: 0
  redisBasedConfigCache: true

Konfigurationsattribute

Die folgenden Konfigurationseigenschaften wurden hinzugefügt, um die Verwendung des Synchronizers zu unterstützen:

Attribut Werte Beschreibung

Attribut	Werte	Beschreibung
`edge_config.synchronizerMode`	0 oder 1	Wenn „0“ (Standard) festgelegt ist, arbeitet das Edge Microgateway im Standardmodus. Wenn „1“, starten Sie die Edge Microgateway-Instanz, damit sie als Synchronisierer verwendet werden kann. In diesem Modus ruft die Instanz Konfigurationsdaten aus Apigee Edge ab und speichert sie in einer lokalen Redis-Datenbank. Diese Instanz kann keine API-Proxy-Anfragen verarbeiten. Ihr einziger Zweck besteht darin, Apigee Edge nach Konfigurationsdaten abzufragen und sie in die lokale Datenbank zu schreiben. Sie müssen dann andere Microgateway-Instanzen so konfigurieren, dass sie aus der Datenbank lesen.
`edge_config.redisBasedConfigCache`	"true" oder "false"	Wenn „true“ festgelegt ist, ruft die Edge Microgateway-Instanz ihre Konfigurationsdaten aus der Redis-Datenbank statt aus Apigee Edge ab. Die Redis-Datenbank muss mit der Datenbank übereinstimmen, in die der Synchronisierer zum Schreiben konfiguriert ist. Wenn die Redis-Datenbank nicht verfügbar oder leer ist, sucht das Microgateway für die Konfiguration nach einer vorhandenen `cache-config.yaml`-Datei. Wenn „false“ (Standardeinstellung) festgelegt ist, ruft die Edge Microgateway-Instanz wie gewohnt Konfigurationsdaten aus Apigee Edge ab.
`edgemicro.config_change_poll_interval`	Zeitintervall in Sekunden	Gibt das Abfrageintervall für den Synchronizer an, mit dem Daten aus Apigee Edge abgerufen werden.

edge_config.synchronizerMode

0 oder 1

Wenn „0“ (Standard) festgelegt ist, arbeitet das Edge Microgateway im Standardmodus.

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

edge_config.redisBasedConfigCache

"true" oder "false"

Wenn „true“ festgelegt ist, ruft die Edge Microgateway-Instanz ihre Konfigurationsdaten aus der Redis-Datenbank statt aus Apigee Edge ab. Die Redis-Datenbank muss mit der Datenbank übereinstimmen, in die der Synchronisierer zum Schreiben konfiguriert ist. Wenn die Redis-Datenbank nicht verfügbar oder leer ist, sucht das Microgateway für die Konfiguration nach einer vorhandenen cache-config.yaml-Datei.

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

edgemicro.config_change_poll_interval Zeitintervall in Sekunden Gibt das Abfrageintervall für den Synchronizer an, mit dem Daten aus Apigee Edge abgerufen werden.

Auszuschließende URLs für Plug-ins konfigurieren

Sie können das Microgateway so konfigurieren, dass die Verarbeitung von Plugins für bestimmte URLs übersprungen wird. Sie können diese auszuschließenden URLs global (für alle Plugins) oder für bestimmte Plugins 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 werden eingehende API-Proxyaufrufe mit den Pfaden /hello oder /proxy_one nicht von Plugins verarbeitet. Außerdem wird das json2xml-Plug-in für APIs mit /hello/xml im Pfad übersprungen.

Das analytics-Plug-in 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 Werte der Umgebungsvariablen ersetzt. Ersatzvideos werden nur im Arbeitsspeicher und nicht in den ursprünglichen Konfigurations- oder Cachedateien gespeichert.

Hinweis : Standardmäßig werden Variablenwerte vom <E>-Tag als Strings geparst. Verwenden Sie die inneren <n>- und <b>-Tags, um positive Ganzzahlen und boolesche Werte anzugeben, wie in den folgenden Beispielen 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 <b>-Tag verwendet, um einen booleschen Wert (d. h. „wahr“ oder „falsch“) anzugeben.

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