A más tardar hace un par de días, se decidió en uno de los servidores mover el almacenamiento de la ventana acoplable (el directorio donde la ventana acoplable almacena todos los archivos de contenedores, imágenes) a una partición separada, que
Poseía más capacidad. La tarea, al parecer, es trivial y no presagia problemas ...
Comenzando:
1. Pare y elimine todos los contenedores de nuestra aplicación:
docker-compose down
Si hay muchos contenedores y están en una composición diferente, puede hacer esto:
docker rm -f $(docker ps -q)
2. Detenga el demonio de docker:
systemctl stop docker
3. Mueva el directorio a la ubicación deseada:
cp -r /var/lib/docker /docker/data/storage
4. Informamos al demonio del acoplador para que busque en un nuevo directorio. Hay varias opciones: usar el indicador -g para apuntar el demonio a una nueva ruta, o las configuraciones de systemd, que usamos. Bueno, o enlace simbólico. No lo pintaré mucho, Internet está
lleno de manuales sobre cómo portar la raíz del acoplador a una nueva ubicación.
5. Iniciamos el demonio Docker, y vemos que se ve donde debería estar:
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 pasara al demonio, ¡ahora comprobaremos si la ha aplicado (gracias
inkvizitor68sl )!
docker info | awk '/Root Dir/ {print $NF}'
6. Comenzamos nuestra aplicación:
docker-compose up -d
7. Verificar
Y aquí comienza la diversión, DBMS, MQ, ¡todo está bien! La base está intacta, todo funciona ... excepto nginx. Tenemos nuestro propio ensamblaje nginx con kerberos
y cortesanas . Y ver los registros del contenedor indicaba que no podía escribir en / var / tmp - Permiso denegado. Estiro los dedos con whisky e intento analizar la situación ... ¿Cómo es eso? La imagen de la ventana acoplable no cambió. Acabamos de mover el directorio. Siempre funcionó, y aquí está para ti ... En aras del experimento, entré en el contenedor con bolígrafos y cambié los derechos de este directorio, había
root, root 755 , dio
root, root 777 . Y todo comenzó ... Un pensamiento sonó en mi cabeza, una especie de tontería ... Pensé, bueno, tal vez no tuve en cuenta algo ...
Decidí que nos gustaban los derechos de acceso a los archivos durante la transferencia. Detuvieron la aplicación, el demonio docker, eliminaron el nuevo directorio e hicieron una copia del directorio / var / lib / docker que ya usa
rsync -a .
Creo que ahora todo está bien, estamos elevando la ventana acoplable, la aplicación.
III ... el problema persiste ... Mi ojo tembló. Me apresuré a la consola de mi máquina virtual, donde estoy ejecutando varias pruebas, tuve esta imagen nginx y me metí dentro del contenedor, y aquí los derechos raíz, root 777 están en el directorio / var / tmp. Es decir, los mismos que tuve que configurar con mis manos . ¡Pero las imágenes son idénticas!
En todas partes se usa FS xfs.Comparé a través del comando
docker inspect my-nginx:12345
Todos los hashes son idénticos, todos uno a uno. Tanto en el servidor como en mi virtualka. Eliminé la imagen nginx local y volví a poner en cola el registro, que por varias razones está en la misma máquina. Y el problema es el mismo ... Ahora mi segundo ojo se crispó.
No recuerdo qué pensamientos había en mi cabeza, además de los gritos de "AAAAAAA" y otras cosas. En la calle a las 4 en punto de la mañana, las fuentes de la ventana acoplable se utilizaron para comprender el principio de capas de imágenes hash. Abrió la tercera lata de energía. Y al final, me di cuenta de que el hashing solo tiene en cuenta el archivo, su contenido, ¡pero
NO EL DERECHO DE ACCESO ! Es decir, de alguna manera misteriosa, los derechos fueron vencidos, y selinux está deshabilitado, no se usa acl, no está presente un bit adhesivo.
Eliminé la imagen local, también eliminé la imagen del registro de Docker y la comencé de nuevo. Y funcionó. Resulta que durante la transferencia se violaron los derechos, tanto dentro de la imagen local como dentro de la imagen que se encuentra en el registro. Como 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 trataron de devolver la mirada del acoplador al antiguo catálogo, no, lamentablemente, las circunstancias no lo permitieron. Sí, y realmente quería resolverlo.
Después de escribir este artículo, la solución al problema me parece obvia, pero en el momento del análisis no parecía ser así. Honestamente busqué en Google y no encontré situaciones similares.
En pocas palabras: resolví el problema, no entendí la razón = (
Si alguien sabe / adivina / tuvo una visión sobre las posibles causas de este problema, ¡me alegrará mucho verte en los comentarios!