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.
En uno de los sitios en los que estuve trabajando, tenía un compañero un poco desordenado. Cada vez que hacía un script que necesitaba guardar la salida en un fichero temporal, reutilizaba los nombres o los acumulaba infinitamente en una carpeta temporal, cuyo nombre dependía de la inspiración del momento.
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.
Continuamos con esta serie de artículos con la finalidad de crear un entorno dockerizado completo. Vamos a ir creando la infraestructura necesaria para alojar nuestro cluster de docker swarm. Esto implica crear una red privada, un gateway para esconderla, y finalmente ataremos el cluster de docker swarm.
Hace tiempo trabajé en una compañía que tenía un entorno productivo basado en docker. Fueron de los primeros en adoptar docker y no utilizaban ninguna tecnología de clusterización. Los contenedores se ponían en alguna máquina con capacidad adecuada; los balanceadores y las bases de datos tenían máquinas dedicadas.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 » »»