Diese Seite wurde von der Cloud Translation API übersetzt.

Vorgangs- und Konfigurationsreferenz für Edge Microgateway

Sie sehen die Apigee Edge-Dokumentation.
Rufen Sie die Apigee X-Dokumentation auf. weitere Informationen

Edge Microgateway Version 3.3.x

In diesem Thema wird beschrieben, wie Edge Microgateway verwaltet und konfiguriert wird.

Edge Microgateway aktualisieren, wenn Sie eine Internetverbindung haben

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

Apigee empfiehlt, dass Sie Ihre vorhandene Konfiguration mit der neuen Version testen, bevor Sie ein Upgrade der Produktionsumgebung ausführen.

Führen Sie den folgenden npm-Befehl aus, um ein Upgrade auf die neueste Version von Edge Microgateway durchzuführen:
```
npm upgrade edgemicro -g
```
Wenn Sie eine bestimmte Version von Edge Microgateway installieren möchten, müssen Sie im Installationsbefehl die Versionsnummer angeben. Verwenden Sie beispielsweise den folgenden Befehl für die Installation in Version 3.2.3:
```
npm install edgemicro@3.2.3 -g
```

Prüfen Sie die Versionsnummer. Wenn Sie beispielsweise Version 3.2.3 installiert haben:

edgemicro --version
current nodejs version is v12.5.0
current edgemicro version is 3.2.3

Führen Sie schließlich ein Upgrade auf die neueste Version des edgemicro-auth-Proxys aus:
```
edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME
```

Konfigurationsänderungen vornehmen

Die Konfigurationsdateien, die Sie kennen müssen, sind:

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

In diesem Abschnitt werden diese Dateien und was Sie über das Ändern von Änderungen wissen müssen.

Standardsystemkonfigurationsdatei

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

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

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

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

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

Standardkonfigurationsdatei für neu initialisierte Edge Microgateway-Instanzen

Wenn Sie edgemicro init ausführen, wird die Systemkonfigurationsdatei (oben beschrieben), default.yaml, im Verzeichnis ~/.edgemicro gespeichert.

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

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

Dynamische Konfigurationsdatei für ausgeführte Instanzen

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

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

Laden Sie die Edge Microgateway-Konfiguration neu:
```
edgemicro reload -o $ORG -e $ENV -k $KEY -s $SECRET
```
Wobei:
- $ORG ist der Name Ihrer Edge-Organisation (Sie müssen ein Organisationsadministrator sein).
- $ENV ist eine Umgebung in Ihrer Organisation (z. B. „test“ oder „prod“).
- $KEY ist der Schlüssel, der zuvor vom Konfigurationsbefehl zurückgegeben wurde.
- $SECRET ist der Schlüssel, der zuvor vom Konfigurationsbefehl zurückgegeben wurde.
Beispiel:
```
edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \
  -s 05c14356e42ed1...4e34ab0cc824
```

Wenn Edge Microgateway beendet ist:

Starten Sie Edge Microgateway neu:
```
edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
```
Wobei:
- $ORG ist der Name Ihrer Edge-Organisation (Sie müssen ein Organisationsadministrator sein).
- $ENV ist eine Umgebung in Ihrer Organisation (z. B. „test“ oder „prod“).
- $KEY ist der Schlüssel, der zuvor vom Konfigurationsbefehl zurückgegeben wurde.
- $SECRET ist der Schlüssel, der zuvor vom Konfigurationsbefehl zurückgegeben wurde.
Beispiel:
```
edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \
  -s 05c1435...e34ab0cc824
```

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

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

Umgebungsvariablen festlegen

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

EDGEMICRO_ORG
EDGEMICRO_ENV
EDGEMICRO_KEY
EDGEMICRO_SECRET

Das Festlegen dieser Variablen ist optional. Wenn Sie sie festlegen, müssen Sie ihre Werte nicht angeben, wenn Sie Edge Microgateway über die Befehlszeile konfigurieren und starten.

SSL auf dem Edge Microgateway-Server konfigurieren

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

Video	Beschreibung
1-Wege-TLS mit nördlicher Richtung konfigurieren	Informationen zum Konfigurieren von TLS in Apigee Edge Microgateway. In diesem Video erhalten Sie einen Überblick über TLS und seine Bedeutung. Außerdem wird TLS in Edge Microgateway vorgestellt und es wird gezeigt, wie One-Way-TLS zum Norden konfiguriert wird.
2-Wege-TLS zum Norden konfigurieren	Dies ist das zweite Video zum Konfigurieren von TLS in Apigee Edge Microgateway. In diesem Video wird erläutert, wie Sie 2-Wege-TLS für Norden in Richtung konfigurieren.
1-Wege- und 2-Wege-TLS-Verbindung nach Süden konfigurieren	In diesem dritten Video zum Konfigurieren von TLS in Apigee Edge Microgateway wird die Konfiguration von 1-Wege- und 2-Wege-TLS nach Süden erläutert.

Sie können den Microgateway-Server für die Verwendung von SSL konfigurieren. Wenn SSL konfiguriert ist, können Sie beispielsweise APIs über Edge Microgateway mit dem Protokoll „https“ wie folgt aufrufen:

https://localhost:8000/myapi

So konfigurieren Sie SSL auf dem Microgateway-Server:

Generieren oder rufen Sie ein SSL-Zertifikat und einen SSL-Schlüssel mit dem Dienstprogramm openssl oder einer anderen Methode ab.
Fügen Sie der Konfigurationsdatei für Edge Microgateway das Attribut edgemicro:ssl hinzu. Eine vollständige Liste der Optionen finden Sie in der Tabelle unten. Beispiel:
```
edgemicro:
  ssl:
   key: <absolute path to the SSL key file>
   cert: <absolute path to the SSL cert file>
   passphrase: admin123 #option added in v2.2.2
   rejectUnauthorized: true #option added in v2.2.2
   requestCert: true
```
Der in der referenzierten SSL-Schlüsseldatei angegebene Schlüssel darf nicht verschlüsselt sein.
Starten Sie Edge Microgateway neu. Folgen Sie den unter Konfigurationsänderungen vornehmen beschriebenen Schritten, je nachdem, welche Konfigurationsdatei Sie bearbeitet haben: Standarddatei oder Laufzeitkonfigurationsdatei.

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

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

Folgende Serveroptionen werden unterstützt:

Option	Beschreibung
`key`	Pfad zu einer `ca.key`-Datei im PEM-Format.
`cert`	Pfad zu einer `ca.cert`-Datei im PEM-Format.
`pfx`	Pfad zu einer `pfx`-Datei, die den privaten Schlüssel, das Zertifikat und die CA-Zertifikate des Clients im PFX-Format enthält.
`passphrase`	Ein String, der die Passphrase für den privaten Schlüssel oder PFX enthält.
`ca`	Pfad zu einer Datei mit einer Liste vertrauenswürdiger Zertifikate im PEM-Format.
`ciphers`	Ein String, der die zu verwendenden Chiffren beschreibt, getrennt durch ein ":".
`rejectUnauthorized`	Bei „true“ wird das Serverzertifikat anhand der Liste der bereitgestellten Zertifizierungsstellen überprüft. Wenn die Überprüfung fehlschlägt, wird ein Fehler zurückgegeben.
`secureProtocol`	Die zu verwendende SSL-Methode. Beispiel: SSLv3_method, um SSL auf Version 3 zu erzwingen.
`servername`	Der Servername für die TLS-Erweiterung für SNI (Server Name Indication).
`requestCert`	true für 2-Wege-SSL; false für 1-Wege-SSL

Client-SSL/TLS-Optionen verwenden

Sie können Edge Microgateway beim Herstellen einer Verbindung zu Zielendpunkten als TLS- oder SSL-Client konfigurieren. Verwenden Sie in der Konfigurationsdatei von Microgateway das Element „targets“, um SSL/TLS-Optionen festzulegen. Sie können mehrere spezifische Ziele angeben. Ein Beispiel für mehrere Ziele finden Sie unten.

Dieses Beispiel enthält Einstellungen, die auf alle Hosts angewendet werden:

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

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

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

Hier ein Beispiel für TLS:

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

Wenn Sie TLS/SSL-Einstellungen auf mehrere bestimmte Ziele anwenden möchten, müssen Sie den ersten Host in der Konfiguration als „leer“ angeben, wodurch universelle Anfragen möglich sind. Anschließend können Sie bestimmte Hosts in beliebiger Reihenfolge angeben. In diesem Beispiel werden die Einstellungen auf mehrere bestimmte Hosts angewendet:

targets:
 - host:   ## Note that this value must be "empty"
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       passphrase: admin123
       rejectUnauthorized: true
 - host: 'myserver1.example.com'
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       rejectUnauthorized: true
 - host: 'myserver2.example.com'
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       rejectUnauthorized: true

