Historia del problema de la migración del almacenamiento de docker (raíz de docker)

Hace un par de días se decidió trasladar el almacenamiento de docker (el directorio donde docker almacena todos los archivos de contenedores e imágenes) a una partición separada en uno de los servidores, que
tenía mayor capacidad. La tarea parecía trivial y no presagiaba problemas...

Comencemos:

1. Detenemos y eliminamos todos los contenedores de nuestra aplicación:

docker-compose down

si hay muchos contenedores y están en diferentes composiciones, se puede hacer así:

docker rm -f $(docker ps -q)

2. Detenemos el demonio de docker:

systemctl stop docker

3. Movemos el directorio al lugar deseado:

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

4. Informamos al demonio de docker para que mire en el nuevo directorio. Aquí hay varias opciones: o especificamos el nuevo camino al demonio a través de la opción -g, o estamos utilizando las configuraciones de systemd. O un enlace simbólico. No me detendré a describir esto, hay muchos manuales en internet sobre cómo mover la raíz de docker a un nuevo lugar.

5. Iniciamos el demonio de docker y observamos que esté mirando donde debe:

systemctl status docker

En una de las líneas de salida deberíamos ver:

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

Confirmamos que hemos pasado la opción al demonio, ahora verifiquemos si la aplicó (gracias a inkvizitor68sl)!

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

6. Iniciamos nuestra aplicación:

docker-compose up -d

7. Verificamos

Y aquí es donde empieza lo más interesante, la base de datos, MQ, ¡todo bien! La base está intacta, todo funciona… excepto nginx. Tenemos nuestra propia construcción de nginx con Kerberos y complementos. Y la revisión de los registros del contenedor indicó que no podía escribir en /var/tmp — Permission denied. Estoy masajeando mis sienes y tratando de analizar la situación… ¿Cómo es posible? La imagen de docker no había cambiado. Solo movimos el directorio. Siempre funcionó, y ahora esto… Por experimento, entré manualmente en el contenedor y cambié los permisos de este directorio, que eran root, root 755, di root, root 777. Y todo comenzó a funcionar… En mi cabeza resonó el pensamiento — es una locura… Pensé, tal vez no conté con algo…

Decidí que habíamos perdido los permisos de los archivos durante la transferencia. Detuvimos la aplicación, el demonio de docker, eliminamos el nuevo directorio y realizamos la copia del directorio /var/lib/docker usando rsync -a.

Creo que ahora todo está bien, subimos docker, la aplicación.

Y... el problema persiste... Me tiembla el ojo. Corrí a la consola de mi máquina virtual, donde ejecuto diversas pruebas. Tenía esta imagen de nginx y entré en el contenedor. Allí, en el directorio /var/tmp, los permisos son root, root 777. Es decir, los mismos que tuve que establecer manualmente. Pero ¡las imágenes son idénticas!

Se utilizó el sistema de archivos xfs en todas partes.

Comparé usando el comando

docker inspect my-nginx:12345

Todos los hashes son idénticos, exactamente iguales. Tanto en el servidor como en mi máquina virtual. Eliminé la imagen local de nginx y la volví a descargar desde el registro, que por varias razones se encuentra en la misma máquina. Y el problema persiste... Ahora me tiembla el segundo ojo.

Ya no recuerdo qué pensamientos había en mi cabeza, aparte de los gritos de ¡“AAAAAA”! y demás. Era la 1:00 AM, y recurrí a los fuentes de Docker con el fin de comprender el principio de hash de las capas de la imagen. Abrí la tercera lata de energética. Y al final comprendí que el hashing solo tiene en cuenta el archivo, su contenido, pero ¡NO LOS PERMISOS!¡Es decir, de alguna manera misteriosa, se rompieron los permisos, además selinux está desactivado, no se utilizan acl, y no hay sticky bit!

Eliminé la imagen local, también eliminé la imagen del registro de Docker y la volví a subir. Y todo funcionó. Resulta que al transferir, los permisos se rompieron, tanto en la imagen local como en la imagen del registro. Como ya mencioné, por varias razones, este estaba en la misma máquina. Y como resultado, en el mismo directorio /var/lib/docker.

Y anticipando la pregunta, si intenté volver a enfocar Docker en el antiguo directorio — no, no lo intenté, lamentablemente las circunstancias no lo permitieron. Además, realmente quería resolverlo.

Después de escribir este artículo, la solución del problema me parece obvia, pero en el momento de analizarlo no parecía así. Honestamente, googleé y no encontré situaciones similares.

Conclusión: resolví el problema, pero no entendí la causa =(

Si alguien sabe o tiene una idea sobre las posibles causas de este problema, ¡estaré muy agradecido si lo dejan en los comentarios!

Fuente: habr.com