Diese Seite wurde von der Cloud Translation API übersetzt.

Vorgangs- und Konfigurationsreferenz für Edge Microgateway

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Edge Microgateway Version 3.2.x

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

Edge Microgateway aktualisieren, wenn Sie eine Internetverbindung haben

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

Apigee empfiehlt, Ihre vorhandene Konfiguration mit die neue Version vor dem Upgrade der Produktionsumgebung.

Führen Sie den folgenden npm-Befehl aus, um ein Upgrade auf die neueste Version von Edge durchzuführen Microgateway:
```
npm upgrade edgemicro -g
```
Um eine bestimmte Version von Edge Microgateway zu installieren, müssen Sie die Version Nummer im Installationsbefehl ein. Für die Installation auf Version 3.2.3 verwenden Sie beispielsweise folgenden Befehl:
```
npm install edgemicro@3.2.3 -g
```

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

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

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

Konfigurationsänderungen vornehmen

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

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

In diesem Abschnitt werden diese Dateien erläutert und Sie erfahren, was Sie wissen müssen, wenn Sie sie ändern.

Standardsystemkonfiguration Datei

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. Weitere Informationen finden Sie unter . Wo ist Edge Microgateway installiert, wenn Sie dieses Verzeichnis nicht finden können.

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

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

Standardkonfigurationsdatei für neu initialisierte Edge Microgateway-Instanzen

Wenn Sie edgemicro init ausführen, ist die Systemkonfigurationsdatei oben), default.yaml, im Verzeichnis ~/.edgemicro platziert.

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

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

Dynamisch Konfigurationsdatei für ausgeführte Instanzen

Wenn Sie edgemicro configure [params] ausführen, wird eine dynamische Konfigurationsdatei wird in ~/.edgemicro erstellt. Der Name der Datei lautet Muster: org-env-config.yaml, wobei org und env sind Ihre Apigee Edge-Organisation und Ihre Umgebungsnamen. Sie können diese Datei zur Konfiguration und sie anschließend ohne Ausfallzeit neu laden. Wenn Sie beispielsweise ein Plug-in hinzufügen und konfigurieren, können Sie die Konfiguration aktualisieren, ohne dass es zu Ausfallzeiten kommt, wie unten erläutert.

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

Aktualisieren Sie die Edge Microgateway-Konfiguration:
```
edgemicro reload -o $ORG -e $ENV -k $KEY -s $SECRET
```
Wobei:
- $ORG ist der Name Ihrer Edge-Organisation (Sie müssen eine Organisation sein) Administrator).
- $ENV ist eine Umgebung in Ihrer Organisation, z. B. „test“ oder „prod“).
- $KEY ist der zuvor vom Befehl „configure“ zurückgegebene Schlüssel.
- $SECRET ist der zuvor vom Befehl „configure“ zurückgegebene Schlüssel.
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 eine Organisation sein) Administrator).
- $ENV ist eine Umgebung in Ihrer Organisation, z. B. „test“ oder „prod“).
- $KEY ist der zuvor vom Befehl „configure“ zurückgegebene Schlüssel.
- $SECRET ist der zuvor vom Befehl „configure“ zurückgegebene Schlüssel.
Beispiel:
```
edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \
  -s 05c1435...e34ab0cc824
```

Hier ist eine Beispielkonfigurationsdatei. Weitere Informationen zu den Einstellungen von Konfigurationsdateien 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 und der Schlüssel und das Secret, die zum Starten von Edge Microgateway erforderlich sind, in diesen Umgebungsvariablen:

EDGEMICRO_ORG
EDGEMICRO_ENV
EDGEMICRO_KEY
EDGEMICRO_SECRET

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

SSL auf dem Edge Microgateway konfigurieren Server

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

Video	Beschreibung
1-Wege-TLS nach Norden konfigurieren	Informationen zum Konfigurieren von TLS in Apigee Edge Microgateway. Dieses Video bietet einen Überblick über TLS und seine Bedeutung sowie eine Einführung in TLS. in Edge Microgateway und zeigt, wie Northbound One-Way TLS konfiguriert wird.
Zwei-Wege-TLS mit Nordausrichtung konfigurieren	Dies ist das zweite Video zum Konfigurieren von TLS in Apigee Edge Microgateway. Dieses erfahren Sie, wie Sie eine 2-Wege-TLS-Verbindung nach Norden konfigurieren.
Ein- und Zwei-Wege-TLS mit Südausrichtung konfigurieren	In diesem dritten Video zum Konfigurieren von TLS in Apigee Edge Microgateway erfahren Sie, wie Sie das 1- und 2-Wege-TLS konfigurieren.

Sie können den Microgateway-Server für die Verwendung von SSL konfigurieren. Wenn SSL beispielsweise konfiguriert ist, kann APIs über Edge Microgateway mit dem wie hier gezeigt:

https://localhost:8000/myapi

So konfigurieren Sie SSL auf dem Microgateway-Server:

Generieren oder erhalten Sie ein SSL-Zertifikat und den Schlüssel mit dem Dienstprogramm openssl oder einer anderen Methode.

Fügen Sie der Edge Microgateway-Konfigurationsdatei das Attribut edgemicro:ssl hinzu. Eine vollständige finden Sie in der Tabelle unten. Beispiel:

edgemicro:
  ssl:
   key: <absolute path to the SSL key file>
   cert: <absolute path to the SSL cert file>
   passphrase: admin123 #option added in v2.2.2
   rejectUnauthorized: true #option added in v2.2.2
   requestCert: true

Starten Sie Edge Microgateway neu. Befolgen Sie die Schritte in Konfigurationsänderungen vornehmen, je nachdem, Konfigurationsdatei, die Sie bearbeitet haben: die Standarddatei oder die Laufzeit-Konfigurationsdatei.

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

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

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

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 enthält des Clients im PFX-Format.
`passphrase`	Ein String mit der Passphrase für den privaten Schlüssel oder PFX.
`ca`	Pfad zu einer Datei, die eine Liste vertrauenswürdiger Zertifikate im PEM-Format enthält.
`ciphers`	Ein String, der die zu verwendenden Chiffren beschreibt, getrennt durch ":".
`rejectUnauthorized`	Falls wahr, wird das Serverzertifikat mit der Liste der bereitgestellten Zertifizierungsstellen abgeglichen. Wenn die Bestätigung fehlschlägt, wird ein Fehler zurückgegeben.
`secureProtocol`	Die zu verwendende SSL-Methode. Beispielsweise SSLv3_method, um SSL auf Version 3 zu erzwingen.
`servername`	Servername für die TLS-Erweiterung SNI (Server Name Indication).
`requestCert`	"true" für Zwei-Wege-SSL; "false" für 1-Wege-SSL

Client-SSL/TLS-Optionen verwenden

Sie können Edge Microgateway beim Herstellen einer Verbindung zum Ziel als TLS- oder SSL-Client konfigurieren Endpunkten. Verwenden Sie in der Microgateway-Konfigurationsdatei das Element "targets", um SSL/TLS festzulegen. Optionen. Sie können mehrere spezifische Ziele angeben. Ein Beispiel für mehrere Ziele ist enthalten 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 ist 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 spezifische Ziele anwenden möchten, müssen Sie den ersten Host in der Konfiguration als „leer“, wodurch universelle Anfragen aktiviert und dann bestimmte und zwar in beliebiger Reihenfolge. In diesem Beispiel werden die Einstellungen auf mehrere bestimmte Hosts angewendet:

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

Hier ist 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 enthält des Clients im PFX-Format.
`key`	Pfad zu einer `ca.key`-Datei im PEM-Format.
`passphrase`	Ein String mit der Passphrase für den privaten Schlüssel oder PFX.
`cert`	Pfad zu einer `ca.cert`-Datei im PEM-Format.
`ca`	Pfad zu einer Datei, die eine Liste vertrauenswürdiger Zertifikate im PEM-Format enthält.
`ciphers`	Ein String, der die zu verwendenden Chiffren beschreibt, getrennt durch ":".
`rejectUnauthorized`	Falls wahr, wird das Serverzertifikat mit der Liste der bereitgestellten Zertifizierungsstellen abgeglichen. Wenn die Bestätigung fehlschlägt, wird ein Fehler zurückgegeben.
`secureProtocol`	Die zu verwendende SSL-Methode. Beispielsweise SSLv3_method, um SSL auf Version 3 zu erzwingen.
`servername`	Servername für die TLS-Erweiterung SNI (Server Name Indication).

Edgemicro-auth-Proxy anpassen

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

Benutzerdefinierten Authentifizierungsdienst verwenden

Standardmäßig verwendet Edge Microgateway für die OAuth2-Authentifizierung einen Proxy, der auf Apigee Edge bereitgestellt ist. Dieser Proxy wird bereitgestellt, wenn Sie edgemicro configure zum ersten Mal ausführen. Standardmäßig Die URL des Proxys wird in der Edge Microgateway-Konfigurationsdatei so angegeben:

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

