Versionshinweise zu 4.18.05 Edge für Private Cloud

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

In diesem Abschnitt wird Version 4.18.05 des Edge for Private Cloud-Feature-Release beschrieben.

Release-Zusammenfassung

In der folgenden Tabelle sind die Änderungen in dieser Feature-Version zusammengefasst:

Neue Funktionen ○ JWT-Richtlinien sind jetzt allgemein verfügbar (GA).
○ RedHat Enterprise Linux 6.9 wird jetzt unterstützt.
○ Oracle Linux 6.9 wird jetzt unterstützt.
○ CentOS 6.9 wird jetzt unterstützt.
○ Änderungen an der Installationskonfiguration für die neue Edge-Umgebung
○ Router-Wiederholungsoptionen können jetzt auf der Ebene des virtuellen Hosts festgelegt werden.
Enthaltene Releases
○ Edge-Benutzeroberfläche:
   18.04.04
   18.03.02
   18.02.14
   17.11.06 		○ Edge Management/Runtime:
   18.04.06
   18.04.04
   18.03.02
   18.02.02
   18.01.05
 ○ Portal:
   18.04.25.01
   18.04.25.00
   18.04.23.00
   18.03.28.00
   18.03.05.00
   18.02.15.00
   18.01.31.00
   17.12.20.00
Ruhestand ○ API BaaS
○ Monitoring-Dashboard (Beta)
Einstellung ○ Apigee-Sicherheitsstores (Vaults) durch KVMs ersetzt
○ Pfade auf dem Tab „Leistung“ des API-Proxys hinzufügen
○ SMTPSSL-Eigenschaft für das Developer Services-Portal
Fehlerkorrekturen ○ Verhindern, dass die E-Mail-Adresse des Nutzers geändert wird (65550638)
○ Sicherheitslücke in jackson-databind (69711616)
○ Speicherleck in Message Processors (71612599)
Bekannte Probleme

Diese Version weist die folgenden bekannten Probleme auf:

○ Beim Sichern des Message Processors wird nicht die richtige Gruppe von Dateien gesichert (121095148)
○ HEAD-Anfragen an Node.js-Ziele hängen (79993247)
○ Die Option zum Erstellen eines Reverseproxys über die Open API wird angezeigt (79949124)
○ Hostnamen werden nicht aufgelöst (79757554)
○ DataAccessExceptions in Konfigurationen mit mehreren Rechenzentren (76087166)
○ Beim Beenden von apigee-postgresql wird eine Fehlermeldung zu Berechtigungen angezeigt (72379834)
○ Die MessageLogging-Richtlinie enthält zusätzliche Informationen im Logeintrag (68722102)

Weitere Informationen zu den einzelnen bekannten Problemen, einschließlich Problemumgehungen, finden Sie unter Bekannte Probleme.

In den folgenden Abschnitten werden die einzelnen Themen ausführlich beschrieben.

Upgrade-Pfade

In der folgenden Tabelle sind die Upgradepfade für diesen Feature-Release aufgeführt:

Ab 4.18.01 Direktes Upgrade von 4.18.01 auf 4.18.05
Ab 4.17.09 Direktes Upgrade von 4.17.09 auf 4.18.05
Ab 4.17.05 Direktes Upgrade von 4.17.05 auf 4.18.05
Ab Version 4.17.01 Upgrade von 4.17.01 auf 4.18.01, dann Upgrade von 4.18.01 auf 4.18.05
Ab dem 16.04.2009 Upgrade von 4.16.09 → 4.18.01, dann Upgrade von 4.18.01 → 4.18.05
Ab 4.16.05 Upgrade von 4.16.05 auf 4.18.01, dann Upgrade von 4.18.01 auf 4.18.05
Ab 4.16.01 Upgrade von 4.16.01 → 4.18.01, dann Upgrade von 4.18.01 → 4.18.05
Ab 4.15.0x Upgrade von 4.15.0x → 4.16.01, dann Upgrade von 4.16.01 → 4.18.01, dann Upgrade von 4.18.01 → 4.18.05

Neue Funktionen

In diesem Abschnitt werden die neuen Funktionen in diesem Feature-Release beschrieben. Zusätzlich zu diesen Funktionen enthält diese Version alle Funktionen der Edge-UI-, Edge-Verwaltungs- und Portal-Releases, die unter Enthaltene Releases aufgeführt sind.

