Comment auto-héberger Shiori en 2026 : archives, comptes et stockage persistant

Un déploiement Shiori défaillant ne tombe pas toujours en panne. Il peut afficher une page de connexion alors que l’archivage échoue à cause de dépendances Chromium manquantes ou de permissions incorrectes sur le système de fichiers. Commencez plutôt par un contrôle de bout en bout : enregistrez un signet avec son contenu archivé, recherchez-le, modifiez ses tags et vérifiez que l’archive reste disponible après la modification de la page source.

Ce contrôle correspond à la vocation répertoriée de Shiori : un gestionnaire de signets qui archive le contenu des pages. Il permet également de détecter plus tôt les dépendances manquantes, les hypothèses incorrectes concernant le proxy et les données éphémères, bien plus efficacement qu’un simple contrôle de disponibilité.

Définir la frontière d’exécution de Shiori

La santé du processus et celle du produit sont deux choses distinctes pour Shiori. Le port 8080 peut répondre alors que la transaction côté utilisateur échoue toujours. Le besoin externe de Shiori est un volume de données accessible en écriture et un accès sortant aux pages à archiver. Testez le DNS sortant, le TLS et le comportement du fournisseur sans publier un autre service entrant.

Utilisez cet exercice de readiness après toute modification significative de la configuration : enregistrez un signet avec son contenu archivé, recherchez-le, modifiez ses tags et vérifiez que l’archive reste disponible après la modification de la page source. Gardez les contrôles externes coûteux hors des sondes de liveness afin qu’une panne du fournisseur ne provoque pas une boucle de redémarrage. Le suivi de la capacité doit porter sur la capture des pages via le navigateur, la taille des archives, les miniatures et les requêtes sortantes, qui reflètent mieux les contraintes réelles de Shiori que les requêtes de page.

Restaurer Shiori sur un hôte vide

Répertoriez l’état nécessaire avant de créer le premier enregistrement réel : base de données, contenu des pages archivées, miniatures et configuration. Montez /shiori avant le bootstrap, écrivez des données d’exemple inoffensives, puis remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Confirmez le montage en écrivant des données inoffensives, en remplaçant Shiori, puis en les relisant.

Les snapshots sont utiles pour revenir rapidement en arrière, mais une sauvegarde indépendante est nécessaire si l’hôte ou le volume disparaît. Effectuez la restauration dans un environnement vide avec l’image versionnée et vérifiez que les signets, les tags, les fichiers d’archive et les comptes sont récupérés, et qu’un lien source mort ouvre toujours son contenu enregistré. Utilisez les volumes persistants et les snapshots pour bien distinguer ces deux mécanismes de récupération.

Décisions de sécurité propres à Shiori

Le risque de sécurité propre à l’application consiste à conserver le compte initial sur une instance publique. La réponse opérationnelle consiste à remplacer le compte initial, à limiter le partage public et à traiter les URL privées archivées comme du contenu sensible. Terminez le bootstrap via une route restreinte et supprimez immédiatement l’accès temporaire à la configuration.

SHIORI_DIR contrôle le comportement, pas la confidentialité ; validez son type et sa valeur, et stockez les véritables identifiants Shiori séparément. N’accordez au processus Shiori que les montages et les routes de dépendances documentés ; évitez tout accès à la racine de l’hôte et au socket Docker. Journalisez les échecs d’authentification et les erreurs de configuration, mais masquez les tokens, les chaînes de connexion et le contenu utilisateur.

Procédure d’acceptation de Shiori en production

Une release candidate de Shiori mérite de recevoir du trafic lorsqu’elle termine un scénario défini : enregistrer un signet avec son contenu archivé, le rechercher, modifier ses tags et vérifier que l’archive reste disponible après la modification de la page source. 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 de la base de données, du contenu des pages archivées, des miniatures et de la configuration. La récupération est validée lorsque les signets, les tags, les fichiers d’archive et les comptes sont restaurés, et qu’un lien source mort ouvre toujours son contenu enregistré. Comparez les mesures de ressources liées à la capture des pages via le navigateur, à la taille des archives, aux miniatures et aux requêtes sortantes avec celles de la version précédente, puis examinez tout écart significatif avant la mise en production.

Enfin, provoquez cet incident contrôlé : refusez temporairement l’accès au chemin de test utilisé par un volume de données accessible en écriture ainsi qu’aux pages à archiver accessibles en sortie. Vérifiez que Shiori explique l’échec, n’endommage pas l’état existant et reprend son fonctionnement dès que la condition valide est rétablie. Enregistrez un extrait de log expurgé et le temps de récupération. Ensemble, ces contrôles couvrent le comportement, la durabilité et l’exploitabilité, et pas uniquement la disponibilité du processus.