Wenn Sie Ihren eigenen benutzerdefinierten Dienst für die Authentifizierung verwenden möchten, ändern Sie den authUri-Wert in der Konfigurationsdatei, um auf Ihren Dienst zu verweisen. Zum Beispiel haben Sie möglicherweise ein Dienst, der LDAP zur Identitätsüberprüfung verwendet.

Wichtig:Wenn Sie die Standardauthentifizierung überschreiben Proxy verwenden, muss der neue Proxy oder Dienst ein Antwortformat zurückgeben, das dem Standardwert edgemicro-auth-Proxy

Protokolldateien verwalten

Edge Microgateway protokolliert Informationen über jede Anfrage und Antwort. Protokolldateien bieten nützliche Informationen zur Fehlerbehebung.

Wo werden Protokolldateien gespeichert?

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

So ändern Sie das Standardprotokoll Dateiverzeichnis

Das Verzeichnis, in dem die Protokolldateien gespeichert sind, wird in der Edge Microgateway-Konfiguration angegeben -Datei. Siehe auch Konfiguration vornehmen Änderungen.

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

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

Protokolle an die Konsole senden

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

edgemicro:
  logging:
    to_console: true

Bei dieser Einstellung werden Logs an den Standard-Ausgang gesendet. Derzeit können Sie Logs nicht an beide senden stdout und in eine Protokolldatei.

Logging-Ebene festlegen

Sie geben die Logebene an, die in der edgemicro-Konfiguration verwendet werden soll. Für 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. Weitere Informationen finden Sie unter Konfigurationsänderungen vornehmen.

Folgende konfigurierbare Attribute sind verfügbar:

stats_log_interval: (Standard: 60) Intervall in Sekunden, wenn die Statistiken wird in die API-Protokolldatei geschrieben.
rotate_interval: (Standard: 24) Intervall in Stunden, in dem die Protokolldateien gespeichert werden gedreht. Beispiel:

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

Strenge Berechtigungen für Logdateien lockern

Standardmäßig generiert Edge Microgateway die Anwendungsprotokolldatei (api-log.log) mit der Dateiberechtigung auf 0600 eingestellt ist. Mit dieser Berechtigungsstufe sind keine externen Anwendungen oder Nutzer erlaubt um die Protokolldatei zu lesen. Zum Lockern dieser strengen Berechtigungsstufe logging:disableStrictLogFile festlegen an true. Wenn dieses Attribut den Wert true hat, wird die Logdatei mit die Dateiberechtigung auf 0755 eingestellt ist. Wenn false oder das Attribut nicht angegeben ist, wird die Berechtigung standardmäßig auf 0600 festgelegt.

In Version 3.2.3 hinzugefügt.

Beispiel:

edgemicro:
 logging:
   disableStrictLogFile: true

Gute Vorgehensweisen bei der Wartung von Logdateien

Da sich Protokolldatei-Daten im Laufe der Zeit ansammeln, empfiehlt Apigee die folgende Vorgehensweise: Best Practices:

Da Protokolldateien sehr groß werden können, sollten Sie sicherstellen, dass das Protokolldateiverzeichnis ausreichend Speicherplatz. Weitere Informationen finden Sie in den folgenden Abschnitten Speicherort der Protokolldateien und So ändern Sie die Standardprotokolldatei. -Verzeichnis.
Löschen oder verschieben Sie Protokolldateien mindestens einmal pro Woche in ein separates Archivverzeichnis.
Wenn Sie Logs löschen möchten, können Sie den Befehl edgemicro log -c über die Befehlszeile verwenden. um ältere Logs zu entfernen (bereinigt).

Namenskonvention für Protokolldateien

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

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 die JSON-Daten heruntergeladener Proxys, Produkte und JSON-Dateien weg. Webtoken (JWT). Wenn Sie diese Objekte an die Konsole ausgeben möchten, setzen Sie das Befehlszeilen-Flag DEBUG=*, wenn Sie Edge Microgateway starten. Beispiel:

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

Unter Windows SET DEBUG=* verwenden

Inhalt von „api“ Protokolldatei

Die API Protokolldatei enthält detaillierte Informationen zum Fluss von Anfragen und Antworten. über Edge Microgateway. Die API Protokolldateien haben den folgenden Namen:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Für jede Anfrage an Edge Microgateway werden vier Ereignisse in der „API“ erfasst Protokoll Datei:

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

Jeder dieser Einträge wird in Kurzschreibweise dargestellt, damit das Protokoll Dateien kompakter sein. Hier sind vier Beispieleinträge, die jedes der vier Ereignisse darstellen. Im Protokoll Datei sehen, sehen sie so aus (die Zeilennummern dienen nur als Referenz im Dokument, sie werden nicht in der Protokolldatei).

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

Sehen wir sie uns im Einzelnen an:

1. Beispiel für eine 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 festgelegten Logging-Ebene ab in der edgemicro-Konfiguration. Siehe Logging-Ebene festlegen. Für Statistikeinträge ist der Wert auf stats festgelegt. Statistikeinträge werden gemeldet unter Ein reguläres Intervall, das mit der stats_log_interval-Konfiguration festgelegt wurde. Weitere Informationen finden Sie unter Logintervalle ändern.
req: Kennzeichnet das Ereignis. In diesem Fall muss die Anfrage vom Client.
m – Das in der Anfrage verwendete HTTP-Verb.
u – Der Teil der URL nach dem Basispfad.
h – Die Host- und Portnummer für das Edge Microgateway. Zuhören.
r – Remote-Host und Port, an den der Client anfordert entstand.
i – Die Anfrage-ID. Alle vier Ereigniseinträge haben dieselbe ID. Jedes -Anfrage eine eindeutige Anfrage-ID zugewiesen. Das Korrelieren von Protokolleinträgen nach Anfrage-ID kann wertvolle Einblicke in die Latenz des Ziels.
d – Dauer in Millisekunden seit dem Empfang der Anfrage durch Edge Microgateway. Im obigen Beispiel ist die Antwort des Ziels auf Anfrage 0 eingegangen nach 7 Millisekunden (Zeile 3) und die Antwort wurde nach weiteren 4 Millisekunden (Zeile 4). Mit anderen Worten, die gesamte Anfragelatenz betrug 11 Millisekunden, welche 7 Millisekunden vom Ziel und 4 Millisekunden vom Edge Microgateway erfasst wurden selbst.

2. Beispiel einer ausgehenden 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 festgelegten Logging-Ebene ab in der edgemicro-Konfiguration. Siehe Logging-Ebene festlegen. Für Statistikeinträge ist der Wert auf stats festgelegt. Statistikeinträge werden gemeldet unter Ein reguläres Intervall, das mit der stats_log_interval-Konfiguration festgelegt wurde. Weitere Informationen finden Sie unter Logintervalle ändern.
treq: Kennzeichnet das Ereignis. In diesem Fall ist dies die Zielanfrage.
m – HTTP-Verb, das in der Zielanfrage verwendet wird.
u – Der Teil der URL nach dem Basispfad.
h – Host und Portnummer des Back-End-Ziels.
i – Die ID des Logeintrags. Diese wird für alle vier Veranstaltungseinträge freigegeben. ID.

3. Beispiel einer eingehenden Antwort des Ziels

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 festgelegten Logging-Ebene ab in der edgemicro-Konfiguration. Siehe Logging-Ebene festlegen. Für Statistikeinträge ist der Wert auf stats festgelegt. Statistikeinträge werden gemeldet unter Ein reguläres Intervall, das mit der stats_log_interval-Konfiguration festgelegt wurde. Weitere Informationen finden Sie unter Logintervalle ändern.
tres: Kennzeichnet das Ereignis. in diesem Fall die Zielantwort.
s – HTTP-Antwortstatus.
d – Dauer in Millisekunden Die für den API-Aufruf vom das Ziel zu erreichen.
i – Die ID des Logeintrags. Diese wird für alle vier Veranstaltungseinträge freigegeben. ID.

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

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 festgelegten Logging-Ebene ab in der edgemicro-Konfiguration. Siehe Logging-Ebene festlegen. Für Statistikeinträge ist der Wert auf stats festgelegt. Statistikeinträge werden gemeldet unter Ein reguläres Intervall, das mit der stats_log_interval-Konfiguration festgelegt wurde. Weitere Informationen finden Sie unter Logintervalle ändern.
res: Kennzeichnet das Ereignis. In diesem Fall wird die Antwort auf die Client.
s – HTTP-Antwortstatus.
d – Dauer in Millisekunden Dies ist die Gesamtzeit, die durch den API-Aufruf, einschließlich der von der Ziel-API verbrauchten Zeit und der von Edge benötigten Zeit Microgateway selbst.
i – Die ID des Logeintrags. Diese wird für alle vier Veranstaltungseinträge freigegeben. ID.