Zusätzlich zu den folgenden Verbesserungen enthält dieser Release auch mehrere Verbesserungen in Bezug auf Benutzerfreundlichkeit, Leistung, Sicherheit und Stabilität.

JWT-Richtlinien

Die folgenden JWT-Richtlinien sind nicht mehr in der Betaphase, sondern allgemein verfügbar:

Unterstützte Software

Diese Feature-Version enthält die folgenden Änderungen an der unterstützten Software:

  • Red Hat Enterprise Linux (RHEL) 6.9 wird jetzt unterstützt
  • Oracle Linux 6.9 wird jetzt unterstützt
  • CentOS 6.9 wird jetzt unterstützt
  • RHEL/CentOS/Oracle Linux 7.2 werden nicht mehr unterstützt

Weitere Informationen finden Sie unter Unterstützte Software und unterstützte Versionen.

Änderungen an der Installationskonfiguration für die neue Edge-Benutzeroberfläche

Die Version 4.18.05 der neuen Edge-Benutzeroberfläche enthält Änderungen an der Konfigurationsdatei im Vergleich zur Version 4.18.01. Die neuen Attribute werden unter Änderungen an der Installationskonfiguration ab Edge 4.18.01 beschrieben.

Wiederholungsoptionen für Router können jetzt auf Ebene des virtuellen Hosts festgelegt werden

Sie können jetzt Wiederholungsoptionen für die Kommunikation des Routers mit dem Message Processor auf dem virtuellen Host festlegen. So haben Sie eine genauere Kontrolle als mit den vorherigen Optionen, die nur auf Routerebene festgelegt werden konnten.

Weitere Informationen finden Sie unter Konfigurationseigenschaften für virtuelle Hosts.

Neue Analytics-Dimension und Änderung der Dimension x_forwarded_for_ip

Die Art und Weise, wie die Dimension x_forwarded_for_ip in Edge Analytics festgelegt wird, hat sich geändert. Bisher enthielt die Dimension x_forwarded_for_ip nur die letzte aufgeführte IP-Adresse, wenn im X-Forwarded-For-Header mehrere IP-Adressen vorhanden waren. Kunden haben die Dimension x_forwarded_for_ip häufig verwendet, um die IP-Adresse des Clients zu ermitteln, der die API-Anfrage an Edge sendet.

Mit diesem Release enthält die Dimension x_forwarded_for_ip jetzt die vollständige Liste der IP-Adressen im X-Forwarded-For-Header.

Warnung: Der X-Forwarded-For-Header kann von einer IP-Adresse, der der Zugriff verweigert wurde, gefälscht werden. Dies gilt jedoch nicht für die letzte Adresse im Header. Das ist die IP-Adresse, die Edge vom letzten externen TCP-Handshake erhalten hat. Um die ursprüngliche Client-IP-Adresse zu ermitteln, von der die API-Anfrage an Edge gesendet wurde, wird in dieser Version eine neue Dimension für Edge Analytics hinzugefügt: ax_resolved_client_ip.

Sie können die Dimension ax_resolved_client_ip jetzt in einem benutzerdefinierten Bericht oder in einer Filterbedingung in einem benutzerdefinierten Bericht verwenden, um die IP-Adresse des Clients zu ermitteln, der die API-Anfrage stellt. Weitere Informationen zur Dimension ax_resolved_client_ip finden Sie unter Referenz zu Analytics-Messwerten, -Dimensionen und -Filtern.

Diese Änderung wirkt sich auch auf die Art und Weise aus, wie die AccessControl-Richtlinie den X-Forwarded-For-Header verarbeitet. In dieser Version füllt Edge den X-Forwarded-For-HTTP-Header automatisch mit der einzelnen IP-Adresse ein, die er vom letzten externen TCP-Handshake erhalten hat, z. B. die Client-IP oder den Router. In früheren Versionen hat Edge den X-Forwarded-For-HTTP-Header mit der einzelnen IP-Adresse festgelegt, die er vom ersten externen TCP-Handshake erhalten hat, z. B. die Client-IP oder den Router. Weitere Informationen finden Sie unter X-Forwarded-For-HTTP-Header.

