Storage persistente con Docker in produzione: quale soluzione e perché?


8

Di recente ho iniziato a lavorare per un'azienda che vuole suddividere la sua applicazione monolitica SaaS in microservizi containerizzati. Tuttavia, sto facendo fatica a cogliere una parte fondamentale dell'archiviazione persistente. Perché ci sono così tante piattaforme concorrenti diverse? Portworx, Rexray, StorageOS, Flocker, Inifint, ecc.

Le mie domande

  1. Perché qualcuno non dovrebbe semplicemente creare un server NFS e utilizzare una struttura di cartelle gerarchica come back-end di archiviazione? Quali vantaggi ottieni quando usi uno di questi strumenti?

  2. Quanto è pericoloso usare qualcosa di simile con Docker? Quali sono le cause più comuni di perdita di dati catastrofica in un ambiente basato su docker?

  3. Quale soluzione di archiviazione persistente consiglieresti e perché? La mia azienda gestisce una piattaforma SaaS. I payload dei dati sono di piccole dimensioni (5kb-100kb). L'elaborazione dei dati è medio-piccola nel consumo di risorse. Il volume complessivo è medio, ma continua a crescere. Speriamo di spostare completamente la nostra applicazione monolitica nel cloud come microservizi containerizzati separati. Compreso il nostro data warehouse.

  4. Un po 'estraneo, ma si lega. Quali sono i punti di forza dell'utilizzo di Kubernetes come orchestratore rispetto a Rancher / Cattle? Kubernetes non è troppo ingegnerizzato per una piattaforma di dimensioni medio-piccole? Ci sono dei punti di forza nell'utilizzo di Kubernetes in Rancher oltre all'installazione con un clic?

Grazie per la comprensione. Ci scusiamo per l'ingenuità. Accolgo con favore tutta la documentazione e il materiale di lettura supplementare.

EDIT: per il contesto stiamo usando Azure come piattaforma cloud sottostante.


1
Per il 4: Kubernetes gioca bene con l'azzurro per creare Volumi persistenti come Disco di Azure . NFS ha una storia di cattivo meccanismo di blocco, in caso di errore nell'orchestrator potresti corrompere i tuoi file in modo semplice.
Tensibai,

1
i team con cui ho lavorato in questo contesto hanno buone esperienze con Cassandra come backend di archiviazione per una serie di servizi macro ma l'attenzione si concentra piuttosto sulla lettura che sulla scrittura dei dati
Peter Muryshkin,

1
Che tipo di dati? Dati del database? Immagini? File di testo?
James Shewey,

Risposte:


4

Posso rispondere al secondo punto:

Docker è particolarmente adatto in un'architettura basata su micro servizi quando l'applicazione viene eseguita all'interno dei contenitori ma l'archiviazione o qualsiasi altra sessione live viene mantenuta nella RAM condivisa o nel database.

Fondamentalmente non dovresti semplicemente conservare nulla all'interno del contenitore della finestra mobile. Ci sono molte ragioni:

  1. Prendi in considerazione l'aggiornamento: qualcuno del tuo team ha creato un'immagine più recente dell'applicazione e devi disporre del contenitore in esecuzione con l'immagine più recente. La finestra mobile corrente e il modo più diffuso per farlo sono di abbattere il contenitore esistente e di far girare un nuovo contenitore con gli stessi parametri di runtime del contenitore precedente ma con l'immagine più recente. Questo è uno dei motivi principali per cui i contenitori devono essere sempre apolidi e non contenere dati. Puoi avere tutti i tuoi dati montati in un posto e le sessioni conservate all'interno di un db o qualcosa come memchached ecc.

  2. Uno dei grandi casi d'uso della finestra mobile è la creazione di cluster. Se si inizia a mantenere i dati all'interno dei contenitori, è un sovraccarico per mantenere i dati sincronizzati tra i contenitori dell'applicazione.

  3. La comunità docker in generale non consiglia di conservare i dati nel container e quindi nessuno ha provato a correre questo rischio in produzione e nessuno vuole essere il primo narratore di come hanno incasinato la produzione :)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.