Ya sabéis que me encantan los sistemas reconstruibles y, en ese aspecto, nada supera a Docker. Sin embargo, la imagen oficial de Jenkins para Docker normalmente no contiene las herramientas que nos interesan. Por eso podemos descargar los trabajos a agentes más adecuados, posiblemente desplegados también en contenedores Docker.
Es muy frecuente practicar el despliegue continuo en mis clústeres de Docker Swarm. Sin embargo, esta práctica viene acompañada de un molesto pequeño problema: se me acaba el espacio en disco por acumulación de objetos de docker (imágenes, contenedores parados, volúmenes, etc.).
Ya hablamos sobre los sidekick containers en otro artículo. Vimos como podemos tener contenedores que se dediquen a “ayudar” a otros contenedores, y la idea es la misma cuando trabajamos con Docker Swarm. Lo que no es tan simple es crear un contenedor que ejecute una acción y “muera”, una vez cumplido su objetivo.
Ya hemos hablado de los healthchecks de Docker en otras ocasiones. Sin embargo, aprecio en muchos de los servicios que administro que brillan por su ausencia; es algo que no puedo entender, por la multitud de beneficios que nos aporta desde un punto de vista de operaciones en los despliegues.
Muchas veces nos encontramos que es más fácil y barato contratar un servicio de registro Docker en el cloud. Así nos olvidamos del hosting, certificados SSL, backups y demás tareas de administración. Otras veces preferimos recortar en costes y hacer un registro local en nuestra propia infraestructura, como ya hicimos aquí y aquí.
Hace ya mucho tiempo que trabajo con Docker y Docker Swarm. He intentado documentar lo que voy haciendo para futuras referencias y eso se refleja en los artículos de este blog. Sin embargo, algunos de los trucos que he usado no tienen suficiente material para justificar un artículo nuevo.
Soy un fanático del paradigma everything as code y del nada en local. Esto me lleva a versionar en un repositorio todo lo que hago y a tenerlo alojado en algún servicio cloud. Esto significa que necesito alguna forma de ocultar las variables de entorno problemáticas de un stack de Docker Swarm.
Cuando trabajamos en un entorno de varias aplicaciones tipo web o API nos solemos encontrar con la necesidad casi absoluta de poner un balanceador o proxy reverso; a veces es para balancear, otras es para la terminación SSL, y otras es para forzar la redirección a HTTPS. Para todas ellas nos sirve nginx.
Uno de los aspectos que voy dejando de lado en mis artículos es el tema de los backups; suele bastar con ejecutar algún comando o script en una tarea tipo cron. Si el servicio mongodb se encuentra en docker, a veces queda inaccesible fuera de docker y hay que dockerizar el backup.
Todos aquellos que hemos desplegado stacks en docker swarm que usan algunas configuraciones o secretos, nos hemos topado con problemas cuando el contenido de estos ficheros cambia. Esto es así porque el sistema los ha diseñado para ser objetos de lectura, y no de modificación, pero hay maneras de arreglar este problema.