Enthaltene Releases

Seit dem letzten Feature-Release für Edge for Private Cloud sind die folgenden Releases erfolgt, die in diesem Feature-Release enthalten sind:

Edge-Benutzeroberfläche Edge-Verwaltung/Laufzeit Portal
18.04.04
18.03.02
18.02.14
17.11.06 		18.04.06
18.04.04
18.03.02*
18.02.02
18.01.05
 18.04.25.01
18.04.25.00
18.04.23.00
18.03.28.00
18.03.05.00
18.02.15.00
18.01.31.00
17.12.20.00
* Der Fehlerkorrektur 74622499 ist nicht in der Version 4.18.05 von Edge for Private Cloud enthalten.

Klicken Sie auf die Links oben, um die Fehlerkorrekturen und neuen Funktionen aus diesen Releases zu sehen, die in diesem Feature-Release enthalten sind.

Einstellungen

In diesem Abschnitt werden Funktionen beschrieben, die in diesem Feature-Release eingestellt wurden.

API BaaS

Die API BaaS wurde eingestellt. Weitere Informationen finden Sie unter Apigee-Einstellungen, ‑Außerbetriebnahmen und ‑CPS-Änderungen.

Monitoring-Dashboard (Beta)

Das Monitoring-Dashboard (Beta) wurde eingestellt und wird nicht mehr unterstützt. Daher sind die folgenden Komponenten nicht mehr Teil der Installation:

  • apigee-influxdb
  • apigee-telegraf
  • apigee-grafana

Damit Sie weiterhin Router-, Message Processor- und Knotenmesswerte erhalten, empfiehlt Apigee, dass Sie JMX verwenden, um die Daten von Edge for Private Cloud in Ihre eigenen Monitoring-Tools einzubinden. Weitere Informationen finden Sie unter Was sollte überwacht werden? und Wie wird überwacht?.

Wenn Sie ein Upgrade einer vorhandenen Installation auf Version 4.18.05 durchführen, sollten Sie das Monitoring-Dashboard deinstallieren. Apigee garantiert nicht, dass es weiterhin wie erwartet funktioniert.

Verworfene Produkte/Funktionen

Die folgenden Funktionen wurden in diesem Feature-Release eingestellt.

Weitere Informationen finden Sie unter Apigee-Einstellungen, ‑Außerbetriebnahmen und ‑CPS-Änderungen.

Apigee Secure Store (Vaults)

Der sichere Apigee-Speicher, auch als „Vaults“ bezeichnet, wird eingestellt und im September 2018 deaktiviert.

Verwenden Sie anstelle des sicheren Speichers verschlüsselte Schlüssel/Wert-Zuordnungen (Key Value Maps, KVMs), wie unter Mit Schlüssel/Wert-Zuordnungen arbeiten beschrieben. Verschlüsselte KVMs sind genauso sicher wie Tresore und bieten mehr Optionen für das Erstellen und Abrufen.

Pfade auf dem Tab „Leistung“ des API-Proxys hinzufügen

Vor dieser Version konnten Sie in der Verwaltungsoberfläche zu einem API-Proxy navigieren, den Tab Leistung aufrufen und verschiedene Pfade für einen diagrammbasierten Vergleich auf dem Tab Leistung des Proxys und im Dashboard Geschäftsvorgänge erstellen.

Diese Funktion wurde eingestellt und ist nicht mehr in der Benutzeroberfläche verfügbar. Eine Alternative zu dieser Funktion finden Sie unter Alternative zur Business Transactions API.

SMTPSSL-Property für das Developer Services-Portal

Um das Protokoll festzulegen, das vom mit dem Portal verbundenen SMTP-Server verwendet wird, verwenden Sie jetzt die Property SMTP_PROTOCOL anstelle der Property SMTPSSL. Gültige Werte für SMTP_PROTOCOL sind „standard“, „ssl“ und „tls“.

Weitere Informationen finden Sie unter Developer Services-Portal installieren.

Fehlerkorrekturen

In diesem Abschnitt werden die Fehler in der Private Cloud aufgeführt, die in diesem Feature-Release behoben wurden. Zusätzlich zu den unten aufgeführten Fehlern enthält diese Feature-Version alle Fehlerkorrekturen in den Versionen der Edge-Benutzeroberfläche, Edge Management und des Portals, die unter Enthaltene Versionen aufgeführt sind.

