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.).
Muchas veces nos ponemos a escribir nuestros ficheros Dockerfile sin prestar mucha atención a lo
que salga, siempre que funcione. Es una forma correcta de ver las cosas, pero suele ser un error;
verificar unos pocos puntos antes de dar el fichero por bueno nos puede ahorrar problemas futuros
y no requiere mucho tiempo.
Hace mucho tiempo que he creído en MongoDB. Sin embargo, con el cambio de licencia el soporte del mismo ha caído en los repositorios oficiales de las diferentes distribuciones. Para añadir más sal a la herida, la empresa responsable no soporta las últimas distribuciones estables de Debian en sus repositorios.
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.
Los que leéis de vez en cuando este blog ya sabéis que tengo especial predilección por Python y Docker, con el que utilizo la versión “alpine” de las imágenes siempre que puedo. Al menos eso es lo que pensaba hasta hace poco tiempo, cuando la librería musl libc me dejó tirado.
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.