Come aggiornare automaticamente l'elenco dei server upstream di nginx quando il nome host di aws ec2 cambia o aumenta?

Voglio impostare il ridimensionamento automatico in AWS. Non voglio usare Elastic Load Balancer.

Il ridimensionamento automatico in Amazon crea istanze EC2 senza soluzione di continuità durante i picchi di domanda per mantenere le prestazioni e diminuisce automaticamente durante i periodi di pausa della domanda per ridurre al minimo i costi.

Poiché queste istanze EC2 vengono create automaticamente, i loro nomi host sono sconosciuti a NGINX.

Conosco e ho già installato upstream in nginx a 10 istanze EC2.

Voglio essere in grado di aggiungere / aggiornare / eliminare automaticamente i nomi dei server nella mia configurazione nginx upstream, quando il ridimensionamento automatico aggiunge / aggiorna / elimina le istanze EC2.

— Luis Lobo Borobia
fonte

Devi rimuovere "ridimensionamento automatico" dalla tua domanda. Il ridimensionamento automatico è un termine AWS. Penso che vuoi dire che vuoi ridimensionare automaticamente (orizzontalmente), aggiungendo più nodi upstream al tuo nginx che agisce come un LB, e stai chiedendo come modificare automaticamente la tua configurazione nginx quando i nodi upstream vengono aggiunti / cancellati / modificati. In tal caso, modifica la domanda di conseguenza.

— Talonx,

bene, in realtà, so cos'è il ridimensionamento automatico e lo dico. Voglio mescolare entrambi. Aggiornerò la domanda.

— Luis Lobo Borobia,

La domanda è più chiara ora, nel suo intento. Volevo votare per riaprire, ma non vedo un'opzione - suppongo di non avere ancora abbastanza rappresentante.

— Talonx,

Grazie @talonx Spero che altri possano votare per trovare la mia risposta

— Luis Lobo Borobia

Penso che puoi combinare le notifiche di ridimensionamento automatico AWS (fornite tramite SNS) - supponendo che restituisca il nome host dell'istanza appena creata / terminata - e una delle API nginx di terze parti per aggiornare e ricaricare la tua configurazione nginx. Scusate se sono vago: non ho molta familiarità con l'API di scalabilità automatica.

— Talonx,

Risposte:

Ciò può essere ottenuto utilizzando Amazon SDK (ho quasi finito, lo inserirò su github), utilizzando il servizio SNS, EC2 e Autoscaling.

Ho seguito i passaggi seguenti per raggiungere questo obiettivo:

Abilita la notifica HTTP e sottoscritto il mio server web.
Aggiunto un hook del ciclo di vita con battito cardiaco di 1 minuto (attendere 1 minuto prima di terminare) al mio gruppo di scalabilità automatica per terminare il server
Creato un file indice per analizzare il messaggio per rilevare che tipo di messaggio è (es. Avvia o Termina)
Una volta deciso il tipo di evento, ho richiesto a EC2 di ottenere l'ip privato dell'istanza
In caso di avvio attendere fino a quando non viene ricevuta l'intestazione 200, quindi aggiungere l'ip alla configurazione di nginx e ricaricare
In caso di Terminate rimuovere l'IP dalla configurazione e ricaricare nginx

Puoi trovare lo script qui https://github.com/singhupendra/aws-autoscale

— Upendra
fonte

Qualche possibilità che tu l'abbia pubblicato su github? Sto cercando di fare la stessa cosa e qualsiasi assistenza sarebbe apprezzata.

— Aaron,

si prega di utilizzare - github.com/singhupendra/aws-autoscale

— Upendra,

