Quali sono i motivi per cui Docker non deve essere utilizzato per i database?

Sto discutendo con un amico sui casi d'uso di Docker . Un ragazzo del team vuole utilizzare Docker per tutto, come una sorta di wrapper universale per processi unix. L'altro pensa che Docker dovrebbe essere usato solo per applicazioni senza stato come microservizi e app in stile AWS Lambda .

Abbiamo progettato la prova dei concetti per entrambi. Nel nostro cluster docker abbiamo un'unità condivisa che viene montata quando viene montato l'host Docker e se viene montato un database in un contenitore, monta semplicemente un volume sull'unità condivisa.

Il mio amico rimane fedele alla sua posizione, nonostante le prove contrarie mostrino. (Sostiene inoltre che Docker aggiunge rischi inutili aggiungendo complessità allo stack.)

Sto cercando di ascoltare e comprendere il suo punto di vista, sia in un atto di empatia, sia anche per ragionare meglio con lui. (Andiamo tutti abbastanza d'accordo, quindi questo è un mix di discussioni scherzose e serie).

Il tipo di domanda alla base della domanda è: i database sono bovini ? Questo commento suggerisce che una buona strategia di backup e recupero automatizzata per il database non è distinguibile da un server di bestiame.

La mia domanda è: quali sono le ragioni per cui Docker non dovrebbe essere usato per i database?

EDIT: le persone mi hanno chiesto di chiarire la mia terminologia. Supponevo che l'applicazione di database fosse nel contenitore e che lo spazio di archiviazione fosse nel volume. Intendevo dire che RDBMS era nel contenitore e l'archiviazione del database è nel volume.

Alcuni commentatori hanno suggerito che i driver del volume della finestra mobile non funzioneranno molto bene con le scritture del database. (O qualcosa in tal senso). Potresti per favore ampliarlo?

Quando le persone parlano dell'esecuzione di un database in Docker, non intendono archiviare i dati in un contenitore; stanno parlando di avere un'immagine docker con il software DB e di montare i dati come volume (un volume di bind, non un volume del contenitore).

I volumi sono una parte essenziale di Docker e non sono qualcosa che è imperfetto o semplicemente appiccicato. Docker non è fatto solo per servizi (micro) senza stato.

Per quanto mi piacerebbe, non riesco a trovare un motivo tecnico per non eseguire un database in un Docker, quindi sfortunatamente selezionerò l'altro lato dell'argomento e quindi forse non ti darò la risposta che stai cercando.

(Sto usando Oracle come esempio perché ne ho familiarità, sia in metallo nudo che dockerizzato, e perché è una bestia abbastanza nota per essere un po 'non banale operare se si superano le impostazioni predefinite.)

• Il confezionamento del software DB stesso in un contenitore offre i soliti vantaggi: avere la stessa versione ovunque, evitare problemi di dipendenza / libreria condivisa, essere in grado di creare lo stesso DB esatto sui laptop degli sviluppatori o ovunque ne abbiate bisogno.
• È un gioco da ragazzi farlo funzionare ovunque; l'aggiornamento è banale e così via. Si applicano tutti i vantaggi Docker. C'è un'immagine Oracle su Dockerhub che ti consente di creare un DB funzionante in un minuto o tre (e ovviamente anche per gli altri).
• Le persone hanno eseguito test delle prestazioni e non hanno riscontrato differenze I / O tra volumi e bare metal ( https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/ , https: // stackoverflow .com / questions / 21889053 / what-is-the-runtime-performance-cost-of-a-docker-container ).
• Sotto il cofano, non è come se Docker in qualche modo intercettasse tutti gli I / O. Diventa solo creativo con gli strumenti Linux standard (i bind si montano in questo caso, alterando le tabelle interne del kernel che rendono possibile il Docker-fu).
• Ovviamente ciò non significa che è possibile eseguire due istanze del DB e farle funzionare sugli stessi file, ma nessuno lo implica. Docker non ti dà accesso automatico simultaneo e magicamente libero ai volumi e non ha mai fatto finta di farlo. Il resto dei benefici si applica ancora. Se il DB stesso non rileva conflitti come questo, è meglio fornire uno script CMD all'immagine che rifiuta di girare un secondo contenitore quando il volume è già in uso.
• Devi essere un po 'più attento a girare / chiudere il contenitore (proprio come non spegni semplicemente un server DB bare metal), ma dovrebbe essere abbastanza gestibile.

Ora, a seconda delle circostanze, potrebbero esserci motivi morbidi per non farlo:

• Oracle (la società), ad esempio, non ti supporterà sicuramente se esegui il loro RDBMS in un contenitore Docker. Ma forse stai usando immagini Oracle RDBMS dockerizzate solo per i tuoi sviluppatori e l'ambiente di test, in cui non avresti bisogno del loro supporto in ogni caso, riservandolo a un server di produzione bare metal. (Ma non dimenticare di pagare le tue licenze ...).
• Se i ragazzi delle operazioni non hanno familiarità con Docker, potrebbe essere solo un po 'più facile uccidere accidentalmente tutto, distruggere i file di dati ecc.
• Se hai già grandi macchine DB dedicate in metallo, con grandi quantità di memoria SAN dedicata molto veloce e non esegui nient'altro comunque, allora non avrebbe senso usare Docker per containerizzare quelle in quanto non farai mai girare un altro server quando ci sono 100s di GB o addirittura TB di dati. Dopotutto, per la produzione, un RDBMS come Oracle è molto, molto avanzato in tutti gli aspetti di replica, integrità dei dati, failover senza tempi di inattività, ecc. Nota che questo argomento dice semplicemente "non è necessario containerizzare il tuo RDBMS". Non dice "non dovresti farlo" - forse vuoi farlo perché desideri distribuire gli aggiornamenti del software del database attraverso i contenitori o per qualsiasi altra ragione che tu possa immaginare.

Quindi eccoti. Con tutti i mezzi non dockerize vostro DB, per lo meno per gli sviluppatori (che saranno eternamente grati) e gli ambienti di test. Per quanto riguarda la produzione, si ridurrà il gusto, e almeno lì , preferirei anche la soluzione che si adatta meglio ai DBA / Op specializzati - se hanno decenni di esperienza a lavorare su server DB bare metal, allora fidati di loro per continuare così. Ma se sei una startup che ha comunque tutto l'IT nel cloud, un contenitore Docker sarebbe solo un ulteriore pezzo di cipolla nell'intera immagine.

Ne ho scritto a fondo ma ecco il riassunto:

• La prevenzione della divisione del cervello (elezione di più di un nodo principale) deve essere risolta. In caso contrario, può essere catastrofico

• Non esistono soluzioni di archiviazione condivise pronte per la produzione che consentano l'arresto dei database su un'istanza e il recupero su un'altra senza perdere tutti i dati.

Quando si afferma che i dati sono montati in un contenitore finestra mobile, non sarebbe più corretto affermare che il "database" è montato nel contenitore finestra mobile? Se stai persistendo i tuoi dati fuori dal contenitore, stai facendo la cosa "corretta" di non mettere il tuo database in un contenitore.

Certo, vai in città mettendo un DBMS in un contenitore per consentirgli di gestire i dati che memorizzi all'esterno, personalmente penso che sia solo un buon design perché mantiene una netta separazione tra logica e dati. Ma una volta messi i tuoi dati in un contenitore li stai potenzialmente giocando con il fuoco.

Sebbene i driver per l'archiviazione dei container abbiano fatto molta strada, personalmente non sono ancora disposto a immergermi e a lasciare i miei dati impigliati in un container.