tag setup hub example docker device-mapper

hub - docker-storage-setup



Entorno limpio de docker: devicemapper (2)

Tengo un entorno Docker con 2 contenedores (Jenkins y Nexus, ambos con su propio volumen). Tengo un trabajo cron diario que elimina contenedores e imágenes sin usar. Esto está funcionando bien. Pero el problema está dentro de mi devicemapper:

du -sh /var/lib/docker/ 30G docker/

Puedo cada carpeta en mi carpeta de portada: Volúmenes (grande, pero eso es normal en mi caso):

/var/lib/docker# du -sh volumes/ 14G volumes/

Contenedores:

/var/lib/docker# du -sh containers/ 3.2M containers/

Imágenes:

/var/lib/docker# du -sh image/ 5.8M image/

Devicemapper:

/var/lib/docker# du -sh devicemapper/ 16G devicemapper/

/var/lib/docker/devicemapper/mnt es 7.3G /var/lib/docker/devicemapper/devicemapper es 8.1G

Información de Docker:

Storage Driver: devicemapper Pool Name: docker-202:1-xxx-pool Pool Blocksize: 65.54 kB Base Device Size: 10.74 GB Backing Filesystem: ext4 Data file: /dev/loop0 Metadata file: /dev/loop1 Data Space Used: 5.377 GB Data Space Total: 107.4 GB Data Space Available: 28.8 GB Metadata Space Used: 6.148 MB Metadata Space Total: 2.147 GB Metadata Space Available: 2.141 GB Udev Sync Supported: true

¿Qué es este espacio y puedo limpiarlo sin romper cosas?

Primero, ¿qué es devicemapper ( documentación oficial )?

Device Mapper se ha incluido en el núcleo principal de Linux desde la versión 2.6.9. Es una parte central de la familia RHEL de distribuciones de Linux.

El controlador devicemapper almacena cada imagen y contenedor en su propio dispositivo virtual. Estos dispositivos son dispositivos de instantáneas de copiado sobre escritura de aprovisionamiento fino.
La tecnología de Device Mapper funciona en el nivel de bloque en lugar del nivel de archivo. Esto significa que las operaciones de thin provisioning y copy-on-write del controlador de almacenamiento de dispositivo funcionan con bloques en lugar de archivos completos.

El devicemapper es el controlador de almacenamiento Docker predeterminado en algunas distribuciones de Linux.

Los hosts Docker que ejecutan el controlador de almacenamiento devicemapper de forma predeterminada a un modo de configuración conocido como loop-lvm. Este modo usa archivos dispersos para construir el grupo delgado utilizado por las instantáneas de imagen y contenedor

Docker 1.10 y versiones posteriores ya no coinciden con los ID de la capa de imagen con nombres de directorio en / var / lib / docker.
Sin embargo, hay dos directorios clave.

  • El directorio /var/lib/docker/devicemapper/mnt contiene los puntos de montaje para las capas de imágenes y contenedores .
  • El directorio / var / lib / docker / devicemapper / metadatad contiene un archivo para cada capa de imagen y una instantánea de contenedor.

Si la docker info su devicemapper muestra que su Storage Driver es devicemapper (y no aufs ), proceda con precaución con esas carpetas.
Véase, por ejemplo, el número 18867 .

¡No use un archivo de loop de mapa de dispositivo para nada serio ! Docker tiene grandes advertencias sobre esto.

El directorio /var/lib/docker/devicemapper/devicemapper contiene los archivos de bucle dispersos que contienen todos los datos que el docker monta. Entonces necesitaría usar herramientas lvm para navegar alrededor de ellos y hacer cosas. Aunque hayas leído los problemas con el DeviceMapper , están un poco resueltos pero quizás no.

Me alejaría de devicemapper siempre que fuera posible o usaría pools finos de LVM en cualquier dispositivo basado en RHEL. Si no puede cambiar los controladores de almacenamiento, el mismo procedimiento al menos aclarará cualquier espacio escaso asignado que no pueda reclamar.

Cambiar el controlador de almacenamiento de la ventana acoplable

Cambiar el controlador de almacenamiento requerirá volcar sus directorios /var/lib/docker que contienen todos sus datos de acoplador. Hay formas de guardar partes, pero eso implica jugar con las partes internas de Docker. Es mejor comprometer y exportar los contenedores o volúmenes que desee conservar e importarlos después del cambio. De lo contrario, tendrá una nueva instalación Docker en blanco.

  1. Exportar datos

  2. Detener Docker

  3. Eliminar /var/lib/docker

  4. Modifique su inicio de docker para usar el nuevo controlador de almacenamiento. Establezca --storage-driver=<name> en /lib/systemd/system/docker.service o /etc/systemd/system/docker.service o /etc/default/docker o /etc/sysconfig/docker

  5. Comience Docker

  6. Datos de importacion

AUFS

AUFS no está en el núcleo principal (y nunca lo estará), lo que significa que la distribución debe incluirlo activamente de alguna manera. Para Ubuntu está en los paquetes linux-image-extra .

apt-get install linux-image-extra-$(uname -r) linux-image-extra-virtual

A continuación, cambie la opción del controlador de almacenamiento a --storage-driver=aufs

OverlayFS

OverlayFS ya está disponible en Ubuntu, simplemente cambie el controlador de almacenamiento a --storage-driver=overlay2 o --storage-driver=overlay si todavía está usando un núcleo 3.x

No estoy seguro de cuán buena idea es esto ahora. No puede ser mucho peor que el archivo de bucle, pero el controlador overlay2 es bastante sólido para el uso del desarrollador, pero aún no se considera preparado para la producción (por ejemplo, Docker Enterprise no brinda soporte) pero se está convirtiendo en el controlador estándar debido a los problemas AUFS / Kernel.

Grupo delgado directo LVM

En lugar del archivo de bucle del mapeador de dispositivos, puede usar directamente un conjunto delgado de LVM. RHEL hace que esto sea fácil con una utilidad docker-storage-setup que se distribuye con su paquete EPEL Docker. Docker tiene pasos detallados para configurar los volúmenes de forma manual .

--storage-driver=devicemapper / --storage-opt=dm.thinpooldev=/dev/mapper/docker-thinpool / --storage-opt dm.use_deferred_removal=true

Docker 17.06+ es compatible con la administración de configuraciones simples direct-lvm dispositivos de bloque direct-lvm para usted.

Simplemente no se quede sin espacio en el volumen LVM, nunca. Usted termina con un daemon Docker que no responde y necesita ser eliminado y luego recursos LVM que todavía están en uso y que son difíciles de limpiar.