Operación y mantenimiento
Manual para el equipo de TI de la Academia Deltamontero. Cómo desplegar, configurar, respaldar, recuperar, vigilar y mantener la plataforma.
Esta sección es el manual de operación de la Academia Deltamontero (DELTA-APP), la plataforma de capacitación construida sobre Moodle 4.5 LTS. Está pensada para el equipo de TI que la despliega, la vigila y la recupera si algo falla.
La plataforma en una página
| Pieza | Qué es | Dónde vive |
|---|---|---|
moodle | Moodle 4.5 LTS con PHP 8.3 y Apache, con todos los plugins y parches incluidos en la imagen | Contenedor delta-lms_app (local) o el que nombre Coolify (producción) |
moodle-cron | La misma imagen, ejecutando el cron de Moodle cada 60 segundos | Contenedor delta-lms_cron |
mariadb | Base de datos MariaDB 11.4 | Contenedor delta-lms_db, volumen mariadb_data |
moodledata | Archivos subidos (PDF, imágenes, documentos) y cachés de Moodle | Volumen moodledata, compartido por moodle y moodle-cron |
traefik | Proxy inverso propio, solo para recuperación sin Coolify (perfil standalone) | Contenedor delta-lms_traefik |
| Coolify | Plataforma de despliegue en producción: construye la imagen, inyecta las variables de entorno y sirve la Academia con su propio Traefik | Servidor de producción (contenedor LXC de Proxmox 172246) |
| Cloudflare | Planificado: CDN y proxy público de learning.deltamontero.net. Todavía no está publicado | Externo |
Flujo de una visita en producción hoy: red interna de la empresa → http://192.168.0.192 → Traefik (de Coolify) → Moodle. Planificado: Cloudflare → learning.deltamontero.net → Traefik (de Coolify) → Moodle.
La regla que ordena toda la operación: la configuración es código y los datos son respaldo. Los ajustes del sitio, el tema, los permisos y las reglas de la Academia se vuelven a aplicar solos en cada arranque desde el repositorio. Lo que generan las personas (usuarios, avances, notas, certificados, archivos) vive en la base de datos y en moodledata, y eso es lo que se respalda.
Tareas frecuentes
| Necesito... | Dónde |
|---|---|
| Levantar la plataforma en mi equipo | Entorno local |
| Publicar una versión nueva en producción | Despliegue en producción |
| Saber qué variable de entorno hace qué | Variables de entorno |
| Entender qué pasa en cada arranque o por qué falló un paso | Arranque y actualizaciones |
| Actualizar Moodle o un plugin | Arranque y actualizaciones |
| Activar o revisar el respaldo diario | Respaldos |
| Configurar la copia fuera del servidor | Respaldos |
| Recuperar la Academia tras un desastre | Recuperación (DRP) |
| Ver qué pruebas de respaldo y recuperación se hicieron | Registro de pruebas |
| Saber si algo está fallando | Monitoreo y avisos |
| Recuperar el acceso de un super administrador | Accesos y cuentas de administración |
| Saber qué revisar cada día, semana, mes o año | Mantenimiento periódico |
| Resolver un problema conocido | Solución de problemas |
| Ver lo que falta por hacer en operación | Pendientes operativos |
Comandos de referencia
# Primer arranque o tras cambios en el Dockerfile
docker compose up -d --build
# Arranque normal (imagen ya construida)
docker compose up -d
# Registros en tiempo real
docker compose logs -f moodle
docker compose logs -f moodle-cron
# Parar sin destruir datos
docker compose down
# Reinicio total: DESTRUYE la base de datos y moodledata
docker compose down -v
# Consola dentro del contenedor
docker exec -it delta-lms_app bash
# CLI de Moodle
docker exec -it delta-lms_app php /var/www/html/admin/cli/purge_caches.php
docker exec -it delta-lms_app php /var/www/html/admin/cli/upgrade.php --non-interactive
# Respaldo manual (base + moodledata, con sha256; --keep N, --maintenance, --with-env)
./infrastructure/scripts/backup.sh ./backups
# Restauración (siempre primero --dry-run)
./infrastructure/scripts/restore.sh --dry-run ./backups/delta-lms_backup_YYYY-MM-DD_HHMMSS.tar
./infrastructure/scripts/restore.sh ./backups/delta-lms_backup_YYYY-MM-DD_HHMMSS.tarLos nombres delta-lms_app, delta-lms_cron y delta-lms_db son los del entorno local (o de una instalación sin Coolify). En producción Coolify les pone otros nombres (por ejemplo moodle-<uuid>). Los scripts de respaldo los encuentran solos por su etiqueta de servicio.
Objetivos de recuperación
| Indicador | Objetivo | Medido en prueba |
|---|---|---|
| RPO (pérdida máxima de datos) | 24 horas (un respaldo diario) | — |
| RTO (tiempo para volver a estar en línea) | Unas 2 horas, contando la construcción de la imagen | Unos 13 minutos desde cero (imagen 11 min + restauración 2 min), más el cambio de dirección |
Más información
Guía de cambios
Procedimientos para modificar y ampliar la plataforma - páginas, reglas, correos, tours, scripts, parches, plugins de terceros, versiones, pruebas locales y commits.
Levantar la Academia desde cero
Procedimiento completo y en orden para montar la arquitectura, cargar las variables del sistema (base de datos, correo, seguridad, IA) y restaurar un respaldo en un servidor nuevo.