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.
Es muy habitual tener varios entornos en donde ejecutar nuestras aplicaciones; algunos son entornos productivos o copias exactas, pero muchos otros son entornos de desarrollo y de pruebas que solo son accedidos por una minoría, normalmente de nuestra misma empresa. Y si usan certificados SSL válidos, el coste se dispara.
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.
Hacía tiempo que no hacía pruebas de carga contra una web, pero como no podía
ser de otra forma, me cayó una petición de este tipo el otro día. Reconociendo
que el venerable ab se quedaba corto, decidí buscar una alternativa viable;
encontré una que me sacó una sonrisa: vegeta.
Nunca dejo de maravillarme de la cantidad de keywords y parámetros que nos ofrece SSH. Sin embargo, tanta funcionalidad tiene un precio, que es la dificultad de descubrirlos todos y, a la larga, nos quedamos con solo unos pocos. Otro problema es la creciente longitud de nuestras líneas de comandos.