Distribuzione continua e scalabilità automatica di 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.

Attualmente stiamo utilizzando Ansible per entrambi:

• configurazione del sistema (da un'immagine semplice del sistema operativo)
• frequenti distribuzioni di codice attivate manualmente.

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

Ora vogliamo implementare la scalabilità automatica in EC2 e ciò richiede alcune modifiche verso a "tratta i server come bestiame, non come animali domestici" filosofia.

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

La prossima grande domanda è come implementarla in questo nuovo mondo in cui le istanze usa e getta vanno su e giù nel cuore della notte.Le opzioni che mi vengono in mente sono:

1. Crea una nuova AMI completamente distribuita per ogni distribuzione, crea una nuova configurazione di AS Launch e aggiorna il gruppo AS con quella.Sembra molto, molto complicato, ma anche molto affidabile grazie all'approccio pulito e garantirà che qualsiasi modifica al sistema richiesta dal codice sarà qui.Inoltre, non sono necessari passaggi aggiuntivi all'avvio dell'istanza, quindi attiva e funzionante più rapidamente.
2. Utilizza un'AMI di base questo non cambia molto spesso, ottieni automaticamente il codice dell'app più recente da git all'avvio, avvia il server web.Una volta terminato, esegui semplicemente le distribuzioni manuali secondo necessità, come prima.Ma cosa succede se il nuovo codice dipende da un cambiamento nella configurazione del sistema (nuovo pacchetto, permessi, ecc.)?Sembra che tu debba iniziare a prenderti cura delle dipendenze tra le versioni del codice e le versioni del sistema/AMI, mentre l'approccio "basta eseguire un'esecuzione ansible completa" era più integrato e più affidabile.È qualcosa di più di un semplice mal di testa nella pratica?
3. Utilizzare Docker? Ho la forte sensazione che possa essere utile, ma non sono ancora sicuro di come si adatterebbe alla nostra immagine.Siamo un'app front-end Django relativamente autonoma con solo RabbitMQ + memcache come servizi, che comunque non eseguiremo mai sullo stesso host.Quindi quali vantaggi ci sono nel creare un'immagine Docker utilizzando Ansible che contiene pacchetti di sistema + codice più recente, piuttosto che fare in modo che Ansible lo faccia direttamente su un'istanza EC2?

Come si fa ?Eventuali approfondimenti/migliori pratiche?Grazie !

Answer 1

Questa domanda è molto basata sull'opinione.Ma solo per darti la mia opinione, preferirei semplicemente precostituire le AMI con Ansible e quindi utilizzare CloudFormation per distribuire i tuoi stack con Autoscaling, Monitoraggio e le tue AMI precotte.Il vantaggio di ciò è che se la maggior parte dello stack dell'applicazione è preintegrata nell'AMI, la scalabilità automatica UP accadrà più velocemente.

Docker è un altro approccio ma a mio avviso aggiunge un livello aggiuntivo alla tua applicazione di cui potresti non aver bisogno se stai già utilizzando EC2.Docker può essere davvero utile se dici di voler containerizzare in un singolo server.Forse hai una capacità extra in un server e Docker ti consentirà di eseguire quell'applicazione extra sullo stesso server senza interferire con quelle esistenti.

Detto questo, alcune persone trovano Docker utile non nel senso di ottimizzare le risorse in un singolo server, ma piuttosto in un certo senso che ti consente di pre-cotturare le tue applicazioni in contenitori.Pertanto, quando distribuisci una nuova versione o un nuovo codice, tutto ciò che devi fare è copiare/replicare questi contenitori docker sui tuoi 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ò darti il risultato desiderato.Conservare l'immagine della testata della testa in S3, prebake l'AMI con un semplice recupero di recupero e eseguire lo script all'inizio (o passalo in un AMI azionario con dati utente).Controllo della versione Spostando l'immagine della testina sulla tua ultima versione stabile, è probabile che sia probabilmente anche implementare le pile di test di nuove versioni rendendo lo script di recupero abbastanza intelligente per identificare quale versione Docker per recuperare in base a tag di istanza che sono configurabili in un'istanza.

Answer 3

You can also use AWS CodeDeploy with AutoScaling and your build server. We use CodeDeploy plugin for Jenkins.

This setup allows you to:

1. perform your build in Jenkins
2. upload to S3 bucket
3. deploy to all the EC2s one by one which are part of the assigned AWS Auto-Scaling group.

All that with a push of a button!

Here is the AWS tutorial: Deploy an Application to an Auto Scaling Group Using AWS CodeDeploy