Im Folgenden finden Sie eine Liste aller unterstützten Clientoptionen:

Option	Beschreibung
`pfx`	Pfad zu einer `pfx`-Datei, die den privaten Schlüssel, das Zertifikat und die CA-Zertifikate des Clients im PFX-Format enthält.
`key`	Pfad zu einer `ca.key`-Datei im PEM-Format.
`passphrase`	Ein String, der die Passphrase für den privaten Schlüssel oder PFX enthält.
`cert`	Pfad zu einer `ca.cert`-Datei im PEM-Format.
`ca`	Pfad zu einer Datei mit einer Liste vertrauenswürdiger Zertifikate im PEM-Format.
`ciphers`	Ein String, der die zu verwendenden Chiffren beschreibt, getrennt durch ein ":".
`rejectUnauthorized`	Bei „true“ wird das Serverzertifikat anhand der Liste der bereitgestellten Zertifizierungsstellen überprüft. Wenn die Überprüfung fehlschlägt, wird ein Fehler zurückgegeben.
`secureProtocol`	Die zu verwendende SSL-Methode. Beispiel: SSLv3_method, um SSL auf Version 3 zu erzwingen.
`servername`	Der Servername für die TLS-Erweiterung für SNI (Server Name Indication).

Edgemicro-auth-Proxy anpassen

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

Benutzerdefinierten Authentifizierungsdienst verwenden

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

Wenn Sie Ihren eigenen benutzerdefinierten Dienst für die Authentifizierung verwenden möchten, ändern Sie den Wert authUri in der Konfigurationsdatei so, dass er auf Ihren Dienst verweist. Angenommen, Sie haben einen Dienst, der LDAP zur Identitätsüberprüfung verwendet.

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

Protokolldateien verwalten

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

Speicherort der Protokolldateien

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

Standardverzeichnis für Logdateien ändern

Das Verzeichnis, in dem Logdateien gespeichert sind, wird in der Edge Microgateway-Konfigurationsdatei angegeben. Siehe auch Konfigurationsänderungen vornehmen.

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

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

Protokolle an die Konsole senden

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

edgemicro:
  logging:
    to_console: true

Mit dieser Einstellung werden Protokolle an den Standardausgang gesendet. Derzeit können Logs nicht sowohl an stdout als auch an eine Logdatei gesendet werden.

Logging-Ebene festlegen

Sie geben die Logebene an, die in der edgemicro-Konfiguration verwendet werden soll. Eine vollständige Liste der Logebenen und ihrer Beschreibungen finden Sie unter edgemicro-Attribute.

Die folgende Konfiguration legt beispielsweise die Logging-Ebene auf debug fest:

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

Protokollintervalle ändern

Sie können diese Intervalle in der Edge Microgateway-Konfigurationsdatei konfigurieren. Siehe auch Konfigurationsänderungen vornehmen.

Die konfigurierbaren Attribute sind:

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

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

So lockern Sie strenge Logdateiberechtigungen

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

In Version 3.2.3 hinzugefügt.

Beispiel:

edgemicro:
 logging:
   disableStrictLogFile: true

Tipps für die Pflege von Logdateien

Da sich Logdateidaten mit der Zeit ansammeln, empfiehlt Apigee, die folgenden Praktiken anzuwenden:

Da Logdateien sehr groß werden können, muss das Logdateiverzeichnis genügend Speicherplatz haben. Weitere Informationen finden Sie in den Abschnitten Speicherort der Logdateien und Standardverzeichnis für Logdateien ändern.
Löschen Sie mindestens einmal pro Woche Protokolldateien oder verschieben Sie sie in ein separates Archivverzeichnis.
Wenn Ihre Richtlinie zum Löschen von Logs vorgesehen ist, können Sie mit dem CLI-Befehl edgemicro log -c ältere Logs entfernen (bereinigt).

Namenskonvention für Logdateien

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

edgemicro-HOST_NAME-INSTANCE_ID-api.log

Beispiel:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log

Inhalt der Protokolldatei

Hinzugefügt in: v2.3.3

Standardmäßig lässt der Logging-Dienst den JSON-Code heruntergeladener Proxys, Produkte und das JSON-Webtoken (JWT) aus. Wenn Sie diese Objekte an die Konsole ausgeben möchten, legen Sie beim Starten von Edge Microgateway das Befehlszeilen-Flag DEBUG=* fest. Beispiel:

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

Unter Windows: SET DEBUG=*

Inhalt der API-Protokolldatei

Die Logdatei "api" enthält detaillierte Informationen über den Fluss von Anfragen und Antworten über Edge Microgateway. Die "api"-Protokolldateien sind wie folgt benannt:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

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

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

Jeder dieser einzelnen Einträge wird in einer Kurzschreibweise dargestellt, um die Logdateien kompakter zu machen. Hier sind vier Beispieleinträge für jedes der vier Ereignisse. In der Protokolldatei sehen sie so aus (die Zeilennummern dienen nur zu Referenzzwecken im Dokument, sie sind in der Protokolldatei nicht enthalten).

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

Sehen wir 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-Datumsstempel
info – Die Protokollierungsebene. Dieser Wert hängt vom Kontext der Transaktion und der in der edgemicro-Konfiguration festgelegten Logging-Ebene ab. Weitere Informationen finden Sie unter Logging-Ebene festlegen. Bei Statistikeinträgen wird das Level auf stats festgelegt. Statistiken werden in einem regelmäßigen Intervall gemeldet, das in der stats_log_interval-Konfiguration festgelegt ist. Weitere Informationen finden Sie unter Protokollintervalle ändern.
req: identifiziert das Ereignis. Senden Sie in diesem Fall eine Anfrage vom Client.
m – Das in der Anfrage verwendete HTTP-Verb.
u – Der Teil der URL, der dem Basispfad folgt.
h – Host- und Portnummer, die Edge Microgateway überwacht.
r – Remote-Host und Port, von denen die Clientanfrage stammt.
i – Die Anfrage-ID. Alle vier Veranstaltungseinträge haben dieselbe ID. Jeder Anfrage wird eine eindeutige Anfrage-ID zugewiesen. Durch die Korrelation von Logeinträgen nach Anfrage-ID erhalten Sie wertvolle Einblicke in die Latenz des Ziels.
d – Die Dauer in Millisekunden, seit die Anfrage von Edge Microgateway empfangen wurde. Im obigen Beispiel wurde die Antwort des Ziels auf Anfrage 0 nach 7 Millisekunden empfangen (Zeile 3), während die Antwort weitere 4 Millisekunden an den Client gesendet wurde (Zeile 4). Mit anderen Worten, die gesamte Anfragelatenz betrug 11 Millisekunden, davon wurden 7 Millisekunden vom Ziel und 4 Millisekunden vom Edge Microgateway selbst verbraucht.

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

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

1436403888651 – Unix-Datumsstempel
info – Die Protokollierungsebene. Dieser Wert hängt vom Kontext der Transaktion und der in der edgemicro-Konfiguration festgelegten Logging-Ebene ab. Weitere Informationen finden Sie unter Logging-Ebene festlegen. Bei Statistikeinträgen wird das Level auf stats festgelegt. Statistiken werden in einem regelmäßigen Intervall gemeldet, das in der stats_log_interval-Konfiguration festgelegt ist. Weitere Informationen finden Sie unter Protokollintervalle ändern.
treq: Identifiziert das Ereignis. In diesem Fall die Zielanfrage.
m – Das in der Zielanfrage verwendete HTTP-Verb.
u – Der Teil der URL, der dem Basispfad folgt.
h – Host- und Portnummer des Back-End-Ziels.
i – ID des Logeintrags. Alle vier Veranstaltungseinträge haben dieselbe ID.

3. Beispiel einer eingehenden Antwort vom Ziel

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

1436403888651 – Unix-Datumsstempel

info – Die Protokollierungsebene. Dieser Wert hängt vom Kontext der Transaktion und der in der edgemicro-Konfiguration festgelegten Logging-Ebene ab. Weitere Informationen finden Sie unter Logging-Ebene festlegen. Bei Statistikeinträgen wird das Level auf stats festgelegt. Statistiken werden in einem regelmäßigen Intervall gemeldet, das in der stats_log_interval-Konfiguration festgelegt ist. Weitere Informationen finden Sie unter Protokollintervalle ändern.
tres – Kennzeichnet das Ereignis. In diesem Fall die Zielantwort.
s – HTTP-Antwortstatus
d – Dauer in Millisekunden. Die vom Ziel für den API-Aufruf benötigte Zeit.
i – ID des Logeintrags. Alle vier Veranstaltungseinträge haben dieselbe ID.

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

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

1436403888651 – Unix-Datumsstempel

