Procedimiento de despliegue (Docker)
Pasos para publicar los componentes del Manifiesto de entrega en un entorno Moodle del
campus. Usa las variables del runbook (HOST, DST, WEB,
DB, OWNER…). Los comandos asumen ejecución remota vía SSH; en local, omite el prefijo
ssh -i "$KEY" "$HOST".
Plugins locales primero, bloques después, tema al final. El tema y los bloques consumen
clases de datos y Web Services de los plugins locales. Si se copia el árbol completo y se ejecuta
un solo upgrade.php, Moodle resuelve el orden automáticamente por las dependencias declaradas.
Paso 0 — Build de assets (condicional)
Solo si cambiaron theme/cdigital/amd/src/* o el SCSS del tema. Ver
Build de assets. El build se hace en local, antes de copiar;
nunca en el servidor destino. Si solo cambió SCSS, no hace falta build: se recompila en el destino
con purge_caches.php (Paso 4).
Paso 1 — Backup de base de datos
Obligatorio antes de cualquier upgrade.php.
ssh -i "$KEY" "$HOST" '
docker exec '"$DB"' sh -c "exec mariadb-dump -uroot -p\$MYSQL_ROOT_PASSWORD \
--single-transaction moodle" > ./moodle_dump_$(date +%Y%m%d_%H%M%S).sql
ls -lh moodle_dump_*.sql | tail -1
'
Este dump es un artefacto del propio $HOST: solo sirve de rollback para
este mismo despliegue, en este mismo ambiente. No se copia a otro ambiente ni
se usa para poblarlo — ver
qué NO incluye la entrega.
Paso 2 — Copiar el código
Ubica los componentes bajo public/local/, public/blocks/ y public/theme/. Con rsync
(entrega incremental), haz primero un dry-run y revisa que no haya borrados inesperados:
DIRS="local/pccntr8203403_dashboard local/pccntr8203403_aitutor \
blocks/pccntr8203403_logros blocks/pccntr8203403_atencion theme/cdigital"
for d in $DIRS; do
echo "=== DRY RUN: $d ==="
rsync -azn --delete --itemize-changes -e "ssh -i $KEY" "$SRC/$d/" "$HOST:$DST/$d/"
done
Si el dry-run es correcto (sin líneas *deleting inesperadas), aplica sin -n:
for d in $DIRS; do
rsync -az --delete --itemize-changes -e "ssh -i $KEY" "$SRC/$d/" "$HOST:$DST/$d/"
done
Si la entrega solo incluye un subconjunto de componentes, limita
DIRSa los directorios afectados.
Entrega por git: si el código llega por el repositorio, basta con
git pullde la rama de entrega dentro del árbol del docroot. El resto de pasos (propietario, upgrade, purga) es igual.
Paso 3 — Restaurar propietario
rsync/copia vía root crea archivos root:root. Re-aplica el esquema del árbol (OWNER,
dirs 755 / files 644):
ssh -i "$KEY" "$HOST" 'chown -R '"$OWNER"' \
'"$DST"'/local/pccntr8203403_dashboard \
'"$DST"'/local/pccntr8203403_aitutor \
'"$DST"'/blocks/pccntr8203403_logros \
'"$DST"'/blocks/pccntr8203403_atencion \
'"$DST"'/theme/cdigital && echo chown-OK'
Paso 4 — Upgrade + purga de cachés
upgrade.php registra el bump de versión del plugin/tema y, si aplica, los Web Services nuevos de
db/services.php. purge_caches.php recompila el SCSS del tema y recarga plantillas y strings
(necesario aunque el tema no cambie de versión).
ssh -i "$KEY" "$HOST" '
docker exec '"$WEB"' php /var/www/admin/cli/upgrade.php --non-interactive
docker exec '"$WEB"' php /var/www/admin/cli/purge_caches.php
'
Si el CSS/JS no refresca en el navegador, limpia la caché en disco y reinicia el contenedor web, luego vuelve a purgar:
ssh -i "$KEY" "$HOST" '
rm -rf $(dirname '"$DST"')/../moodledata/localcache \
$(dirname '"$DST"')/../moodledata/cache
docker restart '"$WEB"'
'
# esperar a que el contenedor levante, luego repetir purge_caches.php
Ajusta la ruta de
moodledataa la del entorno destino (en Pruebas:/opt/docker/apps/colombiaaprende/moodledata/).
Paso 5 — Activar el tema y ajustes
- Administración del sitio → Apariencia → Temas → confirmar que
cdigitales el tema activo. - Revisar los ajustes del tema (hero, feature cards, toggle del banner de curso) si la entrega los modifica.
Paso 6 — Verificación
Continúa con la verificación post-despliegue.
Referencia interna: el runbook original específico de Pruebas (con host, llave SSH y rutas concretas) se conserva en
pruebas/DESPLIEGUE_PRUEBAS.mddel repositorio. Esta página es su versión generalizada y entregable.