Llevando a Docker a ambiente de producción con confianza

Llevando a Docker a ambientde de producción con confianza

Muchas organizaciones que desarrollan software hoy en día usan Docker de una forma u otra. Si asiste a cualquier conferencia de desarrollo de software o DevOps y pregunta a una gran cantidad de personas "¿Quién usa Docker?", La mayoría de las personas en la sala levantarán la mano. Pero si ahora le preguntas a la multitud: “¿Quién usa Docker en la producción? ”, La mayoría de las manos caerán inmediatamente. ¿Por qué es que una tecnología tan popular que ha disfrutado de un crecimiento meteórico se usa tanto en las primeras fases de la línea de desarrollo, pero rara vez se usa en la producción?

Calidad del software: Desarrollado probado, Aprobado por Ops

Una tubería típica de entrega de software se ve así (¡y lo ha hecho durante más de una década!)

En cada fase de la tubería, la compilación representativa se prueba, y el resultado binario de esta compilación solo puede pasar a la siguiente fase si pasa todos los criterios de la puerta de calidad relevante. Al promocionar el binario original, garantizamos que el mismo binario que construimos en el servidor CI es el implementado o distribuido. Al implementar puertas de calidad rígidas, garantizamos el control de acceso a los artefactos no probados, probados y listos para la producción.

La insoportable ligereza de 
$ docker build

Dado que ejecutar una compilación de Docker es muy fácil, en lugar de una compilación que pase a través de una puerta de calidad a la siguiente fase ...

... se reconstruye en cada fase.

"¿Y qué" dices? Tan abundante Veamos un script de compilación típico.

Para construir su producto, necesita un conjunto de dependencias, y la compilación normalmente descargará las últimas versiones de cada dependencia que necesita. Pero dado que cada fase del desarrollo del gasoducto se construye en un momento diferente, ...

… No puede estar seguro de que la misma versión de cada dependencia en la versión de desarrollo también se incorporó a su versión de producción.

Pero podemos arreglar eso. Vamos a utilizar: 

DESDE ubuntu: 14.04 .

Hecho.

¿O somos nosotros?

¿Podemos estar seguros de que la versión de Ubuntu 14.04 descargada en desarrollo será exactamente la misma que la construida para la producción? No, no podemos. ¿Qué pasa con los parches de seguridad u otros cambios que no afectan el número de versión? Pero espera; Hay una manera. Usemos la huella dactilar de la imagen. Eso es roca sólida! Especificaremos la imagen base como:

DESDE ubuntu: 0bf3461984f2fb18d237995e81faa657aff260a52a795367e6725f0617f7a56c

Pero, ¿cuál era esa versión otra vez? ¿Es mayor o más reciente que la que estaba usando la semana pasada?

Te dan la imagen. El uso de huellas dactilares no es legible ni mantenible, y al final, nadie sabe realmente lo que sucedió en la imagen de Docker.

¿Y qué pasa con el resto del archivo docker? La mayor parte es solo un montón de resolución de dependencia implícita o explícita, ya sea en forma de apt-get , o comandos wget para descargar archivos desde ubicaciones arbitrarias. Para algunos de los comandos, puede definir la versión, pero con otros, ¡ni siquiera está seguro de que realicen la resolución de dependencias! ¿Y qué pasa con las dependencias transitivas?

Así que terminas con esto:

Básicamente, al reconstruir la imagen de Docker en cada fase de la tubería, realmente la está cambiando, por lo que no puede estar seguro de que la imagen que pasó todas las puertas de calidad sea la que llegó a producción .

Deja de reconstruir, empieza a promocionar.

Lo que deberíamos estar haciendo es tomar nuestra compilación de desarrollo y, en lugar de reconstruir la imagen en cada etapa, deberíamos promocionarla, como un binario inmutable y estable a través de las puertas de calidad para la producción.

Suena bien. Vamos a hacerlo con Docker.

Espera, no tan rápido.

Docker tag es un arrastre

Esto es lo que parece una etiqueta Docker:

La etiqueta Docker nos limita a un registro por host.

¿Cómo se crea un canal de promoción si solo puede trabajar con un registro?

"Voy a promover el uso de etiquetas", dice usted. "De esa manera, solo necesito un registro Docker  por host". Eso funcionará, por supuesto, hasta cierto punto. Las etiquetas Docker (clave simple: propiedades de valor) pueden ser una solución justa para promocionar imágenes a través de puertas de menor calidad, pero ¿son lo suficientemente fuertes como para proteger su despliegue de producción? Teniendo en cuenta que no puede administrar permisos en etiquetas, probablemente no. ¿Cuál es el nombre de la propiedad? ¿QA lo actualizó? ¿Pueden los desarrolladores seguir accediendo (y cambiando) al candidato de lanzamiento? Las preguntas siguen y siguen. En su lugar, echemos un vistazo a la promoción para una solución más robusta. Después de todo, lo hemos estado haciendo durante años con Artifactory.

Repositorios virtuales probados y verdaderos.

Los repositorios virtuales han estado en Artifactory desde la versión 1.0. Más recientemente, también agregamos la capacidad de implementar artefactos en un repositorio virtual . Esto significa que los repositorios virtuales pueden ser un único punto de entrada para cargar y descargar imágenes de Docker. Así: estoes lo que vamos a hacer:

• Implemente nuestra compilación en un repositorio virtual que funcione como nuestro registro de Docker dedesarrollo 
• Promover la construcción dentro de Artifactory a través de la tubería
• Resuelva imágenes listas para producción del mismo (o incluso diferente) repositorio virtual que ahora funciona como nuestro registro Docker de producción

Así es como funciona:

Nuestro desarrollador (o nuestro Jenkins) trabaja con un repositorio virtual que envuelve un repositorio de desarrollo local, un repositorio de producción local y un repositorio remoto que apunta a Docker Hub (como primer paso en la tubería, nuestro desarrollador puede necesitar acceso a Docker Hub en Para crear nuestra imagen). Una vez que se construye nuestra imagen, se implementa a través del repositorio virtual de la ventana acoplable a la ventana acoplable-local .

Ahora, Jenkins interviene de nuevo y promueve nuestra imagen a través de la línea de producción.

En cualquier paso a lo largo del camino, puede apuntar un cliente Docker a cualquiera de los repositorios intermedios y extraer la imagen para probarla o ponerla en escena antes de pasar a producción. 
Una vez que su imagen de Docker está en producción, puede exponerla a sus clientes a través de otro repositorio virtual que funciona como su registro de Docker de producción. No desea que los clientes accedan a su registro de desarrollo ni a ninguno de los demás en su canalización. Sólo el registro de producción Docker. No hay necesidad de ningún otro repositorio, porque a diferencia de otros formatos de paquetes, el punto de una imagen acoplable es que tiene todo lo que necesita.

Así que lo hemos hecho. Construimos una imagen Docker, la promovimos a través de todas las fases de prueba y preparación, y una vez que pasó todas esas puertas de calidad, la misma imagen que creamos en el desarrollo ahora está disponible para su descarga por el usuario final o implementada en servidores de producción, sin riesgo. de una imagen no curada siendo recibida.

¿Qué pasa con la configuración?

Puede preguntar si conseguir que Docker trabaje con todos estos repositorios en Artifactory es fácil de configurar. Bueno, ahora es más fácil que nunca con nuestro nuevo generador de configuración de proxy inverso . Siga con Artifactory y NGINX o Apache y podrá acceder fácilmente a todos sus registros de Docker para comenzar a promocionar las imágenes de Docker a producción.