Zeitplan für Logdateien

Die Protokolldateien werden in dem durch rotate_interval angegebenen Intervall rotiert. Konfigurationsattribut. Die Einträge werden weiterhin dem bis das Rotationsintervall abläuft. Jedes Mal, wenn Edge Microgateway erhält er eine neue UID und erstellt einen neuen Satz von Protokolldateien mit dieser UID. Siehe auch Gute Pflege der Protokolldateien .

Fehlermeldungen

Einige Logeinträge enthalten Fehlermeldungen. Um zu ermitteln, wo und warum die Fehler auftreten, sehen Sie sich den Edge Microgateway-Fehler Referenz.

Edge Microgateway-Konfigurationsreferenz

Standort des Konfigurationsdatei

Die in diesem Abschnitt beschriebenen Konfigurationsattribute befinden sich im Edge Microgateway. Konfigurationsdatei. Siehe auch Konfiguration vornehmen Änderungen.

Edge_config-Attribute

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

bootstrap: (Standardeinstellung: keine) Eine URL, die auf einen Edge verweist. Microgateway-spezifischer Dienst, der auf Apigee Edge ausgeführt wird. Edge Microgateway verwendet diesen Dienst, um mit Apigee Edge kommunizieren können. Diese URL wird zurückgegeben, wenn Sie den Befehl zum Generieren des Paar aus öffentlichem/privatem Schlüssel: edgemicro genkeys. Weitere Informationen finden Sie im Abschnitt Einrichtung und Edge Microgateway konfigurieren.
jwt_public_key: (Standardeinstellung: none) Eine URL, die auf das Edge Microgateway verweist Proxy, der in Apigee Edge bereitgestellt wird. Dieser Proxy dient als Authentifizierungsendpunkt für Ausstellen signierter Zugriffstokens an Clients Diese URL wird zurückgegeben, wenn Sie den Befehl für Stellen Sie den Proxy edgemicro configure bereit. Weitere Informationen finden Sie im Abschnitt Einrichtung und Edge Microgateway konfigurieren.
quotaUri: Diese Konfiguration festlegen Property, wenn Sie Kontingente über den edgemicro-auth-Proxy verwalten möchten, der die in Ihrer Organisation bereitgestellt wurden. Wenn diese Eigenschaft nicht festgelegt ist, ist der Kontingentendpunkt standardmäßig der interne Edge Microgateway-Endpunkt.
```
edge_config:
  quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
```

Edgemicro-Attribute

Mit diesen Einstellungen wird der Edge Microgateway-Prozess konfiguriert.

port: (Standard: 8000) Die Portnummer, auf der das Edge Microgateway verwendet wird. Prozessüberwachung.
max_connections: (Standard: -1) Gibt die maximale Anzahl von Verbindungen an gleichzeitig eingehende Verbindungen, die Edge Microgateway empfangen kann. Wenn diese Nummer gleich wird der folgende Status zurückgegeben:

res.statusCode = 429; // Too many requests
max_connections_hard: (Standard: -1) Die maximale Anzahl gleichzeitiger Verbindungen. Anforderungen, die Edge Microgateway empfangen kann, bevor die Verbindung unterbrochen wird. Diese Einstellung soll Denial-of-Service-Angriffe verhindern. Legen Sie dafür eine Zahl fest, die größer als max_connections.
logging: <ph type="x-smartling-placeholder">
- level: (Standard: Fehler) <ph type="x-smartling-placeholder">
  - Info (empfohlen): Protokolliert alle Anfragen und Antworten, die durch eine Edge Microgateway-Instanz
  - 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 sich die Protokolldateien befinden. gespeichert sind.
- stats_log_interval: (Standard: 60) Intervall in Sekunden, wenn die Statistiken wird in die API-Protokolldatei geschrieben.
- rotate_interval: (Standard: 24) Intervall in Stunden, in dem die Protokolldateien gespeichert werden gedreht.

plugins: Plug-ins bieten Edge Microgateway Funktionen. Weitere Informationen Informationen zur Entwicklung von Plug-ins finden Sie unter Benutzerdefinierte Plug-ins entwickeln.

dir: Ein relativer Pfad vom ./gateway-Verzeichnis zum ./plugins-Verzeichnis oder einen absoluten Pfad angeben.
Sequenz: Eine Liste der Plug-in-Module, die dem Edge Microgateway hinzugefügt werden Instanz. Die Module werden in der hier angegebenen Reihenfolge ausgeführt.

debug: Fügt dem Edge Microgateway-Prozess das Remote-Debugging hinzu.
- port: Die Portnummer, die überwacht werden soll. Richten Sie beispielsweise Ihren IDE-Debugger ein. um diesen Port zu überwachen.
- args: Argumente für den Debug-Prozess. Beispiel: args --nolazy
config_change_poll_interval: (Standard: 600 Sekunden) Edge Microgateway lädt regelmäßig eine neue Konfiguration und führt eine Aktualisierung durch, falls sich etwas geändert hat. Das Polling erfasst alle in Edge vorgenommenen Änderungen (Änderungen an Produkten, Microgateway-fähigen Proxys usw.) sowie Änderungen an der lokalen Konfigurationsdatei.
disable_config_poll_interval: (Standard: „false“), festgelegt auf true, um das automatische Änderungsabfrage zu deaktivieren.
request_timeout: Legt ein Zeitlimit für Zielanfragen fest. Das Zeitlimit wird eingestellt in Sekunden. Wenn eine Zeitüberschreitung auftritt, antwortet Edge Microgateway mit dem Statuscode 504. (Hinzugefügt v2.4.x)
keep_alive_timeout: Mit dieser Eigenschaft können Sie das Edge Microgateway festlegen. Timeout (in Millisekunden). (Standardeinstellung: 5 Sekunden) (Hinzugefügt v3.0.6)
headers_timeout: Dieses Attribut begrenzt den Zeitraum (in Millisekunden). wartet der HTTP-Parser auf den Empfang des vollständige HTTP-Header.
Beispiel:
```
edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000
```
Der Parameter legt intern die Node.js-Datei fest. Server.headersTimeout bei Anfragen ändern. (Standardeinstellung: 5 Sekunden länger als die mit edgemicro.keep_alive_timeout festgelegte Zeit. Diese Standardeinstellung verhindert, dass Load-Balancer oder Proxys die Verbindung fälschlicherweise unterbrechen.) (Hinzugefügt v3.1.1)
noRuleMatchAction: (String) Die auszuführende Aktion (Zugriff erlauben oder ablehnen), wenn die Die im Plug-in accesscontrol angegebene Übereinstimmungsregel wird nicht aufgelöst (keine Übereinstimmung). Gültige Werte: ALLOW oder DENY Standard: ALLOW (Hinzugefügt: v3.1.7)
enableAnalytics:: (Standardeinstellung: true) Setzen Sie das Attribut auf enableAnalytics:, um um das Analyse-Plug-in zu verhindern, geladen werden kann. In diesem Fall werden keine Apigee Edge-Analysen aufgerufen. Wenn dieser Wert auf true gesetzt ist oder wenn nicht angegeben ist, funktioniert das Analyse-Plug-in wie gewohnt. Weitere Informationen finden Sie unter edgemicro-Attribute für Details. (Version 3.1.8 hinzugefügt).
Beispiel:
```
edgemicro
  enableAnalytics=false|true
```
Wenn enableAnalytics auf false gesetzt ist, aber Edge mit dem Messwert-Plug-in gestartet, dann funktioniert das Analyse-Plug-in wie gewohnt. da das Messwert-Plug-in ein Analyse-Plug-in benötigt. Informationen zu Das Messwert-Plug-in finden Sie unter Edge Microgateway v1.3.6 Versionshinweise.

on_target_response_abort: Mit diesem Attribut steuern Sie, wie sich Edge Microgateway verhält, wenn die Verbindung zwischen dem Client (Edge Microgateway) und dem der Zielserver vorzeitig geschlossen wird.

Wert	Beschreibung
Standard	Wenn `on_target_response_abort` nicht angegeben ist, gilt das Standardverhalten die Antwort zu kürzen, ohne einen Fehler anzuzeigen. In den Protokolldateien wird eine Warnung wird mit `targetResponse aborted` und dem Antwortcode 502 angezeigt.
`appendErrorToClientResponseBody`	Der benutzerdefinierte Fehler `TargetResponseAborted` wird an den Client. In den Protokolldateien wird eine Warnung wird mit `targetResponse aborted` und dem Antwortcode 502 angezeigt. In Außerdem wird der Fehler `TargetResponseAborted` mit der Meldung `Target response ended prematurely.`
`abortClientRequest`	Edge Microgateway bricht die Anfrage ab und eine Warnung wird in die Protokolldateien geschrieben: `TargetResponseAborted` durch den Statuscode 502.