info – Die Protokollierungsebene. Dieser Wert hängt vom Kontext der Transaktion und der in der edgemicro-Konfiguration festgelegten Logging-Ebene ab. Weitere Informationen finden Sie unter Logging-Ebene festlegen. Bei Statistikeinträgen wird das Level auf stats festgelegt. Statistiken werden in einem regelmäßigen Intervall gemeldet, das in der stats_log_interval-Konfiguration festgelegt ist. Weitere Informationen finden Sie unter Protokollintervalle ändern.
res – Kennzeichnet das Ereignis. In diesem Fall eine Antwort an den Client.
s – HTTP-Antwortstatus
d – Dauer in Millisekunden. Dies ist die Gesamtzeit des API-Aufrufs, einschließlich der Zeit, die von der Ziel-API benötigt wird, und der Zeit, die Edge Microgateway selbst benötigt.
i – ID des Logeintrags. Alle vier Veranstaltungseinträge haben dieselbe ID.

Zeitplan für Protokolldatei

Logdateien werden in dem Intervall rotiert, das im Konfigurationsattribut rotate_interval angegeben ist. Einträge werden weiterhin derselben Logdatei hinzugefügt, bis das Rotationsintervall abgelaufen ist. Jedes Mal, wenn Edge Microgateway neu gestartet wird, empfängt es jedoch eine neue UID und erstellt einen neuen Satz von Protokolldateien mit dieser UID. Weitere Informationen finden Sie unter Gute Handhabung von Logdateien.

Fehlermeldungen

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

Edge Microgateway-Konfigurationsreferenz

Speicherort der Konfigurationsdatei

Die in diesem Abschnitt beschriebenen Konfigurationsattribute befinden sich in der Konfigurationsdatei Edge Microgateway. Siehe auch Konfigurationsänderungen vornehmen.

Edge-Konfigurationsattribute

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

bootstrap: (Standard: keine) Eine URL, die auf einen Edge Microgateway-spezifischen Dienst verweist, der auf Apigee Edge ausgeführt wird. Edge Microgateway verwendet diesen Dienst für die Kommunikation mit Apigee Edge. Diese URL wird zurückgegeben, wenn Sie den Befehl zum Generieren des öffentlichen/privaten Schlüsselpaars ausführen: edgemicro genkeys. Weitere Informationen finden Sie unter Edge Microgateway einrichten und konfigurieren.
jwt_public_key: (Standard: keine) Eine URL, die auf den Edge Microgateway-Proxy verweist, der auf Apigee Edge bereitgestellt wird. Dieser Proxy dient als Authentifizierungsendpunkt für die Ausstellung signierter Zugriffstokens an Clients. Diese URL wird zurückgegeben, wenn Sie den Befehl edgemicro config ausführen, um den Proxy bereitzustellen. Weitere Informationen finden Sie unter Edge Microgateway einrichten und konfigurieren.
quotaUri: Legen Sie dieses Konfigurationsattribut fest, wenn Sie Kontingente über den edgemicro-auth-Proxy verwalten möchten, der für Ihre Organisation bereitgestellt wird. Wenn dieses Attribut nicht festgelegt ist, wird als Kontingentendpunkt standardmäßig der interne Edge Microgateway-Endpunkt verwendet.
```
edge_config:
  quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
```

Edgemicro-Attribute

Diese Einstellungen konfigurieren den Edge Microgateway-Prozess.

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

res.statusCode = 429; // Too many requests
max_connections_hard: (Standard: -1) Die maximale Anzahl gleichzeitiger Anfragen, die Edge Microgateway empfangen kann, bevor die Verbindung getrennt wird. Diese Einstellung dient dazu, Denial-of-Service-Angriffe zu verhindern. Legen Sie dafür in der Regel einen Wert fest, der größer als „max_connections“ ist.
logging:
- level: (Standard: Fehler)
  - info (empfohlen): Protokolliert alle Anfragen und Antworten, die durch eine Edge Microgateway-Instanz fließen.
  - warn: Protokolliert nur Warnmeldungen.
  - error – protokolliert nur Fehlermeldungen.
  - debug: Protokolliert Debug-Meldungen zusammen mit Informationen, Warnungen und Fehlermeldungen.
  - trace: Protokolliert Trace-Informationen für Fehler zusammen mit Informationen, Warnungen und Fehlermeldungen.
  - none: Es wird keine Protokolldatei erstellt.
- dir: (Standard: /var/tmp) Das Verzeichnis, in dem die Logdateien gespeichert sind.
- stats_log_interval: (Standard: 60) Intervall in Sekunden, wenn der Statistikeintrag in die API-Logdatei geschrieben wird.
- rotate_interval: (Standardeinstellung: 24) Intervall in Stunden, wenn Logdateien rotiert werden.

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

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

debug : Fügt dem Edge Microgateway-Prozess Remote-Debugging hinzu.
- port: Die Portnummer, die überwacht werden soll. Legen Sie beispielsweise fest, dass der IDE-Debugger diesen Port überwacht.
- args: Argumente für den Fehlerbehebungsprozess. Beispiel: args --nolazy
config_change_poll_interval: (Standardeinstellung: 600 Sekunden) Edge Microgateway lädt regelmäßig eine neue Konfiguration und führt eine Aktualisierung durch, wenn sich etwas geändert hat. Beim Abfragen werden alle in Edge vorgenommenen Änderungen (Änderungen an Produkten, Microgateway-fähigen Proxys usw.) sowie an der lokalen Konfigurationsdatei vorgenommene Änderungen erfasst.
disable_config_poll_interval: (Standardeinstellung: "false") Wenn dieser Wert auf true gesetzt ist, wird die automatische Änderungsabfrage deaktiviert.
request_timeout: Legt ein Zeitlimit für Zielanfragen fest. Das Zeitlimit wird in Sekunden festgelegt. Wenn eine Zeitüberschreitung auftritt, antwortet Edge Microgateway mit einem 504-Statuscode. (Version 2.4.x hinzugefügt)
keep_alive_timeout: Mit diesem Attribut können Sie das Edge Microgateway-Zeitlimit (in Millisekunden) festlegen. (Standardeinstellung: 5 Sekunden) (Version 3.0.6 hinzugefügt)
headers_timeout: Dieses Attribut begrenzt die Zeit (in Millisekunden), die der HTTP-Parser auf den Empfang der vollständigen HTTP-Header wartet.
Beispiel:
```
edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000
```
Intern wird mit dem Parameter das Node.js-Attribut Server.headersTimeout für Anfragen festgelegt. (Standardeinstellung: 5 Sekunden mehr als die mit edgemicro.keep_alive_timeout festgelegte Zeit. Diese Standardeinstellung verhindert, dass Load-Balancer oder Proxys die Verbindung versehentlich trennen.) (Version 3.1.1 hinzugefügt)
noRuleMatchAction: (String) Die auszuführende Aktion (Zugriff zulassen oder ablehnen), wenn die im Plug-in accesscontrol angegebene Übereinstimmungsregel nicht aufgelöst wird (keine Übereinstimmung). Gültige Werte: ALLOW oder DENY Standardeinstellung: ALLOW (Hinzugefügt: Version 3.1.7)
enableAnalytics: (Standardeinstellung: true) Setzen Sie das Attribut auf false, um zu verhindern, dass das Analyse-Plug-in geladen wird. In diesem Fall werden keine Aufrufe an Apigee Edge-Analysen durchgeführt. Wenn true festgelegt oder dieses Attribut nicht angegeben ist, funktioniert das Analyse-Plug-in wie gewohnt. Weitere Informationen finden Sie unter edgemicro-Attribute. (Version 3.1.8 wurde hinzugefügt.)
Beispiel:
```
edgemicro
  enableAnalytics=false|true
```
Wenn enableAnalytics auf false gesetzt ist, Edge Microgateway aber mit dem Messwert-Plug-in gestartet wird, funktioniert das Analyse-Plug-in wie gewohnt, da für das Messwert-Plug-in ein Analyse-Plug-in erforderlich ist. 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 ohne Fehlermeldung gekürzt. In Logdateien wird eine Warnmeldung mit `targetResponse aborted` und dem Antwortcode 502 angezeigt.
`appendErrorToClientResponseBody`	Der benutzerdefinierte Fehler `TargetResponseAborted` wird an den Client zurückgegeben. In Logdateien wird eine Warnmeldung mit `targetResponse aborted` und dem Antwortcode 502 angezeigt. Außerdem wird der Fehler `TargetResponseAborted` mit der Meldung `Target response ended prematurely.` protokolliert.
`abortClientRequest`	Edge Microgateway bricht die Anfrage ab und in die Logdateien wird eine Warnung mit dem Statuscode 502 der Anfrage geschrieben: `TargetResponseAborted`.

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: true) Legen Sie diesen Wert auf "false" fest, um zu verhindern, dass x-forwarded-for-Header an das Ziel übergeben werden. Wenn sich ein „x-forwarded-for“-Header in der Anfrage befindet, wird sein Wert auf den Client-IP-Wert in Edge Analytics festgelegt.
x-forwarded-host: (Standardeinstellung: true) Legen Sie diesen Wert auf "false" fest, um zu verhindern, dass x-forwarded-host-Header an das Ziel übergeben werden.
x-request-id: (Standardeinstellung: true) Legen Sie diesen Wert auf "false" fest, um zu verhindern, dass x-request-id-Header an das Ziel übergeben werden.
x-response-time: (Standardeinstellung: true) Legen Sie diesen Wert auf "false" fest, um zu verhindern, dass x-response-time-Header an das Ziel weitergegeben werden.
via: (Standardeinstellung: true) Legen Sie diesen Wert auf "false" fest, um zu verhindern, dass via-Header an das Ziel übergeben werden.

