Comment auto-héberger DokuWiki en 2026 : stockage des fichiers, ACL et sauvegardes

Considérez DokuWiki comme un petit système, pas comme une image Docker. L’objectif côté utilisateur est clair : un wiki basé sur des fichiers qui n’a pas besoin de base de données ; le déploiement n’est acceptable que lorsque vous pouvez remplacer les identifiants de configuration, modifier une page, téléverser un média, appliquer une ACL, consulter une révision et restaurer une version antérieure.

Cette distinction permet de détecter le problème que les opérateurs rencontrent après les tests locaux : les permissions des fichiers empêchent l’enregistrement des pages alors que l’interface se charge correctement. Elle rend également le plan de sauvegarde et de mise à niveau suffisamment précis pour être testé.

Ports, processus et services privés

Commencez par l’espace de noms réseau de DokuWiki : son listener web utilise le port 80, et non un port hôte copié depuis un tutoriel réalisé sur un ordinateur portable. La contrainte d’exécution locale est un volume de configuration persistant contenant les pages, les médias et les ACL. Documentez la capacité attendue, les permissions et le mode de défaillance au lieu de laisser ces éléments dépendre des valeurs par défaut de l’image.

Une fois la contrainte satisfaite, exécutez le scénario complet — remplacer les identifiants de configuration, modifier une page, téléverser un média, appliquer une ACL, consulter une révision et restaurer une version antérieure. Consignez les logs et les mesures concernant les métadonnées du système de fichiers, le volume des médias, l’indexation de la recherche et les workers PHP. Ces éléments constituent la première architecture connue comme fonctionnelle et permettent de tester les déplacements ultérieurs entre le compute Dockup et un serveur raccordé.

Scénarios de défaillance pour DokuWiki

Un conteneur en état nominal est nécessaire, mais pas suffisant. L’indicateur de niveau de service est la réussite du scénario « remplacer les identifiants de configuration, modifier une page, téléverser un média, appliquer une ACL, consulter une révision et restaurer une version antérieure », tandis que les signaux de saturation probables sont les métadonnées du système de fichiers, le volume des médias, l’indexation de la recherche et les workers PHP.

La gestion des changements est importante, car les plugins et les templates peuvent prendre du retard sur les versions de DokuWiki, même si les simples fichiers de pages restent lisibles. Conservez l’ancienne image, testez les migrations sur un état copié et documentez si un rollback est pris en charge après l’évolution du schéma. Si les permissions des fichiers empêchent l’enregistrement des pages alors que l’interface se charge correctement, diagnostiquez la première limite qui diffère de l’environnement fonctionnel.

Documenter un déploiement DokuWiki connu comme fonctionnel

Une release candidate de DokuWiki mérite de recevoir du trafic lorsqu’elle réussit un scénario défini : remplacer les identifiants de configuration, modifier une page, téléverser un média, appliquer une ACL, consulter une révision et restaurer une version antérieure. Capturez le digest de l’image, la configuration effective non secrète, l’origine publique et les horodatages associés à ce scénario. Les données de test doivent être supprimables, tout en restant suffisamment réalistes pour emprunter le même parcours que les utilisateurs.

Exécutez ce scénario après avoir remplacé le runtime, puis reconstruisez le service à partir des pages, des médias, des métadonnées, des utilisateurs, des ACL et des plugins. La récupération est réussie lorsque les pages, les révisions, les médias, les utilisateurs, les ACL et les plugins sont restaurés et que la page protégée reste protégée. Comparez les mesures de ressources concernant les métadonnées du système de fichiers, le volume des médias, l’indexation de la recherche et les workers PHP avec celles de la version précédente, puis analysez tout écart significatif avant la mise en production.

Enfin, testez cette défaillance contrôlée : envoyez une entrée inoffensive proche de la limite de ressource ou de format associée à cette limite : les permissions des fichiers empêchent l’enregistrement des pages alors que l’interface se charge correctement. Vérifiez que DokuWiki explique la défaillance, ne corrompt pas l’état existant et reprend son fonctionnement lorsque la condition valide est rétablie. Conservez un extrait de log anonymisé ainsi que le temps de récupération. Ensemble, ces vérifications couvrent le comportement, la durabilité et l’exploitabilité, et pas seulement la disponibilité du processus.

Exécuter la première instance représentative de la production

Utilisez une commande qui expose chaque choix important. Cette configuration de référence lie DokuWiki à la loopback de l’hôte, ajoute les mounts de données connus et fournit le premier paramètre requis. Vérifiez la contrainte locale avant toute exposition : un volume de configuration persistant contenant les pages, les médias et les ACL.

docker run -d \
  --name dokuwiki \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v dokuwiki-data:/config \
  lscr.io/linuxserver/dokuwiki:latest

Remplacez les tags flottants par une version ou un digest testé. Après le démarrage, consultez docker logs --tail 200 dokuwiki et confirmez que le processus écoute sur le port 80. Exécutez ensuite l’action de validation DokuWiki ; une réponse de la page d’accueil ne peut pas prouver que le scénario complet fonctionne : remplacer les identifiants de configuration, modifier une page, téléverser un média, appliquer une ACL, consulter une révision et restaurer une version antérieure.

Les volumes ne constituent que la première couche de récupération

