Docker en su fábrica de software

1. Docker a todos los niveles

Hemos mostrado en el capítulo anterior cómo utilizar Docker para desarrollar una aplicación. Pero Docker también es muy útil en los editores de software: participa del funcionamiento fluido de la ALM (Application Lifecycle Management, es decir, la orquestación del ciclo de vida del software, desde el diseño a la obsolescencia), integrando una gran cantidad de formas en estas herramientas.

Los puntos de integración son múltiples. Docker es una especie de navaja suiza que va ayudar a resolver diversos puntos de dificultad:

Producir imágenes en salida de build;
soportar máquinas de compilación;
utilizar contenedores para las pruebas;
establecer más fácilmente una integración continua;
etc.

En esta segunda parte del capítulo, vamos a centrarnos en estos usos quizás más destinados a los administradores y administradores de herramientas para desarrolladores. El siguiente esquema muestra las diferentes etapas típicas de un ciclo de vida de una aplicación de software, desde el diseño del código fuente a su despliegue, marcando las etapas del uso de Docker que hemos mostrado hasta ahora:

Estos dos usos se corresponden con:

La implantación de Docker para facilitar el despliegue en un entorno destino, controlando la equivalencia completa entre los entornos, ya sea de desarrollo, pruebas o producción. Esto se corresponde con la flecha entre la herramienta de instalación y los entornos, así como estos últimos, que utilizan Docker.
La utilización de Docker para implementar un registro de imágenes Docker. Para ser preciso, hemos explicado el funcionamiento de un registro como almacén de imágenes Docker, sobre todo en el caso de un registro público. En lo que respecta al registro interno, el funcionamiento es el mismo, salvo que el registro no se expone al exterior (al contrario que un registro público o privado, este último expuesto al exterior pero securizado, mientras que el registro público está abierto a cualquier potencial usuario).

En las secciones siguientes, vamos a ver que Docker puede servir en casi todas las otras etapas de la fabricación de software.

2. Producir imágenes como salida de build

a. Posicionamiento

Una de las primeras...

Antes de empezar en producción con Docker

En la actualidad, el ecosistema de Docker es de tal riqueza que un libro sobre los fundamentos del funcionamiento solo puede mencionarlo.

En particular, se podría dedicar un tomo completo a la orquestación de Docker en producción. Sin extenderse sobre un posible contenido, parece imposible no mencionar en un libro sobre Docker, aunque sea brevemente, algunos aspectos como los siguientes.

1. Seguridad

Durante mucho tiempo, Docker ha estado rezagado respecto a la seguridad. La empresa ha querido ocupar el mercado lo más rápidamente posible, para no ceder espacio a la competencia y algunas veces, el precio a pagar ha sido la seguridad de las instalaciones. Afortunadamente, esta época ha pasado desde que el software en sí mismo se ha hecho estable y se ha dedicado tiempo a su securización.

En las últimas tecnologías aparecidas en 2016 y 2017, la seguridad se ha pensado desde el mismo momento de la aparición de las nuevas funcionalidades. Este es el caso en particular de la implementación de un cluster Docker Swarm, donde el acoplamiento de un demonio al cluster, solo se hace si el primero conoce un token secreto. Además, el token se divide entre una versión para unirse como sencillo agente de ejecución o para unirse al cluster como nodo de tipo manager.

Hay buenas prácticas que han aparecido sobre la securización...

Docker y Windows

Aunque Docker sea un producto de Linux y basado en funcionalidades de bajo nivel, que no se encuentran en la misma forma en el nodo Windows, Microsoft ha conseguido en 2016 crear una implementación nativa de Docker, y ha tenido la buena idea de seguir las recomendaciones del Open Container Initiative, que garantían una compatibilidad con Docker a nivel del API. Por supuesto, las imágenes no se pueden mezclar entre las máquinas Windows y Linux, pero el API es el mismo en un caso o en el otro. Esto no solo permite un fácil aprendizaje, sino abrir incluso la vía a escenarios extremadamente potentes, como plataformas Swarm híbridas, compuestas por el demonio de los dos tipos y por lo tanto soportando contenedores Windows y Linux, en la misma plataforma de despliegue.

Conclusión

Docker ha cambiado la manera en la que lo desplegamos y de rebote, la relación entre los desarrolladores y los administradores de sistema, que ya había evolucionado mucho con el movimiento DevOps.

Hay muchas posibilidades de que haya más sorpresas y ya podemos imaginar algunos cambios adicionales, por ejemplo, la diseminación cada vez más grande de servicios incorporados por los contenedores Docker. La capacidad de Docker de presentar una interfaz idéntica independientemente del soporte de máquina del contenedor, permitirá a determinadas imágenes convertirse en estándares de facto para un servicio en particular. Adicionalmente, esto permitirá a los desarrolladores concentrarse en el valor añadido de los desarrollos, y no tener que reinventar constantemente servicios, como sigue siendo el caso demasiado habitualmente, en la actualidad.

Del lado de la orquestación, Docker ha anunciado en octubre del 2017 el soporte de Kubernetes de Google, que podría parecer algo negativo para Swarm, pero que bien mirado es una evolución lógica del ecosistema. Docker siempre ha tenido un enfoque llamado ”pilas incluidas”, es decir, que una funcionalidad se podría cambiar, pero Docker proporciona al menos una versión sencilla que permite al ”juguete” funcionar desde su salida de la caja.

Swarm es, de una determinada manera...

Ir aún más allá con Docker