← Volver al índice

Proyecto: Migración de ERP Odoo a Microservicios Contenedorizados

Docker Compose PostgreSQL 15 Apache Reverse Proxy SSL/TLS

Resumen Técnico: Documentación detallada de la arquitectura, persistencia de datos y despliegue del sistema ERP Odoo 16 mediante la contenedorización con Docker Compose, aislando la base de datos relacional en una red privada virtual y publicando el servicio con cifrado SSL automatizado a través de Apache.

1. Arquitectura Lógica de Aislamiento de Red

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.

graph LR User((Usuario Remoto)) -- HTTPS/443 --> Apache[Apache Proxy Inverso] subgraph "Servidor Host - Docker Network (Aislada)" Apache -- Port 8069 --> Odoo[Contenedor Odoo Web :8069] Odoo -- Port 5432 (Interno) --> DB[(Contenedor PostgreSQL :5432)] end style Apache fill:#ffecb3,stroke:#fbc02d,stroke-width:2px style Odoo fill:#e1bee7,stroke:#714b67,stroke-width:2px style DB fill:#b3e5fc,stroke:#0277bd,stroke-width:2px

2. Infraestructura como Código (Docker Compose)

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.

📄 docker-compose.yml (Stack Odoo + PostgreSQL)
version: '3.1' services: web: image: odoo:16.0 container_name: odoo_web depends_on: - db ports: - "127.0.0.1:8069:8069" # Expuesto solo a localhost para Apache volumes: - odoo-web-data:/var/lib/odoo - ./addons:/mnt/extra-addons environment: - HOST=db - USER=odoo - PASSWORD=tu_contrasena_segura restart: always db: image: postgres:15-alpine container_name: odoo_postgres environment: - POSTGRES_DB=postgres - POSTGRES_USER=odoo - POSTGRES_PASSWORD=tu_contrasena_segura volumes: - odoo-db-data:/var/lib/postgresql/data restart: always volumes: odoo-web-data: odoo-db-data:

3. Comandos de Despliegue y Operativa en Terminal

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*).

# 1. Crear directorio de trabajo para el proyecto
mkdir -p ~/docker-apps/odoo && cd ~/docker-apps/odoo
# 2. Crear y guardar el fichero docker-compose.yml
nano docker-compose.yml
# 3. Arrancar el stack en segundo plano
docker compose up -d
# 4. Verificar el estado de ejecución de los contenedores
docker compose ps
# 5. Monitorizar los logs en tiempo real para verificar la inicialización de la BD
docker compose logs -f

4. Configuración del Proxy Inverso (Apache VirtualHost)

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.

📄 /etc/apache2/sites-available/odoo-docker.conf
<VirtualHost *:80> ServerName miproyecto-erp.duckdns.org ErrorLog ${APACHE_LOG_DIR}/odoo-error.log CustomLog ${APACHE_LOG_DIR}/odoo-access.log combined # Enrutamiento Proxy Inverso hacia Docker ProxyPreserveHost On ProxyRequests Off ProxyPass / http://localhost:8069/ ProxyPassReverse / http://localhost:8069/ RequestHeader set "X-Forwarded-Proto" "https" </VirtualHost>

5. Automatización SSL/TLS (Certbot & Let's Encrypt)

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.

# 1. Habilitar la configuración en Apache
sudo a2ensite odoo-docker.conf
# 2. Generar certificado SSL e inyectar redirección HTTPS obligatoria
sudo certbot --apache -d miproyecto-erp.duckdns.org
# 3. Recargar el servidor web para aplicar los cambios de certificados
sudo systemctl reload apache2

6. Verificación de Criterios de Calidad de Infraestructura

Al finalizar el despliegue, la infraestructura cumple con las garantías fundamentales de un entorno de producción moderno:

← Volver a la portada ↑ Volver arriba
🏠