Los contenedores Docker están creciendo como una buena práctica para la implementación y administración de sistemas distribuidos nativos de la nube. Los contenedores son instancias de imágenes Docker. Resulta que hay mucho que saber y comprender acerca de las imágenes.

En este tutorial de dos partes, abordaré las imágenes de Docker en profundidad. En la primera parte traté los principios básicos, consideraciones de diseño y la inspección de las interioridades de una imagen. En esta parte, cubro la construcción de tus propias imágenes, la solución de problemas y el trabajo con los repositorios de imágenes.

Cuando finalices el tutorial, tendrás una sólida comprensión de lo que son exactamente las imágenes de Docker y cómo utilizarlas eficazmente en tus propias aplicaciones y sistemas.

Construyendo Imágenes

Hay dos formas de crear imágenes. Puedes modificar un contenedor existente y luego confirmarlo ('commit') como una nueva imagen, o puedes escribir un Dockerfile y construirlo como imagen. Trataremos ambos casos y explicaremos los pros y los contras.

Construcciones Manuales

Con las construcciones manuales, tratas tu contenedor como un ordenador normal. Instalas paquetes, escribes archivos y, cuando todo esta completado, lo confirmas ('commit') y acabas obteniendo una nueva imagen que usas como plantilla para crear muchos más contenedores idénticos o incluso como base para otras imágenes.

Comencemos con la imagen alpine, que es una imagen muy pequeña y espartana basada en Alpine Linux. Podemos ejecutarla en modo interactivo para entrar en un shell. Nuestro objetivo es agregar un archivo llamado "yeah" (sí) que contenga el texto "it works!" (¡funciona!) en el directorio raíz y luego crear una nueva imagen llamada "yeah-alpine".

Aquí vamos. Bien, ya estamos en el directorio raíz. Veamos qué hay ahí.

> docker run -it alpine /bin/sh
/ # ls
bin      dev      etc      home     lib      linuxrc  media    mnt      proc     root     run      sbin     srv      sys      tmp      usr      var

¿Qué editor está disponible? ¿Sin vim, sin nano?

/ # vim
/bin/sh: vim: not found
/ # nano
/bin/sh: nano: not found

Oh bien. Solo queremos crear un archivo:

/ # echo "it works!" > yeah
/ # cat yeah
it works!

Salí del shell interactivo y puedo ver el contenedor llamado "vibrant_spence" con docker ps --all. La marca --all es importante porque el contenedor ya no se está ejecutando.

> docker ps --all
CONTAINER ID IMAGE  COMMAND   CREATED       STATUS NAMES
c8faeb05de5f alpine "/bin/sh" 6 minutes ago Exited vibrant_spence

Aquí, creo una nueva imagen del contenedor "vibrant_spence". Agregué el mensaje de commit "mine, mine, mine" por si acaso.

> docker commit -m "mine, mine, mine" vibrant_spence yeah-alpine
sha256:e3c98cd21f4d85a1428...e220da99995fd8bf6b49aa

Vamos a ver. Sí, hay una nueva imagen, y en su historial se puede ver una nueva capa con el comentario "mine, mine, mine".

> docker images
REPOSITORY       TAG    IMAGE ID      SIZE
yeah-alpine      latest e3c98cd21f4d  4.8 MB
python           latest 775dae9b960e  687 MB
d4w/nsenter      latest 9e4f13a0901e  83.8 kB
ubuntu-with-ssh  latest 87391dca396d  221 MB
ubuntu           latest bd3d4369aebc  127 MB
hello-world      latest c54a2cc56cbb  1.85 kB
alpine           latest 4e38e38c8ce0  4.8 MB
nsqio/nsq        latest 2a82c70fe5e3  70.7 MB

> docker history yeah-alpine
IMAGE        CREATED         SIZE   COMMENT
e3c98cd21f4d 40 seconds ago  66 B   mine, mine, mine
4e38e38c8ce0 7 months ago    4.8 MB

