Diese Seite wurde von der Cloud Translation API übersetzt.

Vorgangs- und Konfigurationsreferenz für Edge Microgateway

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Edge Microgateway Version 2.5.x

In diesem Thema wird beschrieben, wie Sie Edge Microgateway verwalten und konfigurieren.

Edge Microgateway aktualisieren, wenn Sie eine Internetverbindung haben

Führen Sie den folgenden npm-Befehl aus, um ein Upgrade auf die neueste Version von Edge Microgateway durchzuführen:
```
npm upgrade edgemicro -g
```
Für ein Upgrade auf eine bestimmte Version von Edge Microgateway müssen Sie im Upgradebefehl die Versionsnummer angeben. Wenn Sie keine Versionsnummer angeben, wird die neueste Version installiert. Führen Sie beispielsweise den folgenden Befehl aus, um auf Version 2.5.26 zu aktualisieren:
```
npm upgrade edgemicro@2.5.26 -g
```

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

edgemicro --version
current nodejs version is v8.9.0
current edgemicro version is 2.5.26

Führen Sie abschließend ein Upgrade auf die neueste Version des Proxys edgemicro-auth durch:
```
edgemicro upgradeauth -o org_name -e env_name -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 zum Ausführen von Instanzen

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

Standardsystemkonfigurationsdatei

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

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

Dabei ist prefix das Präfixverzeichnis 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 dann neu starten:

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

Standardkonfigurationsdatei für neu initialisierte Edge Microgateway-Instanzen

Wenn Sie edgemicro init ausführen, wird die oben beschriebene Systemkonfigurationsdatei default.yaml im Verzeichnis ~/.edgemicro abgelegt.

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

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

Dynamische Konfigurationsdatei zum Ausführen von Instanzen

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

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

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

Wenn Edge Microgateway beendet ist:

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

Hier ist ein Beispiel für eine Konfigurationsdatei. Weitere Informationen zu den Einstellungen 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, für die Werte für Ihre Edge-Organisation und -Umgebung erforderlich sind, 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

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“ so aufrufen:

https://localhost:8000/myapi

So konfigurieren Sie SSL auf dem Microgateway-Server:

Generieren oder erhalten Sie ein SSL-Zertifikat und einen SSL-Schlüssel mit dem Dienstprogramm openssl oder einer anderen Methode.
Fügen Sie der 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 Schritten unter Konfigurationsänderungen vornehmen, je nachdem, welche Konfigurationsdatei Sie bearbeitet haben: die Standarddatei oder die Laufzeitkonfigurationsdatei.

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

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

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

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 und „false“ für 1-Wege-SSL

Client-SSL/TLS-Optionen verwenden

Sie können Edge Microgateway beim Herstellen einer Verbindung zu Zielendpunkten als TLS- oder SSL-Client konfigurieren. Verwenden Sie in der Microgateway-Konfigurationsdatei das Element „targets“, um SSL/TLS-Optionen festzulegen.

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

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 Ablauf des Tokens 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ätsbestätigung verwendet.

Wichtig: Wenn Sie den Standardauthentifizierungs-Proxy überschreiben, muss der neue Proxy oder Dienst ein Antwortformat zurückgeben, das mit dem standardmäßigen edgemicro-auth-Proxy identisch ist.

Protokolldateien verwalten

Edge Microgateway protokolliert Informationen zu jeder Anfrage und Antwort. Protokolldateien bieten nützliche Informationen für die Fehlerbehebung.

Speicherort der Protokolldateien

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

Standardverzeichnis für Logdateien ändern

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

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

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

Logs an die Konsole senden

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

edgemicro:
  logging:
    to_console: true

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

Protokollierungsebene festlegen

Sie können die folgenden Logebenen festlegen: info, warn und error. Die Informationsebene wird empfohlen. Sie protokolliert alle API-Anfragen und -Antworten und ist die Standardeinstellung.

Protokollintervalle ändern

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

Folgende Attribute sind konfigurierbar:

stats_log_interval: (Standardwert: 60) Intervall in Sekunden, wenn der Statistikeintrag in die API-Logdatei geschrieben wird.
rotate_interval: (Standardwert: 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

Gute Vorgehensweisen für die Pflege von Protokolldateien

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

Da Logdateien sehr groß werden können, muss im Protokolldateiverzeichnis genügend Speicherplatz vorhanden sein. Weitere Informationen finden Sie in den folgenden Abschnitten: Speicherort von 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 ältere Logs mit dem Befehl edgemicro log -c über die Befehlszeile entfernen.

Benennungskonvention für Logdateien

Jede Edge Microgateway-Instanz erzeugt drei Typen von Protokolldateien:

api – protokolliert alle Anfragen und Antworten, die über Edge Microgateway fließen. API-Zähler (Statistiken) und Fehler werden ebenfalls in dieser Datei protokolliert.
err: Protokolliert alles, was an stderr gesendet wird.
out – Protokolliert alles, was an stdout gesendet wird.

Dies ist die Namenskonvention:

edgemicro-<Host Name>-<Instance ID>-<Log Type>.log

Beispiel:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log
edgemicro-mymachine-local-MTQzNTg1NDMODAyMQ-err.log
edgemicro-mymachine-local-mtqzntgndmxodaymq-out.log

Inhalt der Protokolldatei

Hinzugefügt in: Version 2.3.3

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

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

Unter Windows: SET DEBUG=* verwenden

Inhalt der Protokolldatei "api"

Die Logdatei "api" enthält detaillierte Informationen zum Fluss von Anfragen und Antworten über Edge Microgateway. Die "api"-Protokolldateien haben folgenden Namen:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

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

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

Jeder dieser 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 Logdatei sehen sie so aus (die Zeilennummern dienen nur zu Referenzzwecken im Dokument und sind in der Logdatei nicht enthalten).

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

Sehen wir uns diese im Einzelnen an:

1. Beispiel für eine vom Client eingehende Anfrage:

1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0

1436403888651 – Unix-Datumsstempel
info: Hängt vom Kontext ab. Kann je nach Logebene „info“, „warn“ oder „error“ sein. Kann Statistiken für einen Statistikeintrag sein, warnen bei Warnungen oder Fehler für Fehler.
req: Identifiziert das Ereignis. 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 – Der Host und die Portnummer, die Edge Microgateway überwacht.
r – Der Remote-Host und Port, von dem die Clientanfrage stammt.
i – Die Anfrage-ID. Alle vier Ereigniseinträge haben dieselbe ID. Jeder Anfrage wird eine eindeutige Anfrage-ID zugewiesen. Die Korrelation von Logdatensätzen nach Anfrage-ID kann wertvolle Informationen zur Latenz des Ziels liefern.
d – Die Dauer in Millisekunden, seit der Anfrage von Edge Microgateway empfangen wurde. Im obigen Beispiel wurde die Antwort des Ziels für Anfrage 0 nach 7 Millisekunden (Zeile 3) empfangen und die Antwort wurde nach weiteren 4 Millisekunden an den Client gesendet (Zeile 4). Mit anderen Worten, die gesamte Anfragelatenz betrug 11 Millisekunden, davon 7 Millisekunden vom Ziel und 4 Millisekunden vom Edge Microgateway selbst.

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

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

1436403888651 – Unix-Datumsstempel
info: Hängt vom Kontext ab. Kann je nach Logebene „info“, „warn“ oder „error“ sein. Kann Statistiken für einen Statistikeintrag sein, warnen bei Warnungen oder Fehler für Fehler.
treq – Kennzeichnet das Ereignis. In diesem Fall 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 – die ID des Logeintrags. Alle vier Ereigniseinträge haben diese ID.

3. Beispiel für eingehende Antwort vom Ziel

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

1436403888651 – Unix-Datumsstempel

info: Hängt vom Kontext ab. Kann je nach Logebene „info“, „warn“ oder „error“ sein. Kann Statistiken für einen Statistikeintrag sein, warnen bei Warnungen oder Fehler für Fehler.
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 – die ID des Logeintrags. Alle vier Ereigniseinträge haben diese ID.

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

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

1436403888651 – Unix-Datumsstempel

info: Hängt vom Kontext ab. Kann je nach Logebene „info“, „warn“ oder „error“ sein. Kann Statistiken für einen Statistikeintrag sein, warnen bei Warnungen oder Fehler für Fehler.
res – Identifiziert das Ereignis. Antworten Sie in diesem Fall dem Client.
s – HTTP-Antwortstatus
d – Dauer in Millisekunden. Dies ist die Gesamtzeit des API-Aufrufs, einschließlich der Zeit, die die Ziel-API benötigt, und die Zeit, die Edge Microgateway selbst benötigt.
i – die ID des Logeintrags. Alle vier Ereigniseinträge haben diese ID.

Zeitplan für Protokolldateien

Protokolldateien werden in dem Intervall rotiert, das im Konfigurationsattribut rotate_interval angegeben ist. Einträge werden weiterhin derselben Logdatei hinzugefügt, bis das Rotationsintervall abläuft. Jedes Mal, wenn Edge Microgateway neu gestartet wird, erhält es jedoch eine neue UID und erstellt einen neuen Satz von Logdateien mit dieser UID. Siehe auch Gute Wartungspraktiken für 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 von Edge Microgateway. Siehe auch Konfigurationsänderungen vornehmen.

Edge_config-Attribute

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

bootstrap: (Standard: keine) Eine URL, die auf einen Edge Microgateway-spezifischen Dienst verweist, der auf Apigee Edge ausgeführt wird. Edge Microgateway verwendet diesen Dienst für die Kommunikation mit Apigee Edge. Diese URL wird zurückgegeben, wenn Sie den Befehl zum Generieren des öffentlichen/privaten Schlüsselpaars ausführen: edgemicro genkeys. Weitere Informationen finden Sie unter Edge Microgateway einrichten und konfigurieren.
jwt_public_key: (Standard: keiner) Eine URL, die auf den Edge Microgateway-Proxy verweist, der auf Apigee Edge bereitgestellt wird. Dieser Proxy dient als Authentifizierungsendpunkt für die Ausstellung signierter Zugriffstokens an Clients. Diese URL wird zurückgegeben, wenn Sie den Befehl edgemicro configure ausführen, um den Proxy bereitzustellen. Weitere Informationen finden Sie unter Edge Microgateway einrichten und konfigurieren.

Edgemicro-Attribute

Mit diesen Einstellungen wird der Edge Microgateway-Prozess konfiguriert.

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

res.statusCode = 429; // Too many requests
max_connections_hard: (Standard: -1) Die maximale Anzahl gleichzeitiger Anfragen, die Edge Microgateway empfangen kann, bevor die Verbindung heruntergefahren wird. Diese Einstellung dient dazu, Denial-of-Service-Angriffen vorzubeugen. Legen Sie dafür in der Regel eine Zahl fest, die größer als „max_connections“ ist.
logging:
- level: (Standard: Fehler)
  - Info: Protokolliert alle Anfragen und Antworten, die durch eine Edge Microgateway-Instanz fließen.
  - warn – protokolliert nur Warnmeldungen.
  - error – protokolliert nur Fehlermeldungen.
- dir: (Standard: /var/tmp) Das Verzeichnis, in dem die Logdateien gespeichert sind.
- stats_log_interval: (Standardwert: 60) Intervall in Sekunden, wenn der Statistikeintrag in die API-Logdatei geschrieben wird.
- rotate_interval: (Standardwert: 24) Intervall in Stunden, wenn Logdateien rotiert werden.

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

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

debug : Fügt dem Edge Microgateway-Prozess Remote-Debugging hinzu.
- port: Die Portnummer, die überwacht werden soll. Legen Sie beispielsweise fest, dass Ihr IDE-Debugger diesen Port überwacht.
- args: Argumente für den Fehlerbehebungsprozess. 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, wenn sich etwas geändert hat. Bei der Abfrage werden alle in Edge vorgenommenen Änderungen (Änderungen an Produkten, Microgateway-fähigen Proxys usw.) sowie Änderungen an der lokalen Konfigurationsdatei erfasst.
disable_config_poll_interval: (Standardeinstellung: false) Wenn Sie diese Option auf true festlegen, deaktivieren Sie automatische Änderungsabfragen.
request_timeout: Legt ein Zeitlimit für Zielanfragen fest. Das Zeitlimit wird in Sekunden festgelegt. Wenn ein Zeitlimit auftritt, antwortet Edge Microgateway mit einem 504-Statuscode. (Version 2.4.x hinzugefügt)

Header-Attribute

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

x-forwarded-for: (Standard: true) Setzen Sie diesen Wert auf "false", um zu verhindern, dass "x-forwarded-for"-Header an das Ziel übergeben werden. Wenn sich ein x-forwarded-for-Header in der Anfrage befindet, wird sein Wert in Edge Analytics auf den Client-IP-Wert festgelegt.
x-forwarded-host: (Standardeinstellung: true) Legen Sie diesen Wert auf "false" fest, um zu verhindern, dass x-forwarded-host-Header an das Ziel übergeben werden.
x-request-id: (Standardeinstellung: true) Ist auf "false" gesetzt, damit keine x-request-id-Header an das Ziel übergeben werden.
x-response-time: (Standard: true) Setzen Sie diesen Wert auf "false", um zu verhindern, dass x-response-time-Header an das Ziel übergeben werden.
via: (Standardeinstellung: true) Legen Sie diesen Wert auf "false" fest, um zu verhindern, dass via-Header an das Ziel übergeben werden.

OAuth-Attribute

Mit diesen Einstellungen wird festgelegt, wie die Clientauthentifizierung von Edge Microgateway erzwungen wird.

allowNoAuthorization: (Standard: false) Wenn auf „true“ gesetzt, dürfen API-Aufrufe Edge Microgateway ohne Autorisierungsheader passieren. Setzen Sie diesen Wert auf „false“, damit ein Autorisierungsheader erforderlich ist (Standardeinstellung).
allowInvalidAuthorization: (Standardeinstellung: „false“). Bei Einstellung auf „true“ dürfen API-Aufrufe übergeben werden, wenn das im Autorisierungsheader übergebene Token ungültig oder abgelaufen ist. Setzen Sie diesen Wert auf „false“, damit gültige Tokens erforderlich sind (Standardeinstellung).
authorization-header: (Standard: Authorization: Bearer) Der Header, mit dem das Zugriffstoken an Edge Microgateway gesendet 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 zum Übergeben eines API-Schlüssels an Edge Microgateway verwendet wird. Weitere Informationen finden Sie unter API-Schlüssel verwenden.
keep-authorization-header: (Standardeinstellung: false) Bei Einstellung auf "true" wird der in der Anfrage gesendete Autorisierungsheader an das Ziel übergeben und bleibt erhalten.
allowOAuthOnly: Wenn diese Richtlinie auf "true" gesetzt ist, muss jede API einen Autorisierungsheader mit einem Inhaberzugriffstoken enthalten. Ermöglicht es Ihnen, nur das OAuth-Sicherheitsmodell zuzulassen (unter Wahrung der Abwärtskompatibilität). (2.4.x hinzugefügt)
allowAPIKeyOnly: Wenn dieser Wert auf "true" gesetzt ist, muss jede API einen x-api-key-Header (oder einen benutzerdefinierten Speicherort) mit einem API-Schlüssel enthalten.So können Sie nur das Sicherheitsmodell des API-Schlüssels zulassen (unter Aufrechterhaltung der Abwärtskompatibilität). (2.4.x hinzugefügt)
Legen Sie allowOAuthOnly und allowAPIKeyOnly nicht auf "true" fest. Standardmäßig sind beide Flags auf "false" gesetzt (aus Gründen der Abwärtskompatibilität).
gracePeriod: Mit diesem Parameter werden Fehler verhindert, die durch geringfügige Abweichungen zwischen der Systemuhr und den im JWT-Autorisierungstoken angegebenen Zeiten „Nicht vor“ (nbf) oder „Ausgestellt zu“ (iat) verursacht werden. Legen Sie für diesen Parameter die Anzahl der Sekunden fest, um solche Abweichungen zu berücksichtigen. (2.5.7 hinzugefügt)

Plug-in-spezifische Attribute

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

Proxys filtern

Sie können filtern, welche Microgateway-fähigen Proxys eine Edge Microgateway-Instanz verarbeitet. Beim Start von Edge Microgateway werden alle Microgateway-fähigen Proxys in der zugehörigen Organisation heruntergeladen. Verwenden Sie die folgende Konfiguration, um festzulegen, welche Proxys das Mikrogateway verarbeiten soll. Diese Konfiguration beschränkt die vom Mikrogateway verarbeiteten Proxys beispielsweise auf drei: edgemicro_proxy-1, edgemicro_proxy-2 und edgemicro_proxy-3:

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

Push-Frequenz für Analysen konfigurieren

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

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

Beispiel:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Analysedaten maskieren

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

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

API-Aufrufe in Edge Analytics trennen

Sie können das Analyse-Plug-in so konfigurieren, dass ein bestimmter API-Pfad getrennt wird, sodass er in den Edge Analytics-Dashboards als separater Proxy angezeigt wird. Sie können beispielsweise eine Systemdiagnose-API im Dashboard trennen, damit sie nicht mit tatsächlichen API-Proxy-Aufrufen verwechselt wird. 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 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 Analysedashboard als separater Proxy namens edgemicro_proxyname-health getrennt werden.

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

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

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

Unterstützt v2.4.x

Wenn Edge Microgateway hinter einer Firewall installiert ist, kann das Gateway möglicherweise nicht mit Apigee Edge kommunizieren. In diesem Fall haben Sie zwei Möglichkeiten:

Option 1:

Die erste Möglichkeit besteht darin, die Option „edgemicro: proxy_tunnel“ in der Konfigurationsdatei von Microgateway auf „true“ zu setzen:

edge_config:

    proxy: http://10.224.16.85:3128
    proxy_tunnel: true

Wenn proxy_tunnel auf true gesetzt ist, verwendet Edge Microgateway die HTTP-Methode CONNECT, um HTTP-Anfragen über eine einzelne TCP-Verbindung zu streamen. Dasselbe gilt, wenn die Umgebungsvariablen zum Konfigurieren des Proxys TLS-aktiviert sind.

Option 2:

Die zweite Option besteht darin, einen Proxy anzugeben und "proxy_tunnel" in der Konfigurationsdatei des Microgateways auf "false" zu setzen. Beispiel:

edge_config:
     proxy: http://10.224.16.85:3128
     proxy_tunnel: false

In diesem Fall können Sie die folgenden Variablen festlegen, um die Hosts für jeden HTTP-Proxy zu steuern, den Sie verwenden möchten, oder um die Hosts, die keine Edge Microgateway-Proxys verarbeiten sollen, zu steuern: HTTP_PROXY, HTTPS_PROXY und NO_PROXY.

Sie können NO_PROXY als durch Kommas getrennte Liste von Domains festlegen, zu denen Edge Microgateway nicht weitergeleitet werden soll. Beispiel:

export NO_PROXY='localhost,localhost:8080'

Legen Sie HTTP_PROXY und HTTPS_PROXY fest, damit der HTTP-Proxy-Endpunkt Edge Microgateway Nachrichten an ihn senden kann. Beispiel:

export HTTP_PROXY='http://localhost:3786'

export HTTPS_PROXY='https://localhost:3786'

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

Weitere Informationen

Edge Microgateway hinter einer Unternehmensfirewall einrichten in der Apigee-Community.

Platzhalter in Microgateway-fähigen Proxys verwenden

Sie können einen oder mehrere Platzhalter „*“ im Basispfad eines edgemicro_*-Proxys (Microgateway-aware) verwenden. Mit dem Basispfad /team/*/members können Clients beispielsweise https://[host]/team/blue/members und https://[host]/team/green/members aufrufen, ohne 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. Dies wird beispielsweise NICHT unterstützt: /*/-Suche.

JWT-Schlüssel rotieren

Verwendung von JWT durch Edge Microgateway

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.

Edge Microgateway verwendet JWTs als Inhabertokens für die OAuth-Sicherheit. Wenn Sie ein OAuth-Token für Edge Microgateway generieren, erhalten Sie ein JWT. Anschließend kannst du das JWT im Autorisierungsheader von API-Aufrufen verwenden. Beispiel:

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

Neues JWT generieren

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

edgemicro token get -o docs -e test -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

Mit diesem Befehl wird Apigee Edge aufgefordert, ein JWT zu generieren, das dann zur Überprüfung von API-Aufrufen verwendet werden kann. Die Parameter -i und -s sind die Consumer-ID- und Secret-Werte aus einer Entwickler-App in Ihrer Apigee Edge-Organisation.

Alternativ können Sie ein JWT auch mithilfe der Verwaltungs-API generieren:

curl -i -X POST "http://org-env.apigee.net/edgemicro-auth/token" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "your consumer key",
    "client_secret": "your consumer secret",
    "grant_type": "client_credentials"
  }'

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“).
client_id ist die Verbraucher-ID in der Entwickler-App, die Sie zuvor erstellt haben.
client_secret ist das Consumer Secret in der Entwickler-App, die Sie zuvor erstellt haben.

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. Außerdem wird der alte öffentliche Schlüssel zusammen mit seinem ursprünglichen Schlüssel-ID-Wert beibehalten.

Zum Generieren eines JWT verwendet Edge Informationen, die in der verschlüsselten KVM gespeichert sind. Eine KVM namens microgateway wurde erstellt und mit Schlüsseln gefüllt, als Sie Edge Microgateway erstmals 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, mit dem mit dem „private_key“ signierte JWTs verifiziert werden.
private_key_kid – Die 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 neueste (zuletzt erstellte) öffentliche Schlüssel-ID. Dieser Schlüssel ist mit dem Wert „public_key1“ verknüpft und wird zur Unterstützung der Schlüsselrotation verwendet. Dieser Wert entspricht dem untergeordneten privaten Schlüssel.
public_key1 – der neueste (zuletzt erstellte) öffentliche Schlüssel.

Wenn Sie eine Schlüsselrotation durchfü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 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. Schlägt die Verifizierung fehl, wird der alte öffentliche Schlüssel verwendet, bis er (nach 30 Minuten) abläuft. Auf diese Weise können Sie Schlüssel „rotieren“, ohne den API-Traffic sofort zu unterbrechen.

So führen Sie eine Schlüsselrotation aus

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

Wenn Sie Ihre Edge Microgateway-Instanz vor Version 2.5.2 konfiguriert haben

Wenn Sie Ihre Edge Microgateway-Instanz vor Version 2.5.2 konfiguriert haben, müssen Sie die folgenden beiden Befehle ausführen, um ein Upgrade der KVM und der Authentifizierungsrichtlinie durchzuführen:

upgradekvm -o org -e env -u username

Weitere Informationen zu diesem Befehl finden Sie unter KVM upgraden.

Mit dem nächsten Befehl wird der Proxy edgemicro-oauth aktualisiert, der beim Konfigurieren von Edge Microgateway in Ihrer Apigee-Organisation bereitgestellt wurde. Dieser Proxy stellt Dienste bereit, die zum Generieren von Tokens erforderlich sind.

upgradeauth -o org -e env -u username

Weitere Informationen zu diesem Befehl finden Sie unter Edgemicro-auth-Proxy upgraden.

Schlüssel rotieren

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 Microgateway 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 -u username -k kid_value

Beispiel:

edgemicro rotatekey -o jdoe -e test -u jdoe@google.com -k 2
current nodejs version is v6.9.1
current edgemicro version is 2.5.7
password:
Checking if private key exists in the KVM...
Checking for certificate...
Found Certificate
Generating New key/cert pair...
Extract new public key
Key Rotation successfully completed!

Der Parameter -k gibt eine Schlüssel-ID (kid) an. Mit dieser ID wird ein bestimmter Schlüssel abgeglichen. Edge Microgateway verwendet diesen Wert, um während der Schlüsselrotation aus einer Reihe von Schlüsseln auszuwählen. Weitere Informationen finden Sie in Abschnitt 4.5 der JSON-Webschlüsselspezifikation.

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 "kid" (Schlüssel-ID) hat. Das Mikrogateway verwendet diese Schlüssel dann, um Autorisierungstoken zu validieren. Wenn die Tokenvalidierung fehlschlägt, sucht das Mikrogateway nach einem älteren Schlüssel im Schlüsselsatz und versucht, diesen zu verwenden. 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"
    }
  ]
}

Heruntergeladene Proxys filtern

Edge Microgateway lädt standardmäßig alle Proxys in Ihrer Edge-Organisation herunter, die mit dem Namenspräfix „edgemicro_“ beginnen. Sie können diese Standardeinstellung ändern, um Proxys herunterzuladen, deren Namen einem Muster entsprechen.

Öffnen Sie die Edge Micro-Konfigurationsdatei: ~/.edgemicro/org-env-config.yaml
Fügen Sie unter „edge_config“ das „proxyPattern“-Element hinzu. Mit dem folgenden Muster werden beispielsweise Proxys wie „edgemicro_foo“, „edgemicro_fast“ und „edgemicro_first“ heruntergeladen.
```
edge_config:
…
proxyPattern: edgemicro_f*
```

Produkte ohne API-Proxys angeben

In Apigee Edge können Sie ein API-Produkt erstellen, das keine API-Proxys enthält. Bei dieser Produktkonfiguration kann ein mit diesem Produkt verknüpfter API-Schlüssel mit jedem in Ihrer Organisation bereitgestellten Proxy verwendet werden. Ab Version 2.5.4 unterstützt Edge Microgateway diese Produktkonfiguration.

Debugging und Fehlerbehebung

Verbindung zu einem Debugger herstellen

Sie können Edge Microgateway mit einem Debugger wie node-Inspector ausführen. Dies ist nützlich, 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. Beispiel:

DEBUG=* edgemicro start -o  myorg -e test -k
      db4e9e8a95aa7fabfdeacbb1169d0a8cbe42bec19c6b98129e02 -s
      6e56af7c1b26dfe93dae78a735c8afc9796b077d105ae5618ce7ed

Verwenden Sie unter Windows SET DEBUG=*.

Starten Sie den Debugger und richten Sie ihn so ein, dass der Debugging-Prozess die Portnummer überwacht.
Sie können jetzt Schritt für Schritt den Edge Microgateway-Code durchgehen, Haltepunkte, Watch-Ausdrücke festlegen usw.

Sie können Node.js-Standard-Flags für den Debug-Modus angeben. Mit --nolazy können Sie beispielsweise Fehler bei asynchronem Code beheben.

Protokolldateien prüfen

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

API-Schlüsselsicherheit verwenden

API-Schlüssel bieten einen einfachen Mechanismus zur Authentifizierung von Clients, die Anfragen an Edge Microgateway senden. Sie können einen API-Schlüssel abrufen, indem Sie den Wert für den Consumer-Schlüssel (auch Client-ID genannt) aus einem Apigee Edge-Produkt kopieren, das den Edge Microgateway-Authentifizierungs-Proxy enthält.

Caching von Schlüsseln

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

API-Schlüssel verwenden

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

Beispiel für einen Abfrageparameter:

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

Beispiel für Anzeigentitel:

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

API-Schlüsselnamen konfigurieren

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

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

In diesem Beispiel werden sowohl der Abfrageparameter als auch der Headername in apiKey geändert. Der Name x-api-key funktioniert in beiden Fällen nicht mehr. Siehe auch Konfigurationsänderungen vornehmen.

Beispiel:

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

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

OAuth2-Tokensicherheit verwenden

In diesem Abschnitt wird erläutert, wie Sie OAuth2-Zugriffstokens und Aktualisierungstokens erhalten. Zugriffstokens werden verwendet, um sichere API-Aufrufe über das Mikrogateway durchzuführen. Aktualisierungstokens werden verwendet, um neue Zugriffstokens 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 mit dem Befehl edgemicro token der Befehlszeile abrufen. Weitere Informationen zur Befehlszeile finden Sie unter Tokens verwalten.

API 1

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

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

API 2

(in Version 2.5.31 hinzugefügt) Senden Sie die Clientanmeldedaten als Basisauthentifizierungsheader und grant_type als Formularparameter. Dieses Befehlsformular wird auch unter RFC 6749: Das OAuth 2.0-Autorisierungs-Framework behandelt.

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

Beispielausgabe

Die API gibt eine JSON-Antwort zurück. Zwischen den Properties token und access_token gibt es keinen Unterschied. Sie können eine von beiden verwenden.

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

Aktualisierungstoken abrufen

Um ein Aktualisierungstoken abzurufen, senden Sie einen API-Aufruf an den Endpunkt /token des Proxys edgemicro-auth. Sie MÜSSEN diesen API-Aufruf mit dem Berechtigungstyp password ausführen. Führen Sie dazu die folgenden Schritte aus.

Fordern Sie ein Zugriffs- und Aktualisierungstoken mit der /token API an. 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:

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

Sie können jetzt das Aktualisierungstoken verwenden, um ein neues Zugriffstoken zu erhalten. Dazu rufen Sie den /refresh-Endpunkt 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

Forever ist ein Node.js-Tool, das Node.js-Anwendungen 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. In dieser Datei wird ein Forever-Dienst mit dem Namen forever-monitor konfiguriert, der Forever programmatisch verwaltet.

Sie finden die Datei forever.json im Edge Microgateway-Stammverzeichnis für die Installation. 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 Forever-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 deren Konfigurationen möglicherweise von einem einzigen Standort aus verwalten. Dazu geben Sie einen HTTP-Endpunkt an, von dem Edge Micro seine Konfigurationsdatei herunterladen kann. Sie können diesen Endpunkt beim Starten von Edge Micro mit dem Flag -u angeben.

Beispiel:

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

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

Zwischenspeichern von TCP-Verbindungsdaten 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 zu puffern, bevor sie gesendet werden. Wenn Sie nodelay auf true festlegen, wird dieses Verhalten deaktiviert. Daten werden bei jedem Aufruf von socket.write() sofort durch 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
Analysen

Andererseits funktionieren benutzerdefinierte Plug-ins und Spike Arrest normal, da sie keine Verbindung zu Apigee Edge benötigen. Darüber hinaus können Sie mit einem neuen Plug-in namens extauth im eigenständigen Modus API-Aufrufe an das Mikrogateway mit einem JWT autorisieren.

Gateway konfigurieren und starten

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

Achten Sie darauf, dass Sie Edge Microgateway Version 2.5.25 oder höher installiert haben. Andernfalls müssen Sie den folgenden Befehl ausführen, um ein Upgrade auf die neueste Version durchzuführen:
```
npm install -g edgemicro
```
Weitere Informationen finden Sie unter Edge Microgateway installieren.
Erstellen Sie eine Konfigurationsdatei mit folgendem Namen: $HOME/.edgemicro/org_name-env_name-config.yaml
Sie können im Dateinamen beliebige Werte für org_name und env_name 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 wurde. 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 auf die Konnektivität mit Edge angewiesen ist. Die Plug-ins quota, oauth und analytics sind ausgeschlossen, da sie auf der Verbindung 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, wobei Sie Werte zum Instanziieren des lokalen Proxys angeben:
```
edgemicro start -o org_name -e environment_name -a local_proxy_name \
  -v local_proxy_version -t target_url -b base_path