OAuth-Attribute

Diese Einstellungen konfigurieren, wie die Clientauthentifizierung von Edge Microgateway erzwungen wird.

allowNoAuthorization: (Standardeinstellung: false) Wenn auf „true“ gesetzt, dürfen API-Aufrufe Edge Microgateway überhaupt ohne Autorisierungsheader passieren. Legen Sie diesen Wert auf „false“ fest, damit ein Autorisierungsheader erforderlich ist (Standardeinstellung).
allowInvalidAuthorization: (Standardeinstellung: „false“) Wenn die Richtlinie auf „true“ gesetzt ist, können API-Aufrufe passieren, wenn das im Autorisierungsheader übergebene Token ungültig oder abgelaufen ist. Setzen Sie diesen Wert auf „false“, um gültige Tokens anzufordern (Standardeinstellung).
authorization-header: (Standard: Authorization: Bearer) Der Header, der zum Senden des Zugriffstokens an Edge Microgateway verwendet wird. Sie können die Standardeinstellung ändern, wenn das Ziel den Autorisierungsheader für einen anderen Zweck verwenden muss.
api-key-header: (Standard: x-api-key) Der Name des Headers oder Abfrageparameters, der zur Übergabe eines API-Schlüssels an Edge Microgateway verwendet wird. Weitere Informationen finden Sie unter API-Schlüssel verwenden.
keep-authorization-header: (Standardeinstellung: false) Wenn dieser Wert auf "true" gesetzt ist, wird der in der Anfrage gesendete Autorisierungsheader an das Ziel übergeben und beibehalten.
allowOAuthOnly: Wenn die Richtlinie auf "true" gesetzt ist, muss jede API einen Autorisierungsheader mit einem Inhaberzugriffstoken enthalten. Ermöglicht es Ihnen, nur das OAuth-Sicherheitsmodell zuzulassen (unter Aufrechterhaltung der Abwärtskompatibilität). (Version 2.4.x hinzugefügt)
allowAPIKeyOnly: Wenn „true“ festgelegt ist, muss jede API einen x-api-key-Header (oder einen benutzerdefinierten Speicherort) mit einem API-Schlüssel enthalten.So können Sie nur das Sicherheitsmodell des API-Schlüssels zulassen (unter Aufrechterhaltung der Abwärtskompatibilität). (Version 2.4.x hinzugefügt)
Legen Sie nicht sowohl allowOAuthOnly als auch allowAPIKeyOnly auf „true“ fest. Standardmäßig sind beide Flags auf "false" gesetzt (aus Gründen der Abwärtskompatibilität).
gracePeriod – Dieser Parameter verhindert Fehler, die durch leichte Abweichungen zwischen Ihrer Systemuhr und den im JWT-Autorisierungstoken angegebenen Zeiten (nbf) oder Issued at (iat) verursacht werden. Legen Sie für diesen Parameter die Anzahl der Sekunden fest, um solche Abweichungen zu berücksichtigen. (Version 2.5.7 hinzugefügt)

Plug-in-spezifische Attribute

Weitere Informationen zu konfigurierbaren Attributen für jedes Plug-in finden Sie unter "Plug-ins verwenden".

Proxys filtern

Sie können filtern, welche Microgateway-fähigen Proxys eine Edge Microgateway-Instanz verarbeitet. Beim Start von Edge Microgateway werden alle Microgateway-fähigen Proxys in der Organisation heruntergeladen, der es zugeordnet ist. Verwenden Sie die folgende Konfiguration, um festzulegen, welche Proxys das Mikrogateway verarbeitet. Bei dieser Konfiguration sind die vom Mikrogateway verarbeiteten Proxys beispielsweise auf drei begrenzt: edgemicro_proxy-1, edgemicro_proxy-2 und edgemicro_proxy-3:

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

Produkte nach Namen filtern

Verwenden Sie die folgende Konfiguration, um die Anzahl der API-Produkte zu begrenzen, die Edge Microgateway herunterlädt und verarbeitet. Fügen Sie der /products API, die in der Edge Microgateway-Datei *.config.yaml aufgeführt ist, den Abfrageparameter productnamefilter hinzu, um heruntergeladene Produkte zu filtern. Beispiel:

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

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

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

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

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

         ]
      },
      {
         "apiResources":[

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

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

         ]
      }
   ]
}

Produkte nach benutzerdefinierten Attributen filtern

So filtern Sie Produkte anhand von benutzerdefinierten Attributen:

Wählen Sie in der Edge-Benutzeroberfläche den Proxy edgemicro_auth in der Organisation/Umgebung aus, in der Sie Edge Microgateway konfiguriert haben.
Öffnen Sie im Editor unter „Entwickeln“ die JavaCallout-Richtlinie.
Fügen Sie ein benutzerdefiniertes Attribut mit dem Schlüssel products.filter.attributes mit einer durch Kommas getrennten Liste von Attributnamen hinzu. Nur Produkte, die einen der benutzerdefinierten Attributnamen enthalten, werden an Edge Microgateway zurückgegeben.
Optional können Sie die Prüfung, ob das Produkt für die aktuelle Umgebung aktiviert ist, deaktivieren. Dazu setzen Sie das benutzerdefinierte Attribut products.filter.env.enable auf false. Die Standardeinstellung ist „true“.
(Nur Private Cloud) Wenn Sie sich in Edge für Private Cloud befinden, legen Sie das Attribut org.noncps auf true fest, um Produkte für Nicht-CPS-Umgebungen abzurufen.

Beispiel:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout async="false" continueOnError="false" enabled="true" name="JavaCallout">
    <DisplayName>JavaCallout</DisplayName>
    <FaultRules/>
    <Properties>
        <Property name="products.filter.attributes">attrib.one, attrib.two</Property>
        <Property name="products.filter.env.enable">false</Property>
        <Property name="org.noncps">true</Property>
    </Properties>
    <ClassName>io.apigee.microgateway.javacallout.Callout</ClassName>
    <ResourceURL>java://micro-gateway-products-javacallout-2.0.0.jar</ResourceURL>
</JavaCallout>

Push-Häufigkeit für Analysen konfigurieren

Verwenden Sie diese Konfigurationsparameter, um die Häufigkeit zu steuern, mit der Edge Microgateway Analysedaten an Apigee sendet:

bufferSize (optional): Die maximale Anzahl von Analysedatensätzen, die der Puffer enthalten kann, bevor mit dem Löschen der ältesten Datensätze begonnen wird. Standardeinstellung: 10.000
batchSize (optional): Die maximale Größe eines Batches von Analysedatensätzen, die an Apigee gesendet werden. Standardeinstellung: 500
flushInterval (optional): Die Anzahl der Millisekunden zwischen den einzelnen Leerungen eines Batches von Analysedatensätzen, die an Apigee gesendet werden. Standardeinstellung: 5.000

Beispiel:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Analysedaten maskieren

Die folgende Konfiguration verhindert, dass Anfragepfadinformationen in Edge Analytics angezeigt werden. Fügen Sie der Mikrogateway-Konfiguration Folgendes hinzu, um den Anfrage-URI und/oder den Anfragepfad zu maskieren. Der URI besteht aus dem Hostnamen und dem Pfad der Anfrage.

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

API-Aufrufe in Edge Analytics trennen

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

edgemicro_proxyname-health

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

Verwenden Sie diese Parameter, um relative und absolute Pfade im Analytics-Dashboard als separate Proxys zu trennen:

relativePath (optional): Gibt einen relativen Pfad an, der im Analytics-Dashboard getrennt werden soll. Wenn Sie beispielsweise /healthcheck angeben, werden alle API-Aufrufe, die den Pfad /healthcheck enthalten, im Dashboard als edgemicro_proxyname-health angezeigt. Beachten Sie, dass dieses Flag den Proxy-Basispfad ignoriert. Verwenden Sie das Flag proxyPath, um die Trennung basierend auf einem vollständigen Pfad einschließlich Basispfad zu trennen.
proxyPath (optional): Gibt einen vollständigen API-Proxy-Pfad, einschließlich des Proxy-Basispfads, an, der im Analyse-Dashboard getrennt werden soll. Wenn Sie beispielsweise /mocktarget/healthcheck angeben, wobei /mocktarget der Proxy-Basispfad ist, werden alle API-Aufrufe mit dem Pfad /mocktarget/healthcheck im Dashboard als edgemicro_proxyname-health angezeigt.

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

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

