Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. info
Ad agosto e settembre 2015, eseguiremo la migrazione dei router cloud e dei bilanciatori del carico di Apigee Edge a NGINX (pronunciato "Engine X"). NGINX, un server web open source, offre prestazioni ancora migliori e una maggiore concorrenza rispetto ai nostri router e bilanciatori del carico esistenti.
Cosa comporta per i nostri clienti cloud
In sostanza, 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 del software
Eseguiremo l'upgrade di tutti i router al nuovo router basato su NGINX sfruttando il nostro modello di deployment graduale 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 la procedura di rimozione del livello del bilanciatore del carico esistente prima negli ambienti non di produzione. I bilanciatori del carico di produzione rimarranno intatti e invariati durante questo passaggio. Prima di rimuovere i 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
Una volta completato il passaggio 2, determineremo una serie di finestre di manutenzione per rimuovere il livello del bilanciatore del carico negli ambienti di produzione utilizzando lo stesso approccio indicato nel passaggio 2 per garantire che il traffico API di runtime continui a funzionare come previsto.
Modifiche alla funzionalità del prodotto
Di seguito sono riportate 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 risolvere questo problema di deprecazione, 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", poiché non tocchiamo i bilanciatori del carico esistenti, che non modificheranno direttamente nessuno degli indirizzi 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 indirizzi IP potrebbero cambiare nell'ambito della logica di scalabilità (funzionalità esistente). Per questo motivo, non consigliamo di implementare configurazioni di liste consentite 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 comporta implicazioni per le liste consentite. Di conseguenza, collaboreremo a stretto contatto con te durante questi passaggi 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 degli endpoint di destinazione (server chiamati dal pacchetto proxy). Questa modifica riguarda il lato nord 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 a stretto contatto 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 fino a quando non verrà confermato il supporto SNI.
Non prevediamo tempi di inattività. Le modifiche verranno implementate utilizzando il nostro modello di deployment model durante le finestre di rilascio esistenti.