Ya vimos en otro artículo sobre los sistemas de ficheros tipo stacked, como por ejemplo AUFS. Estos nos pueden ser útiles en multitud de ocasiones, y en particular OverlayFS, que ya viene en el kernel de muchos de los Linux habituales y sirve como la base sobre la que se construye Docker.
Hace tiempo que no usaba haproxy. Puede ser porque he priorizado otras soluciones, sean otros servicios como nginx o, simplemente la plataforma ya me ofrecía soluciones incorporadas o empresariales. Pero la verdad es que haproxy funciona, y es una solución a la que vuelvo de forma recurrente.
Cada vez nos encontramos con el mismo problema; empezamos un nuevo proyecto y tenemos que crear toda la estructura del proyecto partiendo de cero, de un ejemplo, o haciendo copy-paste de otro anterior. Esto implica cambiar algunos nombres de ficheros y carpetas, o contenido de ciertos ficheros; es toda una invitación al desastre.
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.
Cuando tenemos un servidor mongodb en un entorno productivo solemos dedicar una máquina entera a la tarea, y no nos importa que consuma toda la memoria disponible. Sin embargo, en entornos de prueba o de preproducción solemos hacer convivir este servicio con otros procesos, y suelen tener conflictos de memoria.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 » »»