Docker Swarm. Aprendiendo como se hacen las cosas (revisado)
He estado revisando como se despliegan cargas de trabajo en Docker Swarm y lo primero que me ha sorprendido es que no existe un mecanismo como docker-compose, al menos no lo he encontrado, esto es un yaml en el que se define tanto los contenedores, como sus parámetros, las redes, los recursos, etc, que existen dos modos de desplegar las cargas de trabajo, o procesos, contenedores o como queráis llamarlos. La forma imperativa y la declarativa.
Imperativa.
Las cargas son, diríamos, atómicas en su concepto. Es como si la intención de docker swarm no sea desplegar microservicios y compartirlos sino que es un cluster esté dedicado a una aplicación exclusivamente en la que se despliega sus componentes/microservicios.
¿Como explicar la sensación? Tenemos una app con sus múltiples componentes, contenedores de microservicios, y se deben de desplegar, cada componente, con el comando correspondiente:
docker service create ...
; más sus opciones que describen cosas como: variables de entorno, montaje de volúmenes.
Es usar la filosofía de comandos de docker con la CLI sin haber implementado ninguna abstracción como se hace en Kubernetes. Todo es definido de forma explicita/mandatoria. Tenemos que definir todos los parámetros y aunque muchos de estos obtienen parámetros por defecto si podemos definirlos. En la página de documentación están todos los definidos: docker service create | Docker Docs .
Esto impide, inicialmente, la gran ventaja que implica el uso de kubernetes que es:
- la modelización de las cargas de trabajo, con archivos yaml
- la posibilidad del versionado, con git,
- la posibilidad del uso de plantillas (helm, no sé si es una exageración usarlo aquí)
Pero es una solución bastante simple y efectiva para empresas que desean las ventajas de la contenerización y la clusterización de las mismas para tener alta disponibilidad, pero no tienen la capacidad y los recursos para gestionar las complejidades de Kubernetes. Eso si a nivel de seguridad se debe de afinar mucho dentro de los contenedores y además también en las comunicaciones entre el clúster y la publicación (en el caso de internet).
Es un paso en el camino desde la complejidades de la administración de los sistemas y aplicaciones on-premise, al mundo de la contenerización de aplicaciones y el cloud, comenzando por clouds pequeños y sistemas de automatización y modelización de las aplicaciones.
Para empresas con pequeños grupos de TI creo que merece mucho la pena explorar la contratación de clúster en los clouds en los que instalar docker Swarm y conectarlos con soluciones de balanceo como Traefik, o HAProxy al resto de Internet o a las redes internas via VPN.
Comentarios
Publicar un comentario