=> De momento es así. Está en proyecto ver orquestación, probablemente con Kubernetes. El soporte para podman en lugar de docker-compose por ejemplo se está mejorando.

De todas formas, esa orquestación no es requerida para instalaciones pequeñas o medianas, en las que ese auto-contenido es más bien la preferencia ideal.

Sí, es cierto que es un ideal, pero también es cierto que kubernetes se ha convertido en estándar de facto.

En instalaciones pequeñas habría que valorar si un solo nodo microk8s compensa, tanto para desarrollo en local, para CI con Runboat, etc

Para producción ya sería cuestión de tener más o menos nodos microk8s unidos, que viene a ser como si federas varios clúster de kubernetes.

Yo sí estoy interesado en contribuir en vías de mejorarlo.

Estoy con microk8s en local, haciendo pruebas, y precisamente me falta una imagen custom como es Doodba sincronizada con otra de postgres. Creo que "Karl", tiene un k8s y utiliza Doodba como base, pero no tengo claro si es así ni cómo lo hace.

Quizá, en vez de kubernetes, os sea más fácil adaptar Doodba con Docker Swarm o como standalone.

En los tres casos, creo que portainer.io sería buena elección, puede gestionar, tanto un docker standalone, un k8s o microk8s, y un swarm.

Habría que investigarlo bien y comparar soluciones y ver viabilidad.

Sí, es cierto que en función de las necesidades es mejor lo necesario, justo y suficiente, jeje.

Viendo la improvisación profudizando en Doodba, enhorabuena, al final si no falla la red es que en mi local funciona, je, y la naturalidad del software espía confrontada con Paranoid-Odoo te la felicito sin que salten los cables.

Conceptualmente Doodba está claro que es fruto de mucha experiencia en Odoo.

Pero el almacenamiento resiliente y compartido y sincronización de BDs..., en el mundo k8s en el que ahora mismo no estoy al día...pero seguirá inmaduro, en principio k8s únicamente para gestionar workloads de CI/CD y de Aplicación ( como un Doodba ). La aproximación que hasta donde llegué se usa en producción, es un sidecar proxy autorizado contra un servicio gestionado de PostgreSQL, y desacoplas la capa de persistencia y aplicación, que no debería tener cuellos de botella en redes privadas de alta capacidad y con QoS en la misma región geográfica...

Pero sí, estoy de acuerdo con que depende de la dimensión del sistema, si aún es la útima milla el cuello de botella que percibe el usuario, que la nube sea óptima es imperceptible para el cliente/usuario.