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.
Tras aprender más de systemd y su modo de usuario, vi infinitas posibilidades para los servicios de usuario. Dependiendo del tipo de tarea en la que iba a trabajar, parecía lógico tener un subconjunto de servicios ejecutando en segundo plano. ¿Había alguna manera de levantar varios con un solo comando?
Una de las funciones que prometía systemd cuando apareció era la de reemplazar las utilidades tipo cron. Esto era bueno porque iba a estandarizar un servicio que no lo estaba (aunque las diferentes distribuciones lo daban por hecho); esta idea se quedó en el tintero y es hora de sacarla.
Es bastante habitual que en mi tiempo de ocio me dedique a trabajar con HTML y CSS por interés personal. A veces puedo hacer pruebas de concepto estáticas y otras puedo utilizar un generador estático; en todos los casos necesito de un servidor web levantado solo para mi sesión personal.
Configurar servidores desde cero es una tarea muy pesada, una fuente de errores innecesaria y hace nuestros servidores difícilmente reproducibles. Los setups más básicos son siempre los mismos, y podemos configurar nuestros servidores para que ejecuten un script la primera vez que se (re)inicien, a falta de mejores herramientas.
Ya vimos en un artículo anterior como levantar túneles SSH para llegar a través del protocolo SSH, a destinos que no están alcanzables normalmente. Esto está muy bien para aplicaciones puntuales, pero si tenemos que usar esos túneles una temporada, y deseamos que se mantengan levantados, ya es mas difícil.
Como ya vimos en un artículo anterior, los replica sets nos ofrecen alta disponibilidad para nuestros despliegues de mongodb. Sin embargo, algunas veces, necesitamos que nuestro cluster ofrezca alto rendimiento, y esto se consigue mediante sharding. Como no queremos renunciar a la alta disponibilidad, podemos aplicar ambas; hoy explicamos como.
Seguimos con la serie de montar un entorno escalable. Tras explicar en el primer artículo lo que vamos a montar, seguimos con ello. En este artículo vamos a montar un cluster de bases de datos; será mongodb porque la aplicación lo requiere y usará la topología de un replica set.
Muchas veces nos interesa obtener alta disponibilidad en los servicios que gestionamos. No hay nada mas desagradable que una llamada a las tantas de la noche porque se ha caído un nodo de una base de datos y no damos servicio. Para eso mongodb nos ofrece el mecanismo de replicación.
Cuando se anunció systemd me llamó la atención que además de las funciones estándares de otros sistemas de init (por ejemplo sysvinit), también se ofrecían otras funcionalidades normalmente delegadas a otros procesos, como por ejemplo, la posibilidad de reiniciar procesos automáticamente o de lanzar procesos temporales al estilo de cron.