Se acuerdan de Hal, el papa de Malcolm?

Todo comenzó con mi proyecto de hacer un docker swarm con Raspberry Pi
Todo funciona a la perfección, pero entonces, decido usar mi blog como ejemplo, hagamos funcionar este blog, de forma distribuida, cuando me tope con el primer problema

Ghost usa SQLite, que aunque es el gestor de base de datos mas utilizado en el mundo, no esta diseñado para consultas concurrentes, así que mi blog requería una seria re-estructuración.

Durante este periodo (que pensé, seria corto) decidí no agregar nada, para evitar trabajar con una base de datos anticuada. pero entonces comencé a trabajar con Docker. y si antes no me gustaba, puedo decir que, aunque me divierte mucho, puedo ver serios problemas.

Todo para ARM

Tuve que hacer imágenes docker para armhf de mis servicios:

1. El blog Ghost
2. Un gestor de base de datos

Las imágenes que existían ignoraban completamente el tamaño final y termine haciendo las propias, logre reducir el tamaño a la mitad, en ambos casos

Volúmenes persistentes entre hosts docker

Aunque docker swarm hace maravillas para balancear tus servicios de forma completamente transparente y casi mágica, haciendo casi innecesaria la configuración de redes, o FQDN's entre servicios, un serio problema para mi, es el hecho de que no es posible, hasta ahora, compartir volúmenes entre hosts docker.

Esto hace prácticamente imposible hacer funcionar un gesto de base de datos standalone en swarm, por lo que la base de datos tiene que se configurada como cluster,desde la imagen, y así permitir añadir o remover nodos (contenedores) de forma sencilla. mi imagen docker tuvo que ser reeditada.

Que hay del contenido estático

No solo mi base de datos requería escribir información en el mismo lugar. ghost también almacena información estática, para funcionar, lo guarda como contenido personalizado para cada blog ghost.

Cada host, genera sus propios volúmenes y los usa en los contenedores locales, este problema puede ser solucionado con NFS, para compartir datos entre varios host docker, pero eso es una solución local todavía, no se debe usar NFS para volúmenes remotos (diferente geografía), e incluso si se usaran, tu servidor NFS se convierte en un punto de falla no redundante.

La solución es relativamente simple, el mejor lugar para mantener tus datos redundantes y siempre disponibles, es en Internet, una vez que algo esta en Internet, es prácticamente imposible borrarlo, y hay servicios de storage públicos, lamentablemente. servicios como los que ofrecen google o amazon. son prestados para sus servicios de cloud, y una raspberry casera, no esta dentro de su alcance (Los servicios redundantes, elevan costos, quien lo diría ).

Entra entonces un viejo conocido, WebDAV, y afortunadamente para mi, BOX ofrece el servicio gratuito, lamentablemente, es un servicio http que es lento por naturaleza, aunque, se puede configurar para permanecer en el servidor de manera estática, y sincronizarse, haciendo de esto, un servicio descentralizado, relativamente fácil de configurar, y lo mas importante de todo

GRATIS

En fin, he estado trabajando con todas esta variables, saltando de un problema a otro, aprendiendo mucho sobre muchas cosas como

1. Kubernetes vs Swarm
2. CoreOS y cloud init
3. overlay networking
4. Automatic builds con DockerHub y github (si, incluso arq ARM)
5. Dockerfiles y sus mejores practicas
6. Balanceo NginX
7. ETCD y fleet

Pero, hasta el día de hoy, no he terminado de migrar este blog, de una solución monolítica con todo ubicado en un solo servidor, a un servicio escalable y repartido por varias geografías, sin ningún punto de falla sencillo (la redundancia rulea!!!). y lo mas importante

con Raspberry PI

Aunque podría entarle a algún servicio local de cloud, la idea es hacerlo con estas pequeñas computadoras, muy baratas, muy pequeñas y alcance de cualquiera.

les actualizare como voy, y luego les enseñare como se hace, pero mientras

Un Saludo