App kann nicht neu erstellt werden: nicht unterstützter Docker-Speichertreiber (btrfs)

Installation
1

Wir werden unseren Server und die Discourse-Installation migrieren.
Wir verwenden einen neuen Server mit dem Btrfs-Dateisystem.

Ich führe einige Tests auf einer Testmaschine durch. Ich habe alle Dateien kopiert und alle notwendigen Teile installiert (nginx, Docker, Discourse selbst).

Ich habe es mit einem ext4-Dateisystem versucht und es funktionierte gut.
Aber jetzt, wenn ich dasselbe mit einem Btrfs-formatierten Dateisystem mache, erhalte ich diese Fehlermeldung, wenn ich ‘launcher rebuild app’ versuche:

Ihre Docker-Installation verwendet keinen unterstützten Speicher-Treiber. Wenn wir fortfahren würden, hätten Sie möglicherweise eine fehlerhafte Installation.
overlay2 ist der empfohlene Speicher-Treiber, obwohl zfs und aufs auch funktionieren könnten.
Andere Speicher-Treiber sind bekanntermaßen problematisch.
Sie können feststellen, welches Dateisystem Sie verwenden, indem Sie "docker info" ausführen und die Zeile 'Storage Driver' betrachten.

Wenn Sie trotzdem fortfahren möchten, indem Sie Ihren bestehenden, nicht unterstützten Speicher-Treiber verwenden,
lesen Sie den Quellcode von launcher und finden Sie heraus, wie Sie diese Prüfung umgehen können.

Offensichtlich gibt docker info an, dass es Btrfs verwendet.
Ich habe in diesem Forum gelesen, dass Discourse Probleme mit einigen Docker-Speicher-Treibern hat und sich deshalb weigert, neu zu bauen.

Gibt es eine Möglichkeit, es auf ‘overlay’ oder einen anderen Treiber zu ändern, der mit Discourse kompatibel ist und die Dateien vom Btrfs-Dateisystem abrufen kann?

Wie sollte ich Docker konfigurieren?
Ist es möglich, das nur für den Discourse-Container zu tun und die restliche Docker-Konfiguration als Standard zu belassen?

Danke.

2

Hinweis

Sowohl overlay als auch overlay2 werden derzeit auf btrfs oder einem beliebigen Copy-on-Write-Dateisystem nicht unterstützt und sollten nur über ext4-Partitionen verwendet werden.

Da Docker die Verwendung des overlay2-Treibers über btrfs nicht unterstützt, scheint die Empfehlung des Launcher-Tools das Ausmaß Ihrer Optionen hier zu sein. Das heißt, Sie können Discourse weiterhin auf einem System ausführen, auf dem Docker von ext4 unterstützt wird, oder Sie können launcher so ändern, dass der Speicher-Treiber ignoriert wird und Sie auf das Beste hoffen.