Beispiel:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

Headerattribute

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

x-forwarded-for: (Standardeinstellung: true) Auf „false“ setzen, um zu verhindern x-forwarded-for-Header, die an das Ziel übergeben werden sollen. Wenn ein x-forwarded-for-Header sich in der Anfrage befindet, wird sein Wert auf den Wert der Client-IP in Edge Analytics festgelegt.
x-forwarded-host: (Standardeinstellung: true) Auf „false“ setzen, um zu verhindern x-forwarded-host-Header, die an das Ziel übergeben werden sollen.
x-request-id: (Standard: true) Auf „false“ setzen, um zu verhindern x-request-id-Header, die an das Ziel übergeben werden sollen.
x-response-time: (Standard: true) Auf „false“ setzen, um zu verhindern x-response-time-Header, die an das Ziel übergeben werden sollen.
via: (Standard: true) Auf „false“ setzen, um zu verhindern, dass Via-Header in an das Ziel übergeben wird.

OAuth-Attribute

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

allowNoAuthorization (Standardeinstellung: false) Wenn die Richtlinie auf „true“ gesetzt ist, werden API-Aufrufe Edge Microgateway ohne Autorisierungsheader passieren darf. Setzen auf false, um einen Autorisierungsheader anzufordern (Standardeinstellung).
allowInvalidAuthorization: (Standardeinstellung: false) Wenn die Richtlinie auf „true“ gesetzt ist, werden API-Aufrufe übergeben werden, wenn das im Autorisierungsheader übergebene Token ungültig oder abgelaufen ist. Festlegen auf „false“, um gültige Tokens anzufordern (Standardeinstellung).
authorization-header: (Standard: Authorization: Bearer) Dieser Header wird verwendet, um das Zugriffstoken an Edge Microgateway senden. Sie können die Standardeinstellung ändern, Das Ziel muss den Autorisierungsheader für einen anderen Zweck verwenden.
api-key-header: (Standard: x-api-key) Name des Headers oder der Abfrage Parameter zum Übergeben eines API-Schlüssels an Edge Microgateway. Siehe auch Verwendung von API-Schlüssel
keep-authorization-header: (Standard: false) Wenn der Wert auf „true“ gesetzt ist, wird der Autorisierungsheader die in der Anfrage gesendet wurden, an das Ziel übergeben (wird beibehalten).
allowOAuthOnly: Wenn die Richtlinie auf "true" gesetzt ist, muss jede API eine Autorisierung enthalten. mit einem Bearer Access Token. Sie können festlegen, dass nur das OAuth-Sicherheitsmodell Aufrechterhaltung der Abwärtskompatibilität). (Hinzugefügt 2.4.x)
allowAPIKeyOnly: Wenn die Richtlinie auf "true" gesetzt ist, muss jede API einen x-api-key (oder einen benutzerdefinierten Speicherort) mit einem API-Schlüssel.Erlaubt Ihnen, nur das Sicherheitsmodell des API-Schlüssels (unter Aufrechterhaltung der Abwärtskompatibilität). (Hinzugefügt 2.4.x)
Legen Sie nicht sowohl allowOAuthOnly als auch allowAPIKeyOnly auf "true" gesetzt. Standardmäßig sind beide Flags auf „false“ gesetzt. (für Abwärtskompatibilität).
gracePeriod: Dieser Parameter verhindert Fehler aufgrund geringfügiger Abweichungen zwischen Ihrer Systemuhr und den Zeiten für „Nicht vor“ (nbf) oder „Ausgestellt um“ (iat) das im JWT-Autorisierungstoken angegeben ist. Legen Sie für diesen Parameter die zulässige Anzahl von Sekunden fest auf solche Abweichungen hin. (Hinzugefügt 2.5.7)

Plug-in-spezifisch Attribute

Einzelheiten zu den konfigurierbaren Attributen für die einzelnen Plug-ins finden Sie unter Plug-ins verwenden.

Proxys filtern

Sie können filtern, welche Microgateway-fähigen Proxys eine Edge Microgateway-Instanz verarbeitet. Beim Start von Edge Microgateway werden alle Microgateway-fähigen Proxys im Organisation zugeordnet ist. Verwenden Sie die folgende Konfiguration, um einzuschränken, welche Proxys den Microgateway verarbeitet. Diese Konfiguration schränkt beispielsweise die Proxys des Microgateways ein werden auf drei Elemente verarbeitet: edgemicro_proxy-1, edgemicro_proxy-2, und edgemicro_proxy-3:

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

Produkte nach Name filtern

Verwenden Sie die folgende Konfiguration, um die Anzahl der API-Produkte zu begrenzen, die Edge Microgateway verwendet Downloads und Prozesse. Füge die productnamefilter hinzu, um heruntergeladene Produkte zu filtern Abfrageparameter für die in Edge Microgateway *.config.yaml aufgeführte API /products -Datei. Beispiel:

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

Der Wert des Suchparameters muss im Format eines regulären Ausdrucks angegeben werden und URL-codiert sein. Der reguläre Ausdruck ^[Ee]dgemicro.*$ fängt beispielsweise folgende Namen ab: „edgemicro-test-1“ , „edgemicro_demo“ und „Edgemicro_New_Demo“. Der URL-codierte Wert, der für im Abfrageparameter verwendet wird: %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. auf dem Sie Edge Microgateway konfiguriert haben.
Öffnen Sie unter „Develop“ die Richtlinie „JavaCallout“ im Editor.
Fügen Sie ein benutzerdefiniertes Attribut mit dem Schlüssel products.filter.attributes mit einem kommagetrennten Wert Liste der Attributnamen. Nur Produkte, die einen der benutzerdefinierten Attributnamen enthalten an Edge Microgateway zurückgegeben.
Sie können die Prüfung auch um zu sehen, ob das Produkt für die aktuelle Umgebung aktiviert ist, indem Sie das benutzerdefinierte Attribut products.filter.env.enable auf false. Der Standardwert ist „true“.
(Nur Private Cloud) Wenn Sie sich in Edge für die private Cloud befinden, legen Sie das Attribut org.noncps auf true, um Produkte für Umgebungen ohne CPS 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 sendet zu Apigee hinzufügen:

bufferSize (optional): Die maximale Anzahl an Analysedatensätzen, die der Puffer enthalten sein kann, bevor die ältesten Datensätze gelöscht werden. Standardeinstellung: 10.000
batchSize (optional): Die maximale Größe eines Batches von Analysedatensätzen. an Apigee gesendet. Standardwert: 500
flushInterval (optional): Die Anzahl der Millisekunden zwischen den einzelnen Leerungen des einen Batch von Analysedatensätzen, der an Apigee gesendet wurde. Standardeinstellung: 5.000

Beispiel:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Analysedaten maskieren

Die folgende Konfiguration verhindert, dass in Edge Informationen zum Anforderungspfad angezeigt werden Analytics. Fügen Sie der Microgateway-Konfiguration Folgendes hinzu, um den Anfrage-URI zu maskieren und/oder Anfragepfad. Der URI besteht aus dem Hostnamen und den Pfadteilen 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 wie folgt angezeigt wird: einen separaten Proxy in den Edge Analytics-Dashboards. So können Sie zum Beispiel Trennen Sie eine Systemdiagnose-API im Dashboard, um sie nicht mit tatsächlichen API-Proxy-Aufrufen zu verwechseln. Im Analytics-Dashboard, getrennte Proxys folgen diesem Namensmuster:

edgemicro_proxyname-health

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

Diese verwenden, um relative und absolute Pfade im Analytics-Dashboard als separate Proxys zu trennen:

relativePath (optional): Gibt einen relativen Pfad zum Trennen in der Analytics-Dashboard. Wenn Sie beispielsweise /healthcheck angeben, werden alle API-Aufrufe, die den Pfad enthalten, /healthcheck wird im Dashboard als edgemicro_proxyname-health angezeigt. Beachten Sie, dass dieses Flag den Proxy-Basispfad ignoriert. Verwenden Sie das Flag proxyPath, um die Daten anhand eines vollständigen Pfads einschließlich Basispfad zu trennen.
proxyPath (optional): Gibt einen vollständigen API-Proxy-Pfad an, einschließlich des Proxys Basispfad, um im Analyse-Dashboard zu trennen. Wenn Sie beispielsweise /mocktarget/healthcheck angeben, wobei /mocktarget der Proxy-Basispfad ist, werden alle API-Aufrufe mit dem Pfad /mocktarget/healthcheck werden im Dashboard als edgemicro_proxyname-health angezeigt.

In der folgenden Konfiguration wird beispielsweise jeder API-Pfad, der /healthcheck enthält, vom Analytics-Plug-in getrennt. Das bedeutet, /foo/healthcheck und /foo/bar/healthcheck wird im Analyse-Dashboard als separater Proxy mit dem Namen edgemicro_proxyname-health getrennt.

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 wird als separater Proxy namens edgemicro_proxyname-health in des Analytics-Dashboards.

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