In der folgenden Konfiguration wird jede API mit dem Proxypfad /mocktarget/healthcheck als separater Proxy namens edgemicro_proxyname-health im Analyse-Dashboard getrennt.

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

Edge Microgateway hinter einer Unternehmensfirewall einrichten

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

In Version 3.1.2 hinzugefügt.

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

Legen Sie die Umgebungsvariablen HTTP_PROXY, HTTPS_PROXY und NO_PROXY fest. Diese Variablen steuern die Hosts für jeden HTTP-Proxy, den Sie für die Kommunikation mit Apigee Edge verwenden möchten oder welche Hosts die Kommunikation mit Apigee Edge nicht übernehmen sollen. Beispiel:
```
export HTTP_PROXY='http://localhost:3786'
export HTTPS_PROXY='https://localhost:3786'
export NO_PROXY='localhost,localhost:8080'
```
Beachten Sie, dass NO_PROXY eine durch Kommas getrennte Liste von Domains sein kann, zu denen Edge Microgateway nicht weitergeleitet werden soll.

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

HTTP-Proxy für die Zielkommunikation verwenden

In Version 3.1.2 hinzugefügt.

So verwenden Sie einen HTTP-Proxy für die Kommunikation zwischen Edge Microgateway und Back-End-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 dieser Wert auf "true" gesetzt ist, verwendet Edge Microgateway die Methode HTTP CONNECT, um HTTP-Anfragen über eine einzelne TCP-Verbindung zu trafficken. Dasselbe gilt, wenn die Umgebungsvariablen zum Konfigurieren des Proxys (wie unten erwähnt) TLS aktiviert sind. Standard: false
- url: Die HTTP-Proxy-URL.
- bypass: (Optional) Gibt eine oder mehrere durch Kommas getrennte Zielhost-URLs an, die den HTTP-Proxy umgehen sollen. Wenn dieses Attribut nicht festgelegt ist, verwenden Sie die Umgebungsvariable NO_PROXY, um anzugeben, welche Ziel-URLs umgangen werden sollen.
- enabled: Wenn „true“ und proxy.url festgelegt ist, verwenden Sie den Wert proxy.url für den HTTP-Proxy. Wenn „true“ und proxy.url nicht festgelegt ist, verwenden Sie die Proxys, die in den HTTP-Proxy-Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY angegeben sind, wie unter HTTP-Proxy für die Kommunikation mit Apigee Edge verwenden beschrieben.
Beispiel:
```
edgemicro:
  proxy:
    tunnel: true
    url: 'http://localhost:3786'
    bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
    enabled: true
```
HINWEIS: Hinweis: Wenn edgemicro.proxy in der Konfigurationsdatei weggelassen wird oder wenn edgemicro.proxy.enabled auf "false" gesetzt ist, verwendet Edge Microgateway keinen HTTP-Proxy für die Zielkommunikation.
Starten Sie Edge Microgateway neu.

Platzhalter in Microgateway-fähigen Proxys verwenden

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

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

JWT-Schlüssel rotieren

So verwendet Edge Microgateway JWTs

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

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

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

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

Was ist Schlüsselrotation?

Nachdem Sie ein JWT erstmals generiert haben, müssen Sie möglicherweise das Paar aus öffentlichem und privatem Schlüssel ändern, das in der Edge-verschlüsselten KVM gespeichert ist. Dieser Vorgang des Generierens eines neuen Schlüsselpaars wird als Schlüsselrotation bezeichnet. Wenn Sie Schlüssel rotieren, wird ein neues Paar aus privatem und öffentlichem Schlüssel generiert und in der KVM „Microgateway“ in Ihrer Apigee Edge-Organisation/Umgebung gespeichert. Darüber hinaus wird der alte öffentliche Schlüssel zusammen mit dem ursprünglichen Schlüssel-ID-Wert beibehalten.

Zum Generieren eines JWT verwendet Edge Informationen, die in der verschlüsselten KVM gespeichert sind. Eine KVM mit dem Namen microgateway wurde erstellt und mit Schlüsseln gefüllt, als Sie Edge Microgateway ursprünglich eingerichtet (konfiguriert) haben. Die Schlüssel in der KVM werden zum Signieren und Verschlüsseln eines JWT verwendet.

Zu den KVM-Schlüsseln gehören:

private_key – Der neueste (zuletzt erstellte) private RSA-Schlüssel zum Signieren von JWTs.
public_key – Das neueste (zuletzt erstellte) Zertifikat, das zur Überprüfung von mit dem privaten_key signierten JWTs verwendet wird.
private_key_kid – Die neueste (zuletzt erstellte) ID des privaten Schlüssels. Diese Schlüssel-ID ist dem Wert "private_key" zugeordnet und wird verwendet, um die Schlüsselrotation zu unterstützen.
public_key1_kid – Die neueste (zuletzt erstellte) ID des öffentlichen Schlüssels. Dieser Schlüssel ist mit dem Wert public_key1 verknüpft und wird verwendet, um die Schlüsselrotation zu unterstützen. Dieser Wert entspricht dem untergeordneten Schlüssel des privaten Schlüssels.
public_key1 – der neueste (zuletzt erstellte) öffentliche Schlüssel.

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

public_key2_kid – Die alte öffentliche Schlüssel-ID. Dieser Schlüssel ist mit dem Wert „public_key2“ verknüpft und wird verwendet, um die Schlüsselrotation zu unterstützen.
public_key2 – Der alte öffentliche Schlüssel.

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

Schlüsselrotation durchführen

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

Verwenden Sie den Befehl edgemicro upgradekvm, um ein Upgrade der KVM durchzuführen. Weitere Informationen zum Ausführen dieses Befehls finden Sie unter Upgrade der KVM ausführen. Sie müssen diesen Schritt nur einmal ausführen.
Verwenden Sie den Befehl edgemicro upgradeauth, um den Proxy edgemicro-oauth zu aktualisieren. Weitere Informationen zum Ausführen dieses Befehls finden Sie unter Edgemicro-auth-Proxy upgraden. Sie müssen diesen Schritt nur einmal ausführen.
Fügen Sie der Datei ~/.edgemicro/org-env-config.yaml die folgende Zeile hinzu. Darin müssen Sie dieselbe Organisation und Umgebung angeben, die Sie für das Mikrogateway konfiguriert haben:
```
jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'
```

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

edgemicro rotatekey -o $ORG -e $ENV -k $KEY -s $SECRET

Beispiel:

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

Nach der Schlüsselrotation gibt Edge mehrere Schlüssel an Edge Microgateway zurück. Beachten Sie, dass im folgenden Beispiel jeder Schlüssel einen eindeutigen Wert für „kid“ (Schlüssel-ID) hat. Das Mikrogateway verwendet diese Schlüssel dann, um Autorisierungstoken zu validieren. Wenn die Tokenvalidierung fehlschlägt, prüft das Mikrogateway, ob im Schlüsselsatz ein älterer Schlüssel vorhanden ist, und versucht, diesen Schlüssel zu testen. Die zurückgegebenen Schlüssel haben das Format JSON Web Key (JWK). Informationen zu diesem Format finden Sie unter RFC 7517.

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

„Nicht vor“-Verzögerung konfigurieren

Bei den Versionen 3.1.5 und davor trat der neue private Schlüssel, der mit dem Befehl rotatekey generiert wurde, sofort in Kraft. Neu generierte Tokens wurden mit dem neuen privaten Schlüssel signiert. Der neue öffentliche Schlüssel wurde Edge Microgateway-Instanzen jedoch standardmäßig nur alle 10 Minuten zur Verfügung gestellt, wenn die Mikrogateway-Konfiguration aktualisiert wurde. Aufgrund dieser Verzögerung zwischen der Tokensignierung und der Aktualisierung der Microgateway-Instanz werden Tokens, die mit dem neuesten Schlüssel signiert wurden, so lange abgelehnt, bis alle Instanzen den öffentlichen neuesten Schlüssel erhalten haben.

In Fällen, in denen mehrere Microgateway-Instanzen vorhanden sind, führte die Verzögerung des öffentlichen Schlüssels manchmal zu vorübergehenden Laufzeitfehlern mit dem Status 403, da die Tokenvalidierung eine Instanz bestanden hat, auf einer anderen jedoch fehlschlagen würde, bis alle Instanzen aktualisiert wurden.

Ab Version 3.1.6 können Sie mit einem neuen Flag für den Befehl rotatekey eine Verzögerung festlegen, bis der neue private Schlüssel wirksam wird. Dadurch haben alle Microgateway-Instanzen Zeit, aktualisiert zu werden und den neuen öffentlichen Schlüssel zu erhalten. Das neue Flag ist --nbf, was für „not before“ steht. Dieses Flag verwendet einen ganzzahligen Wert, also die Anzahl der Minuten, die verzögert werden soll.

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

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