Wenn Sie diesen Weg einschlagen möchten, können Sie die Zeile exit 1 in den folgenden Zeilen des launcher-Skripts mit Ihrem bevorzugten Texteditor auskommentieren (indem Sie # voranstellen):

Wenn man jedoch bedenkt, dass „andere Speicher-Treiber bekanntermaßen problematisch sind“, würde ich davon abraten.

1 „Gefällt mir“
3

Vielen Dank für Ihre schnelle Antwort.

Wenn ich es richtig verstanden habe, kann Docker keinen alternativen Storage-Treiber verwenden, um auf zugrunde liegende Systemdateien zuzugreifen, wenn Sie ein COW-Dateisystem wie btrfs verwenden.

Es gibt also keine gute Lösung, da Discourse Probleme mit der Verwendung des btrfs Storage-Treibers von Docker haben könnte.

Ein Zurücksetzen auf ext4 ist keine Option, da die gesamte Migration darauf abzielte, sicherzustellen, dass die Datendateien unter dem COW btrfs Dateisystem und seiner Fähigkeit, Snapshots zu erstellen und Daten sauber zu halten, aufbewahrt werden.

Es hat keinen Sinn, btrfs in anderen Teilen des Systems zu verwenden, da sein Hauptziel der Zugriff auf das Discourse-Forum ist.

Es ist schade, denn es wäre großartig, es mit dem Schutz eines COW-Dateisystems laufen zu lassen.

Es ist einfacher, die --skip-prereqs Flags zu verwenden. Aber die Verwendung in einem Produktionssystem kann riskant sein.
Ich habe es auf der Testmaschine ausprobiert und es funktioniert im Moment gut, aber das Problem scheint auf lange Sicht zu bestehen.

4

Die Verwendung von --skip-prereqs überspringt viele andere Tests, was, wie Sie erwähnen, verschiedene Risiken bei der Durchführung eines Rebuilds birgt. Das Auskommentieren dieser einen Zeile ist nicht riskanter als die Ausführung auf btrfs und sollte beim automatischen Zusammenführen, wenn der Launcher sich selbst aktualisiert, automatisch zusammengeführt werden, was bedeutet, dass Sie die Änderung wahrscheinlich einmal vornehmen und sie größtenteils vergessen können.

1 „Gefällt mir“
5

OK; danke, das war mir nicht bewusst.

6

Um ehrlich zu sein, richtete sich diese Nachricht an das alte devicemapper, das ein bekanntes Zuverlässigkeitsproblem war.

Im Laufe der Jahre haben wir aufs verwendet und in jüngster Zeit verwenden wir den overlay2-Treiber, ohne Probleme. Wenn Sie brtfs ausprobieren möchten, berichten Sie bitte in ein paar Monaten hier darüber.

2 „Gefällt mir“
7

Vielen Dank.
Auf dem Produktionsserver fürchte ich, das zu tun.
Wenn es Probleme mit dem Docker-Treiber gibt und dieser beschädigte Daten schreibt, helfen Ihnen Snapshots, Backups oder was auch immer nicht, wenn es zu einem Absturz kommt.
Wenn es eine sichere Möglichkeit gibt, die Daten in einem Backup zu erhalten, könnte ich es versuchen…
Welche Art von Problemen gab es in der Vergangenheit?

Aber heutzutage sind diese COW-Dateisysteme sehr nützlich. Sie können Snapshots erstellen, Daten sind vor Beschädigungen während des Schreibens oder anderen Fehlern geschützt, es ist einfach, Speicherplatz hinzuzufügen oder Geräte zu verschieben…

Es wäre großartig, wenn wir das in Zukunft in Discourse sehen könnten.
Vielleicht kann ich beim Testen helfen. Ich habe es auf einer Testmaschine laufen.

8

Das Problem ist, dass, wenn ich die Launcher-Datei bearbeite, um btrfs zur Liste der unterstützten Docker-Speichertreiber hinzuzufügen, das Skript bei der Ausführung beschwert, dass das Skript lokal geändert wurde und von der Remote-Version (von GitHub) überschrieben wird.
Wie löse ich das?

9

Welche genaue Meldung sehen Sie und an welchem Punkt im Rebuild tritt sie auf?

Ich habe gerade eine VM gestartet, die ich zum Testen verwende, die Zeile geändert und dann neu kompiliert. An dem Punkt, an dem der Launcher sich selbst aktualisiert, hat er den git pull ausgeführt und wie erwartet einen Fast-Forward-Merge durchgeführt, wobei die Änderung erhalten blieb.

Die Version, von der ich aktualisiert habe, enthielt keine Änderung am Launcher selbst, aber ich würde erwarten, dass dies auf die gleiche Weise funktioniert, solange es keinen Konflikt gibt, d. h. solange diese exit 1-Zeile oder sehr nahe Zeilen im Repository nicht geändert werden.

1 „Gefällt mir“
10

Vielen Dank für Ihre Antwort und Ihr Interesse.
Lassen Sie mich versuchen, dies zu klären.

Ich habe das Launcher-Skript geändert, um btrfs als eines der akzeptierten Formate einzuschließen.
In der Funktion check_prereqs habe ich Folgendes geändert:

if ! $docker_path info 2> /dev/null | egrep -q 'Storage Driver: (btrfs|aufs|zfs|overlay2)$'; then

Als ich zum ersten Mal versuchte, einen Launcher-Rebuild durchzuführen, erhielt ich eine Meldung, dass der Launcher lokal geändert wurde und ob ich fortfahren möchte, Dateien vom Ursprung herunterzuladen.

Also musste ich es so belassen, wie es war, den Rebuild durchführen und es danach ändern, um die App zu starten.

Aber ich habe heute versucht, einen Rebuild erneut durchzuführen, und es scheint, dass er die Änderung erkennt, sich aber nicht beschwert und die Änderung beibehalten wird.

Ich weiß nicht, ob kürzlich etwas am Launcher geändert wurde und ich ursprünglich einen alten Launcher hatte, der den Rekonstruktion nicht durchgeführt hat und jetzt (nachdem ich ihn gestern aktualisiert habe) doch (nachdem ich ihn gestern aktualisiert habe).

Ich teste es mit btrfs und alles scheint gut zu funktionieren, Sie können Anwendungen starten und stoppen, Backups erstellen, alles funktioniert bisher gut.

Docker scheint btrfs-Subvolumes für die Container-Speicherdaten zu erstellen, wenn es erkennt, dass es auf einem btrfs-Dateisystem läuft und den btrfs-Speichertreiber verwendet.
Es scheint also, dass es einige Optimierungen vornimmt, wenn es Container klont oder Snapshots über Docker-Befehle erstellt.

Aber ich weiß nicht, ob der Treiber in irgendeiner Weise fehlerhaft sein könnte (es scheint kein experimenteller Treiber in Docker zu sein, es gibt keine Hinweise zur Verwendung unter btrfs oder ich konnte sie nicht finden) und ob es besser wäre (wenn möglich), Docker so zu konfigurieren, dass es den overlay2-Treiber verwendet, als ob es auf einem Standarddateisystem laufen würde.
Theoretisch wäre es für Docker möglich, seine Dateien zu schreiben und Operationen auf einem btrfs-Dateisystem durchzuführen, ohne seine Fähigkeiten zu berücksichtigen (da btrfs auf Benutzerebene nicht anders ist als andere Dateisysteme für die Dateiein-/ausgabe).

Jede Meinung oder Erfahrung mit der Verwendung des btrfs Docker Storage Drivers oder der Konfiguration des overlay2 Drivers für die Verwendung mit Docker auf einem btrfs Dateisystem wäre willkommen.

11

Ich habe keine direkten Erfahrungen anzubieten, aber ich würde dringend davon abraten, Docker zu zwingen, den Overlay2-Treiber auf Btrfs zuzulassen. Es wird ausdrücklich nicht unterstützt und der Overlay2-Treiber könnte Annahmen über das Dateisystem treffen, die für Btrfs zutreffen oder auch nicht, was plausibel zu verschiedenen unerwarteten Ergebnissen führen könnte. Sie wollen wirklich keine unerwarteten Ergebnisse auf Dateisystemebene.

Niedrigstufige Dateisystemoperationen werden von Docker und dem Btrfs-Speichertreiber übernommen. Wenn dies eine ausgereifte und gut gewartete Kombination ist, die nicht bekanntermaßen fehlerhaft ist, wie es Devicemapper war, besteht eine gute Chance, dass es einfach gut funktioniert.

Der Grund, warum Btrfs in Discourse nicht unterstützt wird, soweit ich weiß, liegt nicht darin, dass es fehlschlagen würde, sondern einfach daran, dass sie nicht genügend Informationen haben, um den Leuten zu sagen, dass es funktionieren wird.

Sie haben keinen (oder nicht genug) Anreiz, ihre eigenen Server auf Btrfs zu betreiben, daher ist der einzige Weg, diese Informationen zu erhalten, von Leuten aus der Community, die es in der Produktion ausprobieren und nach längeren Zeiträumen berichten. Das ist noch nicht geschehen, daher bleibt es ununterstützt.

Wenn Sie sich in Zukunft in dieser Situation befinden, können Sie die Änderung jederzeit zurücksetzen, aktualisieren und die Änderung erneut anwenden, bevor Sie den Launcher ausführen:

cd /var/discourse
git reset --hard
git pull
sed -i 's/Storage Driver: (/Storage Driver: (btrfs|/' launcher
./launcher rebuild app
1 „Gefällt mir“
12

Vielen Dank.\n\nIch werde also nicht versuchen, den Overlay2-Speichertreiber von Docker auf einem Btrfs-Dateisystem zu verwenden. Ich werde Docker den Btrfs-Treiber verwenden lassen, in der Erwartung, dass er ordnungsgemäß funktioniert und keine Probleme verursacht.\nHier Docker Storage Drivers | Learn the Different Storage drivers of Docker heißt es, dass dies der empfohlene Ansatz und offiziell unterstützt für SLE Linux ist, aber in Ubuntu empfohlen wird.\nDebian 10 und 11 unterstützen Btrfs im Kernel ohne Modifikationen und unterstützen das Booten von einer Btrfs-Partition (nur die UEFI-Partition sollte von einem anderen Typ sein).\n\nIch gehe also davon aus, dass es gut getestet ist.\n\nDie Antwort von Rafael scheint darauf hinzudeuten, dass es keinen besonderen Grund gibt, es nicht zu verwenden. Probleme gab es mit Devicemapper, und sie stellten den Antrag, bekannte Dateisysteme zu verwenden, wahrscheinlich zu einer Zeit, als Btrfs oder andere COW-Systeme noch nicht so viel Aufmerksamkeit erhielten.\n\nIch werde es ausprobieren.\nIch werde über meine Erfahrungen (gut oder schlecht) bei der Verwendung berichten.\nBisher funktioniert es reibungslos und ermöglicht mir, die Dateisystemgröße einfach zu ändern, Geräte hinzuzufügen, zu entfernen usw. und gibt mir die Gewissheit, dass die zugrunde liegenden Daten korrekt sind und fehlerfrei bleiben.\nDie einzige Vorsichtsmaßnahme betrifft den Docker-Speichertreiber, wenn er nicht ausreichend getestet ist, aber es scheint, dass er in SLE (das Btrfs seit langem als Standard-Speicherdateisystem implementiert) weit verbreitet ist.

1 „Gefällt mir“
13

Ich muss sagen, dass wir den Produktionsserver seit 9 Tagen auf einem BTRFS-Dateisystem ohne Probleme laufen lassen.\n\nIch hatte es zuvor auf einem Testserver getestet.\nUnd ich habe das Forum von einem Ort in ein Subvolume verschoben, Festplatten und Speicherplatz vom Dateisystem hinzugefügt und entfernt, ohne Probleme.\n\nIch werde nach längerer Nutzung berichten.\n\nIch bin ziemlich neu bei BTRFS und kenne es nicht im Detail, aber es ist nicht so schwierig und funktioniert wie erwartet.

2 „Gefällt mir“
14

Nun, ich muss sagen, wir betreiben Discourse seit fast einem Monat im btrfs-Dateisystem ohne ein einziges Problem.

Es funktioniert reibungslos.
Die btrfs-Treiber von Docker scheinen perfekt zu funktionieren.
Es wäre großartig, wenn einige andere Leute Discourse unter btrfs testen würden und btrfs-Unterstützung in die Discourse-Distribution integriert werden könnte.

Wir stoppen das Forum für einen Moment, machen den Snapshot mit btrfs (ein paar Sekunden) und starten es wieder.
Dann machen wir ein externes Backup des erstellten Snapshots.

Es scheint perfekt zu funktionieren.

Ich habe das Backup auf einer anderen Maschine wiederhergestellt, um es zu testen, und es funktioniert.

Das

2 „Gefällt mir“
15

Das ist großartig zu hören! Können Sie einen PR senden, der ihn zu
discourse_docker/launcher at main · discourse/discourse_docker · GitHub hinzufügt

16

Ich werde es versuchen. Ich bin nicht sehr gut mit GitHub, ich hoffe, ich mache es gut.

Fertig, ich habe den PR erstellt, ich hoffe, ich habe es gut gemacht.

1 „Gefällt mir“
17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.