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.
Como el número de direcciones IPv4 empieza a escasear, es una práctica habitual utilizar varios dominios para una misma dirección IP. Con HTTP normal lo llamamos virtualhosts y es relativamente sencillo; la cosa se complica cuando estos dominios funcionan por HTTPS y hay que servirlos usando certificados distintos.
Desde que adopté docker no he vuelto a utilizar servidores de aplicaciones para mis aplicaciones python. Sin embargo, en mi trabajo hay mucha gente que no confía en docker y que prefieren utilizar servidores como llevan haciéndolo toda su vida laboral, aunque se ha visto forzados a cambiar el lenguaje de programación usado.
En los anteriores artículos de la serie vimos como montar un entorno entero basado en docker swarm; añadimos un par de servicios de infraestructura básica, como son el balanceador y un cluster de bases de datos. Eran pasos que se hacen una sola vez y raramente se modifican. Ahora toca provisionar aplicaciones, en un proceso que vamos a repetir frecuentemente.
El siguiente artículo de la serie está dedicado a los balanceadores. Harto de mantener varias instancias sincronizadas entre sí y modificar los pools de balanceo cada vez que hay que hacer un despliegue, he optado por la versión fácil de traefik, que nos permite “montar y olvidar”, con mantenimiento cero.
Continuamos la serie enfocada a construir un entorno entero basado en docker swarm siguiendo desde el punto en que lo dejamos: con los servidores a punto y el cluster en marcha. Ahora vamos a poner en marcha un cluster de base de datos en el mismo swarm que, por ejemplo, va a ser un replica set de mongodb.