Creación de sus propias imágenes

1. Instalación de un software en un contenedor

El enfoque más sencillo para crear su propia imagen es utilizar el comando commit, que se ha dejado entrever en el capítulo anterior, para persistir el estado de un contenedor en forma de una nueva imagen, después de haberle añadido las modificaciones necesarias.

El siguiente ejemplo consiste en utilizar una imagen ubuntu como base, instalar MongoDB (una base de datos no relacional) en el contenedor y después, persistirla como una imagen reutilizable.

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 
--recv 7F0CEB10 
echo "deb http://repo.mongodb.org/apt/ubuntu "$(lsb_release 
-sc)"/mongodb-org/3.0 multiverse" | sudo tee 
/etc/apt/sources.list.d/mongodb-org-3.0.list 
sudo apt-get update...

1. Interés de los archivos Dockerfile

La "receta" de la que acabamos de hablar, se presenta en forma de archivo de texto llamado Dockerfile, que utiliza una gramática particular de Docker. Este archivo contiene todas las operaciones necesarias para la preparación de una imagen Docker. De esta manera, en lugar de construir una imagen por medio de operaciones manuales en un contenedor, seguida de un comando commit (incluso varios si procede por etapas), como hemos hecho anteriormente, vamos a poder compilar una imagen desde una descripción textual de estas operaciones.

A continuación se muestra, por ejemplo, el contenido del archivo Dockerfile correspondiente a la imagen oficial MongoDB, tal y como se puede encontrar en el registro Docker Hub a la fecha de escritura de este libro (versión 3.0 de MongoDB, disponible en https://registry.hub.docker.com/_/mongo/):

FROM debian:wheezy 
   
# add our user and group first to make sure their IDs get assigned 
consistently, regardless of whatever dependencies get added 
RUN groupadd -r mongodb && useradd -r -g mongodb mongodb 
   
RUN apt-get update \   
    && apt-get install -y --no-install-recommends \   
          ca-certificates curl \   
          numactl \   
    && rm -rf /var/lib/apt/lists/*   
   
# grab gosu for easy step-down from root   
RUN gpg --keyserver pool.sks-keyservers.net -recv-keys   
B42F6819007F00F88E364FD4036A9C25BF357DD4   
RUN curl -o /usr/local/bin/gosu -SL   
"https://github.com/tianon/gosu/releases/download/1.2/gosu-$(dpkg 
--print-architecture)" \ 
    && curl -o /usr/local/bin/gosu.asc -SL   
"https://github.com/tianon/gosu/releases/download/1.2/gosu-$(dpkg 
--print- architecture).asc" \   
    && gpg --verify /usr/local/bin/gosu.asc \  
    && rm /usr/local/bin/gosu.asc \   
    && chmod +x /usr/local/bin/gosu   
   
# gpg: key 7F0CEB10: public key "Richard Kreuter 
<richard@10gen.com>" imported 
RUN apt-key adv --keyserver pool.sks-keyservers.net -recv-keys ...

1. Enviar a su cuenta Docker Hub

En el capítulo anterior, hemos mostrado cómo conectarse a Docker Hub y asociar la cuenta con un almacén en GitHub. A continuación, nos aseguramos de que este almacén cree una imagen Docker actualizada en cada commit de código fuente.

También es posible ubicar en un registro Docker una imagen creada localmente, como las que hemos implantado en este capítulo. Para esto, utilizaremos un comando que todavía no hemos abordado.

Enviar una imagen local al registro Docker Hub

docker push [imagen]
 

Para que este comando funcione, es necesario que la imagen tenga un nombre completo, usando como prefijo el nombre de la cuenta Docker Hub. Esta es la razón por la que la imagen creada más atrás, se llamó jpgouigoux/repeater. También hubiera sido posible llamar simplemente repeater ya que el ejercicio era local, y después utilizar el comando docker tag para añadirle una etiqueta adicional correspondiente a este nombre completo.

Apliquemos este comando a la imagen que hemos creado anteriormente:

Después de algunos minutos, en función del tamaño de la imagen y de la rapidez de la conexión Internet utilizada, la imagen se puede ver en Docker Hub:

Haciendo clic en el almacén, puede acceder a sus propiedades:

Por lo tanto, es posible hacer que esta...

1. Principio de la caché de las imágenes

Un usuario atento habrá observado la diferencia de tiempo entre la primera ejecución de un contenedor y las siguientes. La diferencia es particularmente notable cuando un contenedor se basa en una imagen ubuntu o debian. Durante la primera ejecución, Docker descarga alrededor de 125 MB para la primera y 100 MB para la segunda. Durante la segunda ejecución así como para las siguientes, esta descarga ya no tiene lugar y la puesta en marcha del contenedor es mucho más rápida.

Docker gestiona una caché para las imágenes. Esta caché es local y varias veces se ha observado su contenido con el comando docker images. La caché simplemente es lo que hemos llamado hasta aquí la lista de las imágenes locales. Un comando docker pull solo lleva a local (por lo tanto, la cachea) una imagen que inicialmente existía en el registro remoto.

Como hemos visto en el capítulo sobre los aspectos principales de Docker, instanciar un contenedor vuelve a crear, desde el punto de vista del contenido, una nueva capa en modo escritura sobre una pila de capas existentes, que solo son accesibles en modo lectura. En la práctica, estas capas están sistemáticamente presentes durante la ejecución, pero por razones diferentes en función del contexto: