El servidor Redis vive fuera (recurso gestionado por Coolify); el app se
conecta vía REDIS_HOST. El servicio redis local era un contenedor muerto.
La extensión PHP phpredis se sigue compilando en la imagen (es el cliente).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Dos despliegues que comparten el mismo Redis pisaban las sesiones.
session.save_path ahora incluye &database=${REDIS_DB} (default 0).
Despliegue secundario usa REDIS_DB=1.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El contenedor Redis (zqmfom0vw6nj3ae66mkwxek1) vive en la red 'coolify'.
La app estaba solo en la red nj05x5... → DNS SERVFAIL → health.php tardaba
10-12s intentando conectar → healthcheck timeout → unhealthy → 'no available server'.
Solución: declarar red coolify como external y conectar el servicio app.
Fix inmediato aplicado manualmente con: docker network connect coolify <container>
06_master_sync.sql:
- Comentario tenía ';' (La columna role_id ya existe; la FK) →
el parser de migrate.php divide por ; y el texto 'la FK' quedaba
como sentencia SQL → error SQLSTATE[42000]
docker-compose.yml:
- Eliminar whatsapp-network (red bridge propia)
- Con 1 solo servicio no se necesita red interna
- Coolify añade automáticamente su red nj05x5... (donde está Traefik)
- La red bridge extra podría interferir con el routing de Traefik
health.php:
- DB fallo → 'warning' (no 'unhealthy', no cierra tráfico Traefik)
- Redis ya era warning desde commit anterior
docker-compose.yml:
- timeout: 5s → 10s (DB externa puede tardar más)
- start_period: 40s → 60s (tiempo suficiente para that migrations corran)
- fallback: si health.php falla, intenta / raíz antes de marcar unhealthy
- Eliminar container_name (Coolify asigna su propio nombre, conflicto evitado)
- Eliminar ./:/var/www/html (bind mount sobreescribía código del contenedor en prod)
- Eliminar ./logs y ./uploads bind mounts (reemplazados por named volumes)
- Eliminar php-socket volume (ya no se usa)
- Usar named volumes app-logs/app-uploads (persistencia correcta en Coolify)
- Redis ahora es un Database Resource externo en Coolify
Configurar: REDIS_HOST, REDIS_PORT, REDIS_PASSWORD en env vars
- Worker corre dentro del contenedor app via Supervisor (no servicio aparte)
- Eliminados: servicio redis, worker, redis-commander, volumenes db-data/redis-data
- Solo queda: servicio app + volumen php-socket
- entrypoint.sh: Redis wait tenía loop infinito sin timeout → el contenedor
se quedaba colgado para siempre si Redis tardaba, causando 504 Gateway Timeout
Ahora tiene MAX_RETRIES=15 (30s) y continúa aunque Redis no esté disponible
- entrypoint.sh: removido set -e para que errores no-críticos (permisos,
SSL, etc.) no maten el arranque del contenedor
- docker-compose.yml: removido depends_on redis con condition:service_healthy
Docker bloqueaba el inicio de app hasta que Redis estuviera healthy,
lo que podía exceder el timeout de Traefik
El archivo docker-compose.yml es el que usa Coolify por defecto.
Con 'ports: 8080:80' Traefik no sabía a qué puerto rutear en cada
redeploy. Con 'expose: 80' Traefik detecta el puerto 80 del contenedor
directamente (igual que docker-compose.prod.yml).
Para desarrollo local usar: docker-compose -f docker-compose.dev.yml up
