Migreremo il nostro server e l’installazione di Discourse.
Stiamo utilizzando un nuovo server con filesystem btrfs.
Sto facendo alcuni test su una macchina di test, ho copiato tutti i file e installato tutte le parti necessarie (nginx, docker, discourse stesso).
Ho provato con un filesystem ext4 e ha funzionato bene.
Ma ora, quando faccio lo stesso con un filesystem formattato btrfs, ottengo questo errore quando provo ‘launcher rebuild app’:
La tua installazione Docker non sta utilizzando un driver di archiviazione supportato. Se procedessimo potresti avere un'installazione danneggiata.
overlay2 è il driver di archiviazione consigliato, anche se zfs e aufs potrebbero funzionare.
Altri driver di archiviazione sono noti per essere problematici.
Puoi sapere quale filesystem stai utilizzando eseguendo "docker info" e guardando la riga 'Storage Driver'.
Se desideri continuare comunque utilizzando il tuo driver di archiviazione non supportato,
leggi il codice sorgente di launcher e scopri come aggirare questo controllo.
Ovviamente, docker info indica che sta utilizzando btrfs.
Ho letto in questo forum che discourse ha problemi con alcuni driver di archiviazione docker ed è per questo che rifiuta la ricostruzione.
C’è un modo per cambiarlo in ‘overlay’ o altro driver compatibile con discourse e in grado di recuperare i file dal filesystem btrfs?
Come dovrei configurare docker?
È possibile farlo solo per il container discourse e lasciare il resto della configurazione docker come predefinito?
Sia overlay che overlay2 non sono attualmente supportati su btrfs o qualsiasi filesystem Copy on Write e dovrebbero essere utilizzati solo su partizioni ext4.
Dato che Docker non supporta l’utilizzo del driver overlay2 su btrfs, sembra che la raccomandazione dello strumento di avvio sia l’estensione delle tue opzioni. Ovvero, continuare a eseguire Discourse su un sistema in cui Docker è supportato da ext4 o modificare launcher per ignorare il driver di archiviazione e sperare per il meglio.
Commentare (precedere con #) la riga exit 1 nelle seguenti righe dello script launcher con il tuo editor di testo preferito otterrà quest’ultima se vuoi intraprendere quella strada:
Considerando tuttavia che “Altri driver di archiviazione sono noti per essere problematici”, non consiglierei di farlo.
Quindi, se ho capito bene, docker non è in grado di utilizzare altri driver di archiviazione alternativi per accedere ai file di sistema sottostanti, se si utilizza un filesystem COW come btrfs.
Quindi non c’è una buona soluzione, poiché discourse potrebbe avere problemi nell’utilizzare il driver di archiviazione btrfs da docker.
Il ripristino a ext4 non è un’opzione, poiché tutta la migrazione doveva garantire che i file di dati fossero mantenuti sotto il filesystem COW btrfs e la sua capacità di eseguire snapshot e mantenere i dati puliti.
Non ha senso utilizzare btrfs in altre parti del sistema, poiché il suo obiettivo principale è fornire l’accesso al forum discourse.
È un peccato perché sarebbe fantastico averlo in esecuzione con la protezione di un filesystem COW.
È più facile usare il flag --skip-prereqs. Ma usarlo nel sistema di produzione può essere rischioso.
L’ho provato sulla macchina di test e per ora funziona bene, ma il problema sembra essere a lungo termine.
Usare --skip-prereqs salta molti altri test che, come hai menzionato, introducono vari rischi durante la ricostruzione. Commentare quella riga non è più o meno rischioso che eseguire su btrfs e dovrebbe auto-unirsi quando il launcher si aggiorna, il che significa che probabilmente puoi apportare la modifica una volta e dimenticartene per lo più.
Ad essere sinceri, quel messaggio era rivolto al vecchio devicemapper che era un problema noto per l’affidabilità.
Nel corso degli anni abbiamo utilizzato aufs e più recentemente utilizziamo il driver overlay2, senza alcun problema. Se vuoi provare brtfs, ti preghiamo di fare un resoconto qui dopo qualche mese.
Grazie.
Nel server di produzione temo di farlo.
Se ci sono problemi con il driver Docker e scrive dati corrotti, avere snapshot, backup o quant’altro non ti aiuterà in caso di crash.
Se ci fosse un modo sicuro di mantenere i dati in un backup, potrei provare…
che tipo di problemi si sono verificati in passato?
Ma oggigiorno, questi filesystem COW sono molto utili. Puoi fare snapshot, i dati sono protetti da corruzioni durante la scrittura o altri errori, è facile aggiungere spazio o spostare dispositivi…
Sarebbe fantastico se potessimo vederlo in discourse in futuro.
Forse posso aiutare a testarlo. Lo sto eseguendo su una macchina di test.
Il problema è che se modifico il file launcher per aggiungere btrfs all’elenco dei driver di archiviazione docker supportati, quando eseguo lo script si lamenta che lo script è stato modificato localmente e verrà sovrascritto dalla versione remota (da github).
Come risolvo questo problema?
Qual è il messaggio esatto che stai visualizzando e in quale punto della ricompilazione si verifica?
Ho appena avviato una VM che uso per i test, ho modificato la riga e poi ho ricompilato. Nel punto in cui il launcher si aggiorna da solo, ha eseguito il git pull e ha effettuato un merge fast-forward come mi aspettavo, lasciando intatta la modifica.
La versione da cui stavo aggiornando non includeva una modifica al launcher stesso, ma mi aspetterei che funzionasse allo stesso modo finché non c’è un conflitto, cioè finché quella riga exit 1 o righe molto vicine non vengono modificate nel repository.
Grazie per la tua risposta e il tuo interesse.
Cercherò di chiarire.
Ho modificato lo script di avvio per includere btrfs come uno dei formati accettati.
Nella funzione check_prereqs ho modificato:
if ! $docker_path info 2> /dev/null | egrep -q 'Storage Driver: (btrfs|aufs|zfs|overlay2)$'; then
Quando ho provato per la prima volta a ricostruire l’applicazione tramite il launcher, ho ricevuto un messaggio che diceva che il launcher era stato modificato localmente e se desideravo continuare a scaricare i file dall’origine.
Quindi ho dovuto lasciarlo così com’era, effettuare la ricostruzione e modificarlo in seguito per avviare l’applicazione.
Ma oggi ho provato a ricostruire di nuovo e sembra che rilevi la modifica ma non si lamenti e la modifica venga mantenuta.
Non so se qualcosa sia stato modificato di recente nel launcher e se potrei originariamente avere un vecchio launcher che non ha effettuato la ricostruzione e ora lo fa (dopo averlo aggiornato ieri).
Lo sto testando con btrfs e tutto sembra funzionare bene, puoi avviare e arrestare l’applicazione, effettuare i backup, tutto funziona bene per ora.
Docker sembra creare sottovolumi btrfs per i dati di archiviazione dei container quando rileva che è in esecuzione su un file system btrfs e utilizza il driver di archiviazione btrfs.
Quindi sembra che apporti alcune ottimizzazioni quando clona container o esegue snapshot tramite comandi docker.
Ma non so se il driver possa essere difettoso in qualche modo (non sembra un driver sperimentale in docker, non ci sono avvisi sull’utilizzo su btrfs o non sono riuscito a trovarli) e se sarebbe meglio (se possibile) modificare le informazioni di docker per eseguirlo utilizzando il driver overlay2 come se fosse in esecuzione su un file system standard.
In teoria sarebbe possibile per docker scrivere i suoi file ed eseguire operazioni su un file system btrfs senza tenere conto delle sue capacità (poiché btrfs non è diverso da altri file system a livello utente, per l’I/O dei file).
Qualsiasi opinione o esperienza sull’utilizzo del driver di archiviazione docker btrfs o sulla configurazione del driver overlay2 da utilizzare quando si utilizza docker su un file system btrfs sarebbe benvenuta.
Non ho esperienza diretta da offrire, ma sconsiglierei vivamente di forzare Docker a consentire l’uso del driver overlay2 sopra btrfs. È esplicitamente non supportato e il driver overlay2 potrebbe fare delle supposizioni sul filesystem che potrebbero essere vere o meno per btrfs, portando plausibilmente a vari risultati inaspettati. Davvero non vuoi risultati inaspettati a livello di filesystem.
Le operazioni a basso livello del filesystem saranno gestite da Docker e dal driver di archiviazione btrfs. Se questa è una combinazione matura e ben mantenuta, che non presenta bug noti come lo era devicemapper, c’è una buona probabilità che funzioni correttamente.
Il motivo per cui btrfs non è supportato in Discourse, per quanto ne so, non è perché ci si aspetti che fallisca, ma semplicemente perché non hanno abbastanza informazioni per dire alle persone che funzionerà.
Non hanno alcun incentivo (o abbastanza) per eseguire i propri server su btrfs, quindi l’unico modo per ottenere queste informazioni è attraverso persone della community che lo provano in produzione e riportano indietro dopo periodi di tempo prolungati. Ciò non è ancora accaduto, quindi rimane non supportato.
Se ti trovi in questa situazione in futuro, puoi sempre resettare la modifica, aggiornare, quindi riapplicare la modifica prima di eseguire il launcher:
cd /var/discourse
git reset --hard
git pull
sed -i 's/Storage Driver: (/Storage Driver: (btrfs|/' launcher
./launcher rebuild app
Quindi, non tenterò di utilizzare il driver di archiviazione overlay2 di Docker su un filesystem btrfs, lascerò che Docker utilizzi il driver btrfs aspettandomi che funzioni correttamente e senza problemi.
Qui Docker Storage Drivers | Learn the Different Storage drivers of Docker dicono che è l’approccio consigliato e ufficialmente supportato per SLE Linux, ma consigliato su Ubuntu.
Debian 10 e 11 supportano btrfs nel kernel senza modifiche e supportano l’avvio da una partizione btrfs (solo la partizione UEFI dovrebbe essere di altro tipo).
Quindi presumo che sia ben testato.
La risposta di Rafael sembra indicare che non ci sono ragioni particolari per non usarlo. I problemi erano con devicemapper e hanno avanzato la richiesta di utilizzare filesystem ben noti, probabilmente in un momento in cui non c’era molta attenzione a btrfs o ad altri sistemi COW.
Ci proverò.
Riporterò la mia esperienza (buona o cattiva) nel suo utilizzo.
Per ora funziona senza intoppi e mi permette di cambiare facilmente la dimensione del filesystem, aggiungere dispositivi, rimuoverli, ecc. e mi dà la fiducia che i dati sottostanti siano corretti e rimarranno senza errori.
L’unica precauzione riguarda il driver di archiviazione di Docker se non è abbastanza testato, ma sembra che sia stato ampiamente utilizzato in SLE (che implementa btrfs come filesystem di archiviazione predefinito da molto tempo).
Devo dire che abbiamo il server di produzione in esecuzione da 9 giorni su un filesystem BTRFS senza alcun problema.
Avevo già testato in precedenza sul server di test.
E ho spostato il forum da un posto a un sottovolume, aggiunto e rimosso dischi e spazio dal filesystem, senza problemi.
Riporterò dopo più tempo di utilizzo.
Sono abbastanza nuovo a BTRFS e non lo conosco a fondo, ma non è così difficile e funziona come previsto.
Devo dire che stiamo eseguendo Discourse nel filesystem btrfs da quasi un mese senza alcun problema.
Funziona senza intoppi.
I driver btrfs di Docker sembrano funzionare perfettamente.
Sarebbe fantastico se altre persone testassero Discourse in esecuzione su btrfs e il supporto btrfs potesse essere integrato nella distribuzione di Discourse.
Fermiamo il forum per un momento, scattiamo lo snapshot usando btrfs (pochi secondi) e lo eseguiamo di nuovo.
Quindi effettuiamo un backup esterno dello snapshot acquisito.
Sembra funzionare perfettamente.
Ho ripristinato il backup su un’altra macchina per testare e funziona.