Los drivers se utilizan para fusionar las distintas capas que forman una imagen, añadirle la capa de lectura/escritura del contenedor y y mostrar al contenedor un sistema de archivos con todas las capas unificadas. Docker utiliza por defecto el sistema de archivos overlay de Linux para hacer esto, con el driver overlay2.

Cuando se lanza un contenedor, Docker utiliza el driver de almacenamiento para poner una capa de escritura sobre las capas de la imagen. La capa de escritura guardará todos los cambios que haga el proceso del contenedor sobre el sistema de archivos. Esta capa se eliminará de forma automática cuando se elimine el contenedor (si se ejecutó con la opción --rm de docker run o al borrarlo con docker rm).

Para persistir los datos de los contenedores que corran en un host, tenemos dos opciones, usar volúmenes gestionados por Docker o exponer contenido del host en el contenedor mediante un punto de montaje. Cualquiera de las dos opciones se configura con las opciones -v o --mount de docker run, que no son equivalentes (-v crea la carpeta en el host si no existe ya, mientras que --mount requiere que el origen exista).

Los volúmenes son una de las formas que tiene Docker para persistir los datos d e un contenedor. Tiene varias ventajas frente a los bind mounts, como permitir que se comparta la información de forma más segura entre contenedores y estar soportados en las distintas plataformas donde corre Docker (al menos, Windows y Linux), además de poder gestionarse con la CLI propia de Docker. Según el driver que usemos, permiten guardar los volúmenes en otros hosts o en proveedores de la nube y cifrarlos.

Los volúmenes tienen mejor rendimiento que los drivers de almacenamiento de las imágenes, especialmente para las operaciones de escritura.

En local, los volúmenes se implementan como carpetas del host que por defecto residen en /var/lib/docker/volumes.

Cuando se lanza un contenedor y se monta en él un volumen vacío, se copia en él el contenido de el directorio del contenedor sobre el que se va a montar, de forma que se puede meter en la imagen el contenido por defecto de los volúmenes que necesite el contenedor. Por ejemplo, si partimos de la imagen blas creada con este Dockerfile:

Tenemos lo siguiente:

En este caso, el volumen se crea al lanzar el contenedor, por lo que está vacío y se inicializa con el contenido de la carpeta de la imagen donde se va a montar. La hora de creación del archivo version son las 15:45, cuando se creó la imagen.

Aunque hayamos creado el volumen antes de lanzar el contenedor, al estar vacío se ha copiado en él el contenido de la imagen.

Como en este caso el volumen no estaba vacío, no se inicializa con el contenido de la carpeta de la imagen.

Los bind mounts pueden utilizar cualquier carpeta o archivo del host. Por lo demás, son similares a los volúmenes, aunque mucho menos flexibles.

Se puede especificar un tercer tipo de montaje para que los contenedores puedan escribir archivos que no haya que compartir con otros contenedores ni persistir. Con la opción --tmpfs de docker run o con --mount type=tmpfs, se puede montar un sistema de archivos tmpfs en el contenedor. Se recomienda usar --mount para hacerlo, ya que permite especificar el tamaño del sistema de archivos y los permisos sobre él, lo que no es posible con --tmpfs, que no pone límite al tamaño.

1. Los volúmenes tienen mejor rendimiento que los bind mounts, dependiendo de la plataforma.

2. Se puede establecer el tamaño máximo ocupado por los volúmenes, pero no por los bind mounts.

3. El contenido de la carpeta de la imagen donde se hace el montaje no se copia al host en los bind mounts, pero sí en los volúmenes, si están vacíos al lanzar el contenedor.

4. Los bind mounts permiten configurar la propagación de los montajes a otros puntos de montaje dentro del contenedor.

5. Los bind mounts permiten modificar las etiquetas de selinux en el host.

Construye una imagen a partir de las instrucciones de un archivo Dockerfile y un contexto con todos los archivos mencionados en las instrucciones. El contexto puede ser una carpeta local, un archivo .tar o la URL de un repositorio Git. Docker espera que el archivo con las instrucciones para construir la imagen se llame Dockerfile y que esté en la raíz del contexto, a menos que se especifique que está en otro lugar con la opción -f. La construcción la hace el demonio de Docker. La CLI le entrega el Dockerfile y todo su contexto que, en el caso de que sea una carpeta local, incluye todas las carpetas dentro de ella.

Se puede utilizar la opción -t nombre_imagen[:tag] para especificar el nombre de la imagen y una etiqueta opcional.

Alias: docker history.

