Wyświetlasz dokumentację Apigee Edge.
Przejdź do
dokumentacji Apigee X. info
W sierpniu i wrześniu 2015 r. migrujemy nasze routery i systemy równoważenia obciążenia w chmurze Apigee Edge do NGINX (wymawiane „Engine X”). NGINX, serwer internetowy typu open source, zapewnia jeszcze lepszą wydajność i większą współbieżność niż nasze dotychczasowe systemy równoważenia obciążenia i routery.
Co to oznacza dla naszych klientów korzystających z chmury
Ta zmiana powinna być dla Ciebie niezauważalna i nie wymaga żadnych działań z Twojej strony poza sprawdzeniem, czy Twoje systemy działają zgodnie z oczekiwaniami. Poniżej znajdziesz opis czynności, które podejmiemy, oraz odpowiedzi na niektóre z najczęstszych pytań.
Krok 1. Aktualizacja oprogramowania
Uaktualnimy wszystkie routery do nowego routera opartego na NGINX, korzystając z naszego modelu wdrożenia etapowego aby zapewnić, że ta operacja nie wpłynie na działanie usług.
Krok 2. Usunięcie warstwy systemu równoważenia obciążenia w środowiskach innych niż produkcyjne
Gdy nowy router NGINX będzie obsługiwał funkcję równoważenia obciążenia, rozpoczniemy proces usuwania dotychczasowej warstwy systemu równoważenia obciążenia w Twoich środowiskach innych niż produkcyjne. W tym kroku systemy równoważenia obciążenia w środowisku produkcyjnym pozostaną nienaruszone. Zanim usuniemy dotychczasowe systemy równoważenia obciążenia, dokładnie sprawdzimy, czy ruch działa zgodnie z oczekiwaniami. Aby wykonać ten krok, nie musisz podejmować żadnych działań. Jeśli jednak zauważysz jakieś problemy, zgłoś je do Apigee. Przed przejściem do kroku 3 pomożemy Ci je rozwiązać.
Krok 3. Usunięcie warstwy systemu równoważenia obciążenia w środowiskach produkcyjnych
Po pomyślnym wykonaniu kroku 2 określimy zestaw okien konserwacyjnych, aby usunąć warstwę systemu równoważenia obciążenia w środowiskach produkcyjnych, stosując tę samą metodę co w kroku 2 . Dzięki temu ruch API w czasie działania będzie nadal działał zgodnie z oczekiwaniami.
Zmiany w funkcjach produktu
Oto niektóre zmiany w funkcjach produktu po przejściu na NGINX.
Wycofano
Te właściwości nie są już obsługiwane w ProxyEndpoints:
- allow.http10
- allow.http11
- allow.http.method.*
- allow.POST.without.content.length
- allow.PUT.without.content.length
Aby obejść ten problem, przeczytaj ten artykuł w społeczności: Proxy Endpoint HTTP allow method properties not working (Właściwości metody HTTP allow w punkcie końcowym proxy nie działają).
Najczęstsze pytania
Poniżej znajdziesz odpowiedzi na niektóre z najczęstszych pytań dotyczących migracji do NGINX.
W kroku 1 odpowiedź brzmi „Nie”, ponieważ nie będziemy modyfikować dotychczasowych systemów równoważenia obciążenia, które nie będą bezpośrednio zmieniać żadnych adresów IP obsługujących ruch. Jednak ze względu na charakter usługi równoważenia obciążenia Amazon Web Services (AWS) obowiązują normalne reguły skalowania, co oznacza, że adresy IP mogą się zmieniać w ramach logiki skalowania (dotychczasowa funkcja). Dlatego nie zalecamy wdrażania konfiguracji list dozwolonych w kierunku północnym w pakiecie produktów Apigee Edge product suite. W krokach 2 i 3 usunięcie systemu równoważenia obciążenia i powiązanych z nim adresów IP będzie miało wpływ na listę dozwolonych. W związku z tym będziemy ściśle współpracować z Tobą w tych krokach, aby zapewnić płynne przejście, udostępniając nowy zestaw adresów IP, do których należy zezwolić na dostęp.
Nie musisz wprowadzać żadnych zmian, jeśli serwery źródłowe są serwerami punktów końcowych docelowych (serwerami wywoływanymi z pakietu proxy). Ta zmiana dotyczy strony północnej Apigee lub punktu wejścia do Apigee.
Nie. Dotychczasowe wpisy CNAME będą nadal działać zgodnie z oczekiwaniami.
Jeśli używasz protokołu SSL, pierwszy krok nie wpłynie na dotychczasową konfigurację SSL. Przed przejściem do kroków 2 i 3 musimy jednak ściśle współpracować z Tobą, aby upewnić się, że protokół SSL jest prawidłowo skonfigurowany na nowym routerze.
Kroki 2 i 3 zostaną opóźnione do czasu potwierdzenia obsługi SNI.
Nie przewidujemy żadnych przestojów. Zmiany zostaną wdrożone przy użyciu naszego standardowego modelu wdrożenia w ramach dotychczasowych okien wydania.