El otro día recibí una petición diferente en mi trabajo. Se necesitaba monitorizar una carpeta, de forma que cuando alguien dejara ficheros, se lanzara una tarea para procesarlos. Tras buscar un poco por internet, topé con una herramienta tipo cron, que ejecutaba comandos ante eventos en el sistema de ficheros.
Cuando trabajamos con python, muchas veces necesitamos instalar librerías con pip o easy_install. Dependiendo de la naturaleza de nuestros proyectos, las librerías suelen variar, pero siempre solemos utilizar las mismas. En estos casos puede ser útil tenerlos cerca, cacheados en un servidor en nuestra red local, para su rápido acceso.
Estaba yo el otro día buscando un servidor de aplicaciones para aplicaciones python, y entre todas las opciones encontré uno que es una auténtica joya: uWSGI. Se trata de un servidor modular, que permite servir un amplio abanico de posibilidades en cuanto a lenguajes se refiere, usando un plugin adecuado.
Hoy quiero presentar una distribución de linux que es una maravilla; es rápida, altamente actualizada, y lo último en innovación. Se trata de una distribución tipo rolling, con una filosofía de última tendencia que es especialmente útil en un entorno no tan crítico, como puede ser una máquina tipo escritorio.
Cuando tenemos un entorno grande o con previsiones de crecimiento, nos interesa poder poner a trabajar varios servidores similares. En casos así nos hace falta un balanceador de carga, que actúa como un agente de tráfico, dirigiendo las peticiones que él mismo recibe a los diferentes servidores, por ejemplo, haproxy.
Algunas veces tenemos necesidad de crear un proyecto con un equipo pequeño y necesitamos versionarlo en un sitio accesible para todos los participantes involucrados. El precio de soluciones en la nube suele ser prohibitivo, y montar una solución gráfica puede ser demasiado. Lo podemos hacer simplemente usando git y ssh.
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.
Acabamos el artículo anterior de esta serie con las aplicaciones corriendo en sus respectivas máquinas. En este artículo vamos a poner una fachada a todo el sistema, mediante un proxy HTTP que haga las funciones de terminación SSL y de balanceador, exponiendo todo el sistema en una sola dirección IP.
En el artículo anterior de esta serie montamos el cluster de la base de datos que íbamos a necesitar para las aplicaciones que conformaban este entorno de ejemplo. Ahora que tenemos la base de datos, falta poner los servidores de aplicaciones que sirven nuestras aplicaciones y que usan el cluster.
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.