Introducción detallada al controlador de almacenamiento de Docker
Recientemente trabajé en un proyecto y no sabía cómo usar el controlador de almacenamiento de Docker durante este período, así que busqué información en línea y la resolví. Lo grabaré aquí.
Objetivo
Docker es un motor de contenedores de aplicación de código abierto que utiliza principalmente el espacio de nombres del núcleo de Linux para lograr el aislamiento de sandbox y utiliza CGroup para lograr la limitación de recursos. Docker es un contenedor de Linux liviano utilizado para el desarrollo y la implementación unificados, tratando de resolver el problema de "dependencia del infierno", combinando servicios y componentes dependientes, similares a los contenedores utilizados por los barcos y logrando una instalación e implementación rápida.
1. La arquitectura básica de Docker - Cliente y Daemon
Primero comprendamos la arquitectura básica y el proceso de inicio de Docker. De hecho, Docker adopta una arquitectura C/S, incluido el cliente y el servidor. Docker Daemon acepta solicitudes de los clientes como servidor y procesa estas solicitudes (cree, ejecute, envíe contenedores). El cliente y el servidor se comunican en la misma máquina a través de la API RESTFUL. En el proceso específico de uso, después de ejecutar Service Docker Start, el proceso Docker Deamon Daemon se genera en el host, se ejecuta en segundo plano y espere a recibir mensajes del cliente (es decir, los comandos de entrada Docker, como Docker Pull XXX, Docker Run ..., Docker Commit XXX) para lograr la interacción con Docker Deamon. Después de comenzar el servicio Docker, puede ver el proceso Docker.
Por defecto
[root@localhost ~]# ps -aux | GREP Dockerroot 11701 0.0 0.4 359208 16624? SSL 21:05 0:00/usr/bin/docker -d -h fd: // --selinux -habilitado --insecure -registry 186.100.8.216:5000 raíz 11861 0.0 0.0 113004 2256 PTS/0 S+ 23:01 0:00 GREP -COLOR = AUTO Docker
Esto se debe principalmente a que al especificar el sistema de archivos más adelante, debe configurar el controlador de almacenamiento específico en/etc/sysconfig/docker (esto escribirá un blog especial), y luego iniciar Docker Daemon, y no puede operar a través de los parámetros del comando Ejecutar. También puede configurarlo directamente desde la línea de comando de host a través de Docker d.
2. Método de almacenamiento de Docker - Conductor de almacenamiento
La parte central del modelo Docker es utilizar de manera efectiva el mecanismo de reflejo jerárquico. El espejo puede ser heredado a través de la jerarquía. Basado en la imagen básica (sin la imagen principal), se pueden hacer varias imágenes de aplicaciones específicas. Los diferentes contenedores de Docker pueden compartir algunas capas básicas del sistema de archivos, y al mismo tiempo, junto con sus propias capas de cambio únicas, mejorando en gran medida la eficiencia de almacenamiento. El mecanismo principal es el modelo jerárquico y montar diferentes directorios al mismo sistema de archivos virtuales (unir varios directorios en un solo sistema de archivos virtuales, de este artículo). Se utilizan varios controladores de almacenamiento diferentes para Docker de almacenamiento de espejo, que incluyen: AUFS, DeviceMapper, BTRFS y Overlay (del sitio web oficial). La siguiente es una breve introducción a diferentes controladores de almacenamiento.
AUFS
AUFS (OTROUNIONFS) es un sistema de archivos conjunto. AUFS admite la configuración de los permisos Readonly, ReadWrite y WhiteOutable para cada directorio de miembros (similar a GIT). Al mismo tiempo, hay un concepto similar en AUFS, donde las ramas con permisos de solo lectura pueden modificarse lógicamente de forma incremental (sin afectar la parte de solo lectura). El único controlador de almacenamiento de AUFS puede realizar el intercambio de bibliotecas de tiempo de ejecución ejecutables y compartibles entre contenedores, por lo que cuando ejecuta cientos de tiempos de ejecución con el mismo código de programa o bibliotecas de tiempo de ejecución, AUFS es una muy buena opción.
Mapeador
Dispositive Mapper es un mecanismo de marco de mapeo desde dispositivos lógicos hasta dispositivos físicos proporcionados en el núcleo Linux 2.6. Según este mecanismo, los usuarios pueden formular fácilmente las estrategias de gestión para implementar recursos de almacenamiento de acuerdo con sus necesidades (ver detalles). El controlador Mapper de dispositivo creará un archivo simple de 100 g que contiene sus imágenes y contenedores, cada contenedor está limitado a un volumen de tamaño de 10 g (nota: este es un archivo disperso creado automáticamente usando Loopback, específicamente datos y metadatos en/var/lib/docker/deviceMapper/DeviceMapper, que se puede expandir dinámicamente). Puede ajustar el tamaño del contenedor Docker, para referencia específica) puede usar el parámetro -s para especificar el controlador al iniciar el Docker Daemon, es decir, puede configurar el controlador de almacenamiento Docker por Docker -D -S DeviceMapper. Primero cierre el servicio Docker y ejecute el comando:
Por defecto
[root@localhost ~]# docker -d -s deviceMapperInfo [0000] +trabajo serveapi (unix: //var/run/docker.sock) info [0000] escuchando http en unix (/var/run/docker.sock) info [0000] +trabajo init_networkdriver () info [0000 0000 0000] (0) Información [0000] Cargando contenedores: Inicio. .... Información [0000] Cargando contenedores: Hechos. Info [0000] Docker Daemon: 1.4.0 4595d4f/1.4.0; ExecDriver: nativo-0.2; GraphDriver: DeviceMapper Info [0000] +Job AcceptConnections () Info [0000] -Job AceptConnections () = OK (0)
Además, Docker puede especificar el parámetro Storage-OPT al iniciar el contenedor, pero ahora solo DeviceMapper puede aceptar la configuración de los parámetros. Habrá pantallas de blog específicas más tarde.
Btrfs
El controlador BTRFS puede ser muy eficiente en Docker Build. Sin embargo, al igual que DeViceMapper, no admite el almacenamiento compartido entre dispositivos (participe en el sitio web oficial). BTRFS admite instantáneas y clones, y también puede administrar fácilmente múltiples dispositivos físicos. (Para más detalles, consulte la introducción de IBM a BTRFS)
cubrir
Overlay es muy similar a AUFS, pero su rendimiento es mejor que AUFS y tiene una buena utilización de memoria. Ahora se ha fusionado en Linux Kernel 3.18. Comando de uso específico: Docker DS Overlay
Nota en el sitio web oficial: actualmente no está respaldado en BTRFS o cualquier copia en el sistema de archivos de escritura y solo debe usarse en particiones EXT4.
3 Estructura del directorio Docker
Los dos conceptos más importantes de Docker son espejos y contenedores. Entonces, ¿dónde está la imagen que retiramos almacenada? Después de que se inicia el contenedor de ejecución del espejo, ¿dónde se modifica el contenido de nuestra operación? Debido a que los controladores específicos son diferentes, el efecto de implementación final es diferente. Analicemos la estructura de almacenamiento de Docker utilizando el controlador de almacenamiento de mapeadores de dispositivos como ejemplo.
1. Ingrese el directorio/var/lib/docker y enumere el contenido:
Por defecto
[root@localhost ~]# cd/var/lib/docker/[root@localhost docker]# lscontainers deviceMapper execdriver gráfico init linkgraph.db repositorios-deviceMapper TMP Trust Volumes
Según el contenido del directorio, es obvio que se usa el controlador DeviceMapper.
Nota: Las carpetas que se muestran a continuación son todas debajo/var/lib/docker.
2. ¿Qué carpeta existe el archivo de imagen? (Consulte)
La información de la imagen de Pull se guarda en la carpeta gráfica, y el contenido de la imagen existe en DeviceMapper/ DeviceMapper/ Data.
3. ¿Dónde se ejecuta el contenedor iniciado?
La información de configuración del contenedor iniciado se guarda en contenedores, y el ExecDriver/ Native/ también se ve.
El contenido de la operación en el contenedor se guarda en DeviceMapper/DeviceMapper/Data.
4. El papel del gráfico
En la arquitectura Docker, reproduce el custodio de la imagen del contenedor descargado y la grabadora de la relación entre la imagen del contenedor descargado. En el directorio local del gráfico, la información específica almacenada para cada imagen del contenedor es: los metadatos (JSON) de la imagen del contenedor, la información del tamaño de la capa (capas) de la imagen del contenedor y las raíces específicas representadas por la imagen del contenedor.
5. Prueba experimental:
- Inicialmente ningún contenedor está habilitado:
Por defecto
[root@localhost docker]# ll contenedores/total 0
- Inicie un contenedor:
Por defecto
[root@localhost docker]# docker run -i -t - -rm centos: 7 /bin /bash [root@187a8f9d2865 /]#
El UUID del contenedor iniciado = 187A8F9D2865
- Antes de comenzar el contenedor, verifique el tamaño real del archivo en/var/lib/docker/deviceMapper/deviceMapper/
Por defecto
[root@bhdocker216 docker]# du -h deviceMapper/deviceMapper/*2.1g deviceMapper/deviceMapper/data3.5m deviceMapper/deviceMapper/metadata
- Ver sobre el host
Por defecto
[root@bhdocker216 docker]# ls contenedores/187a8f9d2865c2ac *** 91b981
Verifique el contenido del contenedor iniciado debajo de la carpeta UUID:
Por defecto
[root@bhdocker216 contenedores]# ll 187a8f9d2865c2ac *** 91b981total 24-rw -----. 1 raíz raíz 273 marzo 5 23:59 187a8f9d2865 ***-json.log-rw-r--. 1 raíz raíz 1683 marzo de marzo 23:58 config.json-rw-r--. 1 raíz raíz 334 marzo 5 23:58 hostconfig.json-rw-r--. 1 raíz de raíz 13 de marzo 5 23:58 Nombre de host-rw-r--. 1 raíz raíz 174 marzo 5 23:58 hosts-rw-r--. 1 raíz raíz 69 marzo 5 23:58 resolv.conf- Agregar archivo en el contenedor de inicio y verlo.
Primero cree un archivo en el contenedor en ejecución:
Por defecto
[root@8a1e3ad05d9e/]# dd if =/dev/cero of = floppy.img bs = 512 count = 57605760+0 registros in5760+0 registros out2949120 bytes (2.9 mb) copiados, 0.0126794 S, 233 MB/s
Luego vea el archivo en/var/lib/docker/deviceMapper/deviceMapper/:
Por defecto
[root@bhdocker216 docker]# du -h deviceMapper/deviceMapper/*5.5g DeviceMapper/DeviceMapper/Data4.6m DeviceMapper/DeviceMapper/Metadata
El tamaño de este lugar es un poco diferente porque primero ejecuté #dd if =/dev/cero de = test.txt bs = 1m count = 8000 para crear un archivo de tamaño 8G. Lo terminé porque era demasiado lento, pero puedo ver claramente que ambas carpetas han cambiado (agregado) al operar en el contenedor en ejecución.
- Verifique el gráfico. Cuando solo se extrae una imagen (Ubuntu14.10), aparecen 7 directorios con nombre de UUID largo. ¿Cómo surgió esto?
Use el árbol de imágenes Docker para enumerar la estructura del árbol de espejo, y podemos ver la estructura de almacenamiento jerárquico del espejo. El Ubuntu final (capa 7) se basa en los cambios de la capa 6, es decir, la capa N-Th en este árbol lógico se basa en los cambios N-1, y la capa N depende de la imagen N-1. La capa 0, el tamaño es 0, se llama imagen base.
- ¿Cuál es el contenido en el directorio gráfico/UUID?
Por defecto
[Root@localhost gráfico]# ll 01BF15A18638145EB *** -HTOTAL 8.0K-RW -----. 1 raíz raíz 1.6k marzo 5 18:02 JSON-RW -----. 1 raíz raíz 9 marzo 5 18:02 capas
Vea el contenido de capas: el tamaño de la capa de representación digital (Unidad: B). JOSN: Guarde los metadatos de esta imagen (como: tamaño, arquitectura, configuración, contenedor, ** UUID de padres **, etc.).
- Ver la carpeta DeviceMapper/DeviceMapper
Hay dos carpetas, datos y metadatos. De hecho, el controlador Mapper de dispositivos almacena los archivos de espejo y contenedor en el archivo ** Data **. Puede ver el tamaño de los datos y los metadatos a través de la información de Docker. Además, puede usar Du H (utilizado anteriormente) para ver los tamaños reales de estos dos archivos dispersos.
- ExecDriver
Por defecto
[root@bhdocker216 docker]# ls execdriver/nativo/8a1e3ad05d9e66a455e683a2c *** 2437bdcccdfdfa // Ver el contenido dentro: [root@bhdocker216 8a1e3ad05d9e66a455ee ***]
- volúmenes
Los volúmenes sin el parámetro -v están vacíos. Después de la prueba, si se inicia el contenedor, agregue el parámetro -V, se mostrará un UUID en la carpeta Volumes. Se realizará una búsqueda global en el host y se encontrará solo bajo volúmenes. No tiene nada que ver con la imagen y el UUID del contenedor.
Por defecto
[root@bhdocker216 docker]# find/-name 86eb77f9f5e25676f100 *** d5a/var/lib/docker/volumes/86eb77f9f5e25676f100 *** d5a // Ver el contenido dentro: [root@bhdocker216 volumes]# lsss]# lss 86eb77f9f5e25676f100 *** d5aconfig.json [root@bhdocker216 volúmenes]# cat 86eb77f9f5e25676f100 *** d5a /config.json {"Id": "86eb77f9f5e25676f100a89ba727bc15185303236aae0dcf4c17223e37651d5a", "ruta": "/home/data", "isbindmount": verdadero, "wrencial": verdadero} Descripción de la tabla de la función de carpeta
Haga un resumen, organice una tabla y explique las funciones de diferentes carpetas en/var/lib/docker:
Gracias por leer, espero que pueda ayudarte. ¡Gracias por su apoyo para este sitio!