Docker Compose PostgreSQL 15 Apache Reverse Proxy SSL/TLS
En instalaciones tradicionales monolíticas, la aplicación web y el gestor de base de datos se ejecutan en el mismo sistema operativo compartiendo espacio de puertos. En nuestra arquitectura orientada a microservicios, desacoplamos la aplicación web Odoo 16 de la base de datos relacional PostgreSQL 15 en contenedores Docker independientes.
Ambos contenedores se comunican exclusivamente a través de una red privada virtual de Docker. El puerto 5432 de PostgreSQL no se expone hacia el servidor host ni hacia internet, impidiendo cualquier intento de conexión externa no autorizada a la base de datos relacional. El único punto de entrada autorizado es el Proxy Inverso Apache en el puerto seguro 443.
La especificación de servicios se declara en el fichero docker-compose.yml. Para garantizar la inalterabilidad de la información contable y los módulos personalizados, se utilizan volúmenes nombrados (odoo-web-data y odoo-db-data) que mapean las rutas de almacenamiento fuera del ciclo de vida del contenedor.
Además, se incluye el montaje de directorio ./addons:/mnt/extra-addons para permitir la inyección de módulos personalizados desarrollados en Python sin necesidad de reconstruir la imagen de Docker. La directiva restart: always garantiza que en caso de reinicio del servidor físico (Raspberry Pi / Linux), la pila de servicios vuelva a estar operativa de forma autónoma.
Secuencia de órdenes ejecutadas en la consola del servidor para la puesta en marcha de la infraestructura. El parámetro -d levanta los contenedores en segundo plano (modo desatendido o *detached*).
El servidor web Apache actúa como frontal seguro. Su responsabilidad es recibir las peticiones encaminadas al subdominio miproyecto-erp.duckdns.org por el puerto 80/443 y transmitirlas mediante ProxyPass hacia el servicio interno http://localhost:8069/.
La directiva ProxyPreserveHost On es crítica: asegura que el nombre de dominio original enviado por el usuario se transmita intacto a Odoo, lo que permite la correcta generación de enlaces de cookies de sesión, redirecciones y recursos estáticos.
Para cifrar las comunicaciones de extremo a extremo y proteger las credenciales de acceso de los usuarios del ERP, ejecutamos Certbot. El cliente de Certbot modifica automáticamente el VirtualHost de Apache, instala los certificados X.509 firmados por Let's Encrypt y añade una regla de redirección forzosa de HTTP a HTTPS.
Al finalizar el despliegue, la infraestructura cumple con las garantías fundamentales de un entorno de producción moderno:
restart: always asegura la recuperación automática ante caídas imprevistas del sistema o cortes de energía.