Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. info
Durante agosto e settembre 2015, eseguiremo la migrazione dei nostri router cloud e dei bilanciatori del carico Apigee Edge a NGINX (pronunciato "Engine X"). NGINX, un server web open source, offre prestazioni ancora migliori e una concorrenza più elevata rispetto ai nostri bilanciatori del carico e router esistenti.
Cosa comporta per i nostri clienti cloud
Il risultato finale è che questa modifica dovrebbe essere trasparente per te e non richiede alcuna azione da parte tua, se non la verifica che i tuoi sistemi funzionino come previsto. Di seguito sono riportate le descrizioni dei passaggi che eseguiremo, insieme alle risposte ad alcune domande frequenti.
Passaggio 1: aggiornamento software
Eseguiremo l'upgrade di tutti i router al nuovo router basato su NGINX utilizzando il nostro modello di implementazione in fasi per garantire che i servizi non vengano 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 il processo di rimozione del livello di bilanciamento del carico esistente prima nel tuo ambiente o nei tuoi ambienti non di produzione. I bilanciatori del carico di produzione rimarranno intatti e invariati durante questo passaggio. Prima della rimozione dei bilanciatori del carico esistenti, adotteremo un approccio esaustivo per garantire che il traffico funzioni come previsto. Non è richiesta alcuna azione da parte tua per completare questo passaggio. Tuttavia, devi segnalare eventuali problemi ad Apigee e collaboreremo 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 termine del passaggio 2, determineremo una serie di finestre di manutenzione per rimuovere il livello del bilanciamento 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.
Deprecato
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 ovviare a questo ritiro, consulta il seguente articolo della community: Proxy Endpoint HTTP allow method properties not working.
Domande frequenti
Di seguito sono riportate le risposte ad alcune domande frequenti sulla migrazione di NGINX.
Durante il passaggio 1, la risposta è "No" perché non tocchiamo i bilanciatori del carico esistenti, che non modificheranno direttamente nessuno degli IP che gestiscono il traffico. Tuttavia, data la natura del servizio di bilanciamento del carico di Amazon Web Services (AWS), si applicano le normali regole di scalabilità, il che significa che gli IP potrebbero cambiare nell'ambito della logica di scalabilità (funzionalità esistente). Per questo motivo, non consigliamo di implementare configurazioni di liste consentite in uscita con la suite di prodotti Apigee Edge. Durante i passaggi 2 e 3, la rimozione del bilanciatore del carico e dei relativi indirizzi IP ha implicazioni per la lista consentita. Di conseguenza, ci coordineremo strettamente con te durante questi passaggi per garantire una transizione senza problemi fornendo un nuovo insieme di indirizzi IP per i quali 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 riguarda il lato Northbound di Apigee o il 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 strettamente con te per assicurarci che SSL sia configurato correttamente sul nuovo router prima di procedere con i passaggi 2 e 3.
I passaggi 2 e 3 verranno ritardati finché non verrà confermato il supporto SNI.
Non prevediamo tempi di inattività. Le modifiche verranno implementate utilizzando il nostro modello di deployment standard durante le finestre di rilascio esistenti.