Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen. info
Im August und September 2015 migrieren wir unsere Apigee Edge-Cloudrouter 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 dass Sie überprüfen, ob Ihre Systeme wie erwartet funktionieren. Im Folgenden finden Sie Beschreibungen der Schritte, die wir unternehmen werden, sowie Antworten auf einige häufig gestellte Fragen.
Schritt 1: Software aktualisieren
Wir stellen alle Router auf den neuen NGINX-basierten Router um. Dabei nutzen wir unser stufenweises Bereitstellungsmodell, um sicherzustellen, dass die Dienste durch diese Maßnahme nicht beeinträchtigt werden.
Schritt 2: Load-Balancer-Tier in Nicht-Produktionsumgebungen entfernen
Da der neue NGINX-Router die Load-Balancing-Funktion übernimmt, beginnen wir zuerst mit dem Entfernen der vorhandenen Load-Balancer-Ebene in Ihren Nichtproduktionsumgebungen. Die Produktions-LoadBalancer bleiben in diesem Schritt intakt und unverändert. Vor dem Entfernen vorhandener Load Balancer werden wir umfassende Maßnahmen ergreifen, um sicherzustellen, dass der Traffic wie erwartet funktioniert. Sie müssen nichts weiter tun. Sie sollten jedoch alle Probleme an Apigee melden. Wir arbeiten dann mit Ihnen zusammen, um die Probleme zu beheben, bevor Sie mit Schritt 3 fortfahren.
Schritt 3: Load-Balancer-Tier in Produktionsumgebungen entfernen
Nach erfolgreichem Abschluss von Schritt 2 legen wir eine Reihe von Wartungszeiträumen fest, um die Load-Balancer-Ebene in Produktionsumgebungen zu entfernen. Dabei gehen wir wie in Schritt 2 beschrieben vor, um sicherzustellen, dass der API-Traffic zur Laufzeit weiterhin wie erwartet funktioniert.
Änderungen an der Produktfunktionalität
Im Folgenden finden Sie einige Änderungen an der Produktfunktionalität durch die Umstellung auf NGINX.
Verworfen
Die folgenden Attribute 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 im Community-Artikel Proxy Endpoint HTTP allow method properties not working.
Häufig gestellte Fragen
Nachfolgend 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 ändert sich keine der IP-Adressen, über die Traffic bereitgestellt wird. Aufgrund der Funktionsweise des Load-Balancing-Dienstes von Amazon Web Services (AWS) gelten jedoch normale Skalierungsregeln. Das bedeutet, dass sich IP-Adressen im Rahmen der Skalierungslogik ändern können (bestehende Funktion). Daher empfehlen wir nicht, Zulassungslistenkonfigurationen für Northbound mit der Apigee Edge-Produktfamilie zu implementieren. Bei den Schritten 2 und 3 gibt es Auswirkungen auf die Zulassungsliste, wenn der Load-Balancer und die zugehörigen IP-Adressen entfernt werden. Daher werden wir uns in diesen Schritten eng mit Ihnen abstimmen, um einen reibungslosen Übergang zu gewährleisten. Dazu stellen wir eine neue Reihe von IP-Adressen bereit, für die der Zugriff erlaubt werden muss.
Es sind keine Änderungen erforderlich, sofern die Ursprungsserver die Zielendpunktserver sind (Server, die vom Proxy-Bundle aufgerufen werden). Diese Änderung betrifft die Northbound-Seite von Apigee oder den Ingress-Punkt 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 uns jedoch eng mit Ihnen abstimmen, um sicherzustellen, dass SSL auf dem neuen Router richtig eingerichtet ist, bevor wir mit Schritt 2 und 3 fortfahren.
Die Schritte 2 und 3 werden verzögert, bis die SNI-Unterstützung bestätigt wurde.
Wir gehen nicht davon aus, dass es zu Ausfallzeiten kommt. Die Änderungen werden während unserer bestehenden Releasezeiträume mit unserem Standardbereitstellungsmodell implementiert.