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

Il y a quelques jours à peine, il a été décidé sur l'un des serveurs de déplacer le stockage Docker (le répertoire dans lequel Docker stocke tous les fichiers conteneurs et images) vers une section distincte, qui
avait une plus grande capacité. La tâche semblait anodine et ne présageait pas d'ennuis...

Mise en route:

1. Arrêtez et tuez tous les conteneurs de notre application :

docker-compose down

s'il y a beaucoup de contenants et qu'ils sont de compositions différentes, vous pouvez faire ceci :

docker rm -f $(docker ps -q)

2. Arrêtez le démon Docker :

systemctl stop docker

3. Déplacez le répertoire à l'emplacement souhaité :

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

4. Nous disons au démon docker de rechercher dans le nouveau répertoire. Il existe plusieurs options : soit utilisez l'indicateur -g pour pointer le démon vers un nouveau chemin, soit les configurations systemd, que nous avons utilisées. Ou un lien symbolique. Je ne rentrerai pas trop dans les détails, c’est sur Internet. est plein manuels sur le déplacement de la racine du docker vers un nouvel emplacement.

5. Démarrez le démon Docker et assurez-vous qu'il apparaît au bon endroit :

systemctl status docker

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

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

Nous nous sommes assurés que l'option était passée au démon, vérifions maintenant s'il l'a appliquée (merci inkvizitor68sl)!

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

6. Commençons notre application :

docker-compose up -d

7. Vérification

Et c'est ici que le plaisir commence, SGBD, MQ, tout va bien ! La base de données est intacte, tout fonctionne... sauf nginx. Nous avons notre propre version nginx avec Kerberos et courtisanes. Et l'affichage des journaux du conteneur a indiqué qu'il ne pouvait pas écrire dans /var/tmp - Autorisation refusée. Je me pétris les tempes avec mes doigts et j'essaie d'analyser la situation... Comment est-ce possible ? L'image Docker n'a pas changé. Nous venons de déplacer le répertoire. Cela a toujours fonctionné, et le voici pour vous... Par souci d'expérimentation, je suis entré dans le conteneur avec mes mains et j'ai modifié les droits sur ce répertoire, il y avait racine, racine 755, a donné racine, racine 777. Et tout a commencé... Une pensée a commencé à résonner dans ma tête - une sorte d'absurdité... J'ai pensé, eh bien, peut-être que je n'avais pas pris en compte quelque chose...

J'ai décidé que nous étions tombés amoureux des droits d'accès aux fichiers lors du transfert. Nous avons arrêté l'application, le démon docker, supprimé le nouveau répertoire et copié le répertoire /var/lib/docker en utilisant rsync -a.

Je pense que tout va bien maintenant, développons l'application Docker.

Aaand... le problème restait... Mon œil se contracta. Je me suis précipité vers la console de ma machine virtuelle, où j'ai exécuté divers tests, j'avais cette image nginx, et je suis monté à l'intérieur du conteneur, et ici les droits sur le répertoire /var/tmp sont root, root 777. C'est-à-dire que le pareil que j'ai dû régler manuellement. Mais les images sont identiques !

Le système de fichiers xfs était utilisé partout.

J'ai comparé en utilisant la commande

docker inspect my-nginx:12345

Tous les hachages sont identiques, tous un à un. Aussi bien sur le serveur que sur ma machine virtuelle. J'ai supprimé l'image nginx locale et je l'ai extraite à nouveau du registre, qui, pour plusieurs raisons, se trouve sur la même machine. Et le problème est le même... Maintenant, mon deuxième œil tremble.

Je ne me souviens plus des pensées que j'avais en tête, à part crier « AAAAAAAA » et d'autres choses. Il était 4 heures du matin et le code source de Docker a été utilisé pour comprendre le principe du hachage des couches d'images. J'ai ouvert la troisième canette de boisson énergisante. Et à la fin, je me suis rendu compte que le hachage ne prend en compte que le fichier, son contenu, mais PAS DE DROITS D'ACCÈS! Autrement dit, d'une manière mystérieuse, nos droits ont été perdus, selinux est désactivé, acl n'est pas utilisé et il n'y a pas de bit collant.

J'ai supprimé l'image locale, j'ai également supprimé l'image du registre Docker et je l'ai repoussée. Et tout a fonctionné. Il s'avère que lors du transfert, les droits ont été perdus, tant à l'intérieur de l'image locale qu'à l'intérieur de l'image se trouvant dans le registre. Comme je l'ai déjà dit, pour plusieurs raisons, il se trouvait sur la même voiture. Et par conséquent, dans un répertoire /var/lib/docker.

Et anticipant la question de savoir s'ils ont essayé de ramener le regard du docker sur l'ancien répertoire - non, ils n'ont pas essayé, hélas, les circonstances ne l'ont pas permis. Oui, et je voulais vraiment le comprendre.

Après avoir écrit cet article, la solution au problème me semble évidente, mais au moment de l’analyse elle ne le semblait pas. Honnêtement, j’ai cherché sur Google et je n’ai pas trouvé de situations similaires.

Résultat : j'ai résolu le problème, je ne comprends toujours pas la raison =(

Si quelqu'un sait, devine, a une vision des causes possibles de ce problème, je serai extrêmement heureux d'avoir de vos nouvelles dans les commentaires !

Source: habr.com