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.
A veces nos conviene ejecutar tareas de forma periodica en nuestro servidor, y para ello disponemos de cron y de anacron. Sin embargo, en un entorno clusterizado de Docker no es fácil decidir en qué máquina lo ponemos o simplemente necesitamos que pueda acceder a alguna red overlay.
En mi cruzada por reducir la instalación de una distribución Debian y
conseguir hacerla repetible sigo buscando las herramientas adecuadas para
conseguirlo. Hoy le toca a una herramienta que encontré casi por casualidad
ejecutando un apt search rutinario que no dio el resultado esperado, pero
me dio a conocer debootstick.
Hay veces en las que queremos desplegar de forma rápida una aplicación escrita en python. En algunos casos, instalar un servidor de aplicaciones para gestionar una sola aplicación nos puede parecer exagerado; así que instalamos el servidor de aplicaciones gunicorn en el mismo virtualenv y relegamos la gestión del proceso a systemd.
Todos sabemos que podemos construir jaulas enteras de Debian con una herramienta propia llamada debootstrap, pero pocos saben que es la misma con la que se instala la distribución si usamos el instalador oficial que viene en los CDs descargables. sin embargo la configuración posterior no es trivial.
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.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 » »»