Arranque y actualizaciones

La Academia se configura sola: cada vez que arranca el contenedor moodle (primer despliegue, Redeploy, reinicio o restauración) vuelve a aplicar toda la configuración desde el código. Esta página explica ese proceso y cómo actualizar las versiones fijadas.

Construcción de la imagenCopy Anchor Link

La imagen delta-lms/moodle:4.5 se construye con infrastructure/moodle/Dockerfile:

1. Parte de moodlehq/moodle-php-apache:8.3 e instala git, curl, python3 y las librerías de Python del importador de documentos (pypdf, python-docx, openpyxl).
2. Ajusta PHP y Apache para producción: errores al registro y no a la pantalla, memory_limit=512M, subidas de hasta 512 MB, max_execution_time=300, zona horaria America/Guayaquil y carpetas de desarrollo (behat, vendor, node_modules, .git) inaccesibles desde la web.
3. Hace que el contenedor prefiera IPv4 (/etc/gai.conf), porque el servidor no tiene salida IPv6 y el correo de Office 365 fallaba con "Network is unreachable".
4. Descarga Moodle y los plugins de terceros en versiones fijas (ver la tabla de versiones más abajo).
5. Copia los scripts de arranque, los logos, las fuentes, el inventario de contenidos, los plugins propios, las traducciones y los scripts de respaldo (en /opt/delta-lms).
6. Aplica los parches al código de Moodle y de los plugins y ejecuta verify-patches.php: si un parche importante no quedó aplicado, la construcción falla.

Qué pasa en cada arranqueCopy Anchor Link

Contenedor moodle (entrypoint.sh)Copy Anchor Link

Contenedor moodle-cron (cron-entrypoint.sh)Copy Anchor Link

1. Genera el mismo config.php con write-config.sh (los dos contenedores usan siempre el mismo).
2. Espera a que exista la tabla mdl_config (es decir, a que moodle termine de instalar), reintentando cada 10 segundos.
3. Ejecuta admin/cli/cron.php cada 60 segundos, para siempre.
4. Cada ejecución correcta escribe la hora en /tmp/cron-last-ok, que usa el control de salud.

El cron nunca tumba su contenedor: si una ejecución falla, escribe !!! [cron] ERROR en el registro, sigue reintentando y el control de salud lo marca unhealthy. Si Moodle responde upgrade pending durante 10 minutos seguidos, el registro avisa que la imagen del cron no coincide con la del sitio y que hay que redesplegar.

moodle-config.sh: ajustes y pasosCopy Anchor Link

moodle-config.sh es idempotente: sobrescribe cada valor en cada arranque. Tiene dos tipos de instrucciones.

Ajustes directosCopy Anchor Link

Se aplican con admin/cli/cfg.php: idioma (es), zona horaria (America/Guayaquil), país (EC), tema Boost Union con los colores y estilos de Deltamontero, cabecera HTML adicional (fuentes, chat de IA, ajustes de interfaz), seguridad, archivos, correo, rendimiento, cursos, calificaciones, editor, H5P, certificados, nombre del sitio, servicios web y la recompilación del tema.

Ajustes de seguridad relevantes para TI:

Pasos críticos y cosméticosCopy Anchor Link

Los scripts de la Academia se ejecutan con la función step:

step <critico|cosmetico> "<descripción>" <comando…>

Un paso que falla nunca detiene el arranque, pero tampoco falla en silencio: muestra las últimas 25 líneas de su salida en el registro y anota la descripción en la lista de errores del despliegue.

• critico: permisos, seguridad, certificados o reglas. En el registro aparece !!! ERROR en un paso de seguridad del despliegue: <descripción>.
• cosmetico: aspecto y textos. En el registro aparece ! Aviso: falló un paso no crítico: <descripción>.

Pasos actuales, en orden de ejecución:

Al final, moodle-config.sh guarda el resultado en la configuración de Moodle y purga las cachés:

Cómo ver los errores de despliegueCopy Anchor Link

docker compose logs -f moodle

php /configure-mail.php

Versiones fijadasCopy Anchor Link

Moodle y los plugins de terceros están fijados a un commit exacto con git-at (un script que clona solo ese commit). Así la imagen tiene siempre las mismas versiones: un cambio del autor de un plugin no rompe la imagen ni desactiva en silencio un parche.

Imágenes de los demás servicios: mariadb:11.4 y traefik:v3 (etiquetas, no commits).

Parches verificadosCopy Anchor Link

Durante la construcción se aplican parches al código de Moodle y de los plugins. verify-patches.php comprueba que estos ocho quedaron aplicados (si falta uno, la construcción falla):

Otros tres parches son cosméticos y nunca detienen la construcción: botón de copiar y datos para borrar chats (patch-ai-chat-copy.php, patch-ai-chat-ui.php) y completado de video sin animación de felicitación (patch-video-completion.php).

Actualizar Moodle y los pluginsCopy Anchor Link

docker compose build moodle
docker compose up -d
docker compose logs -f moodle

/opt/delta-lms/infrastructure/scripts/backup.sh /var/backups/delta-lms

Política de actualizacionesCopy Anchor Link

El plan del proyecto (docs/roadmap_v4.md §3.3) propone:

• Automático: solo los parches de seguridad del sistema operativo del servidor (unattended-upgrades limitado al canal de seguridad).
• Manual, con aprobación de TI y en una ventana trimestral: kernel, versión mayor del sistema operativo, imágenes Docker (Moodle, MariaDB) y plugins, siempre probando antes en local.

Si esta política ya está aplicada en el servidor: Por confirmar con TI.