Sobre el proyecto

Este repositorio empaqueta un despliegue de XWiki auto-alojado como una única pila de Docker Compose. XWiki, una plataforma de wiki empresarial, se ejecuta detrás de Traefik actuando como proxy inverso, con certificados de Let's Encrypt emitidos automáticamente para los nombres de host configurados. PostgreSQL 15 almacena los datos del wiki. La configuración sigue una secuencia corta: clonar el repositorio, crear las dos redes de Docker esperadas (traefik-network y xwiki-network), copiar .env.example a .env y rellenar los valores requeridos (XWIKI_DB_PASSWORD, XWIKI_HOSTNAME, TRAEFIK_HOSTNAME, TRAEFIK_ACME_EMAIL, TRAEFIK_BASIC_AUTH), luego levantar la pila con docker compose. El README señala que el primer arranque tarda varios minutos mientras XWiki inicializa su esquema y páginas centrales, y enumera problemas comunes del primer despliegue, como la emisión de certificados que falla porque el DNS no ha propagado o el puerto 80 no es accesible, errores de red por omitir el paso de creación de la red, y fallas por variables faltantes. Un script update.sh mueve el checkout a la última etiqueta de release y vuelve a ejecutar docker compose up. Se niega a cruzar una versión mayor sin supervisión, se niega a correr sobre cambios locales, y reporta cualquier variable que se haya vuelto requerida desde la versión instalada. Una bandera --dry-run previsualiza la acción. Tres imágenes oficiales de Docker Hub (traefik, xwiki, postgres) están pinneadas a digestos tag@sha256 como valores por defecto de interpolación, así que un simple git pull entrega la combinación probada. Los niveles de anulación por imagen están documentados: una variable de versión cambia solo la etiqueta sin el digesto, mientras que una variable de etiqueta reemplaza toda la referencia. Los valores por defecto anidados requieren Docker Compose v2.5 o superior. Un trabajo de CI diario vuelve a resolver los pines contra los registros y compara las versiones pinneadas de XWiki y Traefik con las releases de upstream; las GitHub Actions están pinneadas por SHA de commit y se mantienen frescas por Dependabot. Las copias de seguridad son manejadas por un contenedor dedicado que ejecuta un pg_dump canalizado a través de gzip más un archivo tar.gz de los datos del wiki, luego purga las copias de seguridad antiguas y se duerme. Los valores por defecto son un calentamiento de 30 minutos, un intervalo de 24 horas y una retención de 7 días. Dos scripts de restauración interactivos cubren la base de datos y los datos de la aplicación. El repositorio aconseja montar los volúmenes de copia de seguridad en el host y hacer una copia de seguridad antes de las actualizaciones porque XWiki migra su esquema en los saltos de versión. El endurecimiento se aplica de manera uniforme: cada servicio establece no-new-privileges, los contenedores de infraestructura dejan caer todas las capacidades y añaden solo lo que sus entrypoints necesitan (NET_BIND_SERVICE para Traefik, CHOWN/SETUID/SETGID para las imágenes de base de datos), mientras que los contenedores de aplicación mantienen el conjunto de capacidades por defecto deliberadamente. Cada servicio lleva límites de memoria y CPU más reservas como valores por defecto de compose, anulables a través de variables de .env. Un flujo de trabajo de Verificación de Despliegue se ejecuta en cada push, pull request y diariamente a las 06:00 UTC, cubriendo shellcheck, actionlint, escaneos de Trivy de las tres imágenes pinneadas, la comprobación de frescura, y un trabajo de despliegue-y-prueba que arranca la pila con credenciales efímeras y requiere que la UI del wiki responda a través de Traefik. Un script de copia de seguridad/restauración de extremo a extremo inserta una fila de marcador, restaura la copia de seguridad más antigua y afirma que el marcador ha desaparecido; detiene brevemente el contenedor de la base de datos para probar la detección de fallas y está destinado para staging más que para producción. Las notas de seguridad indican que las credenciales se leen de un .env ignorado por git en el momento del despliegue, que PostgreSQL escucha solo en la red interna, y que las releases antes de v1.0.0 enviaron un .env rastreado con una contraseña de base de datos de aspecto generado que debería ser rotada si se reutiliza.