Il y a quelques jours au plus tard, il a été décidé de déplacer l'un des serveurs de stockage (le répertoire où le docker stocke tous les fichiers des conteneurs, des images) vers une partition distincte, ce qui
possédait plus de capacité. La tâche, semble-t-il, est insignifiante et ne laisse présager aucun problème ...
Pour commencer:
1. Arrêtez et tuez tous les conteneurs de notre application:
docker-compose down
s'il y a beaucoup de conteneurs et qu'ils sont de composition différente, vous pouvez le faire:
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 informons le démon du docker de chercher dans un nouveau répertoire. Il existe plusieurs options: soit utiliser l'indicateur -g pour pointer le démon vers un nouveau chemin, soit les configurations systemd, que nous avons utilisées. Eh bien, ou lien symbolique. Je ne le peindrai pas beaucoup, Internet
regorge de manuels sur le portage de la racine docker vers un nouvel emplacement.
5. Nous démarrons le démon docker et voyons qu'il regarde où il devrait être:
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 a été transmise au démon, nous allons maintenant vérifier si elle l'a appliquée (merci
inkvizitor68sl )!
docker info | awk '/Root Dir/ {print $NF}'
6. Nous commençons notre application:
docker-compose up -d
7. Vérifiez
Et ici le plaisir commence, SGBD, MQ, tout va bien! La base est intacte, tout fonctionne ... sauf pour nginx. Nous avons notre propre assemblage nginx avec des kerberos
et des courtisanes . Et l'affichage des journaux du conteneur indiquait qu'il ne pouvait pas écrire dans / var / tmp - Autorisation refusée. J'étire mes doigts avec du whisky et j'essaie d'analyser la situation ... Comment ça? L'image du 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érience, je suis allé dans le conteneur avec des stylos et j'ai changé les droits sur ce répertoire, il y avait
root, root 755 , give
root, root 777 . Et tout a commencé ... Une pensée a sonné dans ma tête - une sorte de non-sens ... J'ai pensé, eh bien, peut-être que je n'ai pas pris en compte quelque chose ...
J'ai décidé que nous aimions les droits d'accès aux fichiers lors du transfert. Ils ont arrêté l'application, le démon docker, supprimé le nouveau répertoire et fait déjà une copie du répertoire / var / lib / docker en utilisant
rsync -a .
Je pense que maintenant tout va bien, nous élevons le docker, l'application.
III ... le problème demeure ... Mon œil se contracta. Je me suis précipité vers la console de ma machine virtuelle, où j'exécute divers tests, j'ai eu cette image nginx, et j'ai grimpé à l'intérieur du conteneur, et ici les droits root, root 777 sont dans le répertoire / var / tmp. Autrement dit, les mêmes que j'ai dû configurer avec mes mains . Mais les images sont identiques!
Partout utilisé FS xfs.J'ai comparé via la commande
docker inspect my-nginx:12345
Tous les hachages sont identiques, tous un à un. À la fois sur le serveur et sur mon virtualka. J'ai supprimé l'image nginx locale et j'ai de nouveau mis en file d'attente le 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 se contracta.
Je ne me souviens pas quelles pensées étaient dans ma tête, à part les cris de "AAAAAAA" et d'autres choses. Dans la rue à 4 heures du matin, les sources dockers ont été utilisées pour comprendre le principe du hachage des calques d'images. Il a ouvert la troisième boîte d'énergie. Et au final, il m'est apparu que le hachage ne prend en compte que le fichier, son contenu, mais
PAS LE DROIT D'ACCÈS ! Autrement dit, d'une manière mystérieuse, les droits ont été battus et selinux est désactivé, acl n'est pas utilisé, le bit collant n'est pas présent.
J'ai supprimé l'image locale, j'ai également supprimé l'image du registre Docker et l'ai redémarrée. Et ça a marché. Il s'avère que lors du transfert, les droits ont été battus, à la fois à l'intérieur de l'image locale et à l'intérieur de l'image se trouvant dans le registre. Comme je l'ai dit, pour un certain nombre de raisons, il était situé sur la même voiture. Et par conséquent dans un répertoire / var / lib / docker.
Et anticipant la question de savoir s'ils essayaient de retourner le regard du docker sur l'ancien catalogue - non, hélas, les circonstances ne le permettaient pas. 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 semblait pas l'être. Honnêtement, j'ai googlé et je n'ai pas trouvé de situations similaires.
Conclusion: j'ai résolu le problème, je n'ai pas compris la raison = (
Si quelqu'un sait / devine / a une vision des causes possibles de ce problème - je serai extrêmement heureux de vous voir dans les commentaires!