Einrichten von Edge Microgateway hinter einem Unternehmensfirewall

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

In Version 3.1.2 hinzugefügt.

Führen Sie die folgenden Schritte aus, um einen HTTP-Proxy für die Kommunikation zwischen Edge Microgateway und Apigee Edge zu verwenden: Folgendes:

Umgebungsvariablen festlegen HTTP_PROXY, HTTPS_PROXY und NO_PROXY. Diese Variablen steuern die Hosts für jeden HTTP-Proxy, den Sie für die Kommunikation mit Apigee Edge oder die Hosts, die 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, die von Edge Microgateway keinen Proxy verwenden.

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.

Um einen HTTP-Proxy für die Kommunikation zwischen Edge Microgateway und Backend-Zielen zu verwenden, Gehen Sie so vor:

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 ein HTTP-Tunneling durchzuführen. über eine einzelne TCP-Verbindung senden. Das Gleiche gilt, wenn die Umgebungsvariablen wie wie unten erwähnt, zum Konfigurieren des Proxys 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 sollte. Verwenden Sie NO_PROXY, wenn diese Eigenschaft nicht festgelegt ist. um festzulegen, 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, die im HTTP-Proxy angegebenen Proxys verwenden Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY, wie in HTTP-Proxy für die Kommunikation mit Apigee Edge verwenden
Beispiel:
```
edgemicro:
  proxy:
    tunnel: true
    url: 'http://localhost:3786'
    bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
    enabled: true
```
HINWEIS : Wenn edgemicro.proxy im Feld Konfigurationsdatei oder wenn edgemicro.proxy.enabled falsch ist, verwendet Edge Microgateway nicht einen HTTP-Proxy für die Zielkommunikation
Starten Sie Edge Microgateway neu.

Platzhalter in Microgateway-aware verwenden Proxys

Sie können einen oder mehrere „*“ verwenden im Basispfad eines edgemicro_*-Proxy (Microgateway-aware). Ein Basispfad von Mit /team/*/members können Kunden unter https://[host]/team/blue/members und https://[host]/team/green/members, ohne neue API-Proxys erstellen zu müssen um neue Teams zu unterstützen. Beachten Sie, dass /**/ nicht unterstützt wird.

Wichtig: Apigee unterstützt NICHT die Verwendung des Platzhalters „*“. als ersten 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 in RFC7519 beschriebener Tokenstandard. JWT bietet die Möglichkeit, eine Reihe von Anforderungen zu signieren, was vom Empfänger des JWT zuverlässig verifiziert werden kann.

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

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

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

Was ist die Schlüsselrotation?

Irgendwann nach der anfänglichen Generierung eines JWT müssen Sie möglicherweise den Parameter ein öffentliches/privates Schlüsselpaar, das in der Edge-verschlüsselten KVM gespeichert ist. Dieser Prozess der Generierung eines neuen Schlüssels wird als Schlüsselrotation bezeichnet. Wenn Sie Schlüssel rotieren, wird ein neues Paar aus privatem und öffentlichem Schlüssel generiert. die im „Microgateway“ gespeichert sind KVM in Ihrer Apigee Edge-Organisation/-Umgebung. Darüber hinaus enthält der Der alte öffentliche Schlüssel wird zusammen mit seinem ursprünglichen Schlüssel-ID-Wert beibehalten.

Um ein JWT zu generieren, verwendet Edge Informationen, die in der verschlüsselten KVM gespeichert sind. A Die KVM mit dem Namen microgateway wurde bei der Ersteinrichtung erstellt und mit Schlüsseln gefüllt. Edge Microgateway. 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 zuletzt erstellte private RSA-Schlüssel, der zum Signieren verwendet wurde. JWTs
public_key – Das neueste (zuletzt erstellte) Zertifikat zur Überprüfung von JWTs. mit dem privaten_Schlüssel signiert.
private_key_kid – Neueste (zuletzt erstellte) private Schlüssel-ID Diese Schlüssel-ID ist dem Wert "private_key" zugeordnet und wird verwendet, um die Schlüsselrotation zu unterstützen.
public_key1_kid – Die letzte (zuletzt erstellte) öffentliche Schlüssel-ID. Dieser Schlüssel ist ist dem Wert public_key1 zugeordnet und wird zur Unterstützung der Schlüsselrotation verwendet. Dieser Wert ist mit dem untergeordneten Schlüssel des privaten Schlüssels identisch.
public_key1 – Der zuletzt erstellte öffentliche Schlüssel.

Wenn Sie eine Schlüsselrotation durchführen, werden vorhandene Schlüssel/Wert-Paare in der Zuordnung ersetzt und Schlüssel werden 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 public_key2. Dieser Wert wird zur Unterstützung der Schlüsselrotation verwendet.
public_key2: Der alte öffentliche Schlüssel.

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

Schlüsselrotation

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

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

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

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

Beispiel:

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

Nach der Schlüsselrotation gibt Edge mehrere Schlüssel an Edge Microgateway zurück. Hinweis im Im folgenden Beispiel hat jeder Schlüssel einen eindeutigen „Kinder“-Schlüssel, (Schlüssel-ID) zurückgegeben wird. Das Microgateway verwendet diese Schlüssel zum Validieren von Autorisierungstokens. Wenn die Tokenvalidierung fehlschlägt, sucht das Microgateway um zu sehen, ob es einen älteren Schlüssel im Schlüsselsatz gibt, und versucht diesen Schlüssel. Das Format des Die zurückgegebenen Schlüssel sind 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"
    }
  ]
}

Ein "Nicht vorher"-Attribut konfigurieren Verspätung

Ab Version 3.1.5 dauerte der neue private Schlüssel, der durch den Befehl rotatekey generiert wurde, und die neu generierten Tokens wurden mit dem neuen privaten Schlüssel signiert. Sie können jedoch Der neue öffentliche Schlüssel wurde Edge Microgateway-Instanzen nur alle 10 Minuten zur Verfügung gestellt (standardmäßig) Zeitpunkt, zu dem die Microgateway-Konfiguration aktualisiert wurde. Aufgrund dieser Verzögerung zwischen der und Microgateway-Instanzen aktualisieren, werden Tokens, die mit dem neuesten Schlüssel signiert sind, bis zum Alle Instanzen haben den öffentlichen neuesten Schlüssel erhalten.

In Fällen, in denen mehrere Microgateway-Instanzen vorhanden sind, führte die Verzögerung beim öffentlichen Schlüssel manchmal zeitweilig auftretende Laufzeitfehler mit dem Status 403, da die Tokenvalidierung eine Instanz, aber bei einer anderen schlagen sie fehl, 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 für den neuen privaten Schlüssel wirksam werden, sodass alle Microgateway-Instanzen aktualisiert werden können. und den neuen öffentlichen Schlüssel erhalten. Das neue Flag ist --nbf, was für „not before“ (Nicht vorher) steht. Dieses Flag verwendet einen ganzzahligen Wert, d. h. die Anzahl der Minuten, die verzögert werden soll.

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

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

Es empfiehlt sich, die Verzögerung auf einen größeren Wert als die Konfigurationseinstellung config_change_poll_internal festzulegen. der 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 Präfix "edgemicro_" beginnen. Du kannst diese Standardeinstellung ändern, um Proxys herunterzuladen deren Namen mit einem Muster übereinstimmen.

Öffnen Sie die Edge Micro-Konfigurationsdatei: ~/.edgemicro/org-env-config.yaml
Fügen Sie das "proxyPattern"-Element unter "Edge_config" hinzu. Das folgende Muster wird beispielsweise Laden Sie Proxys wie Edgemicro_foo, Edgemicro_fast und Edgemicro_first herunter.
```
edge_config:
…
proxyPattern: edgemicro_f*
```

Produkte ohne API-Proxys angeben

In Apigee Edge können Sie ein API-Produkt erstellen, das keine API-Proxys enthält. Bei dieser Produktkonfiguration kann ein API-Schlüssel, der mit diesem Produkt verknüpft ist, mit beliebigen der in Ihrer Organisation bereitgestellt wird. Ab Version 2.5.4 unterstützt Edge Microgateway dieses Produkt Konfiguration.

Debugging und Fehlerbehebung

Verbindung zu einem Debugger herstellen

Sie können Edge Microgateway mit einem Debugger wie node-inspector ausführen. Dies ist nützlich für und Debugging benutzerdefinierter Plug-ins.