Problem-ID Beschreibung
71612599

Speicherleck in Message Processors

Ein Speicherleck wurde behoben. Der Fehler ist in Message Processors aufgetreten, als Qpidd beendet wurde.
69711616

Sicherheitslücke in jackson-databind

Die jackson-databind-Bibliothek wurde auf Version 2.7.9.1 aktualisiert, um einen Deserialisierungsfehler zu verhindern.
65550638

Änderung der E-Mail-Adresse eines Nutzers verhindern

Sie können die E-Mail-Adresse eines Nutzers nicht mehr in der Nachrichtennutzlast ändern, die an die Management API gesendet wird. Die Management API lässt jetzt auch kein XML im Anfragetext mehr zu.

Bekannte Probleme

In der folgenden Tabelle sind die bekannten Probleme in diesem Feature-Release aufgeführt:

Problem-ID Beschreibung
121095148

Beim Sichern des Message Processors werden nicht die richtigen Dateien gesichert

Workaround:

Führen Sie die Sicherung ein zweites Mal aus. Es sollten dann die richtigen Dateien gesichert werden.
79993247

HEAD-Anfragen an Node.js-Ziele hängen

HEAD-Anfragen an ein Node.js-Ziel können hängen bleiben, sodass Verbindungen ausstehend sind.

Workaround:

Um dieses Problem zu umgehen, definieren Sie einen Handler für HEAD-Anfragen, der explizit eine leere Antwort zurückgibt.
79949124

Option zum Erstellen eines Reverse-Proxys über die Open API wird angezeigt

Der Proxy-Assistent bietet derzeit eine Option zum Erstellen eines neuen Proxys über Open API. Das ist in Edge for Private Cloud nicht möglich.

Workaround:

Keine.
79757554

Hostnamen werden nicht aufgelöst

Nach der Installation oder dem Upgrade von Edge for Private Cloud werden Hostnamen möglicherweise nicht in ihre Adressen aufgelöst.

Workaround:

So beheben Sie das Problem:

/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
76087166

DataAccessException in Konfigurationen mit mehreren Rechenzentren

Wenn in Konfigurationen mit mehreren Rechenzentren ein Datenspeicher nicht mehr verfügbar ist, wird möglicherweise der folgende Fehler angezeigt:

DataAccessException: Error while accessing datastore;
Please retry later

Das Ergebnis ist, dass der Management Server möglicherweise nicht gestartet wird, da er versucht, eine Verbindung zu Cassandra-Knoten in dc-1 und dc-2 herzustellen. Der DataAccessExceptions-Fehler tritt auf, wenn ein Cassandra-Knoten nicht verfügbar ist. Dies kann auch zu Unterbrechungen des API-Traffics führen, wenn Message Processors beim Abrufen von KVMs DataAccessExceptions melden.

Der Management Server sollte keine regionsübergreifenden Verbindungen zu Datastore-Komponenten herstellen.

Problemumgehung

Als Workaround können Sie die folgenden Cassandra-Knotentypen im nicht verfügbaren Rechenzentrum abmelden und dann wieder anmelden, wenn die Cassandra-Knoten wieder verfügbar sind:

  • kms-datastore
  • dc-datastore
  • keyvaluemap-datastore

