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.
Cuando MongoDB decidió cambiar la licencia por una que no cumple los criterios básicos de software libre, muchos decidieron abandonar el barco, siendo las principales distribuciones de linux las primeras en hacerlo. No faltaron voces que cantaran las maravillas de PostgreSQL, y como soy curioso, le he dado un intento.
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.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 » »»