Muestra las órdenes utilizadas para crear una imagen. Necesita como parámetro el nombre o el identificador de la imagen.

Alias: docker images.

Lista las imágenes que tiene el demonio de Docker.

Alias: docker pull.

Obtiene una imagen del registry configurado, o del que se anteponga al nombre e la imagen separado con una '/'.

Si no decimos nada, se baja la versión latest. Para especificar una versión específica, ponerla a continuación del nombre de la imagen, separada con :

Alias: docker push.

Transfiere una imagen local al registro de imágenes al que hayamos hecho login con docker login.

El nombre de la imagen debe incluir la ruta dentro del repositorio. Por ejemplo, si hubiéramos hecho login en el hub de Docker con la cuenta blas, las imágenes deberían llamarse blas/<nombre>:tag.

Se pueden transferir a la vez todas las versiones etiquetadas de una imagen con la opción -a.

Alias: docker rmi.

Elimina una imagen del demonio de Docker.

Establece un nombre y, opcionalmente, una etiqueta para una imagen. Se trata de un alias local, a menos que se suba la imagen a un repositorio con docker push.

Alias: docker attach.

Conecta los stdin, stdout y stderr del terminal actual al proceso en ejecución de un contenedor. Se puede interrumpir la conexión pulsando Ctrl-P+Ctrl-Q, aunque esto es configurable con la opción --detach-keys. Si se pulsa Ctrl-C, se le envía una señal SIGKILL al proceso, que normalmente se cerrará, a menos que la ignore (como pasa con los procesos con PID 1).

Alias: docker commit

Crea una imagen con los cambios hechos por un contenedor en su capa de escritura. La imagen incluirá los cambios hechos en volúmenes montados en el contenedor. El contenedor se pausará mientras se crea la imagen, lo que puede evitarse con la opción --pause=false. También se puede usar la opción --change para aplicar a la imagen una de las instrucciones válidas del Dockerfile.

Al final de la orden se puede pasar el nombre_imagen[:tag] para poner un nombre a la imagen y una etiqueta opcional.

Alias: docker exec.

Ejecuta un nuevo proceso dentro de un contenedor en ejecución. Normalmente se usa con las opciones -it para lanzar una shell interactiva y hacer diagnósticos, aunque se puede usar con -d para lanzar procesos en background, por ejemplo.

Se puede especificar el usuario con el que lanzar el proceso con -u (p. ej, -u root). El nombre del usuario debe estar en la imagen del contenedor.

Alias: docker logs.

Muestra los registros de un contenedor (en general, lo que haya producido en su salida estándar). Usar la opción -f para mostrar en vivo los logs generados.

Alias: docker ps.

Muestra los contenedores en ejecución. Con la opción '-a' se muestra los que están parados y ya no se están ejecutando (pero no se les ha eliminado la capa de escritura).

La opción -s muestra la columna SIZE, con el espacio utilizado por la capa de escritura del contenedor y el espacio total usado por las capas de lectura más la de escritura, en lo que se llama espacio virtual:

Como las capas de solo lectura pueden estar compartidas entre varios contenedores, el espacio total utilizado por Docker no se corresponde con la suma de espacio virtual de los distintos contenedores. Esto puede verse con la orden docker system df.

Alias: docker kill.

Mata el proceso principal de un contenedor enviándole la señal SIGKILL. Se puede utilizar para enviarle otras señales con la opción -s. Mantiene la capa de escritura del contenedor, a menos que se hubiera ejecutado con --rm, en cuyo caso se elimina.

Borra todos los contenedores parados, eliminando las capas de escritura que se han puesto sobre sus imágenes de solo lectura.

Alias: docker restart.

Relanza un contenedor , parando su proceso principal y volviéndolo a arrancar. A diferencia de docker stop, mantiene la capa de escritura del contenedor, aunque se hubiera arrancado con --rm.

Alias: docker rm.

Elimina un contenedor parado, borrando su capa de escritura. Se puede borrar un contenedor que esté arrancado con la opción -f, que mata el proceso con SIGKILL.

Alias: docker start.

Arranca un contenedor que estuviera parado, utilizando la capa de escritura que tuviera.

Alias: docker stop.

Detiene un contenedor, parando su proceso principal con una señal SIGTERM, dándole la oportunidad de cerrarse de forma ordenada. Si el proceso no termina en un tiempo determinado (ajustable con la opción -t, 10s por defecto), se mata con SIGKILL. Mantiene la capa de escritura del contenedor, a menos que se hubiera ejecutado con --rm, en cuyo caso se elimina.

