Hace tiempo me enamoré de MongoDB; era la base de datos por defecto para todos mis proyectos. El status quo cambió cuando decidieron cambiar la licencia (perdiendo el soporte de las principales distribuciones Linux), y cuando decidieron requerir extensiones AVX en el procesador, limitando los entornos virtuales en los que ejecutarlo.
Cuando tenemos un servidor mongodb en un entorno productivo solemos dedicar una máquina entera a la tarea, y no nos importa que consuma toda la memoria disponible. Sin embargo, en entornos de prueba o de preproducción solemos hacer convivir este servicio con otros procesos, y suelen tener conflictos de memoria.
Cuando hacemos proyectos simples que requieren el uso de una base de datos mongodb es habitual poner un servidor simple y poco potente para salir del paso. A veces, estos proyectos empiezan a crecer en número y en importancia y necesitamos plantearnos su traspaso a hardware más potente o a una topología tipo cluster.
Uno de los aspectos que voy dejando de lado en mis artículos es el tema de los backups; suele bastar con ejecutar algún comando o script en una tarea tipo cron. Si el servicio mongodb se encuentra en docker, a veces queda inaccesible fuera de docker y hay que dockerizar el backup.
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.
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.
El otro día estaba revisando viejos artículos, y me tropecé con uno anterior. Este estaba montado con ansible, y se me pasó por la cabeza reescribirlo usando contenedores con docker. Así pues, vamos a montar exactamente el mismo cluster, pero con el cambio que la última revolución tecnológica nos aporta.
Usar autenticación en las bases de datos de nuestros entornos, por muy privados que sean, suele ser una buena idea. Nos sirve para separar los accesos a un servicio compartido y evitar sobreescrituras cuando accidentalmente dos servicios usan la misma base de datos por un error de algún usuario despistado.
Algunas veces queremos probar nuestras aplicaciones en local y necesitamos una base de datos MongoDB; en estos casos, Docker nos presta un gran servicio. Es posible que en estos casos necesitemos un replica set para probar; aunque Docker sigue ayudando, la inicialización del cluster sigue siendo un tedioso proceso manual.
Aquellos que hemos usado mongodb desde python, ya conocemos las virtudes de pymongo. Sin embargo, este lenguaje es orientado a objetos, y trabajar con ellos hace nuestro código más simple y más legible. Mongoengine es un ODM, una librería que se encarga de convertir objetos en documentos mongodb y viceversa.