À propos du projet

Ce dépôt package un déploiement XWiki auto-hébergé en une seule pile Docker Compose. XWiki, une plateforme wiki d’entreprise, s’exécute derrière Traefik agissant comme proxy inverse, avec des certificats Let’s Encrypt émis automatiquement pour les noms d’hôte configurés. PostgreSQL 15 stocke les données du wiki. La configuration suit une courte séquence : cloner le dépôt, créer les deux réseaux Docker attendus (traefik-network et xwiki-network), copier .env.example en .env et remplir les valeurs requises (XWIKI_DB_PASSWORD, XWIKI_HOSTNAME, TRAEFIK_HOSTNAME, TRAEFIK_ACME_EMAIL, TRAEFIK_BASIC_AUTH), puis lancer la pile avec docker compose. Le README note que le premier démarrage prend plusieurs minutes pendant qu’XWiki initialise son schéma et ses pages de base, et liste les problèmes courants de premier déploiement tels que l’échec de l’émission du certificat parce que le DNS n’a pas propagé ou le port 80 n’est pas accessible, les erreurs de réseau dues à l’omission de l’étape de création du réseau, et les échecs de variable manquante. Un script update.sh déplace le checkout vers la dernière étiquette de release et relance docker compose up. Il refuse de franchir une version majeure sans surveillance, refuse de s’exécuter sur des modifications locales, et signale toute variable devenue requise depuis la version installée. Un drapeau --dry-run prévisualise l’action. Trois images officielles Docker Hub (traefik, xwiki, postgres) sont épinglées à des digests tag@sha256 en tant que valeurs par défaut d’interpolation, donc un simple git pull délivre la combinaison testée. Les niveaux de remplacement par image sont documentés : une variable de version échange uniquement l’étiquette sans digest, tandis qu’une variable d’étiquette remplace toute la référence. Les valeurs par défaut imbriquées nécessitent Docker Compose v2.5 ou plus récent. Un job CI quotidien ré-résout les épingles contre les registres et compare les versions épinglées de XWiki et Traefik avec les releases en amont ; les GitHub Actions sont épinglées par SHA de commit et maintenues fraîches par Dependabot. Les sauvegardes sont gérées par un conteneur dédié qui exécute un pg_dump pipé à travers gzip plus une archive tar.gz des données du wiki, puis élague les anciennes sauvegardes et s’endort. Les valeurs par défaut sont un échauffement de 30 minutes, un intervalle de 24 heures et une rétention de 7 jours. Deux scripts de restauration interactifs couvrent la base de données et les données de l’application. Le dépôt conseille de monter les volumes de sauvegarde sur l’hôte et de sauvegarder avant les mises à jour parce qu’XWiki migre son schéma lors des sauts de version. Le durcissement est appliqué uniformément : chaque service définit no-new-privileges, les conteneurs d’infrastructure abandonnent toutes les capacités et n’en ajoutent que celles nécessaires à leurs entrypoints (NET_BIND_SERVICE pour Traefik, CHOWN/SETUID/SETGID pour les images de base de données), tandis que les conteneurs d’application conservent délibérément l’ensemble de capacités par défaut. Chaque service porte des limites de mémoire et de CPU plus des réservations en tant que valeurs par défaut de compose, remplaçables via .env. Un workflow de Vérification du Déploiement s’exécute à chaque push, pull request et quotidiennement à 06:00 UTC, couvrant shellcheck, actionlint, les scans Trivy des trois images épinglées, la vérification de fraîcheur, et un job de déploiement-et-test qui démarre la pile avec des identifiants éphémères et exige que l’interface utilisateur du wiki réponde à travers Traefik. Un script de sauvegarde/restauration de bout en bout insère une ligne de marqueur, restaure la sauvegarde la plus ancienne et affirme que le marqueur a disparu ; il arrête brièvement le conteneur de base de données pour prouver la détection d’échec et est destiné au staging plutôt qu’à la production. Les notes de sécurité indiquent que les identifiants sont lus à partir d’un .env ignoré par git au moment du déploiement, que PostgreSQL écoute uniquement sur le réseau interne, et que les releases avant v1.0.0 ont livré un .env suivi avec un mot de passe de base de données de type généré qui devrait être tourné s’il est réutilisé.