🎃 Grandes descuentos en libros en línea, eformaciones y vídeos*. Código CALABAZA30. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
  1. Libros
  2. Docker
  3. Creación de sus propias imágenes
Extrait - Docker Primeros pasos y puesta en práctica de una arquitectura basada en micro-servicios
Extractos del libro
Docker Primeros pasos y puesta en práctica de una arquitectura basada en micro-servicios Volver a la página de compra del libro

Creación de sus propias imágenes

Creación manual de una nueva imagen

En el capítulo anterior, hemos estudiado el funcionamiento básico de Docker, utilizando imágenes preparadas con antelación para nuestros ejemplos: la imagen hello-world para las primeras pruebas, la imagen ubuntu para los enfoques interactivos por la línea de comandos y para terminar, la imagen nginx para las pruebas que implican un proceso servidor. Estas imágenes se han recuperado en línea del registro Docker Hub.

Aunque esta manera de funcionar pueda ser suficiente en las implantaciones extremadamente sencillas, llega un momento donde se hace necesario crear sus propias imágenes para evolucionar hacia niveles mayores de complejidad. Este es el tipo de operaciones que vamos a ilustrar en el presente capítulo.

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.

 Lance en modo interactivo un contenedor basado en la imagen ubuntu.

 En la línea de comandos escriba los siguientes comandos, necesarios para la instalación de MongoDB. El código proviene de la documentación (http://docs.mongodb.org/manual/tutorial/install-mongodb-on-ubuntu/) y se copia a continuación:


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...

Utilización de un Dockerfile

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 ...

Compartición y reutilización sencilla de imágenes

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:

images/03RI43.png

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:

images/03RI97N.png

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

images/03RI98N.png

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

Buenas prácticas

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.

Hablamos de la puesta en marcha del contenedor, pero también se puede tratar del único comando pull de recuperación de la imagen desde el registro. Se observa que el comando run normalmente se utiliza más y de todas formas se lanza un comando pull, si la imagen no está disponible localmente.

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:

  • Si la imagen se ha construido localmente, el comando de compilación docker build ha recuperado automáticamente toda la pila de imágenes sobre la que se basaba Dockerfile, con la palabra clave FROM.

  • Si la imagen se ha recuperado desde un registro, el comando pull o run ha traído todas las capas necesarias y no solo la más alta, correspondientes al tag proporcionado. Por supuesto, el mecanismo de caché se aplica a todos los niveles y si una imagen se basa en otra, que a su vez se basa en una imagen ya presente, solo se recuperan las dos primeras.

  • Si la imagen se ha cargado desde un archivo por el método load, las imágenes de las que también...

Para ir más lejos

Una última observación en este capítulo sobre la composición de las imágenes: hay numerosas herramientas informáticas que necesitan enfoques similares de descripción del contenido de la aplicación de entidades autónomas. Por ejemplo, herramientas de composición de máquinas virtuales como Vagrant o bien herramientas de descripción de despliegues en las plataformas cloud.

Hay una herramienta, llamada Packer, que permite describir de manera unificada la composición de estas entidades y después, gracias a los plug-ins, conectarse a Amazon Web Services, Vagrant... y Docker. En este último caso, la implantación de Packer conducirá a la creación de una imagen Docker. De una determinada manera, es posible evitar la gramática Dockerfile, abriéndose a otras tecnologías.

En la actualidad, la herramienta Packer de Hashicorp no ha calado, aunque ya existía cuando se escribió la primera versión de este libro, en 2015. Sin embargo, es conveniente mantenerse atento sobre estos enfoques, porque las tecnologías innovadoras algunas veces renacen de sus cenizas.