Ahora para la prueba real. Eliminemos el contenedor y creemos un nuevo contenedor a partir de la imagen. El resultado esperado es que el archivo "yeah" estará presente en el nuevo contenedor.

> docker rm vibrant_spence
vibrant_spence

> docker run -it yeah-alpine /bin/sh
/ # cat yeah
it works!
/ #

¿Qué puedo decir? ¡Sí, funciona!

Usando un Dockerfile

Crear imágenes a partir de contenedores modificados es genial, pero no hay una rendición de cuentas. Es difícil hacer un seguimiento de los cambios y saber cuáles fueron las modificaciones específicas. La manera ordenada de crear imágenes es hacerlo usando un Dockerfile.

El Dockerfile es un archivo de texto similar a un script de shell, pero admite varios comandos. Cada comando que modifica el sistema de archivos crea una nueva capa. En la primera parte discutimos la importancia de dividir correctamente tu imagen en capas. El Dockerfile es un gran tema en sí mismo.

Aquí, solo demostraré un par de comandos para crear otra imagen, "oh-yeah-alpine", basada en un Dockerfile. Además de crear el infame archivo "yeah", también instalaremos vim. La distribución de Alpine Linux utiliza un sistema de gestión de paquetes llamado "apk". Aquí está el Dockerfile:

FROM alpine

# Copy the "yeah" file from the host
COPY yeah /yeah

# Update and install vim using apk
RUN apk update && apk add vim

CMD cat /yeah

La imagen base es alpine. Se copia el archivo "yeah" del mismo directorio de host donde está el Dockerfile (la ruta del build context). Luego, se ejecuta apk update y se instala vim. Finalmente, se establece el comando que se ejecuta cuando se ejecuta el contenedor. En este caso, imprimirá en la pantalla el contenido del archivo "yeah".

Ok. Ahora que sabemos en lo que nos estamos metiendo, construyamos nuestra imagen. La opción "-t" establece el repositorio. No especifiqué una etiqueta, por lo que será la predeterminada "latest".

>  docker build -t oh-yeah-alpine .
Sending build context to Docker daemon 3.072 kB
Step 1/4 : FROM alpine
 ---> 4e38e38c8ce0
Step 2/4 : COPY yeah /yeah
 ---> 1b2a228cc2a5
Removing intermediate container a6221f725845
Step 3/4 : RUN apk update && apk add vim
 ---> Running in e2c0524bd792
fetch https://dl-cdn.alpinelinux.org/.../APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org.../x86_64/APKINDEX.tar.gz
v3.4.6-60-gc61f5bf [http://dl-cdn.alpinelinux.org/alpine/v3.4/main]
v3.4.6-33-g38ef2d2 [http://dl-cdn.alpinelinux.org/.../v3.4/community]
OK: 5977 distinct packages available
(1/5) Installing lua5.2-libs (5.2.4-r2)
(2/5) Installing ncurses-terminfo-base (6.0-r7)
(3/5) Installing ncurses-terminfo (6.0-r7)
(4/5) Installing ncurses-libs (6.0-r7)
(5/5) Installing vim (7.4.1831-r2)
Executing busybox-1.24.2-r9.trigger
OK: 37 MiB in 16 packages
 ---> 7fa4cba6d14f
Removing intermediate container e2c0524bd792
Step 4/4 : CMD cat /yeah
 ---> Running in 351b4f1c1eb1
 ---> e124405f28f4
Removing intermediate container 351b4f1c1eb1
Successfully built e124405f28f4

Se ve bien. Verifiquemos que se creó la imagen:

> docker images | grep oh-yeah

oh-yeah-alpine latest e124405f28f4 About a minute ago 30.5 MB

¡Ten en cuenta cómo la instalación de vim y sus dependencias aumentó el tamaño del contenedor de los 4,8 MB de la imagen base alpine a los enormes 30,5 MB!

Todo está muy bien. ¿Pero funciona?

> docker run oh-yeah-alpine
it works!

¡Oh, sí, funciona!

En caso de que todavía tengas sospechas, vayamos al contenedor y examinemos el archivo "yeah" con nuestro vim recién instalado.

> docker run -it oh-yeah-alpine /bin/sh
/ # vim yeah

it works!
~
~
.
.
.
~
"yeah" 1L, 10C

El Build Context y el archivo .dockerignore

No te lo dije, pero originalmente, cuando traté de construir la imagen oh-yeah-alpine, se quedó colgada durante varios minutos. El problema fue que simplemente puse el Dockerfile en mi directorio de inicio. Cuando Docker crea una imagen, primero empaqueta todo el directorio donde está el Dockerfile (incluidos los subdirectorios) y lo pone a disposición para los comandos COPY en el Dockerfile.

Docker no está tratando de ser inteligente y analizar tus comandos COPY. Simplemente empaqueta todo. Ten en cuenta que el contenido del build no terminará en tu imagen, pero ralentizará tu comando de build si tu build context es innecesariamente grande.

En este caso, simplemente copié el Dockerfile y el "yeah" en un subdirectorio y ejecuté el comando docker build en ese subdirectorio. Pero a veces tienes un árbol de directorios complicado del que desea copiar archivos y subdirectorios específicos e ignorar otros. Ingresa al archivo .dockerignore.

Este archivo le permite controlar exactamente lo que entra en el build context. Mi truco favorito es primero excluir todo y luego comenzar a incluir las partes que necesito. Por ejemplo, en este caso podría crear el siguiente archivo .dockerignore y mantener el archivo Docker y el "yeah" en mi directorio de inicio:

# Exclude EVERYTHING first
*

# Now selectively include stuff
!yeah

No es necesario incluir el "Dockerfile" en sí mismo o el archivo ".dockerignore" en el build context

Copia frente a montaje

A veces, lo que necesitas es copiar archivos en la imagen, pero en otros casos es posible que desees que tus contenedores sean más dinámicos y funcionen con archivos en el host. Aquí es donde entran en juego los volúmenes y los montajes.

Montar directorios de host es un juego diferente. Los datos son propiedad del host y no del contenedor. Los datos se pueden modificar cuando se detiene el contenedor. El mismo contenedor se puede iniciar con diferentes directorios de host montados.

Etiquetado de imágenes

Etiquetar imágenes es muy importante si desarrollas un sistema basado en microservicios y generas muchas imágenes que a veces deben asociarse entre sí. Puedes agregar tantas etiquetas como desees a una imagen.

Ya has visto la etiqueta predeterminada "latest". A veces, tiene sentido agregar otras etiquetas, como "tested", "release-1.4" o el git commit que corresponde a la imagen.

Puedes etiquetar una imagen durante un build o más tarde. A continuación, se explica cómo agregar una etiqueta a una imagen existente. Ten en cuenta que mientras una etiqueta es llamada, también puedes asignar un nuevo repositorio.

> docker tag oh-yeah-alpine oh-yeah-alpine:cool-tag
> docker tag oh-yeah-alpine oh-yeah-alpine-2

> docker images | grep oh-yeah
oh-yeah-alpine-2 latest    e124405f28f4 30.5 MB
oh-yeah-alpine   cool-tag  e124405f28f4 30.5 MB
oh-yeah-alpine   latest    e124405f28f4 30.5 MB

También puedes quitar la etiqueta eliminando una imagen por su nombre de etiqueta. Esto da un poco de miedo porque si quitas la última etiqueta por accidente, pierdes la imagen. Pero si creas imágenes a partir de un Dockerfile, puedes simplemente reconstruir la imagen.

> docker rmi oh-yeah-alpine-2
Untagged: oh-yeah-alpine-2:latest

> docker rmi oh-yeah-alpine:cool-tag
Untagged: oh-yeah-alpine:cool-tag

Si trato de eliminar la última imagen etiquetada restante, aparece un error porque es utilizada por un contenedor.

> docker rmi oh-yeah-alpine

Error response from daemon: conflict: unable to remove repository
reference "oh-yeah-alpine" (must force) - 
container a1443a7ca9d2 is using its referenced image e124405f28f4

Pero si quito el contenedor ...

> docker rmi oh-yeah-alpine
Untagged: oh-yeah-alpine:latest
Deleted: sha256:e124405f28f48e...441d774d9413139e22386c4820df
Deleted: sha256:7fa4cba6d14fdf...d8940e6c50d30a157483de06fc59
Deleted: sha256:283d461dadfa6c...dbff864c6557af23bc5aff9d66de
Deleted: sha256:1b2a228cc2a5b4...23c80a41a41da4ff92fcac95101e
Deleted: sha256:fe5fe2290c63a0...8af394bb4bf15841661f71c71e9a

> docker images | grep oh-yeah

Sí. Se fue. Pero no te preocupes. Podemos reconstruirlo:

> docker build -t oh-yeah-alpine .

> docker images | grep oh-yeah
oh-yeah-alpine latest 1e831ce8afe1 1 minutes ago 30.5 MB

Sí, está de vuelta. ¡Dockerfile para la victoria!

Trabajar con registros de imágenes

Las imágenes son muy similares en algunos aspectos a los repositorios de git. También se crean a partir de un conjunto ordenado de commits. Puedes pensar en dos imágenes que usen las mismas imágenes base como ramas (aunque no hay merge ni rebase en Docker). Un registro de imágenes es el equivalente a un servicio de alojamiento central de git como GitHub. ¿Adivina cuál es el nombre del registro de imágenes oficial de Docker? Así es, Docker Hub.

Haciendo pull de imágenes

Cuando ejecutas una imagen, si no existe, Docker intentará extraerla de uno de sus registros de imágenes configurados. De forma predeterminada, va a Docker Hub, pero puedes controlarlo en tu archivo "~/.docker/config.json". Si usas un registro diferente, puedes seguir sus instrucciones, que generalmente implican iniciar sesión con sus credenciales.

Eliminemos la imagen "hello-world" y hagamos pull de ella nuevamente usando el comando docker pull.

> dockere images | grep hello-world
hello-world latest c54a2cc56cbb 7 months ago 1.85 kB 

> docker rmi hello-world
hello-world

Se ha ido. Hagamos pull ahora.

> docker pull hello-world
Using default tag: latest
latest: Pulling from library/hello-world
78445dd45222: Pull complete
Digest: sha256:c5515758d4c5e1e...07e6f927b07d05f6d12a1ac8d7
Status: Downloaded newer image for hello-world:latest

> dockere images | grep hello-world
hello-world latest 48b5124b2768 2 weeks ago 1.84 kB

El último hello-world fue reemplazado por una versión más nueva.

Haciendo push de imágenes

Hacer push de imágenes es un poco más complicado. Primero debes crear una cuenta en Docker Hub (u otro registro). A continuación, inicia sesión. Luego, debes etiquetar la imagen que deseas enviar de acuerdo con el nombre de tu cuenta ("g1g1" en mi caso).

> docker login -u g1g1 -p <password>
Login Succeeded

> docker tag hello-world g1g1/hello-world

> docker images | grep hello

g1g1/hello-world latest 48b5124b2768 2 weeks ago 1.84 kB
hello-world      latest 48b5124b2768 2 weeks ago 1.84 kB

Ahora, puedo enviar la imagen etiquetada g1g1/hello-world.

> docker push g1g1/hello-world
The push refers to a repository [docker.io/g1g1/hello-world]
98c944e98de8: Mounted from library/hello-world
latest: digest: sha256:c5515758d4c5e...f6d12a1ac8d7 size: 524

Conclusión

Las imágenes de Docker son las plantillas de sus contenedores. Están diseñadas para ser eficientes y ofrecer la máxima reutilización mediante el uso de un controlador de almacenamiento del sistema de archivos en capas.

Docker proporciona muchas herramientas para enumerar, inspeccionar, crear y etiquetar imágenes. Puedes extraer y enviar imágenes a registros de imágenes como Docker Hub para administrar y compartir fácilmente tus imágenes.