So heben Sie die Registrierung dieser Cassandra-Knotentypen auf und registrieren sie neu:

  1. Rufen Sie die UUIDs der Cassandra-Knoten mit dem folgenden curl-Befehl ab: 
    curl -u ADMIN_EMAIL:ADMIN_PW \
  "http://MS_IP:MS_PORT/v1/servers?region=REGION&pod=GATEWAY_POD \
  &type=CASSANDRA_NODE_TYPE"

    Wobei:

    • ADMIN_EMAIL und ADMIN_PW sind die Anmeldedaten Ihres Apigee-Kontos.
    • MS_IP und MS_PORT sind die IP-Adresse und die Portnummer des Management-Servers.
    • REGION ist der Name des Rechenzentrums, in dem sich der Management Server befindet.
    • GATEWAY_POD ist der Pod-Name, der standardmäßig „gateway“ lautet. Möglicherweise haben Sie den Namen geändert. Überprüfen Sie daher Ihre Implementierung.
    • CASSANDRA_NODE_TYPE ist wahlweise kms-datastore, dc-datastore oder keyvaluemap-datastore.

    Beispiel: 

    curl -u nickdanger@google.com:myP@$$w0rD
  "http://192.168.0.1:8080/v1/servers?region=dc-1&pod=gateway&type=dc-datastore"

    Die Antwort hat das folgende Format: 

    {
  "internalIP" : "POD_IP_ADDRESS",
  "isUp" : [true|false],
  "pod" : "GATEWAY_POD",
  "reachable" : [true|false],
  "region" : "dc-1",
  "tags" : {
    "property" : [ ]
  },
  "type" : [ "kms-datastore", "dc-datastore", "keyvaluemap-datastore" ],
    "uUID" : "POD_UUID"
}

    Beispiel: 

    {
  "internalIP" : "192.168.1.11",
  "isUp" : false,
  "pod" : "gateway",
  "reachable" : false,
  "region" : "dc-1",
  "tags" : {
    "property" : [ ]
  },
  "type" : "dc-datastore",
  "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
}

    Notieren Sie sich die Werte des Felds uUID in der Antwort. Sie verwenden diese, um die Registrierung der Knoten aufzuheben.

  2. Wiederholen Sie Schritt 1 für jeden Cassandra-Knotentyp: kms-datastore, dc-datastore und keyvaluemap-datastore. Notieren Sie sich die zurückgegebenen UUIDs.
  3. Heben Sie die Registrierung der Knoten mit dem folgenden Befehl auf: 
    curl -u ADMIN_EMAIL:ADMIN_PW "http://MS_IP:MS_PORT/v1/servers/UUID" -X DELETE

    Dabei ist UUID die UUID, die in der Antwort des vorherigen Befehls zurückgegeben wurde.

  4. Wiederholen Sie Schritt 3 für jede UUID, die Sie in den Schritten 1 und 2 erfasst haben.
  5. Registrieren Sie die Knoten mit dem folgenden Befehl neu: 
    curl -u ADMIN_EMAIL:ADMIN_PW "http://MS_IP:MS_PORT/v1/servers -d \
  "Type=kms-datastore&Type=dc-datastore&Type=keyvaluemap-datastore& \
  Type=counter-datastore&Type=cache-datastore&InternalIP=POD_IP_ADDRESS& \
  region=REGION&pod=GATEWAY_POD" -H \
  'content-type: application/x-www-form-urlencoded' -X POST

Mit diesen Vorgängen werden Knoten bei Zookeeper registriert und die Registrierung aufgehoben. Sie haben keine Auswirkungen auf den Cassandra-Cluster. Weitere Informationen zu diesen Befehlen finden Sie unter Datenspeicherregistrierungen aktualisieren.
72379834

Fehlermeldung zu Berechtigungen beim Beenden von apigee-postgresql

Wenn Sie den Befehl apigee-seriver apigee-postgresql stop verwenden, um apigee-postgresql zu beenden, wird möglicherweise eine Meldung angezeigt, dass apigee-serive nicht in das Home-Verzeichnis des Nutzers geändert werden kann. Sie können diese Meldung ignorieren.

Workaround:

–
68722102

MessageLogging-Richtlinie mit zusätzlichen Informationen im Logeintrag

Das Element FormatMessage der MessageLogging-Richtlinie steuert das Format der protokollierten Nachricht. Wenn FormatMessage=false, darf die protokollierte Nachricht keine von Apigee generierten Informationen enthalten. Selbst wenn Sie FormatMessage=false festlegen, enthält die Log-Nachricht weiterhin die folgenden Informationen:

  • Der Prioritätswert
  • Der Zeitstempel

Workaround:

Keine.

Nächster Schritt

Verwenden Sie die folgenden Links, um mit Edge for Private Cloud 4.18.05 zu beginnen:

Neuinstallationen:
Neuinstallation – Übersicht
Vorhandene Installationen:
Upgrade von 4.18.01
Upgrade von 4.17.05 oder 4.17.09
Upgrade von 4.17.01
Upgrade von 4.16.09
Upgrade von 4.16.01 oder 4.16