Historique du problème de migration du stockage docker (racine docker)

Il y a seulement quelques jours, il a été décidé de déplacer le stockage Docker (répertoire où Docker stocke tous les fichiers des conteneurs et images) vers une partition distincte qui
avait une plus grande capacité. La tâche semblait triviale et ne présageait aucun problème…

Commençons :

1. Arrêtez et détruisez tous les conteneurs de notre application :

docker-compose down

s'il y a beaucoup de conteneurs et qu'ils sont dans différents compose, vous pouvez faire ainsi :

docker rm -f $(docker ps -q)

2. Arrêtez le démon Docker :

systemctl stop docker

3. Déplacez le répertoire au bon endroit :

cp -r /var/lib/docker /docker/data/storage

4. Informez le démon Docker de regarder dans le nouveau répertoire. Il y a plusieurs options : soit indiquer le nouveau chemin avec le drapeau -g, soit utiliser les configurations systemd, ce que nous avons fait. Ou faites un lien symbolique. Je ne vais pas trop détailler cela, il y a beaucoup de manuels en ligne sur le déplacement du répertoire racine de Docker à un nouvel emplacement.

5. Démarrez le démon Docker et vérifiez qu'il regarde où il faut :

systemctl status docker

Dans l'une des lignes de sortie, nous devons voir :

├─19493 /usr/bin/dockerd --data-root=/docker/data/storage

Nous avons vérifié que l'option a été transmise au démon, maintenant voyons s'il l'a appliquée (merci inkvizitor68sl)!

docker info | awk '/Root Dir/ {print $NF}' 

6. Démarrez notre application :

docker-compose up -d

7. Vérifiez

Et c'est ici que ça devient intéressant, SGBD, MQ, tout va bien ! La base est intacte, tout fonctionne… sauf nginx. Nous avons notre propre version de nginx avec Kerberos et des cortisanes. Et en consultant les journaux du conteneur, il s'est avéré qu'il ne pouvait pas écrire dans /var/tmp — Permission refusée. Je masse mes tempes et essaie d'analyser la situation… Comment est-ce possible ? L'image Docker n'a pas changé. Nous avons simplement déplacé le répertoire. Ça a toujours fonctionné, et là, ça ne marche plus… Par curiosité, je suis entré manuellement dans le conteneur et j'ai modifié les permissions sur ce répertoire, étaient root, root 755, j'ai donné root, root 777. Et tout a redémarré… Une pensée m'est venue — c'est n'importe quoi… Je me suis dit, peut-être que j'ai négligé quelque chose…

J'ai décidé que nous avions perdu les permissions des fichiers lors du transfert. Nous avons arrêté l'application, le démon Docker, supprimé le nouveau répertoire et effectué la copie du répertoire /var/lib/docker en utilisant rsync -a.

Je pense que maintenant tout est vraiment en ordre, nous démarquons Docker, l'application.

Eh bien… le problème persiste… J'ai un tic à l'œil. Je me suis précipité vers la console de ma machine virtuelle où j'exécute divers tests, j'avais cette image nginx, et je suis entré dans le conteneur, et là, dans le répertoire /var/tmp, les permissions étaient root, root 777. C'est-à-dire identiques à celles que j'avais dû définir manuellement. Pourtant, les images sont identiques !

Le système de fichiers xfs a été utilisé partout.

J'ai comparé via la commande

docker inspect my-nginx:12345

Tous les hashs sont identiques, à l'unité. Tant sur le serveur que sur ma machine virtuelle. J'ai supprimé l'image locale nginx et j'ai recommencé le tirage avec le registre, qui pour diverses raisons est sur la même machine. Et le problème reste le même… Maintenant, mon autre œil commence à tics également.

Je ne me souviens même plus des pensées qui traversaient mon esprit, à part mes cris de « AAAAAA » et autres. Il est 4 heures du matin, j'ai plongé dans les sources de Docker pour comprendre le principe de hachage des couches d'image. J'ai ouvert ma troisième canette de boisson énergétique. Et finalement, il m'est apparu que le hachage ne tient compte que du fichier, de son contenu, mais PAS DES PERMISSIONS! C'est-à-dire que, d'une manière mystérieuse, nos permissions ont été corrompues, et ce malgré le fait que selinux est désactivé, que les acl ne sont pas utilisés, et qu'il n'y a pas de sticky bit.

J'ai supprimé l'image locale, puis l'image dans le registre Docker et j'ai fait un nouvel envoi. Et tout a fonctionné. Il semble que lors du transfert, les permissions aient été corrompues, tant dans l'image locale que dans celle du registre. Comme je l'ai déjà dit, pour diverses raisons, elle était située sur cette même machine. Et par conséquent, dans le même répertoire /var/lib/docker.

Et anticipant la question, si nous avons essayé de renvoyer Docker vers l'ancien répertoire — non, nous n'avons pas essayé, malheureusement, les circonstances ne le permettaient pas. Et j'avais vraiment envie de comprendre.

Après avoir écrit cet article, la solution à ce problème me paraît évidente, mais au moment de l'examen, cela ne semblait pas être le cas. J'ai honnêtement fait des recherches sur Google et je n'ai trouvé aucune situation similaire.

Conclusion : j'ai résolu le problème, mais je n'ai toujours pas compris la cause =(

Si quelqu'un a une idée ou soupçonne les raisons possibles de ce problème — je serais ravi de lire vos commentaires !

Source : habr.com