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.
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.
Cuando hacemos proyectos simples que requieren el uso de una base de datos mongodb es habitual poner un servidor simple y poco potente para salir del paso. A veces, estos proyectos empiezan a crecer en número y en importancia y necesitamos plantearnos su traspaso a hardware más potente o a una topología tipo cluster.
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 » »»