Lancer Shiori avec des valeurs par défaut observables

Conservez une invocation initiale de Shiori suffisamment reproductible pour pouvoir être examinée dans une pull request.

docker run -d \
  --name shiori \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v shiori-data:/shiori \
  -e SHIORI_DIR=/shiori \
  ghcr.io/go-shiori/shiori:latest

Ne vous fiez pas à latest une fois que de véritables données existent. Notez le digest utilisé, l’utilisateur du conteneur et la propriété du montage. Suivez le log de l’application pendant un test complet — enregistrez un signet avec son contenu archivé, recherchez-le, modifiez ses tags et vérifiez que l’archive reste disponible après la modification de la page source — et relevez toute migration avant d’exposer la route au trafic de production.

Domaines, en-têtes du proxy et port 8080

Considérez l’URL externe de Shiori comme une configuration qui doit survivre aux redéploiements. Commencez par faire passer l’UI et l’API par une origine HTTPS stable ; acheminez ensuite le hostname vers le port 8080 en conservant l’hôte et le schéma d’origine.

La checklist d’accessibilité du déploiement permet de prouver que les requêtes atteignent le conteneur. Après cette étape, le problème connu — l’archivage échoue parce que des dépendances Chromium manquent ou que les permissions du système de fichiers sont incorrectes — doit être recherché dans Shiori, son état ou sa charge de travail, et non dans l’automatisation des certificats.

Mettre à niveau Shiori sans deviner

La première métrique opérationnelle utile pour Shiori est sa capacité à enregistrer un signet avec son contenu archivé, à le rechercher, à modifier ses tags et à vérifier que l’archive reste disponible après la modification de la page source. Associez-la à des signaux de saturation concernant la capture des pages via le navigateur, la taille des archives, les miniatures et les requêtes sortantes. Une sonde limitée au processus ne doit pas appeler de dépendances coûteuses ni redémarrer le conteneur parce qu’un service amont est momentanément indisponible.

Considérez les mises à niveau comme des modifications de données, car les migrations de base de données de Shiori et les dépendances de capture des pages peuvent modifier le comportement des archives. Épinglez les versions, répétez la procédure sur un état restauré et conservez l’image précédente jusqu’à ce qu’un rollback reste possible. Lorsque l’archivage échoue parce que des dépendances Chromium manquent ou que les permissions du système de fichiers sont incorrectes, conservez les logs précédant le redémarrage ; ils contiennent généralement le message à l’origine du problème.

Ce que Dockup devrait automatiser pour Shiori

La couche de plateforme de Shiori comprend le port 8080, l’ingress, le TLS, la configuration du runtime, le stockage et l’accessibilité des dépendances. Dockup peut reproduire ces éléments pour sa propre infrastructure ou pour un serveur connecté par le client.

L’opérateur termine ensuite la couche produit : faire passer l’UI et l’API par une origine HTTPS stable ; appliquer cette règle d’accès — remplacer le compte initial, limiter le partage public et traiter les URL privées archivées comme du contenu sensible ; puis exécuter « enregistrer un signet avec son contenu archivé, le rechercher, modifier ses tags et vérifier que l’archive reste disponible après la modification de la page source ». Enregistrer ce test avec le déploiement évite de confondre le provisioning automatisé avec la readiness de l’application.

Foire aux questions

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

Acheminez le conteneur Shiori sur le port 8080 via une seule origine HTTPS. Le besoin externe pour servir Shiori est un volume de données accessible en écriture et un accès sortant aux pages à archiver. Ne considérez pas Shiori comme prêt avant de pouvoir enregistrer un signet avec son contenu archivé, le rechercher, modifier ses tags et vérifier que l’archive reste disponible après la modification de la page source.

Quelles données Shiori doivent figurer dans une sauvegarde ?

Conservez /shiori et incluez la base de données, le contenu des pages archivées, les miniatures et la configuration dans le même manifeste de récupération. Une restauration propre de Shiori n’est validée que lorsque les signets, les tags, les fichiers d’archive et les comptes sont récupérés, et qu’un lien source mort ouvre toujours son contenu enregistré.

Shiori nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de Shiori et conservez le port 8080 sur la route interne. Appliquez correctement le paramètre Shiori : faites passer l’UI et l’API par une origine HTTPS stable. Pour Shiori, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transport et garantit un comportement cohérent côté client, sensible à l’origine.

Comment tester une mise à niveau de Shiori ?

Restaurez l’état actuel de Shiori dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations de base de données de Shiori et les dépendances de capture des pages peuvent modifier le comportement des archives. Conservez l’image Shiori précédente tant que les limites de migration des données et de rollback ne sont pas clairement établies.