```
Wobei:
- your_org ist der Name der Organisation, den Sie im Namen der Konfigurationsdatei verwendet haben.
- your_environment ist der Name der "env", den Sie im Namen der Konfigurationsdatei verwendet haben.
- local_proxy_name ist der Name des lokalen Proxys, der erstellt wird. Sie können einen beliebigen Namen verwenden.
- local_proxy_version ist die Versionsnummer des Proxys.
- target_url ist die URL für das Ziel des Proxys. Das Ziel ist der Dienst, den der Proxy aufruft.
- base_path ist der Basispfad des Proxys. Dieser Wert muss mit einem Schrägstrich beginnen. Geben Sie für einen Basispfad für das Stammverzeichnis 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 durchgeführt werden können.

Beispiel: Autorisierungstoken abrufen

Das folgende Beispiel zeigt, wie Sie ein JWT vom Edge Microgateway-JWT-Endpunkt in Apigee Edge (edgemicro-auth/jwkPublicKeys) abrufen. Dieser Endpunkt wird bereitgestellt, wenn Sie eine Standardeinrichtung und -konfiguration von Edge Microgateway durchführen. Um das JWT vom Apigee-Endpunkt abzurufen, müssen Sie zuerst das standardmäßige Edge Microgateway einrichten und mit dem Internet verbunden sein. Der Apigee-Endpunkt wird hier nur als Beispiel 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 Einbinden des Plug-ins extauth in die Microgateway-Konfiguration ist optional. Wenn Sie es jedoch hinzufügen, 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 für Ihre Organisation/Umgebung in Apigee Edge bereitzustellen. Wenn Sie diesen Schritt bereits ausgeführt haben, müssen Sie ihn nicht wiederholen.
Wenn Sie Edge Microgateway für 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 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 /
```
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 benötigen Sie eine Apigee-Organisation, in der Sie die standardmäßige Einrichtung und Konfiguration von Edge Microgateway durchgeführt haben. Sie müssen nach diesem Schritt nicht mit dem Internet verbunden sein. 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 der Apigee-Organisation, für die Sie zuvor Edge Microgateway konfiguriert haben.
your_env ist eine Umgebung in der Organisation.
Die Option i gibt den Consumer-Key von einer Entwickler-App an, deren Produkt den edgemicro-auth-Proxy enthält.
Mit der Option s wird das Consumer Secret aus einer Entwickler-App mit einem Produkt angegeben, das den edgemicro-auth-Proxy enthält.

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