Grazie @talonx, ho fatto alcune ricerche, Amazon Autoscale ha un API per interrogare lo stato attuale del gruppo di scalabilità automatica ed enumera i suoi membri. Restituisce l'id dell'istanza ( http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/api_requests.html#query-example ), quindi puoi utilizzare gli strumenti di descrizione per ottenere il nome del server ( http: // docs .aws.amazon.com / AWSEC2 / latest / CommandLineReference / ApiReference-cmd-DescribeInstances.html ) e infine ricreare il file include upstream. Ho potuto avvertire le notifiche di ridimensionamento automatico per avviare un processo che esegue queste attività.

Non l'ho ancora implementato, ma è una strada da percorrere.

Si può anche usare Autocaling con SNS http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/ASGettingNotifications.html

— Luis Lobo Borobia
fonte

Questo è fondamentalmente quello che ho fatto. Ho scritto una sceneggiatura ruby che gira ogni N minuti. Utilizzando AWS SDK, esegue una query per i membri dell'ASG e, utilizzando un modello ERB, genera una nuova configurazione. Se la nuova configurazione è diversa dalla configurazione corrente, la copia in posizione e dice al demone (haproxy nel mio caso) di ricaricare la sua configurazione. Si noti che le istanze rimangono nell'ASG per un po 'dopo che sono state terminate, quindi assicurarsi che instance.status ==: in esecuzione. Si noti inoltre che se occorrono N minuti dopo l'avvio dell'istanza affinché serva le richieste, non utilizzarlo fino a ora> istanza.launch_time + N.

— Mark Wagner,

Grazie @ MarkWagner. C'è qualche possibilità che tu possa condividere quel copione da qualche parte? Gist, github? Grazie!

— Luis Lobo Borobia,

Hai avuto fortuna con questo script? C'è un esempio su github o altrove?

— Aaron,

No, ma al momento nginx-plus (la versione a pagamento) lo consente di più.

— Luis Lobo Borobia,

Non l'ho ancora implementato da solo, ma sto cercando di utilizzare la Riconfigurazione al volo di NGiNX Plus . Sto pensando che l'AMI o la gestione della configurazione (Puppet, Salt o simili) che imposta un'istanza di Auto Scaling Group, potrebbe raggiungere l'API di riconfigurazione di NGiNX (forse, tramite un nome di dominio Route53 interno, quindi nessun IP fisso sarebbe deve essere utilizzato) e aggiungersi al cluster upstream per il proxy inverso. Dopodiché il controllo di integrità incorporato di NGiNX subentrerebbe a tale istanza [aggiunta] e la lascerebbe nel caso in cui non fosse disponibile. Questa sembra la soluzione più pulita e non c'è alcun ritardo nell'aggiungere l'istanza, e quasi nessun ritardo nel lasciarla cadere poiché NGiNX Plus presenta un controllo dello stato fuori banda.

Questo approccio evita la necessità di impostare un sistema di individuazione automatica (Console, Serf o simili) che per configurazioni più piccole spesso sembra molto sovraccarico sia in termini di installazione / amministrazione che di istanze EC2 richieste. Il console, ad esempio, richiede che almeno tre istanze siano stabili. Il servo potrebbe forse essere eseguito sulle stesse istanze di ASG, ma c'è ancora il sovraccarico di mantenerlo, e se l'ASG si ridimensiona a una o due istanze, si perderebbe il quorum.

Infine, questo potrebbe essere combinato con la notifica automatica delle modifiche del gruppo di ridimensionamento automatico, forse sui server NGiNX che sono / sono utilizzati per il bilanciamento del carico. Un ascoltatore attivato da tale notifica (potrebbe essere ciò a cui si riferiva anche Upendra) potrebbe quindi aggiungere immediatamente la nuova istanza a NGiNX tramite l'API di modifica al volo. Oltre al costo di NGiNX Plus, questo fa meravigliarsi perché qualcuno dovrebbe usare Elastic Load Balancer con i suoi numerosi problemi in primo luogo.

Modifica 07-12-2015: ngx_openresty 's balancer-by-lua ( vedi questo thread GitHub ) offre un'altra possibile soluzione open source per l'aggiunta / rimozione a caldo di server dal gruppo upstream di NGiNX. Non l'ho ancora sperimentato da solo, ma volevo aggiungere una menzione qui per chiunque si imbattesse in questo post.

— Ville
fonte