Perché non utilizzare lo strumento di gestione della configurazione anziché Dockerfile?

Sono abbastanza nuovo su Docker e sugli strumenti di gestione della configurazione.

All'inizio ho iniziato a scrivere script bash per eseguire il provisioning dei miei box Vagrant per le mie macchine di sviluppo, ma ora sono passato a utilizzare Chef per quello in modo da poter utilizzare la stessa fonte per eseguire il provisioning di ambienti di sviluppo e produzione per provare a renderli simili il più possibile.

Da quando ho iniziato a usare Chef, sono arrivato a godermi l'aspetto DRY di non dover copiare e incollare le linee di script di shell da un progetto all'altro, la possibilità di eseguire il provisioning di macchine che eseguono una varietà di distribuzioni Linux usando un unico sorgente consolidato e la comodità di usare libri di cucina forniti dalla comunità.

Ora che sto usando Chef per eseguire il provisioning delle mie VM, mi sembra di fare un passo indietro quando sto aggiungendo i comandi RUN seguiti dai comandi shell su un Dockerfile per ottenere ciò che si può ottenere semplicemente eseguendo una ricetta Chef.

Ho cercato su Google e non ho trovato nulla (ma forse mi è sfuggito) ma non sembra che ci sia un modo semplice per usare le ricette dello Chef per costruire contenitori Docker. Perché?

Comprendo che i contenitori devono essere immutabili e che gli strumenti di gestione della configurazione vengono comunemente utilizzati per riconfigurare le macchine durante la loro intera durata, ma non offrirebbero comunque molti vantaggi se utilizzati durante la costruzione iniziale del contenitore?

Lo strumento necessario è Packer che utilizza Docker come "costruttore" e Chef come "fornitore". Quindi puoi aggiungere l'immagine risultante al tuo repository e riutilizzarla senza doverla imballare di nuovo, fino a quando le tue ricette cambiano.

Queste strategie non hanno nulla a che fare l'una con l'altra.

I contenitori (come Docker) sono una metodologia per distribuire e isolare le applicazioni. I container sono apprezzati perché trasportabili. Nella maggior parte dei casi possono essere sviluppati e visualizzati in anteprima a livello locale, quindi ha senso inserirvi delle applicazioni.

Per quanto riguarda il motivo per cui Docker utilizza script di shell : un'immagine docker è letteralmente un'immagine contenitore di Linux. È un sistema operativo Linux e il punto di quel contenitore è il più leggero ed efficiente possibile. Se hai iniziato ad aggiungere Chef, Ruby, Erlang e tutte le altre librerie necessarie per avere Chef come provisioner su un file Docker, elimineresti il ​​punto di usare i container.

La gestione della configurazione serve per eseguire il provisioning di un nodo di calcolo. Lo stato finale della configurazione si riflette generalmente nel codice e ha un server centrale per il mantenimento dello stato. Strumenti come Vagrant consentono di utilizzare Chef per configurare le macchine Vagrant, in gran parte per comodità per gli sviluppatori. Sebbene sia possibile utilizzare la maggior parte di questi strumenti in una modalità solo locale , la loro manutenzione diventa piuttosto onerosa. Questi server centrali servono per risolvere il controllo delle versioni e la gestione delle dipendenze.

Bash non è intrinsecamente un passo indietro. Ad esempio, molte organizzazioni che creano pipeline di immagini completamente immutabili costruiscono le loro immagini utilizzando Bash. Ciò garantisce stabilità e prevedibilità nonché un linguaggio comune tra gli ingegneri (molti ingegneri possono provenire da diversi background di gestione della configurazione).

Gestione immutabile vs config . L'infrastruttura immutabile non cambia e deve essere completamente sostituita per essere aggiornata. Config Management implica che lo stato di una macchina è gestito da un agente o da una connessione esterna (come con Ansible).

I contenitori Docker sono intrinsecamente immutabili. Non persistete dati su di essi e devono essere sottoposti a rolling per essere aggiornati.