Impossible de reconstruire l'application : pilote de stockage Docker non pris en charge (btrfs)

Installation
1

Nous allons migrer notre serveur et l’installation de Discourse.
Nous utilisons un nouveau serveur avec le système de fichiers btrfs.

Je fais quelques tests sur une machine de test, j’ai copié tous les fichiers et installé toutes les parties nécessaires (nginx, docker, discourse lui-même).

J’ai essayé avec un système de fichiers ext4 et cela a fonctionné correctement.
Mais maintenant, lorsque je fais la même chose avec un système de fichiers formaté en btrfs, j’obtiens cette erreur lorsque j’essaie ‘launcher rebuild app’:

Votre installation Docker n'utilise pas de pilote de stockage pris en charge. Si nous devions continuer, vous pourriez avoir une installation défectueuse.
overlay2 est le pilote de stockage recommandé, bien que zfs et aufs puissent également fonctionner.
D'autres pilotes de stockage sont connus pour être problématiques.
Vous pouvez savoir quel système de fichiers vous utilisez en exécutant "docker info" et en regardant la ligne 'Storage Driver'.

Si vous souhaitez continuer quand même en utilisant votre pilote de stockage non pris en charge existant,
lisez le code source de launcher et découvrez comment contourner cette vérification.

Évidemment, docker info indique qu’il utilise btrfs.
J’ai lu sur ce forum que Discourse a des problèmes avec certains pilotes de stockage Docker et c’est pourquoi il refuse de reconstruire.

Y a-t-il un moyen de le changer en ‘overlay’ ou un autre pilote compatible avec Discourse et capable de récupérer les fichiers du système de fichiers btrfs ?

Comment dois-je configurer Docker ?
Est-il possible de le faire uniquement pour le conteneur Discourse et de laisser le reste de la configuration Docker par défaut ?

Merci.

2

Note

overlay et overlay2 ne sont actuellement pas pris en charge sur btrfs ou tout autre système de fichiers Copy on Write et ne doivent être utilisés que sur des partitions ext4.

Comme Docker ne prend pas en charge l’utilisation du pilote overlay2 sur btrfs, la recommandation de l’outil de lancement semble être l’étendue de vos options ici. C’est-à-dire, continuer à exécuter Discourse sur un système où Docker est pris en charge par ext4 ou modifier launcher pour ignorer le pilote de stockage et espérer le meilleur.

