Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info
Im August und September 2015 migrieren wir unsere Apigee Edge-Cloudrouter und Load Balancer zu NGINX (ausgesprochen „Engine X“). NGINX ist ein Open-Source-Webserver, der eine noch bessere Leistung und eine höhere Parallelität als unsere vorhandenen Load Balancer und Router bietet.
Was bedeutet das für unsere Cloud-Kunden?
Diese Änderung sollte für Sie transparent sein und Sie müssen nichts weiter tun, als zu prüfen, ob Ihre Systeme wie erwartet funktionieren. Im Folgenden finden Sie eine Beschreibung der Schritte, die wir unternehmen, sowie Antworten auf einige häufig gestellte Fragen.
Schritt 1: Software aktualisieren
Wir führen ein Upgrade aller Router auf den neuen NGINX-basierten Router durch. Dabei nutzen wir unser Phasenmodell für die Bereitstellung, um sicherzustellen, dass die Dienste von dieser Aktivität nicht beeinträchtigt werden.
Schritt 2: Load Balancer-Ebene in nicht produktiven Umgebungen entfernen
Da die Load Balancing-Funktionen vom neuen NGINX-Router übernommen werden, beginnen wir zuerst damit, die vorhandene Load Balancer-Ebene in Ihren nicht produktionsrelevanten Umgebungen zu entfernen. Produktions-Load Balancer bleiben während dieses Schritts unverändert. Vor dem Entfernen vorhandener Load Balancer prüfen wir gründlich, ob der Traffic wie erwartet funktioniert. Sie müssen nichts weiter tun. Sie sollten jedoch alle Probleme an Apigee melden. Wir arbeiten dann gemeinsam mit Ihnen an der Behebung, bevor Sie mit Schritt 3 fortfahren.
Schritt 3: Load Balancer-Ebene in Produktionsumgebungen entfernen
Nach Abschluss von Schritt 2 legen wir Wartungsfenster fest, in denen wir die Load Balancer-Ebene in den Produktionsumgebungen entfernen. Dabei verwenden wir denselben Ansatz wie in Schritt 2, um sicherzustellen, dass der API-Traffic während der Laufzeit weiterhin wie erwartet funktioniert.
Änderungen an der Produktfunktion
Im Folgenden finden Sie einige Änderungen an den Produktfunktionen durch den Wechsel zu NGINX.
Verworfen
Die folgenden Properties 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 dazu, wie Sie diese Einstellung umgehen, finden Sie im folgenden Communityartikel: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html.
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 keine der IP-Adressen, die Traffic verarbeiten, direkt geändert. Aufgrund der Natur des Load Balancing-Dienstes von Amazon Web Services (AWS) gelten jedoch die normalen Skalierungsregeln. Das bedeutet, dass sich IP-Adressen im Rahmen der Skalierungslogik (vorhandene Funktion) ändern können. Aus diesem Grund empfehlen wir nicht, Konfigurationen für eine Zulassungsliste für ausgehende Verbindungen mit der Apigee Edge-Produktsuite zu implementieren. Bei den Schritten 2 und 3 hat das Entfernen des Load Balancers und der zugehörigen IP-Adressen Auswirkungen auf die Zulassungsliste. Wir werden uns daher während dieser Schritte eng mit Ihnen abstimmen, um eine reibungslose Umstellung zu ermöglichen. Dazu stellen wir Ihnen eine neue Reihe von IP-Adressen zur Verfügung, für die der Zugriff zugelassen werden soll.
Es sind keine Änderungen erforderlich, vorausgesetzt, die Ursprungsserver sind die Zielendpunktserver (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 gewohnt.
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 gehen nicht von einer Ausfallzeit aus. Die Änderungen werden mit unserem Standard-Bereitstellungsmodell während der bestehenden Releasezeiträume implementiert.