Controlador de red TP-Link Omada, migrado de un servidor con CloudPanel a un contenedor Docker en Oracle Cloud, gestionado vía Dokploy.
| Campo | Valor |
|---|---|
| URL de acceso | https://omada.managuanetworks.com:8043 |
| Versión actual | 6.2.10.17 |
| Imagen Docker | mbentley/omada-controller (imagen de la comunidad, no oficial de TP-Link) |
| Arquitectura del servidor | ARM64 (Oracle Ampere) — la imagen soporta multi-arch |
Servicio tipo Compose en Dokploy, con un solo contenedor (MongoDB corre embebido dentro del mismo contenedor desde la v5.14+ de la imagen mbentley, no como contenedor aparte).
services:
omada-controller:
image: mbentley/omada-controller:6.2.10.17
container_name: omada-controller
restart: unless-stopped
ulimits:
nofile:
soft: 4096
hard: 8192
stop_grace_period: 60s
environment:
- TZ=America/Santo_Domingo
- MANAGE_HTTP_PORT=8088
- MANAGE_HTTPS_PORT=8043
- PORTAL_HTTP_PORT=8088
- PORTAL_HTTPS_PORT=8843
- PORT_APP_DISCOVERY=27001
- PORT_DISCOVERY=29810
- PORT_MANAGER_V1=29811
- PORT_ADOPT_V1=29812
- PORT_UPGRADE_V1=29813
- PORT_MANAGER_V2=29814
- PORT_TRANSFER_V2=29815
- PORT_RTTY=29816
- PORT_DEVICE_MONITOR=29817
- SSL_CERT_NAME=tls.crt
- SSL_KEY_NAME=tls.key
volumes:
- omada_data:/opt/tplink/EAPController/data
- omada_logs:/opt/tplink/EAPController/logs
- omada_work:/opt/tplink/EAPController/work
- /opt/omada-certs:/cert:ro
ports:
- target: 8088
published: 8088
protocol: tcp
mode: host
- target: 8043
published: 8043
protocol: tcp
mode: host
- target: 8843
published: 8843
protocol: tcp
mode: host
- target: 27001
published: 27001
protocol: udp
mode: host
- target: 29810
published: 29810
protocol: udp
mode: host
- target: 29811
published: 29811
protocol: tcp
mode: host
- target: 29812
published: 29812
protocol: tcp
mode: host
- target: 29813
published: 29813
protocol: tcp
mode: host
- target: 29814
published: 29814
protocol: tcp
mode: host
- target: 29815
published: 29815
protocol: tcp
mode: host
- target: 29816
published: 29816
protocol: tcp
mode: host
- target: 29817
published: 29817
protocol: tcp
mode: host
volumes:
omada_data:
omada_logs:
omada_work:
Nota sobre mode: host: necesario porque Dokploy usa Docker Swarm por debajo — sin mode: host, el ingress mesh de Swarm rompe el discovery UDP de dispositivos y el reconocimiento correcto de IPs de origen.
Omada gestiona su propio SSL internamente (Tomcat/Java) en el puerto 8043. Usar Traefik como proxy encima causa loops de redirección con los WebSockets que usa la interfaz (estado en tiempo real, terminal remoto SSH vía RTTY). En su lugar, se monta un certificado real de Let's Encrypt directo en el contenedor vía las variables SSL_CERT_NAME / SSL_KEY_NAME y el volumen /opt/omada-certs.
| Volumen | Tamaño aprox. |
|---|---|
omada_data |
~600MB |
omada_logs |
~2MB |
omada_work |
0B (no persiste nada relevante) |
Dentro del propio Omada (no vía Dokploy): Settings → Maintenance → Backup Schedule
| Configuración | Valor |
|---|---|
| Occurrence | Diario, 1:50 AM hora Caracas |
| Backup Contents | Settings, User Info, Authenticated Clients, Firmware Update Logs, Client List, Alert & Event List, Audit Log List |
| Retained Data Backup | 30 días |
| Storage | Save to Local File (mismo path que el software del controlador) |
| Maximum Number of Files | 7 |
Los archivos quedan en: /opt/tplink/EAPController/data/autobackup/ dentro del contenedor (ruta real en el host: /var/lib/docker/volumes/<nombre-volumen>_omada_data/_data/autobackup/).
Script en el servidor (fuera de Dokploy):
# /opt/backup-omada-r2.sh
#!/bin/bash
rclone sync /var/lib/docker/volumes/omada-controller-omada-6hpsq6_omada_data/_data/autobackup r2:omada-backups/omada-cfg \
--s3-no-check-bucket \
--log-file=/var/log/omada-backup-r2.log
Programado en cron (ejecuta después del backup interno de Omada, con margen de seguridad):
sudo crontab -e
# 15 6 * * * /opt/backup-omada-r2.sh
# (6:15 AM UTC = 2:15 AM Caracas, 25 min después del backup de la 1:50 AM Caracas)
Advertencia de nombre de volumen: el nombre del volumen incluye un sufijo aleatorio que Dokploy genera (ej. omada-controller-omada-6hpsq6_omada_data) y cambia si el servicio se recrea en Dokploy. Verificar el nombre actual antes de asumir que el script sigue apuntando al volumen correcto:
sudo docker volume ls | grep omada
.cfg más reciente desde R2:sudo rclone copy r2:omada-backups/omada-cfg/<archivo>.cfg .
.cfgomada.managuanetworks.com) sigue siendo el mismoSe evaluó y se descartó: el volumen completo pesa ~600MB por snapshot vs ~900KB del .cfg nativo — con la misma retención (7 días), el volumen completo consumiría ~4.2GB de los 10GB gratis de R2, sin aportar protección adicional real (la diferencia son logs y archivos temporales que no hace falta conservar).
Settings → Maintenance → Backup & Restore → Backup.cfg del viejoGlobal View → Settings → Migration → Site Migration → Migrate Devices
https:// ni puerto — ej. omada.managuanetworks.com (formato confirmado por prueba directa)Un salto de versión mayor de Omada implica una migración de MongoDB (3.6 → 8.0), que no es automática — requiere un contenedor especial de migración antes de cambiar la imagen.
# 1. Detener el controlador
sudo docker stop -t 60 omada-controller
# 2. Backup del volumen completo (por seguridad extra)
sudo docker run --rm -v <volumen>:/data -v $(pwd):/backup alpine \
tar czf /backup/omada-data-backup-$(date +%Y%m%d).tar.gz /data
# 3. Migración de MongoDB 3.6 → 8.0 (dentro de un contenedor especial)
sudo docker run -it --rm \
-e DEBUG=false \
-v <volumen>:/opt/tplink/EAPController/data \
mbentley/omada-controller:mongodb-upgrade-3.6-to-8
# 4. Cambiar el tag de imagen en el Compose (Dokploy) a la versión nueva y Deploy
Requisito de CPU en ARM: MongoDB 8 requiere soporte ARMv8.2-a. Verificar antes de migrar:
grep -o 'asimd\|sve\|Features.*' /proc/cpuinfo | head -5
```//
Las instancias Ampere Altra de Oracle Cloud cumplen este requisito.
## Adopción de equipos remotos (dispositivos en redes de clientes)
El controlador está en la nube (Oracle), pero los equipos (APs/switches) están en las redes locales de cada cliente — nunca en la misma LAN que el controlador. Esto significa que el **discovery automático por broadcast UDP nunca funciona** para ellos (el broadcast no cruza routers/internet).
### Flujo recomendado (usando la app móvil de Omada)
1. Vincular el controlador a una cuenta **TP-Link ID** (`Settings → Cloud Access`)
2. En el sitio del cliente, conectar el celular/laptop a la red local y abrir la app Omada — descubre los equipos por broadcast local, como siempre
3. Elegir el **controlador en la nube** (vinculado por TP-Link ID) como destino de adopción, en vez de uno local
4. El equipo aparece como "Pending" en el controlador de Oracle → **Adopt**
### Flujo manual (por SSH/CLI, sin la app)
```bash
set-controller-inform-url http://omada.managuanetworks.com:8088/api/info