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.
Es bastante habitual que en mi tiempo de ocio me dedique a trabajar con HTML y CSS por interés personal. A veces puedo hacer pruebas de concepto estáticas y otras puedo utilizar un generador estático; en todos los casos necesito de un servidor web levantado solo para mi sesión personal.
Hace tiempo me enamoré de un generador de webs estáticas llamado pelican; puede que fuera por estar escrito en python, o por tener una gran colección de temas y plugins disponibles. Con el tiempo, han aparecido muchas alternativas, y una de ellas me llamó la atención por su sencillez y velocidad: hugo.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 » »»