Es hat sich bewährt, für die Verzögerung einen größeren Wert als die Konfigurationseinstellung config_change_poll_internal festzulegen, 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, die mit dem Namenspräfix „edgemicro_“ beginnen. Sie können diese Standardeinstellung ändern, um Proxys herunterzuladen, deren Namen einem Muster entsprechen.

Öffnen Sie Ihre 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. Durch diese Produktkonfiguration kann ein mit diesem Produkt verknüpfter API-Schlüssel mit jedem Proxy verwendet werden, der in Ihrer Organisation bereitgestellt wird. Ab Version 2.5.4 unterstützt Edge Microgateway diese Produktkonfiguration.

Debugging und Fehlerbehebung

Verbindung zu einem Debugger herstellen

Sie können Edge Microgateway mit einem Debugger wie node-Inspector ausführen. Dies ist nützlich, um Fehler bei benutzerdefinierten Plug-ins zu beheben.

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

Mit dem folgenden Befehl können Sie die Debug-Ausgabe an eine Datei weiterleiten:
```
export DEBUG=* nohup edgemicro start \
-o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log
```
Starten Sie den Debugger und richten Sie ihn so ein, dass er beim Debugging auf die Portnummer wartet.
Sie können jetzt Schritt für Schritt den Edge Microgateway-Code durchgehen, Haltepunkte festlegen, Überwachungsausdrücke usw. festlegen.

Sie können Node.js-Standard-Flags für den Debug-Modus angeben. --nolazy hilft beispielsweise beim Debugging von asynchronem Code.

Protokolldateien prüfen

Bei Problemen sollten Sie die Protokolldateien auf Ausführungsdetails und Fehlerinformationen prüfen. 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 für den Consumer-Schlüssel (auch Client-ID genannt) aus einem Apigee Edge-Produkt kopieren, das den Edge Microgateway-Authentifizierungs-Proxy enthält.

Schlüssel zwischenspeichern

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

API-Schlüssel verwenden

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

Beispiel für einen Suchparameter:

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

Beispiel für Anzeigentitel:

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

Namen des API-Schlüssels konfigurieren

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

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

In diesem Beispiel werden sowohl der Abfrageparameter als auch der Headername in apiKey geändert. Der Name x-api-key funktioniert in beiden Fällen nicht mehr. 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 Secure Edge Microgateway.

Upstream-Antwortcodes aktivieren

Standardmäßig gibt das oauth-Plug-in nur 4xx-Fehlerstatuscodes zurück, wenn die Antwort kein 200-Status ist. Sie können dieses Verhalten so ändern, dass es je nach Fehler immer den genauen 4xx- oder 5xx-Code zurückgibt.

Fügen Sie Ihrer Edge Microgateway-Konfiguration das Attribut oauth.useUpstreamResponse: true hinzu, um dieses Feature zu aktivieren. Beispiel:

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

OAuth2-Tokensicherheit verwenden

In diesem Abschnitt wird erläutert, wie Sie OAuth2-Zugriffstokens und Aktualisierungstokens erhalten. Zugriffstokens werden verwendet, um sichere API-Aufrufe über das Mikrogateway auszuführen. Aktualisierungstokens werden verwendet, um neue Zugriffstokens zu erhalten.

So erhalten Sie ein Zugriffstoken

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

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

API 1: Anmeldedaten als Textparameter senden

Ersetzen Sie Ihre Organisations- und Umgebungsnamen in der URL und ersetzen Sie die Textparameter client_id und client_secret durch die Werte für die Nutzer-ID und das Consumer Secret, die Sie von einer Entwickler-App auf Apigee Edge erhalten haben:

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

API 2: Anmeldedaten in einem Basic Auth-Header senden

Senden Sie die Clientanmeldedaten als Basisauthentifizierungsheader und grant_type als Formularparameter. Dieses Befehlsformular wird auch unter RFC 6749: The OAuth 2.0 Authorization Framework erläutert.

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

Beispielausgabe

Die API gibt eine JSON-Antwort zurück. Beachten Sie, dass es keinen Unterschied zwischen den Attributen token und access_token gibt. Beides ist möglich. Beachten Sie, dass expires_in eine Ganzzahl in Sekunden ist.

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

Aktualisierungstoken abrufen

Wenn Sie ein Aktualisierungstoken abrufen möchten, führen Sie einen API-Aufruf an den Endpunkt /token des Proxys edgemicro-auth aus. Sie MÜSSEN diesen API-Aufruf mit dem Berechtigungstyp password ausführen. Führen Sie dazu die folgenden Schritte aus.

Mit der /token API können Sie ein Zugriffs- und Aktualisierungstoken abrufen. Der Berechtigungstyp 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 Zugriffstoken und ein Aktualisierungstoken zurück. Die Antwort sieht in etwa so aus. Beachten Sie, dass expires_in ganze Zahlen sind und in Sekunden angegeben werden.

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

Sie können jetzt mit dem Aktualisierungstoken ein neues Zugriffstoken abrufen. Dazu rufen Sie den Endpunkt /refresh derselben API auf. Beispiel:

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

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

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

Dauerhaftes Monitoring

Endlos ist ein Node.js-Tool, das eine Node.js-Anwendung automatisch neu startet, falls der Prozess ausfällt oder ein Fehler auftritt. Edge Microgateway hat eine Datei forever.json, mit der Sie steuern können, wie oft und in welchen Intervallen Edge Microgateway neu gestartet werden soll. Diese Datei konfiguriert den permanenten Dienst forever-monitor, der die Endlosigkeit programmatisch verwaltet.

Sie finden die Datei forever.json im Installationsstammverzeichnis von Edge Microgateway. Weitere Informationen finden Sie unter Wo ist Edge Microgateway installiert?. Weitere Informationen zu den Konfigurationsoptionen finden Sie in der Dokumentation zur dauerhaften Überwachung.

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

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

Weitere Informationen finden Sie in der Befehlszeilenreferenz unter Dauerhaftes Monitoring.

Endpunkt für Konfigurationsdatei angeben

Wenn Sie mehrere Edge Microgateway-Instanzen ausführen, möchten Sie möglicherweise deren Konfigurationen von einem einzigen Standort aus verwalten. Dazu können Sie einen HTTP-Endpunkt angeben, von dem Edge Micro seine Konfigurationsdatei herunterladen kann. Sie können diesen Endpunkt beim Start von Edge Micro mit dem Flag -u angeben.

Beispiel:

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

Dabei gibt der Endpunkt „mgconfig“ den Inhalt der Konfigurationsdatei zurück. Dies ist die Datei, die sich standardmäßig in ~/.edgemicro befindet und die folgende Namenskonvention hat: org-env-config.yaml.

Zwischenspeichern von TCP-Verbindungsdaten wird deaktiviert

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

Standardmäßig verwenden TCP-Verbindungen den Nagle-Algorithmus, um Daten vor dem Senden zu puffern. Wenn Sie nodelay auf true setzen, wird dieses Verhalten deaktiviert (Daten werden bei jedem Aufruf von socket.write() sofort durch die Daten ausgelöst.) Weitere Informationen finden Sie in der Node.js-Dokumentation.

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

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

Edge Microgateway im eigenständigen Modus ausführen

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

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

OAuth und API-Schlüssel
Kontingent
Analytics

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

Gateway konfigurieren und starten

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

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