Starten Sie Edge Microgateway im Debug-Modus neu. Fügen Sie dazu DEBUG=* zum Anfang des start-Befehls:
```
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 für den Fehlerbehebungsprozess die Portnummer überwacht wird.
Sie können nun den Edge Microgateway-Code durchlaufen, Haltepunkte einstellen, Ausdrücke beobachten, und so weiter.

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

Protokolldateien prüfen

Prüfen Sie bei Problemen die Protokolldateien auf Ausführungsdetails und Fehler. Informationen. Weitere Informationen finden Sie unter Protokolldateien verwalten.

API-Schlüsselsicherheit verwenden

API-Schlüssel bieten einen einfachen Mechanismus zum Authentifizieren von Clients, die Anfragen an Edge stellen Microgateway. Sie können einen API-Schlüssel erhalten, indem Sie den Wert des Consumer-Keys (auch Client-ID genannt) kopieren von einem Apigee Edge-Produkt, das den Edge Microgateway-Authentifizierungs-Proxy enthält.

Zwischenspeichern von Schlüsseln

API-Schlüssel werden gegen Inhabertokens ausgetauscht, die im Cache gespeichert werden. Du kannst das Caching deaktivieren, indem du den Cache-Control: no-cache-Header bei eingehenden Anfragen an Edge Microgateway.

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 Der Name des Headers und des Abfrageparameters ist x-api-key.

Beispiel für einen Abfrageparameter:

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

Beispiel für Anzeigentitel:

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

API-Schlüsselnamen konfigurieren

Standardmäßig ist x-api-key der Name, der für den Header des API-Schlüssels und den Abfrageparameter verwendet wird. Sie können diese Standardeinstellung in der Konfigurationsdatei ändern, wie unter Konfigurationsänderungen vornehmen erläutert. Um beispielsweise den Name in apiKey:

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

In diesem Beispiel werden sowohl der Suchparameter als auch der Headername in apiKey geändert. Die mit dem Namen x-api-key funktioniert. Siehe auch Konfigurationsänderungen vornehmen

Beispiel:

curl http://localhost:8000/foobar -H "apiKey:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

Weitere Informationen zur Verwendung von API-Schlüsseln mit Proxyanfragen finden Sie unter Secure Edge Microgateway

Upstream-Antwortcodes aktivieren

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

Fügen Sie oauth.useUpstreamResponse: true hinzu, um diese Funktion zu aktivieren an Ihre Edge Microgateway-Konfiguration an. 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, sichere API-Aufrufe über Microgateway. Aktualisierungstokens werden verwendet, um neue Zugriffstokens abzurufen.

Zugriffstoken abrufen

In diesem Abschnitt wird erläutert, wie Sie den edgemicro-auth-Proxy zum Abrufen eines Zugriffstokens verwenden.

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

API 1: Anmeldedaten als Textparameter senden

Ersetzen Sie die Namen Ihrer Organisation und Umgebung in der URL. Sie ersetzen die Werte der Nutzer-ID und des Consumer-Secrets, die aus einer Entwickler-App auf Apigee abgerufen wurden. Edge für die Textparameter client_id und client_secret:

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

API 2: Anmeldedaten in einem Basic Auth-Header senden

Senden Sie die Client-Anmeldedaten als Basic Authentication-Header und den grant_type als Formularparameter. Dieses Befehlsform wird auch im RFC 6749: Das OAuth 2.0-Autorisierungs-Framework.

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. Es gibt keinen Unterschied zwischen token und access_token-Properties. Beides ist möglich. expires_in ist ein ganzzahliger Wert in Sekunden.

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

Aktualisierungstoken erhalten

Um ein Aktualisierungstoken zu erhalten, führen Sie einen API-Aufruf an den Endpunkt /token der edgemicro-auth-Proxy. Du MÜSSEN diesen API-Aufruf mit der password durchführen Erteilungstyp. Die folgenden Schritte führen Sie durch den Prozess.

Rufen Sie mit der /token API ein Zugriffs- und Aktualisierungstoken ab. Beachten Sie, dass 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: dies. expires_in gibt ganze Zahlen an und wird in Sekunden angegeben.

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

Sie können jetzt das Aktualisierungstoken verwenden, um ein neues Zugriffstoken zu erhalten, indem Sie Folgendes aufrufen: den Endpunkt /refresh derselben API. 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"
    }

Permanente Überwachung

Forever ist ein Node.js-Tool, das startet eine Node.js-Anwendung automatisch neu, wenn der Prozess unterbrochen wird oder ein Fehler auftritt. Rand Microgateway verfügt über eine Datei forever.json, mit der Sie steuern können, wie viele mit welchen Intervallen Edge Microgateway neu gestartet werden soll. Diese Datei konfiguriert ein Forever-Dienst namens forever-monitor, der Forever verwaltet Programmatisch garantiert.

Sie finden die Datei forever.json in der Root-Installation von Edge Microgateway. -Verzeichnis. Weitere Informationen finden Sie unter . Wo ist Edge Microgateway installiert? Details zu den Konfigurationsoptionen finden Sie in der forever-monitor.

Der Befehl edgemicro forever enthält Flags, mit denen Sie den Speicherort der Die Datei forever.json (Flag -f) und das Forever-Monitoring starten/stoppen (das Flag -a). Beispiel:

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

Weitere Informationen finden Sie in der Befehlszeilen-Referenz unter Forevermonitoring.

Endpunkt für Konfigurationsdatei angeben

Wenn Sie mehrere Edge Microgateway-Instanzen ausführen, möchten Sie möglicherweise deren Konfigurationen verwalten von einem einzigen Ort aus. Geben Sie dazu einen HTTP-Endpunkt an, an dem Edge Micro die zugehörige Konfigurationsdatei herunterladen. Sie können diesen Endpunkt beim Starten von Edge Micro mit -u-Flag.

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 folgende Namenskonvention hat: org-env-config.yaml.

Zwischenspeichern von TCP-Verbindungsdaten deaktivieren

Mit dem Konfigurationsattribut nodelay können Sie die Datenzwischenspeicherung für Von Edge Microgateway verwendete TCP-Verbindungen.

Standardmäßig verwenden TCP-Verbindungen den Nagle , um Daten vor dem Senden zu puffern. Wenn nodelay auf true festgelegt wird, deaktiviert dieses Verhalten (Daten werden jedes Mal sofort Daten ausgelöst) socket.write() wird aufgerufen). Weitere Informationen finden Sie im Hilfeartikel Node.js in der 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 unabhängig von jedem Apigee Edge-Abhängigkeit In diesem Szenario, dem eigenständigen Modus, können Sie Edge Microgateway ausführen und testen ohne Internetverbindung nutzen zu können.

Im eigenständigen Modus funktionieren die folgenden Funktionen nicht, da dafür eine Verbindung erforderlich ist. an Apigee Edge:

OAuth und API-Schlüssel
Kontingent
Analytics

Benutzerdefinierte Plug-ins und Spike Arrest funktionieren hingegen normal, da sie eine Verbindung zu Apigee Edge. Darüber hinaus können Sie mit dem neuen Plug-in extauth im eigenständigen Modus API-Aufrufe an das Microgateway mit einem JWT autorisieren.

Gateway konfigurieren und starten

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

Erstellen Sie eine Konfigurationsdatei mit folgendem Namen: $HOME/.edgemicro/$ORG-$ENV-config.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 zu finden, wenn er startet.

Beispiel:
```
vi $HOME/.edgemicro/foo-bar-config.yaml
```
Fügen Sie folgenden Code in die Datei ein:
```
edgemicro:
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - extauth
      - spikearrest
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
extauth:
  publickey_url: https://www.googleapis.com/oauth2/v1/certs
spikearrest:
  timeUnit: second
  allow: 10
  buffersize: 0
```
Die Konfigurationsdatei enthält ein spezielles, optionales Plug-in namens extauth. Dieses Plug-in überprüft ein gültiges JWT-Token, das an das Microgateway übergeben wurde. In einem späteren Schritt erfahren Sie, wie Sie um das Token abzurufen und zu verwenden. Beachten Sie außerdem, dass das Plug-in spikearrest ist enthalten, da es nicht auf Konnektivität mit Edge angewiesen ist. Das quota, Die Plug-ins oauth und analytics sind ausgeschlossen, da sie auf eine Verbindung mit Edge und funktioniert im getrennten Modus nicht. Benutzerdefinierte Plug-ins sind zulässig und funktionieren wie erwartet.
Exportieren Sie die folgende Umgebungsvariable mit dem Wert „1“:
```
export EDGEMICRO_LOCAL=1
```
Führen Sie den folgenden start-Befehl aus. Dabei geben Sie Werte zum Instanziieren der lokaler Proxy:
```
edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
  -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH
