Perché le persone usano Puppet / Chef con Amazon Cloud Formation invece di usare solo CloudInit?

Stiamo progettando di utilizzare istanze AMI EC2 che non sono "preconfezionate". Cioè quando vengono avviati, sono installazioni nude di AWS Linux. Il nostro processo di bootstrap inserirà le varie installazioni di cui abbiamo bisogno, ad esempio python, tomcat. Avremo minimo 3 istanze e massimo 8.

Dati questi requisiti, sarebbe utile utilizzare Puppet / Chef anziché utilizzare Amazon Cloud Formation (CloudInit)?

La cosa migliore che posso vedere è che se usassimo Puppet, avremmo una programmazione dichiarativa che è più facile da controllare per vedere cosa sta succedendo rispetto a uno script. Inoltre CloudInit ha un limite di dimensione dello script di 16k che potremmo o meno incontrare.

Qualcuno è passato da CloudInit a Puppet o Chef per un motivo specifico che possono fornire qui in risposta alla mia domanda?

C'è un vantaggio rispetto a CloudInit? Sì, assolutamente, molti di loro!

Certo, puoi scrivere dall'alto verso il basso una volta che CloudInit esegue il provisioning di un server. Ma cosa succede quando è necessario modificare un file di configurazione, aggiungere un utente, aggiornare un pacchetto o installare un nuovo pacchetto? Finirai per accedere ai server o scrivere script per farlo, e inevitabilmente uno stato incongruo dei server.

CloudInit non è la gestione della configurazione. Se si sceglie di iniziare a utilizzare il software di gestione della configurazione, utilizzare cloud init per una sola attività: per avviare il Puppet / Chef / altro agente.

Puppet non ti aiuta solo ad automatizzare l'installazione di pacchetti, a configurare le chiavi ssh o a ottimizzare l'heap di Tomcat. Assicura lo stato delle cose. Quando uno sviluppatore risolve la risoluzione dei problemi di un'app Java alle 3 del mattino e modifica la configurazione di Tomcat, Puppet la ripristinerà. Puoi cambiare rapidamente la versione di Python per tutti o gruppi di nodi e se qualcuno installa una versione diversa, Puppet la cambierà di nuovo.

Quando lo stack dell'applicazione cambia e inizi a utilizzare, ad esempio RabbitMQ, Jetty o un nuovo RDBMS, puoi facilmente testare e distribuire le modifiche su decine o migliaia di server.

Esistono molti altri motivi per utilizzare il software di gestione della configurazione, come il reporting back-end, il controllo e la conformità della sicurezza.

L'intero punto della gestione della configurazione è avviare le macchine in modo prevedibile e coerente. CloudFormation e cloudinit sono ottimi quando sei limitato esclusivamente ad AWS (anche se il debug dei modelli CloudFormation è un'esperienza miserabile ), ma per quanto riguarda le applicazioni che utilizzano sia le risorse del data center che AWS, o ambienti di test locali o macchine di sviluppo?

Se esisti esclusivamente in AWS, suppongo che potresti farla franca con cloudinit e nient'altro, ma non sono convinto che sia realistico per applicazioni di qualsiasi scala (Netflix, ad esempio, pre-prepara le loro AMI utilizzando le tecnologie OSS che hanno scritto e rilasciato al mondo; considera questo video per i dettagli). Le applicazioni ad alta disponibilità sono transregionali, spesso basate su VPC, tendono a eseguire il backup nei data center attraverso VPN e questo non tocca nemmeno gli ambienti demo, di staging, di test o di sviluppo. In qualità di persona incaricata di eseguire il provisioning delle macchine, le ultime cose che voglio fare sono ripetere il lavoro o rimanere bloccato durante il debug di più metodi di provisioning.

Quindi Chef o Puppet. Funzionano altrettanto bene per AWS come per il mio data center, e altrettanto bene per la mia macchina di sviluppo che esegue Vagrant come fanno per gli ambienti demo di cui ho bisogno occasionalmente al volo. Preferisco di gran lunga avviare Chef o Puppet da cloudinit piuttosto che mantenere sia cloudinit che Chef o Puppet.

Per i server usa e getta, diciamo che corri dietro un gruppo di scalabilità automatica, direi che cloudinit è probabilmente sufficiente. gli script della shell di Linux o gli script di Windows PowerShell dovrebbero fare il trucco.

Se è un server di lunga durata che prevedi di gestire, forse chef, pupazzo o docker potrebbero darti un vantaggio, come menzionato nella risposta accettata. Se non riesci a vedere il vantaggio dopo averli usati, probabilmente non hai bisogno dello strumento.

Nella mia esperienza, ci sono cose semplici che possono essere fatte facilmente con gli strumenti GUI pronti all'uso forniti da AWS, ma man mano che ti avvicini a cose più complesse inizi a scoprire che ci sono limitazioni a ciò che puoi fare con i loro strumenti.

A quel punto, puoi fermarti o trovare altri strumenti (come Chef o Puppet) che possono aiutarti a raggiungere quegli obiettivi più complessi e fare le cose più semplici.

La tua scelta.