Beispiel:
```
vi $HOME/.edgemicro/foo-bar-config.yaml
```
Fügen Sie den folgenden Code in die Datei ein:
```
edgemicro:
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - extauth
      - spikearrest
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
extauth:
  publickey_url: https://www.googleapis.com/oauth2/v1/certs
spikearrest:
  timeUnit: second
  allow: 10
  buffersize: 0
```
Die Konfigurationsdatei enthält ein spezielles, optionales Plug-in namens extauth. Dieses Plug-in überprüft ein gültiges JWT-Token, das an das Mikrogateway übergeben wird. In einem späteren Schritt erfahren Sie, wie Sie das Token abrufen und verwenden. Beachten Sie außerdem, dass das Plug-in spikearrest enthalten ist, da es nicht von der Konnektivität mit Edge abhängig ist. Die Plug-ins quota, oauth und analytics sind ausgeschlossen, da sie auf die Konnektivität mit Edge angewiesen sind und im getrennten Modus nicht funktionieren. Benutzerdefinierte Plug-ins sind zulässig und funktionieren erwartungsgemäß.
Exportieren Sie die folgende Umgebungsvariable mit dem Wert „1“:
```
export EDGEMICRO_LOCAL=1
```
Führen Sie den folgenden start-Befehl aus und geben Sie dabei Werte zum Instanziieren des lokalen Proxys an:
```
edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
  -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH
```
Wobei:
- $ORG ist der Name der Organisation, den Sie im Namen der Konfigurationsdatei verwendet haben.
- $ENV ist der Name der Umgebung, den Sie im Namen der Konfigurationsdatei verwendet haben.
- $LOCAL_PROXY_NAME ist der Name des lokalen Proxys, der erstellt wird. Sie können einen beliebigen Namen verwenden.
- $LOCAL_PROXY_VERSION ist die Versionsnummer des Proxys.
- $TARGET_URL ist die URL für das Ziel des Proxys. Das Ziel ist der Dienst, den der Proxy aufruft.
- $BASE_PATH ist der Basispfad des Proxys. Dieser Wert muss mit einem Schrägstrich beginnen. Geben Sie für den Basispfad des Stammverzeichnisses 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 Plug-in extauth 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 ein JWT vom Edge Microgateway-JWT-Endpunkt auf Apigee Edge (edgemicro-auth/jwkPublicKeys) abgerufen wird. Dieser Endpunkt wird bereitgestellt, wenn Sie eine Standardeinrichtung und -konfiguration von Edge Microgateway durchführen. Damit Sie das JWT vom Apigee-Endpunkt abrufen können, müssen Sie zuerst die standardmäßige Edge Microgateway-Einrichtung vornehmen und mit dem Internet verbunden sein. Der Apigee-Endpunkt wird hier nur zu Beispielzwecken verwendet und ist nicht erforderlich. Sie können bei Bedarf einen anderen JWT-Token-Endpunkt verwenden. In diesem Fall musst du das JWT mithilfe der für diesen Endpunkt bereitgestellten API abrufen.

Das Einfügen des Plug-ins extauth in die Microgateway-Konfiguration ist optional. Wenn Sie es einschließen, müssen Sie im Autorisierungsheader für API-Aufrufe ein gültiges JWT-Token angeben.

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

Sie müssen eine Standardeinrichtung und -konfiguration von Edge Microgateway durchführen, um den edgemicro-auth-Proxy in Ihrer Organisation/Umgebung auf Apigee Edge bereitzustellen. Wenn Sie diesen Schritt bereits ausgeführt haben, müssen Sie ihn nicht wiederholen.
Wenn Sie Edge Microgateway in Apigee Cloud bereitgestellt haben, müssen Sie mit dem Internet verbunden sein, damit Sie ein JWT von diesem Endpunkt abrufen können.
Beenden Sie Edge Microgateway:
```
edgemicro stop
```
Verweisen Sie in der zuvor erstellten Konfigurationsdatei ($HOME/.edgemicro/org-env-config.yaml) das Attribut extauth:publickey_url auf den Endpunkt edgemicro-auth/jwkPublicKeys in Ihrer Apigee Edge-Organisation/Umgebung. Beispiel:
```
extauth:
  publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
```
Starten Sie Edge Microgateway wie zuvor mit den Organisations-/Umgebungsnamen neu, die Sie im Namen der Konfigurationsdatei verwendet haben. Beispiel:
```
edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
Rufen Sie ein JWT-Token vom Autorisierungsendpunkt ab. Da Sie den Endpunkt edgemicro-auth/jwkPublicKeys verwenden, können Sie diesen Befehl über die Befehlszeile 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 müssen Sie eine Apigee-Organisation haben, in der Sie die standardmäßige Einrichtung und Konfiguration von Edge Microgateway durchgeführt haben. Nach diesem Schritt benötigen Sie keine Internetverbindung. Das Token funktioniert weiterhin im eigenständigen Modus, bis es abläuft.

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

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

Wobei:

your_org ist der Name Ihrer Apigee-Organisation, für die Sie zuvor Edge Microgateway konfiguriert haben.
your_env ist eine Umgebung in der Organisation.
Mit der Option i wird der Consumer Key einer Entwickler-App angegeben, deren Produkt den edgemicro-auth-Proxy enthält.
Mit der Option s wird das Consumer Secret aus einer Entwickler-App angegeben, deren Produkt den Proxy edgemicro-auth enthält.

Mit diesem Befehl wird Apigee Edge aufgefordert, ein JWT zu generieren, das dann zur Prüfung von API-Aufrufen verwendet werden kann.

Siehe auch Token generieren.

Eigenständige Konfiguration testen

Um die Konfiguration zu testen, rufen Sie die API mit dem Token im Autorisierungsheader wie folgt auf:

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

Beispiel:

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

Beispielausgabe:

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

Lokalen Proxymodus verwenden

Im lokalen Proxymodus muss für Edge Microgateway kein microgateway-sensitiver Proxy auf Apigee Edge bereitgestellt werden. Stattdessen konfigurieren Sie einen "lokalen Proxy", indem Sie beim Starten des Mikrogateways einen lokalen Proxynamen, einen Basispfad und eine Ziel-URL angeben. API-Aufrufe an das Mikrogateway werden dann an die Ziel-URL des lokalen Proxys gesendet. Davon abgesehen funktioniert der lokale Proxymodus genauso wie das Ausführen von Edge Microgateway im normalen Modus. Die Authentifizierung funktioniert genauso wie die Spitzen Arrest und Kontingenterzwingung, benutzerdefinierte Plug-ins usw.

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

Anwendungsfall und Beispiel

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

Edgemicro als Sidecar

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

Lokalen Proxymodus konfigurieren

Führen Sie die folgenden Schritte aus, um Edge Microgateway für die Ausführung im lokalen Proxymodus zu konfigurieren:

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 wie bei einem typischen Einrichtungsverfahren für Edge Microgateway aus. Beispiel:
```
edgemicro configure -o your_org -e your_env -u your_apigee_username
```
Dieser Befehl stellt die Richtlinie edgemicro-auth für Edge bereit und gibt einen Schlüssel und ein Secret zurück, die Sie zum Starten des Mikrogateways benötigen. Weitere Informationen finden Sie unter Edge Microgateway konfigurieren.
Erstellen Sie in Apigee Edge ein API-Produkt mit den folgenden obligatorischen Konfigurationsanforderungen (Sie können alle anderen Konfigurationen nach Bedarf verwalten):
- Sie müssen dem Produkt den Proxy edgemicro-auth hinzufügen. Dieser Proxy wurde bei Ausführung von edgemicro configure automatisch bereitgestellt.
- Sie müssen einen Ressourcenpfad angeben. Apigee empfiehlt, dem Produkt den folgenden Pfad hinzuzufügen: /**. Weitere Informationen finden Sie unter Verhalten des Ressourcenpfads konfigurieren. Siehe auch API-Produkte erstellen in der Edge-Dokumentation.
Erstellen Sie in Apigee Edge einen Entwickler oder verwenden Sie einen vorhandenen Entwickler, wenn Sie möchten. Weitere Informationen finden Sie unter Entwickler über die Edge-Management-Benutzeroberfläche hinzufügen.
Erstellen Sie in Apigee Edge eine Entwickler-App. Sie müssen das gerade erstellte API-Produkt zur Anwendung hinzufügen. Weitere Informationen finden Sie unter Eine App in der Edge-Verwaltungs-UI registrieren.
Exportieren Sie auf dem Computer, auf dem Edge Microgateway installiert ist, die folgende Umgebungsvariable mit dem Wert „1“.
```
export EDGEMICRO_LOCAL_PROXY=1
```
Führen Sie den folgenden start-Befehl aus:
```
edgemicro start -o your_org -e your_environment -k your_key -s your_secret \
    -a local_proxy_name -v local_proxy_version -t target_url -b base_path
```
Wobei:
- your_org ist Ihre Apigee-Organisation.
- your_environment ist eine Umgebung in Ihrer Organisation.
- your_key ist der Schlüssel, der bei der Ausführung von edgemicro configure zurückgegeben wurde.
- your_secret ist das Secret, das bei der Ausführung von edgemicro configure zurückgegeben wurde.
- local_proxy_name ist der Name des lokalen Proxys, der erstellt wird.
- local_proxy_version ist die Versionsnummer des Proxys.
- target_url ist die URL für das Ziel des Proxys (der Dienst, den der Proxy aufruft).
- base_path ist der Basispfad des Proxys. Dieser Wert muss mit einem Schrägstrich beginnen. Geben Sie für den Basispfad des Stammverzeichnisses nur einen Schrägstrich an, z. B. „/“.
Beispiel:
```
edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
  -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
  -t http://mocktarget.apigee.net -b /echo