Siehe auch Token generieren.

Eigenständige Konfiguration testen

Um die Konfiguration zu testen, rufen Sie die API mit dem im Autorisierungsheader hinzugefügten Token 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-kompatibler Proxy in 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. Ansonsten funktioniert der lokale Proxymodus genauso wie das Ausführen von Edge Microgateway im normalen Modus. Die Authentifizierung funktioniert auf die gleiche Weise wie der Spike Arrest und die Kontingentdurchsetzung, benutzerdefinierte Plug-ins usw.

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

Anwendungsfall und Beispiel

Der lokale Proxymodus ist nützlich, wenn Sie nur einen 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 Companion-Dienst verwaltet. Die folgende Abbildung zeigt diese Architektur, bei der Edge Microgateway als Sidecar-Proxy in einem Kubernetes-Cluster fungiert. Jede Microgateway-Instanz kommuniziert nur mit einem einzelnen Endpunkt auf ihrem Begleitdienst:

Edgemicro als Sidecar

Ein Vorteil dieser Architektur 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

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

Achten Sie darauf, dass Sie Edge Microgateway Version 2.5.25 oder höher installiert haben. Andernfalls müssen Sie den folgenden Befehl ausführen, um ein Upgrade auf die neueste Version durchzuführen:
```
npm install -g edgemicro
```
Weitere Informationen finden Sie unter Edge Microgateway installieren.
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
```
Mit diesem Befehl wird die Richtlinie edgemicro-auth für Edge bereitgestellt und ein Schlüssel und ein Secret zurückgegeben, 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 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. Wenn Sie möchten, können Sie auch einen vorhandenen Entwickler verwenden. 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 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 aufrufen wird).
- base_path ist der Basispfad des Proxys. Dieser Wert muss mit einem Schrägstrich beginnen. Geben Sie für einen Basispfad für das Stammverzeichnis 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"
}

Bei diesem ersten API-Aufruf ist ein Fehler aufgetreten, da Sie keinen gültigen API-Schlüssel angegeben haben. Sie finden den Schlüssel in der Entwickler-App, die Sie zuvor erstellt haben. Öffnen Sie die App in der Edge-Benutzeroberfläche, kopieren Sie den Consumer-Key und verwenden Sie 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":""
}