El día de ayer, buena parte del mundillo informático se sacudió con una noticia, que si bien ya se veía venir, por el lenguaje utilizado causo revuelo y preocupación, veamos:
Esta nota formaba parte del log de cambios de Kubernetes, lo cual iba en la línea de un anuncio anterior donde se anunciaban este objetivo por parte de Kubernetes.
Obviamente las preguntas saltaron, ¿ya no podre seguir usando Docker si quiero trabajar con Kubernetes? ¿Qué pasara con el soporte para contenedores en Windows?, y la verdad la respuesta tardó algo en darse, y de eso hablaremos aquí, pero antes contextualicemos un poco.
Primero, veamos la parte técnica, a estas alturas en el mundo informático ya el concepto de contenedores esta mas o menos establecido, que la equivalencia con los contenedores usados en el transporte marítimo, que es una unidad de software con lo mínimo para ejecutar en un entorno destino y asi asegurar la portabilidad, las diferencias con las máquinas virtuales etc. Dicho esto, si que debemos repasar cual es el ciclo de trabajo que la mayoría de nosotros usamos al trabajar con contenedores, por simplicidad he quitado los componentes DevOps para enfocarnos en los contenedores, Docker y Kubernetes.
- Tenemos un archivo llamado Dockerfile que define los componentes de software que queremos empaquetar y algunas acciones alrededor, este Dockerfile actúa como “receta” para que el comando “docker build” construya una imagen que la llamaremos X.
- En este momento la imagen X esta en nuestro equipo, por lo que ya podríamos ejecutarla usando el comando “docker run”, o publicarla en un Registro tal como Docker Hub, Elastic Container Registry o Azure Container Registry, para lo cual usaremos “docker push”.
- Con la imagen X subida en uno de estos Registros, ya esta lista para ser usada en diversos ambientes (generalmente en la nube), tales como Azure Container Instances, una máquina “convencional, Elastic Beanstalk y… Kubernetes, para lo cual este entorno destino deberá hacer un “pull” contra el Registro respectivo.
Entendiendo este gráfico podemos ver el porque de las dudas, si hemos subido nuestras imágenes apoyándonos en las funcionalidades de Docker… ¿quiere decir que en un futuro ese flujo va a cambiar?, bueno… para responder esta pregunta toca revisar un poco el como hemos llegado hasta aquí.
Seguro recordamos como entre el 2015 y el 2016 vimos el boom de Docker, y como de repente empezamos a hablar básicamente de contenedores, todos querían saltar al barco, ya sea por una necesidad real o por moda, pero rápidamente salto algo como necesidad: nuestras aplicaciones no se conforman únicamente de un módulo, por lo que se necesita “orquestar” a múltiples contenedores en ejecución, así que saltaron a escena nombres como Mesos, Docker Swarm y… Kubernetes, servicios que te ofrecían mecanismos de gestión, despliegue y escalamiento de contenedores dentro de un cluster.
Para nadie es novedad que para la segunda mitad del 2017 (si, estas cosas se han movido muuuy rápido) Kubernetes se consolido como el ganador, Azure anuncio AKS y otros proveedores cloud harían lo propio eventualmente, por lo que pasamos no solo de construir contenedores en Docker, sino a pensar en microservicios (los necesitemos o no, pero esa es otra historia) pues Kubernetes facilitaba su despliegue, y poco a poco la analogía usual de Docker con contenedores como términos intercambiables se perdió, y empezamos a hablar de “pods” que es la forma en que se ejecutan las imágenes dentro de un cluster de Kubernetes.
Antes de continuar con la historia, vale recordar que cuando empezó el boom de Docker por el 2015, hubo voces provenientes del mundo Linux hardcore, que cuestionaban el formato de contenedores que Docker estaba impulsando, aludiendo a razones de seguridad indicando que lo suyo era usar el formato LXC, pero esas voces en su momento no fueron escuchadas en medio de la vorágine, mas aun si tenemos en cuenta que Microsoft empezó a trabajar en el reto de crear contenedores para Windows.
Eventualmente esos cuestionamientos volvieron a aparecer cuando Kubernetes se estaba volviendo en el referente del mundo de los contenedores, a fines del 2016 Kubernetes propuso a Container Runtime Interface (CRI) como el interfaz para los runtimes de contenedores, sutilmente dejando el mensaje “The most widely known container runtime is Docker, but it is not alone in this space” para de esta manera proponer una forma de conectarse a distintos runtimes, como rktnetes que ellos mismos estaban desarrollando.
Y las noticias empezaron a sucederse, a paso lento pero seguro:
- Noviembre 2017: Containerd Brings More Container Runtime Options for Kubernetes Aqui se presenta a cri-containerd como un mecanismo de ejecución mas ligero en el cual se prescinde del motor de Docker, lo curioso es que el proyecto ContainerD originalmente fue donado por Docker a la CNCF
- Mayo 2018: Kubernetes Containerd Integration Goes GA, lo anunciado anteriormente cobra madurez y el nuevo modelo es validado en GCP y Alibaba, con mejoras de performance.
- Mayo 2019: CRI-O: An Open Source Container Runtime for Kubernetes, como opción a ContainerD, surge CRI-O que también será compatible con el modelo CRI.
- Noviembre 2019: Mirantis acquires Docker Enterprise, esto fue la puntilla del asunto, Docker no pudo posicionar su servicio de Docker Enterprise por lo que lo tuvo que vender su servicio empresarial, a fin de enfocarse en Docker for Desktop y Docker Hub (uno de los Registros de los que hablábamos), se mencionó que era para enfocarse en las herramientas para el desarrollador, pero la movida no era sino un síntoma de como Kubernetes le había ganado el espacio que ellos abrieron.
Esto nos lleva a la noticia reciente, ¿esto que significa a efectos prácticos? Para quienes administran clusters de Kubernetes esto les obliga a asegurarse de que estos cluster estén configurados para trabajar con un runtime que soporte directamente Container Runtime Interface(CRI), de momento “solo” recibirán un mensaje de que el runtime Docker esta deprecado, pero en una futura actualización dicho soporte será retirado del todo.
Y lo más importante ¿Qué pasa con los desarrolladores? Pues, en teoría nada, las nuevas versiones de Kubernetes seguirán trabajando con las imágenes generadas con Docker desde nuestros Dockerfile, pues las imágenes tanto containerd como CRI-O saben como trabajar con las imágenes Docker.
Llegados hasta aquí ¿todos felices? ¿todos contentos? Pues no tanto, la forma en que se comunicaron las cosas no ha sido la mejor, cualquiera que lee las notas iniciales no puede sino alarmarse ante el potencial impacto en sus formas de trabajo, vamos.. como desarrollador leo que Docker esta siendo deprecado y pienso en como impactara a mis depuraciones en Visual Studio, que si lo que hago en Windows con Docker luego será compatible, si tendré que cambiar piezas de mis pipelines de despliegue, etc.
Claro, luego se mandan mensajes explicando y procurando que se guarde la calma, como este quipu de Kat Cosgrove, que conmenta de manera mas detallada la relación entre Kubernetes, los runtimes y Docker, todo muy útil, pero recién al final comenta lo mas importante, lo relativo a los Dockerfiles ¡Plop!
Por otro lado tenemos Don’t Panic: Kubernetes and Docker, un post de Kubernetes, que estructura el flujo de decisiones que los llevaron a las decisiones actuales, donde no dejan de ser curiosos mensajes (provenientes del hilo arriba mencioado) como “Docker is cool and useful because it has a lot of UX enhancements that make it really easy for humans to interact with while we’re doing development work, but those UX enhancements aren’t necessary for Kubernetes, because it isn’t a human”, pero claro… tiene toda la cara de ser un control de daños, no algo planeado, lo cual me lleva a pensar de que en este upgrade solo se pensó en la cara administrativa de los contenedores y no en el ciclo de desarrollo de software alrededor de esta tecnología, vamos un pensamiento no muy DevOps que digamos.
Y por el lado del soporte de Windows Containers en Kubernetes queda medio en el aire, pues a la fecha era justo el runtime de Docker el que permitia que Kubernetes soportara este formato de contenedores, siendo que dicho soporte por parte de containerD esta… en ALPHA!!
En todo caso, el golpe esta dado, técnicamente se puede justificar el movimiento de cara a la eficiencia de Kubernetes, pero pero… el temor respecto a si se debe mantener el flujo basado en Docker ya surgió, algún competidor querrá aprovechar el pánico, lo dicho… la forma en que se han manejado las cosas no ha sido buena, y con algo de suspicacia se podría pensar que es una forma para terminar de borrar a Docker ¿Qué opinan?