Implementazione continua e scalabilità automatica AWS utilizzando Ansible (+ Docker?)

Question

Il sito Web della mia organizzazione è un'app Django in esecuzione su server Web front-end + alcuni server di elaborazione in background in AWS.

momento stiamo utilizzando Ansible per entrambi:

• configurazione del sistema (da un'immagine nuda OS)
• frequenti implementazioni di codice manualmente innescato.

Lo stesso playbook di Ansible è in grado di eseguire da zero una VM di Vagrant locale o un'istanza di produzione EC2.

Ora vogliamo implementare la scalabilità automatica in EC2 e ciò richiede alcune modifiche verso una filosofia "treat servers as cattle, not pets".

Il primo prerequisito era passare da un inventario Ansible gestito staticamente a uno dinamico, basato su API EC2, fatto.

La prossima grande domanda è come distribuire in questo nuovo mondo in cui le istanze di "throwaway" si presentano & nel bel mezzo della notte. Le opzioni mi viene in mente sono:

1. Cuocere un nuovo completamente dispiegata AMI per ogni distribuire, creare una nuova configurazione AS avvio e aggiornamento del gruppo come questo. Sembra molto, molto ingombrante, ma anche molto affidabile grazie all'approccio di lavagna pulita, e farà in modo che qualsiasi sistema modifichi il codice richiesto sarà qui. Inoltre, non sono necessari ulteriori passaggi per l'avvio dell'istanza, quindi è possibile eseguire più rapidamente &.
2. Utilizzare una base AMI che non cambia molto spesso, ottenere automaticamente l'ultimo codice dell'app da git all'avvio, avviare server web. Una volta completato, esegui le distribuzioni manuali secondo necessità, come prima. Ma cosa succede se il nuovo codice dipende da una modifica nella configurazione del sistema (nuovo pacchetto, permessi, ecc.)? Sembra che devi iniziare a occuparti delle dipendenze tra versioni di codice e versioni di sistema/AMI, mentre l'approccio "esegui una corsa completa" era più integrato e più affidabile. È più di un semplice mal di testa nella pratica?
3. Usa Docker? Ho una forte impressione che può essere utile, ma non sono ancora sicuro di come si adatti alla nostra immagine. Siamo un'app di front-end Django relativamente autonoma con solo RabbitMQ + memcache come servizi, che non avremo mai eseguito sullo stesso host in ogni caso. Quindi, quali benefici ci sono nella creazione di un'immagine Docker usando Ansible che contiene pacchetti di sistema + il codice più recente, piuttosto che avere Ansible lo faccia direttamente su un'istanza EC2?

Come si fa? Qualche visione/best practice? Grazie!

Answer 1

Questa domanda è basata su molte opinioni. Ma solo per darti la mia opinione, vorrei solo eseguire il prebaking delle AMI con Ansible e quindi utilizzare CloudFormation per distribuire i tuoi stack con la scalabilità automatica, il monitoraggio e le tue AMI precotte. Il vantaggio di questo è che se la maggior parte dello stack di applicazioni è pre-cotta nella scalabilità automatica AMI, UP si verificherà più rapidamente.

Docker è un altro approccio, ma a mio parere aggiunge un ulteriore livello nell'applicazione che potrebbe non essere necessario se si sta già utilizzando EC2. Docker può essere davvero utile se dici di voler containerizzare in un singolo server.Forse hai un po 'di capacità in più in un server e Docker ti permetterà di eseguire quella applicazione extra sullo stesso server senza interferire con quelli esistenti.

Detto questo, alcune persone trovano utile Docker non nel modo in cui ottimizzare le risorse in un singolo server, ma piuttosto in una sorta di modo che consente di pre-cuocere le applicazioni in contenitori. Pertanto, quando si distribuisce una nuova versione o un nuovo codice, tutto ciò che si deve fare è copiare/replicare questi contenitori docker sui server, quindi interrompere le vecchie versioni del contenitore e avviare le nuove versioni del contenitore.

I miei due centesimi.

Answer 2

Una soluzione ibrida può fornire il risultato desiderato. Memorizza l'immagine della finestra mobile in S3, preleva l'AMI con un semplice recupero e avvia lo script all'avvio (o lo passa in un AMI con dati utente). Il controllo della versione spostando l'immagine della testa nella versione più recente stabile, probabilmente potrebbe anche implementare stack di prova di nuove versioni rendendo lo script di recupero abbastanza intelligente da identificare quale versione della finestra mobile recuperare in base ai tag di istanza configurabili all'avvio dell'istanza.

Answer 3

È inoltre possibile utilizzare AWS CodeDeploy con AutoScaling e il server di build. Usiamo il plugin CodeDeploy per Jenkins.

Questa configurazione consente di:

1. eseguire la configurazione in Jenkins
2. upload S3 secchio
3. distribuire a tutti i EC2S uno per uno, che fanno parte del gruppo di auto-scaling AWS assegnato .

Tutto ciò con la semplice pressione di un pulsante!

Ecco il tutorial di AWS: Deploy an Application to an Auto Scaling Group Using AWS CodeDeploy