Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu
Apigee X. info
Im August und September 2015 migrieren wir unsere Apigee Edge-Cloud-Router und Load Balancer zu NGINX (ausgesprochen „Engine X“). NGINX, ein Open-Source-Webserver, bietet eine noch bessere Leistung und höhere Parallelität als unsere vorhandenen Load-Balancer und Router.
Was bedeutet das für unsere Cloud-Kunden?
Diese Änderung sollte für Sie transparent sein und erfordert keine Maßnahmen Ihrerseits , außer zu prüfen, ob Ihre Systeme wie erwartet funktionieren. Im Folgenden werden die Schritte beschrieben, die wir unternehmen, und Antworten auf einige häufig gestellte Fragen gegeben.
Schritt 1: Softwareupdate
Wir aktualisieren alle Router auf den neuen NGINX-basierten Router. Dabei nutzen wir unser stufenweises Bereitstellungs modell, um sicherzustellen, dass die Dienste durch diese Aktivität nicht beeinträchtigt werden.
Schritt 2: Load-Balancer-Ebene in Nicht-Produktionsumgebungen entfernen
Da der neue NGINX-Router die Load-Balancing-Funktionalität übernimmt, entfernen wir zuerst die vorhandene Load-Balancer-Ebene in Ihren Nicht-Produktionsumgebungen. Die Load-Balancer für die Produktion bleiben in diesem Schritt unverändert. Vor dem Entfernen der vorhandenen Load-Balancer prüfen wir umfassend, ob der Traffic wie erwartet funktioniert. Für diesen Schritt sind keine Maßnahmen Ihrerseits erforderlich. Sie sollten jedoch alle Probleme an Apigee melden. Wir arbeiten dann mit Ihnen zusammen, um die Probleme zu beheben, bevor wir mit Schritt 3 fortfahren.
Schritt 3: Load-Balancer-Ebene in Produktionsumgebungen entfernen
Nach Abschluss von Schritt 2 legen wir eine Reihe von Wartungsfenstern fest, um die Load-Balancer-Ebene in Produktionsumgebungen zu entfernen. Dabei verwenden wir denselben Ansatz wie in Schritt 2 um sicherzustellen, dass der API-Traffic zur Laufzeit wie erwartet funktioniert.
Änderungen an der Produktfunktionalität
Hier sind einige Änderungen an der Produktfunktionalität durch den Wechsel zu NGINX.
Verworfen
Die folgenden Eigenschaften werden in ProxyEndpoints nicht mehr unterstützt:
- allow.http10
- allow.http11
- allow.http.method.*
- allow.POST.without.content.length
- allow.PUT.without.content.length
Informationen zur Umgehung dieser Einstellung finden Sie in diesem Community-Artikel: Proxy Endpoint HTTP allow method properties not working.
Häufig gestellte Fragen
Im Folgenden finden Sie Antworten auf einige häufig gestellte Fragen zur NGINX-Migration.
In Schritt 1 lautet die Antwort „Nein“, da wir die vorhandenen Load Balancer nicht ändern. Dadurch werden auch keine der IPs direkt geändert, die Traffic verarbeiten. Aufgrund der Beschaffenheit des Load-Balancing-Dienstes von Amazon Web Services (AWS) gelten jedoch die normalen Skalierungsregeln. Das bedeutet, dass sich IPs im Rahmen der Skalierungslogik ändern können (vorhandene Funktion). Daher empfehlen wir nicht, Konfigurationen für die Zulassungsliste für Northbound-Traffic mit der Apigee Edge Produktsuite zu implementieren. In den Schritten 2 und 3 gibt es Auswirkungen auf die Zulassungsliste, da der Load-Balancer und die zugehörigen IP-Adressen entfernt werden. Daher arbeiten wir in diesen Schr101} itten eng mit Ihnen zusammen, um einen reibungslosen Übergang zu gewährleisten. Dazu stellen wir eine neue Reihe von IP-Adressen bereit, für die der Zugriff zugelassen werden muss.
Es sind keine Änderungen erforderlich, sofern die Ursprungsserver die Ziel-Endpunktserver sind (Server die über das Proxy-Bundle aufgerufen werden). Diese Änderung betrifft die Northbound-Seite von Apigee oder den Eingangspunkt in Apigee.
Nein. Vorhandene CNAME-Einträge funktionieren weiterhin wie erwartet.
Wenn Sie SSL verwenden, hat der erste Schritt keine Auswirkungen auf die vorhandene SSL-Konfiguration. Wir müssen jedoch eng mit Ihnen zusammenarbeiten, um sicherzustellen, dass SSL auf dem neuen Router richtig eingerichtet ist, bevor wir mit den Schritten 2 und 3 fortfahren.
Die Schritte 2 und 3 werden verzögert, bis die SNI-Unterstützung bestätigt wurde.
Wir erwarten keine Ausfallzeiten. Die Änderungen werden mit unserem Standardbereitstellungs modell in unseren vorhandenen Release-Fenstern implementiert.