Pour DokuWiki, la sécurité d’un redéploiement commence par les pages, les médias, les métadonnées, les utilisateurs, les ACL et les plugins. Montez /config avant l’initialisation, écrivez des données d’exemple inoffensives et remplacez le conteneur afin de prouver que ce chemin est réellement persistant. Testez ce chemin en remplaçant le conteneur alors que les données d’exemple inoffensives existent encore ; cela révèle les mounts pointant un niveau de répertoire trop haut ou trop bas.

Testez ensuite la reprise après sinistre sur un hôte vierge. Utilisez si nécessaire un export de base de données cohérent avec l’application et vérifiez que les pages, les révisions, les médias, les utilisateurs, les ACL et les plugins sont restaurés et que la page protégée reste protégée. Le guide des sauvegardes de base de données dont la restauration a été testée fournit une cible plus exigeante que la simple vérification de la création d’un fichier d’archive.

Attribuer une adresse canonique à DokuWiki

L’émission du certificat TLS ne constitue que la moitié du routage de DokuWiki. Servez le wiki via HTTPS et définissez son URL de base canonique. Acheminez le trafic en interne vers le port 80 et transmettez le schéma externe afin que les URL générées et les cookies sécurisés restent cohérents.

Utilisez le scénario DokuWiki complet depuis un réseau vierge, et pas seulement la page d’accueil. Une erreur 502 ou un problème de certificat peut être isolé avec la configuration automatique du domaine et de TLS. Si le trafic atteint le processus et que les permissions des fichiers empêchent l’enregistrement des pages alors que l’interface se charge correctement, diagnostiquez cette condition à l’endroit où elle se produit au lieu d’empiler les redirections.

Fermer les accès temporaires de configuration

Modélisez les menaces liées à l’action effectuée par DokuWiki, et pas seulement à son formulaire de connexion. Ici, l’erreur à haut risque consiste à laisser l’installateur ou les paramètres d’inscription ouverts. Mettez en place cette limite : supprimez l’accès à l’installateur, vérifiez les inscriptions et préservez les fichiers ACL avec le contenu des pages.

DokuWiki n’a pas de secret d’initialisation obligatoire dans cette configuration de référence ; protégez plutôt son véritable compte administrateur ou l’authentification en amont. Ne résolvez pas une erreur de permissions en exécutant le conteneur en tant que root ou en montant largement le système de fichiers de l’hôte. Les limites de ressources font également partie de la conception de sécurité lorsque les utilisateurs peuvent déclencher les métadonnées du système de fichiers, le volume des médias, l’indexation de la recherche et les workers PHP.

Utiliser Dockup pour la couche plateforme

Un template Dockup doit encoder l’image, le port 80, les mounts, le délai de health check, le domaine, TLS et la distribution des secrets. Dockup doit préserver les paramètres du runtime DokuWiki tandis que l’opérateur confirme cette contrainte locale : un volume de configuration persistant contenant les pages, les médias et les ACL. Le même déploiement peut cibler des serveurs Dockup ou une capacité raccordée fournie par le client.

Une fois le routage actif, appliquez le paramètre public et essayez de remplacer les identifiants de configuration, de modifier une page, de téléverser un média, d’appliquer une ACL, de consulter une révision et de restaurer une version antérieure. Sauvegardez les pages, les médias, les métadonnées, les utilisateurs, les ACL et les plugins, puis conservez l’exercice de restauration dans le plan d’exploitation ; ces éléments relèvent de la responsabilité de DokuWiki et restent visibles après le provisionnement de l’infrastructure.

Foire aux questions

De quoi DokuWiki a-t-il besoin pour un déploiement en production ?

Acheminez le conteneur DokuWiki sur le port 80 via une origine HTTPS unique. La contrainte d’exécution locale est un volume de configuration persistant contenant les pages, les médias et les ACL. Ne considérez pas DokuWiki comme prêt tant que vous ne pouvez pas remplacer les identifiants de configuration, modifier une page, téléverser un média, appliquer une ACL, consulter une révision et restaurer une version antérieure.

Quelles données DokuWiki doivent figurer dans une sauvegarde ?

Rendez /config persistant et incluez les pages, les médias, les métadonnées, les utilisateurs, les ACL et les plugins dans le même manifest de récupération. Une restauration DokuWiki propre n’est réussie que lorsque les pages, les révisions, les médias, les utilisateurs, les ACL et les plugins sont restaurés et que la page protégée reste protégée.

DokuWiki a-t-il besoin de HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de DokuWiki et conservez le port 80 sur le routage interne. Appliquez correctement le paramètre DokuWiki : servez le wiki via HTTPS et définissez son URL de base canonique. Pour DokuWiki, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transit et garantit la cohérence du comportement client dépendant de l’origine.

Comment tester une mise à niveau de DokuWiki ?

Restaurez l’état actuel de DokuWiki dans un déploiement isolé, appliquez la version candidate et répétez sa transaction de validation. Soyez particulièrement attentif, car les plugins et les templates peuvent prendre du retard sur les versions de DokuWiki, même si les simples fichiers de pages restent lisibles. Conservez l’ancienne image DokuWiki jusqu’à ce que les limites de migration des données et de rollback soient comprises.