Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. info
Ad agosto e settembre 2015 eseguiremo la migrazione dei router e dei bilanciatori di carico cloud di Apigee Edge a NGINX (pronunciato "Engine X"). NGINX, un server web open source, offre prestazioni ancora migliori e una concorrenza superiore rispetto ai nostri bilanciatori del carico e router esistenti.
Cosa significa per i nostri clienti cloud
In sostanza, questa modifica dovrebbe essere trasparente per te e non richiede alcun intervento da parte tua, a parte la verifica del funzionamento dei tuoi sistemi 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 implementazione 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 prima il processo di rimozione del livello di bilanciamento del carico esistente nei tuoi ambienti non di produzione. I bilanciatori del carico di produzione rimarranno 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 lavoreremo insieme 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 un insieme di finestre di manutenzione per rimuovere il livello del bilanciatore del carico negli ambienti di produzione utilizzando lo stesso approccio descritto nel passaggio 2 per garantire che il traffico delle 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 aggirare questo ritiro, 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 a NGINX.
Durante il passaggio 1, la risposta è "No", poiché non modifichiamo i bilanciatori del carico esistenti, il che non cambierà direttamente nessuno degli IP che generano 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 possono cambiare nell'ambito della logica di scalabilità (funzionalità esistente). Per questo motivo, sconsigliamo 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 comporta 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 target (server chiamati dal bundle proxy). Questa modifica si trova sul lato nord di Apigee o sul 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 fino alla conferma del supporto di SNI.
Non prevediamo tempi di riposo. Le modifiche verranno implementate utilizzando il nostro modello di deployment standard durante le finestre di rilascio esistenti.