Commenter (en ajoutant # au début) la ligne exit 1 dans les lignes suivantes du script launcher avec votre éditeur de texte préféré permettra de réaliser cette dernière option si vous souhaitez suivre cette voie :

Cependant, étant donné que « D’autres pilotes de stockage sont connus pour être problématiques », je ne recommanderais pas de le faire.

1 « J'aime »
3

Merci pour votre réponse rapide.

Si j’ai bien compris, Docker ne peut pas utiliser d’autre pilote de stockage alternatif pour accéder aux fichiers système sous-jacents si vous utilisez un système de fichiers COW comme btrfs.

Il n’y a donc pas de bonne solution, car Discourse pourrait avoir des problèmes à utiliser le pilote de stockage btrfs de Docker.

Revenir à ext4 n’est pas une option, car toute la migration visait à s’assurer que les fichiers de données étaient conservés sous le système de fichiers COW btrfs et sa capacité à prendre des instantanés et à maintenir les données propres.

Il est inutile d’utiliser btrfs dans d’autres parties du système, car son objectif principal est de fournir un accès au forum Discourse.

C’est dommage, car ce serait formidable de l’avoir en cours d’exécution avec la protection d’un système de fichiers COW.

Il est plus facile d’utiliser le drapeau --skip-prereqs. Mais l’utiliser dans le système de production peut être risqué.
Je l’ai essayé sur la machine de test et cela fonctionne bien pour l’instant, mais le problème semble être à long terme.

4

Utiliser --skip-prereqs ignore de nombreux autres tests qui, comme vous le mentionnez, introduisent divers risques lors de la reconstruction. Commenter cette seule ligne n’est ni plus ni moins risqué que de fonctionner sur btrfs et cela devrait se fusionner automatiquement lorsque le lanceur se met à jour, ce qui signifie que vous pouvez probablement apporter la modification une fois et l’oublier en grande partie.

1 « J'aime »
5

D’accord ; merci, je n’avais pas réalisé cela.

6

Pour être honnête, ce message visait l’ancien devicemapper qui était un problème connu en matière de fiabilité.

Au fil des ans, nous avons utilisé aufs et plus récemment, nous utilisons le pilote overlay2, sans aucun problème. Si vous voulez essayer brtfs, veuillez faire un rapport ici après quelques mois d’utilisation.

2 « J'aime »
7

Merci.
Sur le serveur de production, j’ai peur de faire ça.
S’il y a des problèmes avec le pilote Docker et qu’il écrit des données corrompues, avoir des instantanés, des sauvegardes ou quoi que ce soit ne vous aidera pas en cas de crash.
S’il existe un moyen sécurisé de conserver les données dans une sauvegarde, je pourrais essayer…
Quel genre de problèmes se sont produits par le passé ?

Mais de nos jours, ces systèmes de fichiers COW sont très utiles. Vous pouvez prendre des instantanés, les données sont protégées contre les corruptions lors de l’écriture ou d’autres défaillances, il est facile d’ajouter de l’espace ou de déplacer des périphériques…

Ce serait formidable si nous pouvions le voir sur Discourse à l’avenir.
Peut-être que je peux aider à le tester. Je l’ai en cours d’exécution sur une machine de test.

8

Le problème est que si je modifie le fichier launcher pour ajouter btrfs à la liste des pilotes de stockage docker pris en charge, lorsque j’exécute le script, il se plaint que le script a été modifié localement et sera écrasé par la version distante (depuis GitHub).
Comment résoudre ce problème ?

9

Quel est le message exact que vous voyez et à quel moment de la reconstruction se produit-il ?

J’ai juste démarré une VM que j’utilise pour les tests et j’ai modifié la ligne, puis j’ai reconstruit. Au moment où le lanceur se met à jour, il a effectué le git pull et a effectué une fusion rapide comme je m’y attendais, laissant la modification intacte.

La version à partir de laquelle je mettais à jour n’incluait pas de changement au lanceur lui-même, mais je m’attendrais à ce que cela fonctionne de la même manière tant qu’il n’y a pas de conflit, c’est-à-dire tant que cette ligne exit 1 ou des lignes très proches ne sont pas modifiées dans le dépôt.

1 « J'aime »
10

Merci pour votre réponse et votre intérêt.
Laissez-moi essayer de clarifier.

J’ai modifié le script de lancement pour inclure btrfs comme l’un des formats acceptés.
Dans la fonction check_prereqs, j’ai changé :

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

Lorsque j’ai essayé d’abord de reconstruire le lanceur, j’ai reçu un message indiquant que le lanceur avait été modifié localement et si je voulais continuer à télécharger des fichiers depuis l’origine.

J’ai donc dû le laisser tel quel, effectuer la reconstruction et le modifier ensuite pour démarrer l’application.

Mais j’ai essayé aujourd’hui de faire une reconstruction à nouveau, et il semble qu’il détecte le changement mais ne se plaint pas et le changement est préservé.

Je ne sais pas si quelque chose a été modifié récemment dans le lanceur et si j’avais à l’origine un ancien lanceur qui ne faisait pas la reconstruction et qui le fait maintenant (après l’avoir mis à jour hier).

Je le teste avec btrfs et tout semble fonctionner correctement, vous pouvez démarrer et arrêter l’application, faire les sauvegardes, tout fonctionne correctement pour l’instant.

Docker semble créer des sous-volumes btrfs pour les données de stockage des conteneurs lorsqu’il détecte qu’il fonctionne sur un système de fichiers btrfs et utilise le pilote de stockage btrfs.
Il semble donc qu’il effectue des optimisations lorsqu’il clone des conteneurs ou prend des instantanés via des commandes docker.

Mais je ne sais pas si le pilote peut être défectueux d’une manière ou d’une autre (il ne semble pas être un pilote expérimental dans docker, il n’y a pas d’avis sur son utilisation sur btrfs ou je n’ai pas pu les trouver) et s’il serait préférable (si possible) de changer les informations docker afin de l’exécuter en utilisant le pilote overlay2 comme s’il fonctionnait sur un système de fichiers standard.
En théorie, il serait possible pour docker d’écrire ses fichiers et d’effectuer des opérations sur un système de fichiers btrfs sans tenir compte de ses capacités (car btrfs n’est pas différent des autres systèmes de fichiers au niveau utilisateur, pour les entrées/sorties de fichiers).

Toute opinion ou expérience d’utilisation du pilote de stockage docker btrfs ou de configuration du pilote overlay2 à utiliser lors de l’utilisation de docker sur un système de fichiers btrfs serait la bienvenue.

11

Je n’ai aucune expérience directe à offrir, mais je déconseillerais fortement de forcer Docker à autoriser l’utilisation du pilote overlay2 par-dessus btrfs. Ce n’est explicitement pas pris en charge et le pilote overlay2 pourrait faire des suppositions sur le système de fichiers qui peuvent ou non être vraies pour btrfs, conduisant potentiellement à divers résultats inattendus. Vous ne voulez vraiment pas de résultats inattendus au niveau du système de fichiers.

Les opérations de bas niveau du système de fichiers seront prises en charge par Docker et le pilote de stockage btrfs. Si c’est une combinaison mature et bien entretenue, qui n’est pas connue pour avoir des bugs comme devicemapper l’était, il y a de bonnes chances que cela fonctionne bien.

La raison pour laquelle btrfs n’est pas pris en charge dans Discourse, si je comprends bien, n’est pas parce qu’on s’attend à ce qu’il échoue, mais simplement parce qu’ils n’ont pas assez d’informations pour dire aux gens que cela fonctionnera.

Ils n’ont aucun intérêt (ou pas assez) à exécuter leurs propres serveurs sur btrfs, donc la seule façon pour eux d’obtenir ces informations est de la part des personnes de la communauté qui l’essaient en production et qui font un retour après des périodes prolongées. Cela ne s’est pas encore produit, donc cela reste non pris en charge.

Si vous vous retrouvez dans cette situation à l’avenir, vous pouvez toujours réinitialiser le changement, mettre à jour, puis appliquer à nouveau le changement avant d’exécuter le lanceur :

cd /var/discourse
git reset --hard
git pull
sed -i 's/Storage Driver: (/Storage Driver: (btrfs|/' launcher
./launcher rebuild app
1 « J'aime »
12

Merci beaucoup.

Je n’essaierai donc pas d’utiliser le pilote de stockage overlay2 de Docker sur le système de fichiers btrfs. Je laisserai Docker utiliser le pilote btrfs en espérant que cela fonctionne correctement et sans problème.
Ici Docker Storage Drivers | Learn the Different Storage drivers of Docker ils disent que c’est l’approche recommandée et officiellement prise en charge pour SLE Linux, mais recommandée sous Ubuntu.
Debian 10 et 11 prennent en charge btrfs dans le noyau sans modifications et prennent en charge le démarrage à partir d’une partition btrfs (seule la partition UEFI doit être d’un autre type).

Je suppose donc qu’il est bien testé.

La réponse de Rafael semble indiquer qu’il n’y a pas de raison particulière de ne pas l’utiliser. Les problèmes concernaient devicemapper et ils ont demandé d’utiliser des systèmes de fichiers bien connus, probablement à une époque où il n’y avait pas autant d’attention portée à btrfs ou à d’autres systèmes COW.

Je vais essayer.
Je ferai part de mon expérience (bonne ou mauvaise) lors de son utilisation.
Pour l’instant, cela fonctionne parfaitement et me permet de changer facilement la taille du système de fichiers, d’ajouter des périphériques, de les supprimer, etc., et me donne la confiance que les données sous-jacentes sont correctes et resteront sans erreur.
La seule précaution concerne le pilote de stockage Docker s’il n’est pas suffisamment testé, mais il semble qu’il ait été largement utilisé dans SLE (qui implémente btrfs comme système de fichiers de stockage par défaut depuis longtemps).

1 « J'aime »
13

Je dois dire que nous avons fait fonctionner le serveur de production pendant 9 jours sur un système de fichiers BTRFS sans aucun problème.

J’avais testé précédemment sur un serveur de test.
Et j’ai déplacé le forum d’un endroit à un sous-volume, ajouté et retiré des disques et de l’espace du système de fichiers, sans problème.

Je ferai un rapport après plus de temps d’utilisation.

Je suis assez nouveau sur BTRFS et je ne le connais pas en profondeur, mais ce n’est pas si difficile et cela fonctionne comme prévu.

2 « J'aime »
14

Je dois dire que nous utilisons discourse sur le système de fichiers btrfs depuis près d’un mois sans aucun problème.

Cela fonctionne parfaitement.
Les pilotes btrfs de docker semblent fonctionner parfaitement.
Ce serait formidable si d’autres personnes testaient discourse sur btrfs et que le support btrfs pouvait être intégré dans la distribution discourse.

Nous arrêtons le forum un instant, prenons le snapshot en utilisant btrfs (quelques secondes) et le relançons.
Ensuite, nous effectuons une sauvegarde externe du snapshot pris.

Cela semble fonctionner parfaitement.

J’ai restauré la sauvegarde sur une autre machine pour tester et cela fonctionne.

Le

2 « J'aime »
15

C’est une excellente nouvelle ! Pouvez-vous envoyer une PR qui l’ajoute à

16

J’essaierai. Je ne suis pas très compétent avec GitHub, j’espère que je le ferai bien.

C’est fait, j’ai fait la PR, j’espère que je l’ai bien fait.

1 « J'aime »
17

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