Hace mucho tiempo que sé que puedo importar módulos y paquetes de python desde
un archivo .zip, pero desconocía que puedo “empaquetar” un script con todas las
dependencias que tiene y hacerlo autocontenido, ya sea ejecutable o no. Solo haría
falta un intérprete de python y su librería estándar para ejecutarlo.
Tal como el mundo de las aplicaciones va adoptando arquitecturas orientadas a microservicios nos encontramos con la necesidad de alojar más aplicaciones pequeñas, y normalmente con requisitos distintos en cuanto al lenguaje de programación, su versión o sus librerías; esto nos lleva a la adopción de contenedores, pero no siempre es posible.
Hay muchos motivos para recolectar las URLs de un sitio web, tanto legítimas como ilegítimas; es una herramienta que, como todas, se puede utilizar para el bien o para el mal. En mi caso, la petición recibida era legítima: un cliente necesitaba hacer peticiones web con regularidad para mantenerlas cacheadas en la CDN que usaba.
Cada vez nos encontramos con el mismo problema; empezamos un nuevo proyecto y tenemos que crear toda la estructura del proyecto partiendo de cero, de un ejemplo, o haciendo copy-paste de otro anterior. Esto implica cambiar algunos nombres de ficheros y carpetas, o contenido de ciertos ficheros; es toda una invitación al desastre.
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.
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.
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.
Cuando hablamos de equipos distribuidos por diferentes puntos geográficos, se necesitan herramientas de comunicación adecuadas; en nuestro equipo utilizamos Slack. Con el auge de palabras como chatops y otras tendencias, se hace muy interesante que nuestros sistemas puedan notificar mensajes en la misma herramienta que todo el equipo está mirando.
Soy un aficionado a las películas bélicas, especialmente las referentes a la Segunda Guerra Mundial. Una de las imágenes más impactantes es cuando salen los centros de mando, donde los generales tienen una mesa con un mapa y la disposición de sus fuerzas, que se actualizan cuando llegan los mensajeros.