```
Wobei:
- $ORG ist die „Organisation“ den Sie im Namen der Konfigurationsdatei verwendet haben.
- $ENV ist die „Umgebung“. Namen, den Sie in der Konfigurationsdatei verwendet haben. Namen.
- $LOCAL_PROXY_NAME ist der Name des lokalen Proxys, der erstellt wird. Sie können einen beliebigen Namen.
- $LOCAL_PROXY_VERSION ist die Versionsnummer für den Proxy.
- $TARGET_URL ist die URL für das Ziel des Proxys. (Das Ziel ist der den der Proxy aufruft.)
- $BASE_PATH ist der Basispfad des Proxys. Dieser Wert muss mit „Vorwärts“ beginnen Schrägstrich. Geben Sie für einen Stammpfad nur einen Schrägstrich an. Beispiel: „/“.
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, eine „missing_authorization“ abrufen Fehler. Dieses Plug-in validiert ein JWT, das in der Autorisierung vorhanden sein muss des API-Aufrufs an. Im nächsten Abschnitt erhalten Sie ein JWT, das API-Aufrufe zulässt. ohne Fehler durchlaufen werden.

Beispiel: Autorisierungstoken abrufen

Das folgende Beispiel zeigt, wie Sie ein JWT vom Edge Microgateway-JWT-Endpunkt auf Apigee Edge (edgemicro-auth/jwkPublicKeys) abrufen. Dieser Endpunkt wird bereitgestellt, wenn Sie Edge Microgateway standardmäßig einrichten und konfigurieren. Um das JWT vom Apigee-Endpunkt abzurufen, müssen Sie zuerst Edge Microgateway standardmäßig einrichten. mit dem Internet verbunden sein. Der Apigee-Endpunkt wird hier zu Beispielzwecken verwendet und ist nicht erforderlich. Sie können bei Bedarf einen anderen JWT-Tokenendpunkt verwenden. In diesem Fall musst du das JWT mit die für diesen Endpunkt bereitgestellte API.

Das Hinzufügen des Plug-ins extauth in Ihre Microgateway-Konfiguration ist optional. einfügen, müssen Sie um ein gültiges JWT-Token im Autorisierungsheader für API-Aufrufe bereitzustellen.

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

Sie müssen eine Standardeinstellung Edge Microgateway einrichten und konfigurieren, um den edgemicro-auth-Proxy bereitzustellen für Ihre Organisation/Umgebung auf Apigee Edge. Wenn Sie diesen Schritt bereits ausgeführt haben, müssen Sie ihn nicht wiederholen.
Wenn Sie Edge Microgateway auf 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
```
Gehen Sie in der zuvor erstellten Konfigurationsdatei ($HOME/.edgemicro/org–env-config.yaml) so vor: Zeige auf extauth:publickey_url Attribut zu dem Endpunkt edgemicro-auth/jwkPublicKeys in Ihrer Apigee Edge-Organisation/-Umgebung. Beispiel:
```
extauth:
  publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
```
Starten Sie Edge Microgateway wie zuvor neu und verwenden Sie dabei die Organisations-/Umgebungsnamen, 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 /
```
Ruft ein JWT-Token vom Autorisierungsendpunkt ab. Weil du edgemicro-auth/jwkPublicKeys verwendest Endpunkt, können Sie den folgenden Befehl über die Befehlszeile verwenden:
Für diesen Schritt benötigen Sie eine Internetverbindung. Der folgende Befehl ruft ein Token von Apigee Edge. Für diesen Schritt benötigen Sie eine Apigee-Organisation, in der Sie haben Edge Microgateway standardmäßig eingerichtet und konfiguriert. Nach diesem Schritt ist keine Verbindung mit mit dem Internet verbunden. Das Token funktioniert im eigenständigen Modus weiterhin, bis es abläuft.

Sie können ein JWT für Edge Microgateway mit dem Befehl edgemicro token oder eine API. 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 angegeben haben. konfiguriertes Edge Microgateway.
your_env ist eine Umgebung in der Organisation.
Die Option i gibt den Consumer Key einer Entwickler-App an, die ein Produkt enthält. der den edgemicro-auth-Proxy enthält.
Die Option s gibt das Consumer-Secret einer Entwickler-App an, die ein das den edgemicro-auth-Proxy enthält.

Dieser Befehl fordert Apigee Edge auf, ein JWT zu generieren, mit dem dann die API überprüft werden kann. Anrufe.

Siehe auch Token generieren.

Eigenständige Konfiguration testen

Um die Konfiguration zu testen, rufen Sie die API mit dem Token auf, das im Autorisierungsheader wie folgt hinzugefügt wird:

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 Proxy-Modus benötigt Edge Microgateway kein microgateway-aware-Proxy auf Apigee Edge bereitgestellt werden. Stattdessen konfigurieren Sie einen „lokalen Proxy“ indem Sie einen lokalen Proxy-Namen, einen Basispfad und eine Ziel-URL, Starten Sie das Microgateway. API-Aufrufe an das Microgateway werden dann an das Ziel URL des lokalen Proxys. Abgesehen davon funktioniert der lokale Proxymodus genauso Edge Microgateway im normalen Modus Die Authentifizierung funktioniert wie die Spitze, und Kontingentdurchsetzung, benutzerdefinierte Plug-ins und so weiter.

Die beiden wichtigen Unterschiede zwischen dem lokalen Modus und dem regulären Edge Microgateway Konfiguration sind: (1) Im lokalen Modus müssen Sie kein Microgateway-fähiges Gerät erstellen, Proxy in Apigee Edge und (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 weiteren Proxys hinzufügen.

Anwendungsfall und Beispiel

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

Edgemicro als Sidecar

Ein Vorteil dieses Architekturstils besteht darin, dass Edge Microgateway API Verwaltung einzelner Dienste, die in einer Containerumgebung bereitgestellt werden, z. B. ein Kubernetes-Cluster.

Lokalen Proxymodus konfigurieren

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

Führen Sie edgemicro init aus, um Ihre lokale Konfigurationsumgebung genau einzurichten. wie bei einer typischen Edge Microgateway-Einrichtung. Siehe auch Edge Microgateway konfigurieren
Führen Sie edgemicro configure wie bei einer typischen Edge Microgateway-Einrichtung aus Verfahren. Beispiel:
```
edgemicro configure -o your_org -e your_env -u your_apigee_username
```
Dieser Befehl stellt die Richtlinie edgemicro-auth in Edge bereit und gibt einen Schlüssel zurück und das Secret, das Sie zum Starten des Microgateways benötigen. Weitere Informationen findest du unter Edge Microgateway konfigurieren
Erstellen Sie in Apigee Edge ein API-Produkt mit der folgenden obligatorischen Konfiguration (Sie können alle anderen Konfigurationen nach Bedarf verwalten): <ph type="x-smartling-placeholder">
- Sie müssen dem Produkt den Proxy edgemicro-auth hinzufügen. Dieser Proxy wurde automatisch bereitgestellt, als Sie edgemicro configure ausgeführt haben.
- Sie müssen einen Ressourcenpfad angeben. Apigee empfiehlt, diesen Pfad zum das Produkt: /**. Weitere Informationen finden Sie unter Verhalten des Ressourcenpfads konfigurieren. Siehe auch API erstellen Produkte in der Edge-Dokumentation.
Erstellen Sie in Apigee Edge einen Entwickler oder verwenden Sie einen vorhandenen Entwickler, wenn Sie Weitere Informationen finden Sie unter Entwickler mithilfe der Edge-Verwaltungsbenutzeroberfläche hinzufügen.
Erstellen Sie in Apigee Edge eine Entwickler-App. Sie müssen das API-Produkt hinzufügen, das Sie die Sie gerade in der App erstellt haben. Weitere Informationen finden Sie unter Registrieren einer App in Edge. Management-UI.
Exportieren Sie auf dem Computer, auf dem Edge Microgateway installiert ist, Folgendes: den Wert „1“ haben.
```
export EDGEMICRO_LOCAL_PROXY=1
```
Führen Sie folgenden start-Befehl aus:
```
edgemicro start -o your_org -e your_environment -k your_key -s your_secret \
    -a local_proxy_name -v local_proxy_version -t target_url -b base_path
```
Wobei:
- your_org ist Ihre Apigee-Organisation.
- your_environment ist eine Umgebung in Ihrer Organisation.
- your_key ist der Schlüssel, der bei der Ausführung zurückgegeben wurde. edgemicro configure.
- your_secret ist das Secret, das bei der Ausführung zurückgegeben wurde edgemicro configure.
- local_proxy_name ist der Name des lokalen Proxys, der erstellt wird.
- local_proxy_version ist die Versionsnummer für den Proxy.
- target_url ist die URL für das Ziel des Proxys (der Dienst, den der Proxy aufrufen).
- base_path ist der Basispfad des Proxys. Dieser Wert muss mit „Vorwärts“ beginnen Schrägstrich. Geben Sie für einen Stammpfad nur einen Schrägstrich an. Beispiel: „/“.
Beispiel:
```
edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
  -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
  -t http://mocktarget.apigee.net -b /echo
