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

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

Comenzando:

1. Detener y eliminar todos los contenedores de nuestra aplicación:

docker-compose down

Si hay muchos contenedores y tienen diferentes composiciones, puedes hacer esto:

docker rm -f $(docker ps -q)

2. Detenga el demonio acoplable:

systemctl stop docker

3. Mueva el directorio a la ubicación deseada:

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

4. Le decimos al demonio acoplable que busque en el nuevo directorio. Hay varias opciones: usar el indicador -g para señalar al demonio una nueva ruta, o las configuraciones systemd, que usamos. O un enlace simbólico. No entraré en demasiados detalles sobre esto, está en Internet. esta lleno manuales sobre cómo mover la raíz de Docker a una nueva ubicación.

5. Inicie el demonio de la ventana acoplable y asegúrese de que se encuentre en el lugar correcto:

systemctl status docker

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

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

Nos aseguramos de que la opción se haya pasado al demonio, ahora verifiquemos si la aplicó (gracias tintavizitor68sl)!

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

6. Comencemos nuestra aplicación:

docker-compose up -d

7. Comprobación

Y aquí comienza la diversión, DBMS, MQ, ¡todo está bien! La base de datos está intacta, todo funciona... excepto nginx. Tenemos nuestra propia compilación de nginx con Kerberos y cortesanas. Y al ver los registros del contenedor se indicó que no se puede escribir en /var/tmp - Permiso denegado. Me masajeo las sienes con los dedos y trato de analizar la situación... ¿Cómo es posible? La imagen de Docker no cambió. Acabamos de mover el directorio. Siempre funcionó, y aquí está para ti... Para experimentar, entré al contenedor con mis manos y cambié los derechos de este directorio, había raíz, raíz 755, dio raíz, raíz 777. Y todo empezó... Un pensamiento empezó a sonar en mi cabeza, una especie de tontería... Pensé, bueno, tal vez no tomé algo en cuenta...

Decidí que nos enamoramos de los derechos de acceso a los archivos durante la transferencia. Detuvimos la aplicación, el demonio de Docker, eliminamos el nuevo directorio y copiamos el directorio /var/lib/docker usando rsync -a.

Creo que todo está bien ahora, levantemos la aplicación Docker.

Y... el problema persistió... Mi ojo tembló. Corrí a la consola de mi máquina virtual, donde realicé varias pruebas, tenía esta imagen de nginx y subí al contenedor, y aquí los derechos para el directorio /var/tmp son root, root 777. Es decir, el Lo mismo que tuve que configurar manualmente. ¡Pero las imágenes son idénticas!

El sistema de archivos xfs se utilizó en todas partes.

Comparé usando el comando

docker inspect my-nginx:12345

Todos los hashes son idénticos, todos uno a uno. Tanto en el servidor como en mi máquina virtual. Eliminé la imagen nginx local y la saqué nuevamente del registro, que por varias razones está en la misma máquina. Y el problema es el mismo... Ahora mi segundo ojo tiembla.

Ya no recuerdo qué pensamientos pasaban por mi cabeza, además de gritar “AAAAAAAAA” y otras cosas. Eran las 4 de la mañana y se utilizó el código fuente de Docker para comprender el principio de hash de capas de imágenes. Abrió la tercera lata de bebida energética. Y al final me di cuenta de que el hash solo tiene en cuenta el archivo, su contenido, pero NO DERECHOS DE ACCESO! Es decir, de alguna manera misteriosa hemos perdido nuestros derechos, selinux está deshabilitado, no se usa acl y no hay ningún bit adhesivo.

Eliminé la imagen local, también eliminé la imagen del registro de Docker y la volví a enviar. Y todo funcionó. Resulta que durante la transferencia se perdieron los derechos, tanto dentro de la imagen local como dentro de la imagen que se encuentra en el registro. Como ya dije, por varias razones estaba ubicado en el mismo auto. Y como resultado, en un directorio /var/lib/docker.

Y anticipando la pregunta de si intentaron devolver la mirada del estibador al directorio anterior, no, no lo intentaron, por desgracia, las circunstancias no lo permitieron. Sí, y tenía muchas ganas de resolverlo.

Después de escribir este artículo, la solución al problema me parece obvia, pero en el momento del análisis no lo parecía. Honestamente, busqué en Google y no encontré situaciones similares.

Resultado: resolví el problema, todavía no entiendo el motivo =(

Si alguien sabe, adivina o tuvo una visión sobre las posibles causas de este problema, ¡estaré encantado de saber de usted en los comentarios!

Fuente: habr.com