Devo utilizzare Dockerfiles o immagine commit?

Question

Sono un po 'confuso riguardo a queste due opzioni. Sembrano essere correlati. Tuttavia, non sono realmente compatibili.

Ad esempio, sembra che l'uso di Dockerfiles significhi che non dovresti realmente impegnarti con le immagini, perché dovresti semplicemente tracciare il Dockerfile in git e apportare modifiche a questo. Quindi non c'è alcuna ambiguità su ciò che è autorevole.

Tuttavia, i commit dell'immagine sembrano davvero belli. È così bello che puoi modificare direttamente un contenitore e taggare le modifiche per creare un'altra immagine. Capisco che puoi anche ottenere qualcosa di simile a un file system diff da una cronologia di commit delle immagini. Eccezionale. Ma allora non dovresti usare Dockerfiles. Altrimenti, se hai fatto un commit di immagine, dovresti tornare al tuo Dockerfile e fare qualche cambiamento che rappresenta ciò che hai fatto.

Quindi sono distrutto. Adoro l'idea dell'impegno dell'immagine: che non devi rappresentare lo stato dell'immagine in un Dockerfile: puoi semplicemente tracciarlo direttamente. Ma sono a disagio nel rinunciare all'idea di una sorta di file manifest che ti offre una rapida panoramica di cosa c'è in un'immagine. È anche sconcertante vedere due funzionalità nello stesso pacchetto software che sembrano incompatibili.

Qualcuno ha qualche idea su questo? È considerata una cattiva pratica usare i commit delle immagini? O dovrei lasciare andare il mio allegato per manifestare i file dai giorni di Puppet? Cosa dovrei fare?

Aggiornamento:

A tutti coloro che pensano che questa è una domanda di parere a base, io non sono così sicuro. Ci sono alcune qualità soggettive, ma penso che sia soprattutto una domanda obiettiva. Inoltre, credo che una buona discussione su questo argomento sarà informativa.

Alla fine, spero che chiunque leggendo questo post possa capire meglio come i Dockerfile e l'immagine si commettono l'uno con l'altro.

Update - 2017/07/18:

Ho da poco scoperto un uso legittimo per un'immagine impegna. Abbiamo appena creato una pipeline CI nella nostra azienda e, durante una fase della pipeline, i nostri test delle app vengono eseguiti all'interno di un container. Abbiamo bisogno di recuperare i risultati della copertura dal contenitore uscito dopo che il processo del test runner li ha generati (nel file system del contenitore) e il contenitore ha smesso di funzionare. Usiamo l'image commit per fare ciò impegnando il container fermato per creare una nuova immagine e quindi eseguendo comandi che visualizzano e riversano il file di copertura sullo stdout. Quindi è utile avere questo. Oltre a questo caso molto specifico, utilizziamo i Dockerfiles per definire i nostri ambienti.

Answer 1

I Dockerfiles sono uno strumento utilizzato per creare immagini.

Il risultato dell'esecuzione di docker build . è un'immagine con un commit così non è possibile utilizzare un Dockerfile senza creare un commit. La domanda è se dovessi aggiornare l'immagine a mano ogni volta che qualcosa cambia e quindi condannarti alla maledizione dell'immagine dorata?

La maledizione dell'immagine d'oro è una terribile maledizione lanciata su persone che devono continuare a vivere con un buggy buco di sicurezza basato sull'immagine di base per eseguire il loro software perché la persona che lo ha creato è stato divorato molto tempo fa da quelli antichi (o trasferito a un nuovo lavoro) e nessuno sa dove abbiano ottenuto la versione di imagemagic inserita in quell'immagine.ed è l'unica cosa che si collegherà al modulo C++ fornito da quel consulente al figlio del capo assoldato tre anni fa, e comunque non importa perché anche se hai capito dove imagemagic proveniva dalla versione di libstdC++ usata dal JNI chiama lo strumento di supporto che stagista con i capelli lunghi creati esiste solo in una versione non supportata di ubuntu comunque.

Answer 2

Conoscere entrambi i vantaggi e gli inconvenienti delle soluzioni è un buon inizio. Perché un mix dei due è probabilmente un modo valido per andare.

Con: evitare il statua d'oro vicolo cieco:

Utilizzando impegna solo è male se si perde traccia di come ricostruire la vostra immagine. Non si desidera essere nello stato in cui non è possibile ricostruire l'immagine. Questo stato finale è chiamato l'immagine dorata in quanto l'immagine sarà il tuo unico riferimento, punto iniziale e punto finale di ogni fase. Se lo perdi, ti troverai in un sacco di guai visto che non puoi ricostruirlo. Il punto morto fatale è che un giorno dovrai ricostruirne uno nuovo (perché tutte le librerie di sistema sono obsolete per esempio), e non avrai idea di cosa installare ... finendo in grossa perdita di tempo.

Come nota a margine, è probabile che l'uso di commit nel corso commit sarebbe più bello se il registro cronologico sarebbe facilmente utilizzabile (consultare diff, e ripetere su altre immagini), in quanto è in git: noterete quel idiota non ha questo dilemma.

Pro: aggiornamenti della chiazza di petrolio per distribuire

In altra parte, stratificazione commit ha qualche notevole vantaggio in termini di aggiornamenti distribuiti e quindi in larghezza di banda e distribuire il tempo. Se inizi a gestire le immagini della finestra mobile come un panettiere sta gestendo pancake (che è esattamente ciò che la finestra mobile consente), o vuoi implementare la versione dei test all'istante, sarai più felice di inviare solo un piccolo aggiornamento sotto forma di piccolo commit piuttosto che tutta nuova immagine. Soprattutto quando si ha un'integrazione continua per i propri clienti, dove le correzioni di bug devono essere implementate presto e spesso.

cercare di ottenere il meglio di due mondi:

In questo tipo di scenario, probabilmente desidera contrassegnare importante versione delle immagini e dovrebbero venire da Dockerfiles. Ed è possibile fornire versioni di integrazione continua grazie ai commit basati sulla versione con tag. Ciò mitiga i vantaggi e gli inconvenienti dello scenario Dockerfiles e stratificazione dei commit. Qui, il punto chiave è che non smetti mai di tenere traccia delle tue immagini limitando il numero di commit che ti permetteranno di fare su di loro.

Quindi penso che dipenda dal tuo scenario e probabilmente non dovresti cercare di trovare una singola regola. Tuttavia, ci potrebbero essere dei veri e propri vicoli ciechi che dovresti davvero evitare (come finire con uno scenario di "immagine dorata") qualunque sia la soluzione.