# Despliegue Docker

Este paquete queda listo para:

1. subir el `.zip` al servidor,
2. descomprimirlo,
3. configurar `.env`,
4. ejecutar `install.sh`.

## Requisitos del servidor

- Docker Engine
- Docker Compose Plugin (`docker compose`)
- Al menos 8 GB de RAM recomendados
- Espacio suficiente para:
  - imagen Docker,
  - volumen persistente `/data`,
  - indices FAISS,
  - logs y documentos cargados

## Estructura

- `Dockerfile`
- `docker-compose.yml`
- `.env.example`
- `.python-version`
- `install.sh`
- `up.sh`
- `down.sh`
- codigo de aplicación y archivos de datos

MongoDB y Redis se ejecutan dentro del contenedor de la aplicación usando `supervisord`.

## Instalación rápida

```bash
chmod +x install.sh up.sh down.sh
cp .env.example .env
nano .env
./install.sh
```

Luego abre:

```text
http://IP_DEL_SERVIDOR:7000
```

Si subes el proyecto completo en vez del paquete `dist`, no copies `.venv`, `dist`, `logs`, caches ni cargas temporales al servidor.

## Variables mínimas a cambiar

- `SECRET_KEY`
- `ADMIN_PASSWORD`
- `MONGO_APP_PASSWORD`
- `GROQ_API_KEY` o `GEMINI_API_KEY`

El despliegue Docker activa además estas variables por defecto:

```env
EPICRISIS_AUTO_WARMUP=1
EPICRISIS_WARMUP_RESOURCES=cie10,cups,soat
```

El warmup es obligatorio para los recursos enumerados: si alguno no termina en estado `ready`, el
entrypoint cancela el arranque antes de iniciar la aplicación. Al actualizar un servidor existente, edita
su `.env`; copiar una nueva versión de `.env.example` no modifica el archivo ya configurado.

## Operación

Levantar:

```bash
./up.sh
```

Detener:

```bash
./down.sh
```

Ver logs:

```bash
docker compose logs -f
```

Estado:

```bash
docker compose ps
curl http://127.0.0.1:7000/health
curl http://127.0.0.1:7000/ready
```

En los logs de un arranque correcto deben aparecer:

```text
cie10: ready
cups: ready
soat: ready
```

`/health` debe reportar `services.cie10_resource.details.available=true`; después de usar el recurso en
el proceso web también reportará `loaded=true`. `/ready` debe responder con estado `ready`.

## Persistencia

Los datos persisten en el volumen Docker:

- `epicrisis-data`

Incluye:

- MongoDB
- Redis appendonly
- logs
- uploads batch e individuales
- indices FAISS persistidos dentro de `/data/runtime`

## Actualizacion

Para actualizar el sistema:

1. sube una nueva version del paquete,
2. reemplaza los archivos del directorio,
3. conserva `.env`,
4. ejecuta:

```bash
docker compose down
docker compose build --no-cache
docker compose up -d
```

Después de reconstruir, revisa el warmup y los endpoints de estado:

```bash
docker compose logs epicrisis
curl http://127.0.0.1:7000/health
curl http://127.0.0.1:7000/ready
```

Si el contenedor no inicia, busca en los logs un recurso con estado `error:*` o `skipped`. No regeneres
los índices con otro usuario dentro del contenedor: la imagen los construye con `epicrisis` y conserva el
modelo de embeddings en una caché de Hugging Face compartida y legible durante el runtime.

Como verificación funcional final, procesa una historia clínica nueva sin códigos CIE-10 inline, genera
su epicrisis y confirma que contiene los diagnósticos codificados. La corrección no repara documentos ni
cachés de epicrisis creados antes de reconstruir la imagen.

## Observaciones

- El worker Celery ya queda levantado dentro del contenedor.
- En Linux el pool de Celery usa `prefork`, que es adecuado para servidor.
- El contenedor arranca MongoDB temporalmente para bootstrap, migraciones y usuario de aplicación; luego levanta el stack estable con `supervisord`.
- El paquete limpio de despliegue se genera con `python scripts/build_docker_bundle.py`.
