Una semana después del evento más importante de Europa encontenedores, junto con la KubeCon, hacemos un breve repaso de lo que hemos podido ver estos días.
Este ha sido un evento muy especial para mí en lo personal, ya que he participado muy activamente: fui speaker en los Workshops de Comunicaciones como instructor y además acudí a la cita como Docker Captain.
El evento no defraudó y el primer día todos los workshops estaban llenos; se hizo lo que se pudo. Se anunciaron para 60 alumnos, gracias al equipo de Mano Marks y Elton Stoneman pudo ampliarse a 70 participantes. Pero había mucha demanda y gente interesada no pudo entrar. En este punto hay que tener en cuenta que había varios workshops en ejecución a la vez, y que cada alumno disponía de una media de 4 nodos para poder realizar las prácticas.
Multiplicando rápidamente el aforo por los nodos y los workshops en paralelo, vemos claramente que los recursos proporcionados para el evento eran importantes. Debemos dar las gracias a Docker por el esfuerzo que realizaron para poder entregar estos entornos.
Hubo charlas muy interesantes. Siempre destaca el track Black Belt y, una vez más, la charla de Lize Rice fue de lo mejor. En esta ocasión entró menos en detalle que en otras ocasiones, pero siempre es interesante revisar temas de seguridad con los expertos.
Junto con Guillaume Morini, preparamos una charla sobre prácticas avanzadas de networking con Docker Enterprise. Enfocamos la charla en la securización de la intercomunicación de microservicios y aplicaciones desplegadas en contenedores con Network Policies en Kubernetes y las mejores posibilidades de publicación de aplicaciones que nos proporciona el entorno. Tanto en Kubernetes (Ingress Controllers) como en Swarm (Interlock). Realizamos un par de demostraciones interesantes publicando como ejemplo aplicaciones simples con balanceos avanzados mediante NGINX Plus y Kong como ingress controllers.
Docker demostró su orientación al mundo empresarial con el anuncio de Docker Desktop Enterprise, herramienta muy demandada desde los clientes más importantes.
Poder contar con un framework unificado que abarque desde el portátil del desarrollador hasta el propio entorno productivo, es francamente interesante y motiva aún más a la gran corporación a optar por Docker Enterprise. De esta forma, se mejora el workflow de desarrollo, impulsando el uso de técnicas de «Code and Run» en sus escritorios.
El problema que encontrábamos hasta ahora era la incompatibilidad de características entre los entornos productivos. Con Engines Docker Enterprise, y los entornos de escritorio, con Engines Docker Community. Además se unían las diferencias entre características inherentes a las versiones de API. Docker Desktop además requiere de permisos de administración que no están accesibles en todos los entornos.
La versión empresarial de Desktop vendrá preparada para los entornos de cliente, con gestión distribuida como la de cualquier otro aplicativo corporativo. Los administradores de la plataforma podrán restringir los cambios en la ejecución del aplicativo y configurar características del propio motor de Docker. Como por ejemplo las especificaciones de proxy corporativo, además de poder incluirse en las políticas del sistema. Por último, Docker Desktop Enterprise incluirá plantillas de despliegue de componentes habituales de infraestructura y ejecución de aplicaciones, proporcionando una herramienta francamente potente para un desarrollador que necesita un entorno ágil para poder empezar a «tirar líneas de código» lo antes posible y con la certeza de que funcionará en producción.
Como complemento al entorno Docker Enterprise, se anunció Docker assemble, que permite de forma sencilla construir imágenes sin tener que escribir un fichero Dockerfile. Depende lógicamente del framework de desarrollo (la demo se realizó con Maven por ejemplo), pero docker-assemble se encarga de detectar el framework, las dependencias, configuraciones, etc.. y prepara una imagen optimizada con nuestro aplicativo o microservicio. Docker-assemble desde luego es una herramienta muy prometedora e interesante que habrá que ver cómo se va desarrollando. Además de realizar esta compilación, analiza los elementos que se van incluyendo en la imagen y añade etiquetas de referencia con los hashes y versiones. Esto es muy práctico a la hora de realizar un seguimiento exhaustivo de los cambios que se realizan en la imágenes. Francamente muy interesante.
Durante el tercer día, segundo de sesiones, se anunció la liberación del código fuente de Docker Compose on Kubernetes. Esto supone un paso adelante en un intento de simplificar los despliegues de Kubernetes. Siempre cuento en los cursos de «Docker Fundamentals» que hay una leyenda que dice que hay un gurú en una cueva que es el que crea los primeros ficheros de deployment de Kubernetes en yaml y el resto de mortales sólamente los modificamos para nuestras necesidades. Esto, que es un chiste, es algo que diferencia claramente Kubernetes de Swarm. Poder usar el sencillo lenguaje de Docker Compose para realizar nuestros despliegues ayudará en la curva de aprendizaje de Kubernetes y además podremos elegir orquestador sin apenas cambios en Docker Enterprise.
Otro de los grandes anuncios de las jornadas fue CNAB (Cloud Native Application Bundle) y el empaquetado de aplicaciones. Nuestras aplicaciones desarrolladas en microservicios o simplemente bajo el paraguas de un entorno de contenedores, están basadas fundamentalmente en dos componentes:
Por un lado, tenemos las imágenes. Las tratamos como piezas de un «lego» que encajamos y configuramos de la forma apropiada para el diseño de nuestra aplicación.
Y por otra parte, está el propio diseño del aplicativo y la forma en que se ejecutan de forma orquestada todos sus componentes, incluyendo incluso la forma en que se publicará para su consumo.
El primero de los componentes sabemos gestionarlo, proporcionarle una versión, firmarlo y podemos almacenarlo de forma segura y accesible siempre que se necesite para la ejecución de contenedores.
La descripción del despliegue es más complejo de gestionar. En principio, cualquier sistema de gestión de ficheros nos valdría, pero la distribución de los mismos, de forma desacoplada a las imágenes, complica un poco las cosas. Desde Hopla! Software, siempre recomendamos un repositorio de infraestructura, en el que almacenamos y versionamos (fundamental) todos los ficheros de despliegue. Tratamos con ficheros de Compose de Docker, Deployments de Kubernetes o incluso Charts de Helm, pero ajenos a los otros componentes y las configuraciones específicas del despliegue también serían un tema aparte.
Docker Application Packages trata de unificar estos componentes para facilitar su gestión y poder tener un workflow que se apoye de forma confiable en versiones y sepamos en todo momento qué aplicaciones y con qué componentes tenemos desplegados en nuestra infraestructura.
CNAB va más allá del mero empaquetamiento de aplicaciones. De hecho, es posible probar ahora en beta Docker Application Package con soporte de CNAB. Cloud Native Application Bundle surge con la premisa de unificar los diferentes despliegues que podemos realizar con tecnologías nativas cloud. Tenemos Terraform, Ansible, Charts de Helm, CloudFormation, Compose…. cada herramienta con sus propias primitivas y particularidades. No existe una solución que unifique todos los servicios y formatos para la distribución de aplicaciones.
CNAB surge como especificación agnóstica totalmente al entorno de ejecución y con la premisa de unificar servicios y primitivas en un formato unificado. Ahora mismo CNAB está surgiendo y está en fase de borrador. Todo está por hacer, pero sí parece desde luego interesante tener una especificación unificada que las herramientas interpreten y no seamos nosotros quienes nos volvamos locos con decenas de formatos.
Entraremos en detalle de estos avances en próximos posts.
