Modello server immutabile con Docker / Ansible vs. Ansible, Puppet e Foreman in AWS?

Stiamo incontrando un argomento interessante e stiamo cadendo in due campi. Sono interessato a problemi particolari con l'idea o il pensiero che potremmo perdere. Davvero, tutto ciò che può aiutarci a prendere una decisione o sottolineare cose che non stiamo prendendo in considerazione. So che questo aggira un po 'da vicino la regola "nessuna opinione", ma spero che sia ancora una domanda accettabile. Ci scusiamo anche per la lunghezza, c'è un bel po 'di sfumature.

1) Un lato (il mio - non sono senza parzialità) trova il modello di server immutabile molto interessante per i sistemi cloud. A tal fine, abbiamo prototipato spostando tutti i componenti della nostra infrastruttura in Docker. Le nostre applicazioni personalizzate si basano direttamente su Jenkins in immagini Docker che vengono distribuite in un registro Docker locale. Quindi abbiamo creato un ampio set di ruoli Ansible e un playbook in grado di raggiungere un server vuoto, installare Docker e quindi dire a Docker di installare tutti i container in base alle esigenze. Dopo un paio di minuti, l'intera app e tutta la sua infrastruttura di supporto sono cablate e funzionanti - registrazione, monitoraggio, creazione / popolamento del database, ecc. La macchina finita è un ambiente di controllo qualità o di sviluppo autonomo con una copia esatta del applicazione. Il nostro piano per ridimensionarlo sarebbe quello di creare nuovi Playbook per costruire nuovi server AWS da un'AMI attendibile di base (probabilmente un'immagine molto spoglia), eseguire distribuzioni rolling dell'applicazione di produzione per gestire la gestione e le versioni della configurazione e generalmente non modificare mai più i server - fateli di nuovo. Non mi preoccupo di ottenere ciò che ho descritto lavorando in pratica - solo se si tratta di un modello ragionevole.

2) L'altro campo vuole usare Puppet per gestire la gestione della configurazione, Ansible per distribuire le nostre applicazioni personalizzate che sono tarball generate dal nostro processo di compilazione, Foreman per gestire l'attivazione e la gestione del processo nel suo insieme e Katello per fare un po 'di base gestione delle immagini. Le versioni implicherebbero la modifica della configurazione di Puppet in base alle esigenze e Ansible implementando componenti aggiornati con un certo grado di coordinamento di Foreman. I server verrebbero costruiti ragionevolmente rapidamente se ne avessimo bisogno di nuovi, ma l'intento non è di renderli usa e getta come parte del processo standard. Questo è più vicino al modello di server Phoenix anche se con una lunga durata.

Quindi la mia domanda arriva davvero a questo: il modello di server immutabile con gli strumenti come li ho descritti sopra è realmente realistico come sembra? Adoro l'idea che il nostro processo di gestione temporanea possa letteralmente creare un intero clone di applicazioni in tempo reale, lasciare che il QA lo martelli, quindi basta girare l'archiviazione del database e alcune impostazioni DNS per renderlo attivo.

O in pratica il modello di server immutabile fallisce? Abbiamo una buona esperienza con entrambi gli ambienti AWS e cloud, quindi non è questo il problema, piuttosto una questione di come ottenere un'app ragionevolmente sofisticata distribuita in modo affidabile in futuro. Questo è di particolare interesse poiché rilasciamo abbastanza frequentemente.

Abbiamo Ansible che fa la maggior parte delle cose necessarie, ad eccezione della creazione effettiva di server EC2 per noi e non è difficile. Ho difficoltà a capire perché in questo modello BISOGNO davvero di Puppet / Foreman / Katello. Docker è molto più pulito e semplice degli script di distribuzione personalizzati in qualsiasi strumento là fuori che posso dire. Ansible sembra molto più semplice da usare rispetto a Puppet quando smetti di preoccuparti di doverli configurare in situ e semplicemente ricostruirli di nuovo con la nuova configurazione. Sono un fan del preside dei KISS, in particolare nell'automazione in cui la legge di Murphy imperversa. Meno macchinari, migliore IMO.

Eventuali pensieri / commenti o suggerimenti sull'approccio sarebbero molto apprezzati!

Nella nostra azienda abbiamo implementato con successo Puppet sull'infrastruttura legacy del cliente. Stiamo anche utilizzando i contenitori Docker per eseguire un servizio dedicato (che in realtà è una vecchia applicazione tagliata e attorcigliata per adattarsi ai contenitori).
La prima volta che ho iniziato a lavorare con loro non ero contento dei container (sì ... l'app da 30kb diventa un'immagine pesante da 200 MB) ma quando ho dovuto ricreare l'intero ambiente dopo un piccolo disastro ho cambiato idea. Penso che Docker sia stato inventato esattamente per questo: distribuzioni veloci e spesso senza preoccupazioni per la configurazione del server. Se si progettano correttamente i contenitori, è possibile passare facilmente tra provider cloud, laptop degli sviluppatori e datacenter di colocation. Perché tutto ciò che serve è una scatola Linux vanilla con demone Docker.

• Nello scenario 1) hai tutto in un unico posto (intendo uno perché con Docker avrai codice E configurazione nello stesso repository) facile da gestire, leggere e distribuire.
  
• Nello scenario 2) è necessario memorizzare le parti di configurazione per 3 diversi (!) Strumenti in un repository e il codice dell'applicazione nell'altro, il che rende le cose più complicate

Nel mio precedente progetto usavo anche Puppet e la mia esperienza finora è che il server immutabile è realizzabile piuttosto con Docker che con Puppet o Chef. Credo che gli strumenti di gestione della configurazione siano più utili per i provider di cloud piuttosto che per il team di sviluppo.

Ecco i miei 2 centesimi di euro.

Le 2 opzioni che proponi sono valide per ottenere (un qualche tipo di) immutabilità.
Penso che dovresti scegliere quello con cui ti senti più a tuo agio.
Tuttavia, da quello che scrivi sembra che non ci sia ancora consenso.
Forse è necessaria una terza opzione? ;)

Tuttavia, poiché tale immutabilità non è un obiettivo ma un mezzo per garantire altre proprietà (nessuna deriva di configurazione, migliore stabilità, ...).
Dichiarerei chiaramente i miei obiettivi, metterei alcune metriche per convalidarli e fare alcuni test usando le 2 opzioni. Avresti quindi alcune cifre per selezionare quella più allineata alla tua attività.

In bocca al lupo!