```

Konfiguration testen

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

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

Bei diesem ersten API-Aufruf ist ein Fehler aufgetreten, da Sie keinen gültigen API-Schlüssel angegeben haben. Sie finden den Schlüssel in der zuvor erstellten Entwickler-App. Öffnen Sie die App in der Edge-Benutzeroberfläche, kopieren Sie den Consumer-Key und verwenden Sie diesen Schlüssel wie folgt:

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

Beispiel:

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

Beispielausgabe:

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

Synchronisierer verwenden

In diesem Abschnitt wird die Verwendung des Synchronisierers (optionales Funktion) erläutert, verbessert die Ausfallsicherheit von Edge Microgteway, um Konfigurationsdaten von Apigee Edge abzurufen und in eine lokale Redis-Datenbank zu schreiben. Mit eine Synchronisierer-Instanz, andere Edge Microgateway-Instanzen, die auf verschiedenen Knoten ausgeführt werden können ihre Konfiguration direkt aus dieser Datenbank abrufen.

Die Syncrhonizer-Funktion wird derzeit für die Arbeit mit Redis 5.0.x unterstützt.

Was ist der Synchronisierer?

Der Synchronisierer bietet ein gewisses Maß an Ausfallsicherheit für Edge Microgateway. Es trägt dazu bei, dass jede Instanz von Edge Microgateway dieselbe Konfiguration verwendet Bei einer Internetunterbrechung können Edge Microgateway-Instanzen gestartet und ausgeführt werden. ordnungsgemäß funktioniert.

Standardmäßig müssen Edge Microgateway-Instanzen mit Apigee Edge kommunizieren können, um Konfigurationsdaten wie API-Proxy- und API-Produktkonfigurationen abzurufen und zu aktualisieren. Wenn die Internetverbindung mit Edge unterbrochen wird, können Microgateway-Instanzen weiterhin da die neuesten Konfigurationsdaten im Cache gespeichert werden. Neue Microgateway-Instanzen kann ohne klare Verbindung nicht gestartet werden. Außerdem kann ein Internet Unterbrechung, sodass eine oder mehrere Microgateway-Instanzen mit der Konfiguration ausgeführt werden Daten, 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 aus Aufrufen von Apigee Edge abgerufenen Konfigurationsdaten gehören: der jwk_public_keys-Aufruf, die Aufrufe jwt_public_key, Bootstrap und API-Produkte. Der Synchronisierer ermöglicht es, dass alle Edge Microgateways auf verschiedenen Knoten ausgeführt werden, um ordnungsgemäß zu starten und synchron zu bleiben, Die Internetverbindung zwischen Edge Microgateway und Apigee Edge ist unterbrochen.

Der Synchronisierer ist eine speziell konfigurierte Instanz von Edge Microgateway. Sein einziger Zweck ist das Abfragen von Apigee Edge (das Timing ist konfigurierbar), Konfigurationsdaten abzurufen und in eine lokale Redis-Datenbank schreiben. Die Synchronisierungsinstanz selbst kann den API-Proxy nicht verarbeiten. Zugriffe. Andere Instanzen von Edge Microgateway, die auf verschiedenen Knoten ausgeführt werden, so konfiguriert sein, dass Konfigurationsdaten aus der Redis-Datenbank und nicht aus Apigee abgerufen werden Edge Da alle Microgateway-Instanzen ihre Konfigurationsdaten aus der lokalen können sie auch im Falle einer Internetverbindung API-Anfragen starten und verarbeiten. Störungen.

Synchronisierer-Instanz konfigurieren

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

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

Beispiel:

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

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

Mit der Umgebungsvariable EDGEMICRO_REDIS_PASSWORD können Sie der edgemicro.redisPassword-Parameter. Siehe auch Konfigurationsattribute mit Werten von Umgebungsvariablen festlegen

Speichern Sie schließlich die Konfigurationsdatei und starten Sie die Edge Microgateway-Instanz. Es beginnt Apigee Edge abfragen und heruntergeladene Konfigurationsdaten in der Redis-Datenbank 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 Microgateway-Instanzen auszuführen, die API-Proxy-Traffic verarbeiten. Sie konfigurieren jedoch um die Konfigurationsdaten dieser Instanzen aus der Redis-Datenbank abzurufen, Apigee Edge

Fügen Sie jedem zusätzlichen Edge Microgateway-Knoten die folgende Konfiguration hinzu org-env/config.yaml-Datei. Beachten Sie, dass die synchronizerMode ist auf 0 festgelegt. Dieses Attribut legt fest, dass die Instanz normal arbeitet. Edge Microgateway-Instanz, die den API-Proxy-Traffic verarbeitet, und die Instanz erhält seine Konfigurationsdaten aus der Redis-Datenbank.

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

Beispiel:

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

Konfigurationsattribute

Die folgenden 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), arbeitet Edge Microgateway im Standardmodus. Wenn 1, starten Sie die Edge Microgateway-Instanz, damit sie als Synchronisierer verwendet wird. In dieser ruft die Instanz die Konfigurationsdaten aus Apigee Edge ab und speichert sie im eine lokale Redis-Datenbank. Diese Instanz kann keine API-Proxy-Anfragen verarbeiten. sein Der einzige Zweck besteht darin, Konfigurationsdaten aus Apigee Edge abzufragen und diese in die lokale Datenbank. Anschließend müssen Sie weitere Mikrogateway-Instanzen so konfigurieren, dass sie aus der Datenbank lesen.
`edge_config.redisBasedConfigCache`	"true" oder "false"	Wenn wahr, ruft die Edge Microgateway-Instanz ihre Konfigurationsdaten vom Redis-Datenbank statt von Apigee Edge. Die Redis-Datenbank muss dieselbe sein in das der Synchronisierer schreibt. Wenn die Redis-Datenbank nicht verfügbar ist Ist die Datenbank leer, sucht das Microgateway nach einem vorhandenen `cache-config.yaml` für die Konfiguration. Bei Einstellung auf „false“ (Standardeinstellung) ruft die Edge Microgateway-Instanz Konfigurationsdaten aus Apigee Edge wie gewohnt verwenden.
`edgemicro.config_change_poll_interval`	Zeitintervall in Sekunden	Gibt das Pollingintervall für den Synchronisierer an, um Daten aus Apigee Edge abzurufen.

edge_config.synchronizerMode

0 oder 1

Wenn 0 (Standardeinstellung), arbeitet Edge Microgateway im Standardmodus.

Wenn 1, starten Sie die Edge Microgateway-Instanz, damit sie als Synchronisierer verwendet wird. In dieser ruft die Instanz die Konfigurationsdaten aus Apigee Edge ab und speichert sie im eine lokale Redis-Datenbank. Diese Instanz kann keine API-Proxy-Anfragen verarbeiten. sein Der einzige Zweck besteht darin, Konfigurationsdaten aus Apigee Edge abzufragen und diese in die lokale Datenbank. Anschließend müssen Sie weitere Mikrogateway-Instanzen so konfigurieren, dass sie aus der Datenbank lesen.

edge_config.redisBasedConfigCache

"true" oder "false"

Wenn wahr, ruft die Edge Microgateway-Instanz ihre Konfigurationsdaten vom Redis-Datenbank statt von Apigee Edge. Die Redis-Datenbank muss dieselbe sein in das der Synchronisierer schreibt. Wenn die Redis-Datenbank nicht verfügbar ist Ist die Datenbank leer, sucht das Microgateway nach einem vorhandenen cache-config.yaml für die Konfiguration.

Bei Einstellung auf „false“ (Standardeinstellung) ruft die Edge Microgateway-Instanz Konfigurationsdaten aus Apigee Edge wie gewohnt verwenden.

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

Ausschluss-URLs für Plug-ins konfigurieren

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

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 dem Pfad /hello oder /proxy_one. Außerdem enthält die json2xml wird das Plug-in für APIs mit /hello/xml im Pfad übersprungen.

Das Plug-in analytics kann nicht ausgeschlossen werden.

Konfigurationsattribute mit Werten von Umgebungsvariablen festlegen

Sie können Umgebungsvariablen mithilfe von Tags in der Konfiguration angeben -Datei. Die angegebenen Umgebungsvariablen-Tags werden durch die tatsächliche Umgebung ersetzt. Variablenwerte. Ersatzgeräte werden nur im Arbeitsspeicher gespeichert, nicht im Original Konfigurations- oder Cache-Dateien.

Hinweis : Standardmäßig parst das Tag <E> Variablenwerte. als Zeichenfolgen. Um positive ganzzahlige und boolesche Werte anzugeben, verwenden Sie den inneren <n>- und <b>-Tags, wie in den folgenden Beispielen veranschaulicht.

In diesem Beispiel wird das Attribut key durch den Wert des TARGETS_SSL_CLIENT_KEY 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. Nur positive Ganzzahlen unterstützt werden.

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

In diesem Beispiel wird das <b>-Tag verwendet, um einen booleschen Wert ( wahr oder false).

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