Instalación de un registro privado

1. Observación inicial importante

Durante la primera edición del presente libro, este capítulo solo mostraba cómo establecer un registro privado utilizando sus propios medios, mencionando rápidamente la posible utilización de un servicio existente en el cloud. Durante la segunda edición, observamos que estas soluciones en el cloud están maduras y ofrecen un servicio extremadamente difícil y costoso de reproducir implementando un registro personal. Su alto grado de compartición permite reducir los costes de manera masiva. Delegar la seguridad en las plataformas especializadas en seguridad, le permite concentrarse en lo principal, a saber, la producción de las imágenes. Para terminar, ya no se presentan las cuestiones de actualización y mantenimiento en condiciones operativas, todo por un coste extremadamente bajo.

En resumen, las dos primeras secciones del presente capítulo se conservan porque permiten entender correctamente las implicaciones de un registro privado, incluso puede ayudar a trabajar en un contexto muy específico que necesite evitar los servicios cloud (proyecto de alto nivel de confidencialidad, necesidad de utilización de un cloud privado, etc.). Pero en la gran mayoría de casos, establecer un registro privado consistirá en seguir las instrucciones de la tercera sección, que explica el concepto de registro privado en el cloud, utilizando como ejemplo el proporcionado por Microsoft en Azure.

2. Advertencia sobre el antiguo registro...

1. Gestión de la persistencia

a. Gestión local por volumen

El hecho de arrancar el registro en una máquina diferente de la que consume las imágenes, implicó una primera etapa en el despliegue de un registro realista, pero por el momento estamos lejos tener un registro listo para una utilización en producción.

El primer problema que se plantea es que, por el momento, el almacenamiento de las imágenes situadas en el registro se hace en el contenedor Docker en sí mismo. Desde este momento, ¿qué pasa si el contenedor se detiene y se olvida validar su estado en una nueva imagen? Simplemente, el contenido del registro se pierde. Es evidente que este tipo de comportamiento es inimaginable para un registro en producción y por lo tanto, ahora vamos a centrarnos en gestionarlo de manera más sostenible.

Un primer enfoque un poco simplista, sin lugar a dudas, pero funcional, consiste en utilizar los volúmenes para redirigir al lugar donde el contenedor del registro almacena las imágenes que se le envían, a una ubicación un poco más permanente por ejemplo, un directorio de la máquina host sobre la que se haga un backup regularmente, incluso se sincronice de manera permanente con una máquina remota. En un contexto más profesional, el destino podría ser una SAN bay, compartición NFS (Network File System), etc.

La documentación explica que el comportamiento por defecto del registro que Docker ofrece, es almacenar en /tmp/registry-dev. Por lo tanto, sustituimos este directorio por otro.

 Lance una nueva instancia de registro con el mismo comando que antes, pero añadiendo una opción de gestión de volumen (argumento que empieza por -v en el siguiente ejemplo), de manera que el almacenamiento del registro se realice en un directorio de su conveniencia:

docker run -d --name register -p 5000:5000 -v 
/home/jpg/miregistro/contenido:/tmp/registry-dev 
jpgouigoux/registry-volume
 

 Desde la máquina que haya servido para esta operación, lance un comando push para enviar el contenido al registro.

 Una vez terminado, puede comprobar el resultado de este comando, observando el contenido del directorio elegido para el almacenamiento del registro:

La arborescencia muestra el nombre de la imagen en la que hemos realizado la operación...

1. Principio

No es una opción, si el trabajo necesario para mantener su propio registro le parece demasiado elevado frente a las ventajas, poniendo sus imágenes en línea en la parte pública de Docker Hub, por lo tanto sin ninguna seguridad respecto a quien las consuma (y eventualmente se podría realizar ingeniería inversa en ella). Sin embargo, la utilización de un almacén privado donde el alojamiento de los recursos y del software se gestiona por un proveedor comercial, es sin lugar a dudas una solución mejor.

En este caso, el proveedor se encarga de:

En este modo de funcionamiento, al usuario solo le queda cargar sus imágenes en el registro remoto y configurar las condiciones de acceso de dichas imágenes.

El panorama de las ofertas es muy amplio. Amazon ofrece EC2 Container Registry (https://aws.amazon.com/es/ecr/), Google el producto Google Container Registry (https://cloud.google.com/container-registry/), Microsoft el servicio Azure Container Registry (del que veremos una demonstración más completa en una sección posterior), en resumen, todas las empresas importantes tienen su oferta, rivalizando en funcionalidades y rendimiento.

Hay empresas más pequeñas, incluso startups que se lanzan también en este mundo, destacando en uno u otro comportamiento particular como ventaja competitiva. De esta manera, Artifactory propone su registro integrado, Quay.io y Canister.io tienen ofertas que insisten más en la excelente integración con un proceso de despliegue continuo, etc.

Rancher...

1. El API del registro

Como curiosidad, todo registro que quiera estar conforme al modo de funcionamiento de Docker, debe implementar un API tal y como se especifica en https://docs.docker.com/registry/spec/api/.

De manera general, nos conectamos a un registro por el cliente Docker que transforme los comandos transmitidos en llamadas de API, para que nos ahorre complejidad. Pero para determinadas operaciones muy específicas (emisión masiva de imágenes, diagnóstico, etc.), pueda ser útil saber que este API existe y que expone todos los comandos utilizables por el cliente Docker, de manera estándar (REST/JSON).

Hemos mostrado un ejemplo muy sencillo cuando hemos validado el almacén de una imagen en un registro, accediendo a este último desde un navegador:

2. Implementación de un espejo

En las secciones anteriores del presente capítulo, se ha detallado abundantemente el funcionamiento de la caché local de imágenes. Hemos mostrado cómo las imágenes se almacenaban en una máquina host durante la compilación o mediante el uso de un comando pull que las trae para su utilización desde el registro Docker Hub u otro registro de la red, si es necesario. La gran utilidad de esta caché local se ha explicado de manera que si varias imágenes utilizan la misma imagen básica (ubuntu o debian, en nuestros ejemplos) en la misma máquina host, solo la primera puesta en marcha implicaría la descarga efectiva de estas imágenes desde el registro remoto Docker Hub. El resto de las ejecuciones siguientes de una imagen utilizando estas imágenes como base de un nivel cualquiera, serán mucho más rápidas.

Este mecanismo de caché es uno de los grandes progresos de Docker respecto a un sistema de virtualización, donde las máquinas completas se tenían que descargar, provocando redundancias y un desperdicio enorme de ancho de banda. Solo, su implantación en grandes conjuntos de servidores, plantea problemas de eficiencia.

Imaginemos en efecto un cluster de máquinas hosts para alojar numerosos contenedores Docker:

Cada una de las máquinas del cluster va a tener el mismo comportamiento con una caché local, pero cada una deberá descargar en Internet la imagen básica durante la primera ejecución. Si se añade...