```

Konfiguration testen

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

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

Dieser erste API-Aufruf hat einen Fehler erzeugt, da Sie keinen gültigen API-Schlüssel angegeben haben. Sie finden den Schlüssel in der Entwickler-App, die Sie zuvor erstellt haben. Öffnen Sie die App in der Edge-Benutzeroberfläche, kopieren Sie den Consumer-Key und verwenden Sie diesen Schlüssel so:

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

Beispiel:

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

Beispielausgabe:

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

Synchronisierer verwenden

In diesem Abschnitt wird erläutert, wie Sie den Synchronisierer verwenden, ein optionales Feature, das die Ausfallsicherheit von Edge Microgteway verbessert, indem es Konfigurationsdaten von Apigee Edge abrufen und in eine lokale Redis-Datenbank schreiben kann. 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 Syncrhonizer-Funktion wird derzeit für Redis 5.0.x unterstützt.

Was ist der Synchronisierer?

Der Synchronisierer bietet einen Grad an Ausfallsicherheit für Edge Microgateway. Sie sorgt dafür, dass jede Instanz von Edge Microgateway die gleiche Konfiguration verwendet und Edge Microgateway-Instanzen bei einer Internetunterbrechung ordnungsgemäß gestartet und ausgeführt werden können.

Standardmäßig müssen Edge Microgateway-Instanzen mit Apigee Edge kommunizieren können, um ihre Konfigurationsdaten wie API-Proxy- und API-Produktkonfigurationen abzurufen und zu aktualisieren. Wenn die Internetverbindung mit Edge unterbrochen wird, können Microgateway-Instanzen weiterhin funktionieren, da die neuesten Konfigurationsdaten im Cache gespeichert werden. Neue Mikrogateway-Instanzen können jedoch nicht ohne eine stabile Verbindung gestartet werden. Darüber hinaus kann es bei einer Internetstörung zur Folge haben, dass eine oder mehrere Mikrogateway-Instanzen mit Konfigurationsinformationen ausgeführt werden, die nicht mit anderen Instanzen synchron sind.

Der Edge Microgateway-Synchronisierer bietet einen alternativen Mechanismus für Edge Microgateway-Instanzen, um Konfigurationsdaten abzurufen, die sie zum Starten und Verarbeiten des API-Proxy-Traffics benötigen. Zu den Konfigurationsdaten, die von Aufrufen an Apigee Edge abgerufen werden, gehören: der jwk_public_keys-Aufruf, der jwt_public_key-Aufruf, der Bootstrap-Aufruf und der API-Produktaufruf. Der Synchronisierer ermöglicht es allen Edge Microgateway-Instanzen, die auf verschiedenen Knoten ausgeführt werden, ordnungsgemäß zu starten und synchron zu bleiben, auch wenn die Internetverbindung zwischen Edge Microgateway und Apigee Edge unterbrochen ist.

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

Synchroner-Instanz konfigurieren

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

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

Beispiel:

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

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

Sie können die Umgebungsvariable EDGEMICRO_REDIS_PASSWORD verwenden, um den Parameter edgemicro.redisPassword zu überschreiben. Weitere Informationen finden Sie unter Konfigurationsattribute mit Werten für Umgebungsvariablen festlegen.

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

Reguläre Edge Microgateway-Instanzen konfigurieren

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

Fügen Sie der Datei org-env/config.yaml jedes zusätzlichen Edge Microgateway-Knotens die folgende Konfiguration hinzu. Beachten Sie, dass das Attribut synchronizerMode auf 0 festgelegt ist. Dieses Attribut legt fest, dass die Instanz als normale Edge Microgateway-Instanz betrieben wird, die API-Proxy-Traffic verarbeitet. Die Instanz erhält ihre Konfigurationsdaten von der Redis-Datenbank.

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

Beispiel:

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

Konfigurationsattribute

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

Attribut Werte Beschreibung

Attribut	Werte	Beschreibung
`edge_config.synchronizerMode`	0 oder 1	Wenn 0 (Standardeinstellung) ist, wird Edge Microgateway im Standardmodus ausgeführt. Wenn 1, starten Sie die Edge Microgateway-Instanz, um als Synchronisierung zu arbeiten. In diesem Modus ruft die Instanz Konfigurationsdaten von Apigee Edge ab und speichert sie in einer lokalen Redis-Datenbank. Diese Instanz kann keine API-Proxy-Anfragen verarbeiten. Sie dient lediglich dazu, Konfigurationsdaten von Apigee Edge abzufragen und in die lokale Datenbank zu schreiben. Anschließend müssen Sie andere Mikrogateway-Instanzen so konfigurieren, dass sie aus der Datenbank lesen.
`edge_config.redisBasedConfigCache`	True oder false?	Bei „true“ ruft die Edge Microgateway-Instanz ihre Konfigurationsdaten aus der Redis-Datenbank und nicht von Apigee Edge ab. Die Redis-Datenbank muss mit derjenigen übereinstimmen, in der der Synchronisierer für Schreibvorgänge konfiguriert ist. Wenn die Redis-Datenbank nicht verfügbar oder leer ist, sucht das Mikrogateway nach einer vorhandenen `cache-config.yaml`-Datei für ihre Konfiguration. Bei „false“ (Standardeinstellung) ruft die Edge Microgateway-Instanz wie gewohnt Konfigurationsdaten von Apigee Edge ab.
`edgemicro.config_change_poll_interval`	Zeitintervall in Sekunden	Gibt das Abfrageintervall für den Synchronisierer an, um Daten aus Apigee Edge abzurufen.

edge_config.synchronizerMode

0 oder 1

Wenn 0 (Standardeinstellung) ist, wird Edge Microgateway im Standardmodus ausgeführt.

Wenn 1, starten Sie die Edge Microgateway-Instanz, um als Synchronisierung zu arbeiten. In diesem Modus ruft die Instanz Konfigurationsdaten von Apigee Edge ab und speichert sie in einer lokalen Redis-Datenbank. Diese Instanz kann keine API-Proxy-Anfragen verarbeiten. Sie dient lediglich dazu, Konfigurationsdaten von Apigee Edge abzufragen und in die lokale Datenbank zu schreiben. Anschließend müssen Sie andere Mikrogateway-Instanzen so konfigurieren, dass sie aus der Datenbank lesen.

edge_config.redisBasedConfigCache

True oder false?

Bei „true“ ruft die Edge Microgateway-Instanz ihre Konfigurationsdaten aus der Redis-Datenbank und nicht von Apigee Edge ab. Die Redis-Datenbank muss mit derjenigen übereinstimmen, in der der Synchronisierer für Schreibvorgänge konfiguriert ist. Wenn die Redis-Datenbank nicht verfügbar oder leer ist, sucht das Mikrogateway nach einer vorhandenen cache-config.yaml-Datei für ihre Konfiguration.

Bei „false“ (Standardeinstellung) ruft die Edge Microgateway-Instanz wie gewohnt Konfigurationsdaten von Apigee Edge ab.

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

Auszuschließende URLs für Plug-ins konfigurieren

Sie können das Mikrogateway so konfigurieren, dass die Verarbeitung von Plug-ins für bestimmte URLs übersprungen wird. Sie können diese „ausschließenden“ URLs global (für alle Plug-ins) oder für bestimmte Plug-ins konfigurieren.

Beispiel:

...
edgemicro:
  ...
  plugins:
    excludeUrls: '/hello,/proxy_one' # global exclude urls
    sequence:
      - oauth
      - json2xml
      - quota
json2xml:
  excludeUrls: '/hello/xml'  # plugin level exclude urls
...

In diesem Beispiel verarbeiten Plug-ins keine eingehenden API-Proxy-Aufrufe mit den Pfaden /hello oder /proxy_one. Außerdem wird das json2xml-Plug-in bei APIs mit /hello/xml im Pfad übersprungen.

Das Plug-in analytics kann nicht ausgeschlossen werden.

Konfigurationsattribute mit Werten für Umgebungsvariablen festlegen

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

Hinweis : Standardmäßig parst das Tag <E> Variablenwerte als Strings. Wenn du positive ganzzahlige und boolesche Werte angeben möchtest, verwende die inneren <n>- und <b>-Tags, wie in den folgenden Beispielen veranschaulicht.

Hinweis: Das Umgebungsvariablen-Tag wird für die folgenden Konfigurationsattribute nicht unterstützt:

edge_config:
  bootstrap:
  authUri:
  baseUri:

In diesem Beispiel wird das Attribut key durch den Wert der Umgebungsvariablen TARGETS_SSL_CLIENT_KEY ersetzt usw.

targets:
  - ssl:
      client:
        key: <E>TARGETS_SSL_CLIENT_KEY</E>
        cert: <E>TARGETS_SSL_CLIENT_CERT</E>
        passphrase: <E>TARGETS_SSL_CLIENT_PASSPHRASE</E>

In diesem Beispiel wird das Tag <n> verwendet, um einen ganzzahligen Wert anzugeben. Es werden nur positive Ganzzahlen unterstützt.

edgemicro:
  port: <E><n>EMG_PORT</n></E>

In diesem Beispiel wird mit dem Tag <b> ein boolescher Wert (wahr oder falsch) angegeben.

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