Stai visualizzando la documentazione di Apigee Edge.
Vai alla
documentazione di Apigee X. informazioni
Durante i mesi di agosto e settembre 2015, eseguiremo la migrazione dei nostri router cloud e bilanciatori del carico Apigee Edge a NGINX (pronunciato "Engine X"). NGINX, un server web open source, offre prestazioni ancora migliori e maggiore contemporaneità rispetto ai bilanciatori del carico e ai router esistenti.
Cosa comporta tutto ciò per i nostri clienti cloud
Il punto è che questa modifica deve essere trasparente per te e non richiede alcun intervento da parte tua, se non la verifica che i tuoi sistemi funzionino come previsto. Di seguito sono riportate le descrizioni dei passaggi che seguiremo, insieme alle risposte ad alcune domande frequenti.
Passaggio 1 - Aggiornamento software
Eseguiremo l'upgrade di tutti i router al nuovo router basato su NGINX sfruttando il nostro modello di deployment a fasi per garantire che i servizi non siano interessati da questa attività.
Passaggio 2: rimuovi il livello del bilanciatore del carico negli ambienti non di produzione
Con il nuovo router NGINX che gestisce la funzionalità di bilanciamento del carico, inizieremo prima il processo di rimozione del livello del bilanciatore del carico esistente negli ambienti non di produzione. Durante questo passaggio, i bilanciatori del carico di produzione rimarranno invariati e invariati. Prima di rimuovere i bilanciatori del carico esistenti, adotteremo un approccio esaustivo per garantire che il traffico funzioni come previsto. Per completare questo passaggio non è richiesta alcuna azione da parte tua. Tuttavia, devi segnalare eventuali problemi ad Apigee e lavoreremo con te per risolverli prima di procedere con il Passaggio 3.
Passaggio 3: rimuovi il livello del bilanciatore del carico negli ambienti di produzione
Al completamento del passaggio 2, determiniamo un insieme di periodi di manutenzione per rimuovere il livello del bilanciatore del carico negli ambienti di produzione, utilizzando lo stesso approccio menzionato nel passaggio 2, per garantire che il traffico API di runtime continui a funzionare come previsto.
Modifiche alla funzionalità del prodotto
Ecco alcune modifiche alla funzionalità del prodotto con il passaggio a NGINX.
Deprecata
Le seguenti proprietà non sono più supportate in ProxyEndpoints:
- allow.http10
- allow.http11
- allow.http.method.*
- allow.POST.without.content.length
- allow.PUT.without.content.length
Per risolvere questo problema, consulta il seguente articolo della community: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html.
Domande frequenti
Di seguito sono riportate le risposte ad alcune domande frequenti sulla migrazione NGINX.
Durante il passaggio 1, la risposta è "No" perché non stiamo toccando i bilanciatori del carico esistenti, il che non modificherà direttamente nessuno degli IP che gestiscono il traffico. Tuttavia, data la natura del servizio di bilanciamento del carico Amazon Web Services (AWS), si applicano le normali regole di scalabilità, il che significa che gli IP potrebbero cambiare come parte della logica di scalabilità (funzionalità esistente). Per questo motivo, non consigliamo di implementare le configurazioni di inserimento nella lista consentita in direzione nord con la suite di prodotti Apigee Edge. Durante i passaggi 2 e 3, la rimozione del bilanciatore del carico e dei relativi indirizzi IP associati comporta implicazioni per la lista consentita. Di conseguenza, ci coordineremo a stretto contatto con te durante queste fasi per garantire una transizione senza problemi fornendo un nuovo insieme di indirizzi IP per cui consentire l'accesso.
Non sono necessarie modifiche, supponendo che i server di origine siano i server endpoint di destinazione (server chiamati dal bundle proxy). Questa modifica avviene sul lato nord di Apigee o del punto di ingresso in Apigee.
No. Le voci CNAME esistenti continueranno a funzionare come previsto.
Se utilizzi SSL, il passaggio iniziale non influirà sulla configurazione SSL esistente. Tuttavia, dovremo coordinarci a stretto contatto con te per garantire che SSL sia configurato correttamente sul nuovo router prima di procedere con i passaggi 2 e 3.
I passaggi 2 e 3 verranno ritardati fino alla conferma del supporto SNI.
Non prevediamo tempi di inattività. Le modifiche verranno implementate utilizzando il nostro modello di deployment standard durante i periodi di rilascio esistenti.