Alias: docker top.

Muestra información sobre el proceso que se está ejecutando en un contenedor. Se le puede pasar después del nombre del contenedor cualquier opción que admita la orden ps.

Muestra información detallada de un objeto (contenedor, imagen, volumen, red…​). Para contenedores incluye, entre otros, el PID con el que se está ejecutando en el host, la orden que está ejecutando, el tiempo que lleva funcionando, el estado de funcionamiento (pausado, funcionando, parado), la información sobre la red (direcciones, redirecciones de puertos…​), los puntos de montaje del sistema de archivos.

Se puede extraer un dato concreto con la opción --format.

Existen órdenes específicas para distintos tipos de objetos, como docker container inspect, docker image inspect, docker network inspect, docker volume inspect…​

Ejecuta un contenedor con la imagen especificada. Si la imagen no está en el demonio de Docker, se busca del registry configurado. Se puede especificar el registro anteponiéndolo al nombre de la imagen, separado con una /.

A menos que se especifique lo contrario, el proceso especificado en la imagen arranca en primer plano (attach mode), con las corrientes estándar del proceso stdin, stdout y stderr conectadas a nuestro terminal, y enviándole las señales generadas en él. Se pueden lanzar en segundo plano con -d.

Podemos ejecutar procesos interactivos en un contenedor que ya se esté ejecutando y conectarles una pseudo-TTY, con las opciones -it:

Si el contenedor estuviera pensado para ejecutar una orden en modo interactivo (p. ej, bash), podemos ejecutarlo en background y usar la opción -t para asignarle una pseudo-TTY en su stdin, de manera que el proceso no termine:

También podemos redirigir puertos del servidor hacia el contenedor con la opción -p [host_ip]:[host_port]:[container_port]. La IP del host es opcional. Esta orden hace que cambien las tablas DOCKER de iptables.

Podemos montar carpetas locales en el contenedor con la opción -v [/host/volume/location]:[/container/storage], independientemente de los volúmenes que se hayan declarado en la imagen.

También podemos eliminar el contenedor cuando termine el proceso que se ejecuta en él, usando la opción --rm. Si no hacemos esto, el contenedor permanecerá en el sistema, con la capa de escritura en él. Podemos ejecutar órdenes interactivas en él para ver los cambios.

La opción --env clave=valor sirve para asignar variables de entorno que pueden examinarse dentro del contenedor.

Se puede usar la opción --name <nombre> para ponerle un nombre al contenedor. Si no lo hacemos, Docker les pondrá nombres aleatorios.

Muestra las estadísticas de consumo de recursos de todos los contenedores o de los que se pasen por parámetro.

Transfiere una imagen al repositorio de imágenes en el que hayamos hecho login. Con la opción -a, se suben todas

Hace login en un registro de imágenes, o en hub.docker.com si no se especifica ninguno. Se puede pasar el usuario con la opción -u, y la contraseña con -p. Para ejecutarlo de forma no interactiva, se puede usar la opción --password-stdin para pasar la contraseña por la entrada estándar.

Cierra la sesión con el registro de imágenes.

Busca una imagen en el registry, e indica si se trata de imágenes oficiales y si están automatizadas.

Limpia la caché de construcción de imágenes utilizada por docker build.

Muestra el espacio utilizado por Docker, incluyendo el espacio de las imágenes, las capas de escritura de los contenedores, los volúmenes locales y la caché de construcción de imágenes. Se puede ver el detalle con la opción -v.

Conecta un contenedor a una red que no sea host. Un contenedor conectado a la red none no puede estar conectado a ninguna otra.

Crea una nueva red. Podemos especificar el driver a utilizar con la opción --driver (por defecto, bridge, aunque también puede ser none, host y overlay, esta última soporta comunicación entre contenedores que corran en distintos hosts, como los orquestados con Docker swarm).

Desconecta un contenedor de una red.

Muestra los detalles de una red, incluyendo las direcciones IP asignadas en ella y los contenedores asociados.

Muestra las redes creadas por Docker: identificador, nombre, driver y alcance (generalmente, local).

Alias: docker build

Construye una imagen siguiendo las instrucciones de un Dockerfile.

Alias: docker info.

Muestra información sobre el cliente y el servidor de docker, incluyendo los drivers y los plugins usados, las opciones de seguridad, el sistema operativo base, el directorio raíz de Docker (donde se crean los directorios usados para hacer el overlay de las imágenes), la cantidad de contenedores e imágenes que hay en el sistema…​

Muestra la versión de la CLI y del servidor: