Comment exécuter Hermes Agent sur un serveur domestique sans perdre de données

Réponse rapide

Pour exécuter Hermes Agent sur un serveur domestique sans perdre de données, ne comptez pas sur le système de fichiers interne du conteneur comme seul endroit où vivent la configuration, les compétences, les journaux, les fichiers générés ou les paramètres de passerelle. Planifiez d’abord un dossier persistant sur l’hôte ou un volume Docker, montez-le dans le chemin du conteneur que l’application utilise réellement, vérifiez la propriété des fichiers et assurez-vous que les données existent toujours après redémarrage ou reconfiguration. Cet article se concentre sur le cas fréquent d’échec où un conteneur ne trouve pas un dossier à cause de problèmes de montage de volume, de permissions ou de mappage de chemin.

Le flux de travail le plus sûr pour les débutants est :

1. Identifiez quelles données de Hermes Agent doivent être conservées.
2. Choisissez un dossier dédié sur l’hôte ou un volume géré par Docker.
3. Mappez ce stockage au bon chemin dans le conteneur.
4. Confirmez que l’utilisateur de l’application peut écrire dans cet emplacement.
5. Sauvegardez la configuration importante avant les mises à jour ou reconstructions.
6. Redémarrez et vérifiez que la configuration, les journaux, les fichiers générés et les paramètres de passerelle sont toujours présents.

Un conteneur en fonctionnement ne garantit pas automatiquement la sécurité de vos données. Les données sont sûres uniquement lorsqu’elles sont stockées dans un emplacement persistant, modifiable par l’utilisateur correct, sauvegardées si nécessaire et vérifiées après redémarrage.

Pourquoi les données de Hermes Agent peuvent disparaître dans une configuration conteneurisée

Les applications conteneurisées sont souvent faciles à démarrer et à remplacer. Cela est utile pour les mises à jour, les tests et la récupération, mais cela signifie aussi que tout ce qui est stocké uniquement dans la couche jetable du conteneur peut être perdu lorsque le conteneur est supprimé, recréé ou reconstruit.

Pour un agent IA auto-hébergé, cela peut affecter plus que les paramètres de base. Selon votre utilisation de l’agent, vous pouvez vous soucier de la configuration du modèle, des compétences, des fichiers générés, des journaux, des paramètres de passerelle de messagerie et d’autres états de l’application.

Redémarrages de conteneurs vs données persistantes de l’application

Un redémarrage normal du conteneur ne supprime pas toujours les données. Si les données sont stockées dans un volume persistant ou un dossier hôte correctement mappé, elles devraient rester disponibles après le redémarrage.

Le risque apparaît lorsque des fichiers importants vivent uniquement dans la couche modifiable du conteneur. Cette couche n’est pas la même qu’un emplacement de données persistant planifié. Si vous recréez le conteneur sans préserver ou remonter le bon chemin, l’application peut démarrer à zéro ou ne pas retrouver ses fichiers précédents.

Pourquoi supprimer ou recréer un conteneur peut entraîner la perte d’état non sauvegardé

Supprimer ou recréer un conteneur est différent de le redémarrer. Un conteneur recréé peut utiliser un nouveau système de fichiers interne, de nouvelles variables d’environnement ou un mappage de montage différent.

Si les paramètres, compétences, journaux ou sorties générées par Hermes Agent n’ont jamais été écrits dans un dossier ou volume persistant de l’hôte, ils peuvent ne pas suivre le nouveau conteneur. C’est pourquoi « l’application fonctionnait hier » et « l’application a été réinitialisée après la mise à jour » peuvent être tous deux vrais.

La bonne habitude est de considérer le remplacement d’un conteneur comme un événement à risque pour les données, sauf si vous avez confirmé où les données de l’application sont stockées.

Pourquoi les chemins d’hôte et les chemins de conteneur doivent être planifiés en premier

Un chemin hôte est l’endroit où les données résident sur le serveur domestique. Un chemin de conteneur est l’endroit où l’application voit ces données depuis l’intérieur du conteneur. Un montage de volume ou un montage lié connecte ces deux mondes.

Si le chemin hôte est correct mais monté sur un mauvais chemin dans le conteneur, l’application peut se comporter comme si le dossier n’existait pas. Si le chemin du conteneur est correct mais que le chemin hôte est temporaire, l’application peut écrire des données quelque part où vous ne le souhaitez pas.

Planifiez le mappage avant de lancer l’application, pas après avoir perdu des données.

Quelles données devez-vous protéger avant d’exécuter Hermes Agent ?

Avant de modifier un conteneur, mettre à jour une image ou reconfigurer une passerelle, listez les données qu’il serait pénible de recréer. Tous les fichiers ne nécessitent pas la même protection, mais vous devez savoir quels fichiers sont critiques.

Une règle utile est : protégez tout ce qui stocke l’identité, l’accès, la configuration, le workflow appris ou la sortie que vous ne pouvez pas facilement régénérer.

Configuration de l’agent et paramètres du fournisseur de modèle

Les paramètres du modèle incluent généralement le choix du fournisseur, les valeurs des points de terminaison, les noms de modèles, les options liées au contexte et l’accès à l’API. Si ces paramètres sont perdus, l’agent peut démarrer mais ne pas répondre correctement.

Stockez la configuration du modèle dans un chemin de données d’application persistant, pas dans une session shell temporaire. Si la configuration est fournie via des variables d’environnement, conservez une copie sécurisée du fichier compose, du fichier env ou des notes de déploiement.

Protégez également tout choix de configuration qui détermine comment l’agent utilise les outils du terminal ou les passerelles de messagerie.

Mémoire de l’application, sessions, compétences et état d’exécution

Les données de l’agent Hermes peuvent inclure plus d’un fichier de configuration. La structure des données des compétences Hermes explique que les compétences résident dans ~/.hermes/skills/, qui est la source principale pour les compétences intégrées, installées via le hub et créées par l’agent. Elle décrit aussi l’état associé comme les manifests intégrés, bundles de compétences, configuration du hub tap, écritures en attente des compétences et paramètres de configuration.

Cela importe car les compétences créées par l’agent peuvent devenir une mémoire procédurale réutilisable. Si le mauvais chemin est monté, vous risquez de perdre non seulement les paramètres mais aussi les workflows appris par l’agent ou les compétences que vous avez installées.

Considérez les compétences, bundles, écritures en attente et états liés au profil comme des données persistantes de l’agent.

Téléchargements, fichiers générés, journaux et sorties d’outils

Les fichiers générés sont faciles à négliger. Un agent peut créer des plans, scripts, rapports, captures d’écran, journaux ou fichiers téléchargés lors d’une utilisation normale.

Ces fichiers peuvent être enregistrés dans l’espace de travail actif, le répertoire de travail du backend, le répertoire d’accueil de l’application ou un chemin de sortie monté. Si cet emplacement se trouve uniquement à l’intérieur du conteneur, les fichiers peuvent disparaître lorsque le conteneur est supprimé.

Pour une utilisation pratique, décidez où les fichiers générés doivent apparaître sur le serveur hôte et vérifiez que le conteneur y écrit.

Clés API, jetons de bot et variables d’environnement

Les secrets ne sont pas des données d’application ordinaires. Les clés API, jetons de bot, mots de passe de tableau de bord et variables d’environnement nécessitent à la fois persistance et protection.

Ne sauvegardez pas les secrets dans des dossiers de sortie générés aléatoirement ou des répertoires partagés larges. Gardez-les dans un chemin de configuration contrôlé avec un accès limité.

Une bonne configuration de gestion des secrets doit répondre à :

• où le secret est stocké ;
• quel utilisateur peut la lire ;
• si elle est incluse dans les sauvegardes ;
• si la sauvegarde est chiffrée ou contrôlée en accès ;
• comment le secret peut être renouvelé s’il est exposé.

Chemin hôte vs chemin conteneur vs montages de volume

C’est le concept clé derrière la plupart des problèmes « le conteneur ne trouve pas le dossier » et « les données ont disparu après le redémarrage ». Un conteneur ne peut voir que ce qui existe dans son propre système de fichiers ou ce qui lui a été monté.

Utilisez La carte de survie des données de l’agent pour organiser la configuration avant de dépanner.

Module cadre	Question clé	Ce que cela vous aide à décider	Focus sur la configuration / le dépannage
Inventaire des données	Quelles données doivent survivre au redémarrage ou à la recréation du conteneur ?	Quelles configurations, compétences, journaux, téléchargements, jetons et fichiers générés doivent être protégés	Évite de traiter les données importantes de l'agent comme un état jetable
Chemin de persistance	Où les données persistantes doivent-elles vivre sur l'hôte ?	Utiliser un dossier hôte dédié, un volume Docker ou un montage par liaison	Évite la réinitialisation des données après la recréation du conteneur
Mappage de montage	Le chemin hôte est-il correctement mappé dans le chemin du conteneur ?	Si l'application peut réellement voir le dossier prévu	Aide à diagnostiquer les erreurs de dossier manquant et de chemin de destination incorrect
Limite de permission	Quel utilisateur possède les données montées et quel utilisateur y écrit ?	Si l'utilisateur hôte, l'utilisateur du conteneur, l'utilisateur de l'application ou root possède les fichiers	Aide à résoudre les erreurs de permission refusée sans rendre tout propriétaire root
Limite de sauvegarde	Que faut-il sauvegarder avant les mises à jour ou la reconfiguration ?	Quelles données sont critiques et quelles données sont temporaires	Évite la perte de configuration, compétences, sessions, jetons et paramètres de passerelle
Validation du redémarrage	Les données existent-elles toujours après un redémarrage ou une mise à jour ?	Si la configuration est réellement durable	Transforme « ça fonctionne » en un contrôle de sécurité répétable

Ce que le serveur hôte stocke

Le serveur hôte stocke les dossiers réels, les disques et les emplacements de stockage gérés par Docker. Si vous utilisez un montage par liaison, vous choisissez un dossier hôte spécifique. Si vous utilisez un volume Docker nommé, Docker choisit et gère l'emplacement de stockage.

Cette distinction est importante car la visibilité de l'hôte affecte la sauvegarde et la migration. Un dossier monté par liaison peut être plus facile à localiser et copier pour un débutant. Un volume nommé peut être plus propre pour les données d'application gérées par Docker, mais vous devez toujours savoir comment l'inspecter ou le sauvegarder.

Choisissez le type de stockage en fonction de si vous avez besoin de dossiers hôtes lisibles par l'humain, d'une persistance d'application gérée par Docker, ou d'un chemin de sauvegarde contrôlé.

Ce que le conteneur peut voir

Le conteneur voit son propre système de fichiers interne et tous les chemins montés. Il ne voit pas automatiquement tous les dossiers de votre serveur domestique.

Le tutoriel sur les montages bind de Docker montre comment un répertoire hôte peut apparaître à l'intérieur d'un conteneur à un chemin cible, et comment les modifications de fichiers peuvent être reflétées entre l'hôte et le conteneur lorsque le montage est correct.

C'est l'idée principale : l'application ne se soucie pas de l'endroit où un fichier existe sur l'hôte à moins que le fichier ne soit monté dans le chemin utilisé par l'application.

Comment les montages de volume maintiennent la persistance des données d'application

Un montage persistant offre à l'application un endroit stable pour écrire des données au-delà de la durée de vie d'un seul conteneur. Pour les données d'application, c'est souvent la différence entre « sûr au redémarrage » et « uniquement pendant la durée de vie du conteneur ».

Le montage doit correspondre au chemin de données attendu par l'application. Si l'application écrit dans un dossier interne mais que vous montez un dossier différent, les données peuvent toujours aller dans un stockage jetable.

Une bonne configuration persistante doit définir :

• le dossier hôte ou le volume nommé ;
• le chemin cible dans le conteneur ;
• si le montage est en lecture-écriture ou en lecture seule ;
• quelles données d'application y appartiennent ;
• comment le chemin sera sauvegardé.

Pourquoi une mauvaise correspondance de chemin cause des erreurs de dossier manquant

Une mauvaise correspondance ressemble souvent à un problème de dossier manquant. Le dossier peut exister sur l'hôte, mais le conteneur ne peut pas le voir. Ou le conteneur peut avoir un dossier au chemin attendu, mais il n'est pas connecté au dossier hôte que vous aviez prévu.

Les symptômes courants incluent :

• l'application indique qu'un dossier n'existe pas ;
• les fichiers générés apparaissent dans le conteneur mais pas sur l'hôte ;
• les journaux disparaissent après la reconstruction du conteneur ;
• la configuration se réinitialise après la mise à jour ;
• vous modifiez un dossier hôte mais l'application continue d'utiliser d'anciens paramètres ;
• les scripts de sauvegarde s'exécutent mais n'incluent pas les vraies données de l'application.

Lorsque cela se produit, vérifiez ensemble le chemin hôte et le chemin du conteneur. N'inspectez pas seulement un côté.

Comment exécuter Hermes Agent sans perdre de données

L'objectif n'est pas seulement de démarrer Hermes Agent. L'objectif est de s'assurer que les données qui vous importent survivent au redémarrage, à la mise à jour, à la reconstruction et à la reconfiguration.

Étape 1 : Choisir un dossier de données hôte dédié

Choisissez un dossier de données hôte avant d'exécuter ou de reconstruire le conteneur. Il doit être facile à identifier, facile à sauvegarder et ne pas être mélangé avec des fichiers personnels non liés.

Un dossier dédié réduit les risques car vous pouvez voir ce qui appartient à l'application. Il évite également de monter tout votre répertoire personnel ou d'autres dossiers sensibles dans le conteneur.

Un dossier de données hôte pratique doit être :

• spécifique à l'application ;
• en dehors des chemins de téléchargement jetables ;
• inclus dans votre plan de sauvegarde ;
• non partagé largement avec des services non liés ;
• modifiable uniquement par les utilisateurs ou services qui ont besoin d'accès.

Étape 2 : Monter le dossier de données dans le conteneur

Montez le dossier de données hôte dans le chemin du conteneur attendu par l'application. C'est à ce moment que de nombreux problèmes de perte de données sont créés ou évités.

Pour un montage bind, le chemin hôte est choisi par vous et le chemin cible est l'endroit où il apparaît à l'intérieur du conteneur. Pour un volume nommé, Docker gère l'emplacement côté hôte.

Ne supposez pas que l’application utilisera automatiquement un dossier monté. Confirmez que la cible montée correspond bien au chemin réel des données de l’application.

Étape 3 : Confirmer que le conteneur utilise le chemin de données de l’application attendu

Après montage, vérifiez le chemin depuis l’intérieur du conteneur. Un dossier peut exister sur l’hôte et rester invisible à l’application s’il n’est pas monté correctement.

La validation la plus simple est de créer ou localiser un fichier test inoffensif d’un côté et de confirmer qu’il apparaît de l’autre côté. Puis vérifiez que l’application écrit de vrais fichiers de configuration, journaux ou générés dans le même chemin persistant.

Cette étape est particulièrement importante avant les mises à jour ou la migration.

Étape 4 : Vérifier la propriété des fichiers et les permissions d’écriture

Un montage correct peut quand même échouer si l’application ne peut pas écrire dedans. Les erreurs de permission surviennent souvent lorsque des fichiers sont créés par root mais que l’application s’exécute ensuite sous un autre utilisateur.

Vérifiez la propriété avant de modifier les permissions de manière large. La bonne solution est généralement de permettre à l’utilisateur prévu de l’application de lire et écrire dans le dossier de données spécifique, pas de donner un contrôle total à tous les processus sur de larges répertoires de l’hôte.

Si vous voyez un refus de permission, identifiez :

1. le chemin monté sur l’hôte ;
2. le chemin cible dans le conteneur ;
3. l’utilisateur exécutant l’application ;
4. le propriétaire du fichier ;
5. si le montage est en lecture seule ;
6. si un chemin de sauvegarde ou d’export est aussi accessible en écriture.

Étape 5 : Garder les secrets et fichiers de configuration hors des chemins jetables

Les secrets et fichiers de configuration ne doivent pas vivre uniquement dans des dossiers temporaires, des répertoires de sortie générés ou l’historique shell ad hoc. Si vous utilisez des variables d’environnement, conservez le fichier de déploiement ou le fichier env dans un emplacement persistant et contrôlé.

Évitez de mélanger secrets avec journaux ou artefacts générés. Les journaux peuvent être partagés pour le dépannage, tandis que les secrets ne doivent jamais être partagés à la légère.

Si vous sauvegardez des secrets, protégez la sauvegarde. Une sauvegarde qui expose des clés API ou des jetons de bot crée un risque différent.

Étape 6 : Redémarrer le conteneur et vérifier que les données existent toujours

Après la configuration, redémarrez le conteneur et vérifiez si les données importantes sont toujours présentes. C’est le test le plus pratique de la persistance.

Ne vous arrêtez pas à « le conteneur démarre ». Confirmez que :

• les paramètres du modèle existent toujours ;
• les compétences ou l’état de l’application restent visibles ;
• les journaux continuent à l’endroit attendu ;
• les fichiers générés apparaissent sur l’hôte ;
• les paramètres de la passerelle ou du bot fonctionnent toujours ;
• les fichiers de sauvegarde peuvent être localisés.

Une configuration qui passe la validation après redémarrage est bien plus sûre qu’une configuration qui a seulement passé l’installation initiale.

Permissions, sauvegardes et limites de sécurité

La sécurité des données dépend de trois limites : qui peut écrire, ce qui est sauvegardé, et ce que l'agent est autorisé à toucher. Ces limites sont particulièrement importantes pour les agents auto-hébergés car ils peuvent créer des fichiers, modifier des workflows ou interagir avec des outils.

Pourquoi les permissions utilisateur du conteneur sont importantes

Les permissions utilisateur du conteneur déterminent si l'application peut lire et écrire ses données. Si l'application s'exécute sous un utilisateur mais que le dossier monté appartient à un autre utilisateur, les opérations d'écriture peuvent échouer.

C'est pourquoi exécuter une commande d'installation en root peut créer un problème ultérieur. Root peut créer des fichiers avec succès, mais l'utilisateur normal de l'application peut ne pas pouvoir les modifier.

Corrigez les permissions au niveau du dossier de données de l'application. Évitez les changements de permissions larges qui exposent des fichiers hôtes non liés.

Pourquoi vous devriez éviter d'exécuter tout en root

Root peut contourner de nombreuses restrictions, mais cela ne fait pas de lui un choix sûr par défaut. Tout exécuter en root peut créer des fichiers appartenant à root, masquer des problèmes de permission et donner à l'application plus d'accès qu'elle n'en a besoin.

Pour la plupart des flux de travail d'applications auto-hébergées, root ne devrait être utilisé que pour des étapes administratives spécifiques. La configuration courante de l'application devrait s'exécuter en tant qu'utilisateur prévu de l'application ou du conteneur quand c'est possible.

Un schéma plus sûr est le moindre privilège : donnez à l'application un accès en écriture uniquement aux dossiers dont elle a besoin.

Quand utiliser des montages en lecture seule ou des dossiers limités

Utilisez des montages en lecture seule lorsque l'agent doit inspecter les fichiers mais ne doit pas les modifier. Utilisez des dossiers limités en écriture lorsque l'agent doit créer des sorties mais ne doit pas toucher aux répertoires personnels ou système étendus.

Ceci est particulièrement utile lorsque vous voulez que l'agent génère des rapports, plans ou scripts sans lui donner un accès en écriture à tous les fichiers du serveur.

Un design avec dossier limité réduit l'impact des erreurs. Il facilite aussi les sauvegardes car vous savez quel dossier contient l'état de l'application et quel dossier contient les sorties générées.

Comment sauvegarder les données de l'agent avant les mises à jour ou la reconfiguration

Sauvegardez les données importantes de l'application avant de changer les images de conteneur, les chemins de montage, les paramètres de passerelle ou les profils. Une sauvegarde n'est utile que si vous savez ce qu'elle inclut et comment la restaurer.

La communauté Docker discussion sur les permissions de sauvegarde de volume montre un schéma d'échec courant pour les utilisateurs : un chemin peut exister, mais les opérations de sauvegarde ou d'écriture peuvent échouer à cause de restrictions liées aux permissions, à la propriété, au marquage ou au montage.

Utilisez cela comme rappel pour tester les sauvegardes, pas seulement pour les créer. Un plan de sauvegarde doit inclure à la fois la création de sauvegardes et la vérification de la restauration.

Problèmes courants et comment les résoudre

Lorsque les données de l'agent Hermes sont manquantes, ne réinstallez pas immédiatement l'application. Identifiez d'abord quelle couche a échoué : inventaire des données, chemin de persistance, mappage de montage, limite de permission, limite de sauvegarde ou validation de redémarrage.

Le conteneur ne trouve pas un dossier monté

Cela signifie généralement que le chemin existe dans une couche mais pas dans l'autre. Le dossier hôte peut ne pas être monté, le chemin cible du conteneur peut être incorrect, ou l'application peut chercher ailleurs.

Vérifiez dans cet ordre :

1. Confirmez que le dossier existe sur l'hôte.
2. Confirmez que le conteneur a le montage.
3. Confirmez le chemin cible à l'intérieur du conteneur.
4. Confirmez que l'application est configurée pour utiliser ce chemin cible.
5. Confirmez que l'utilisateur de l'application peut lire le dossier.
6. Confirmez que le montage a été recréé après avoir modifié les paramètres de compose ou d'exécution.

Ne corrigez pas cela en créant des dossiers aléatoires à l'intérieur du conteneur. Cela peut faire disparaître temporairement l'erreur tout en laissant les données dans un stockage jetable.

Les données de l'application sont réinitialisées après redémarrage

Si les données sont réinitialisées après redémarrage, l'application peut écrire dans le système de fichiers interne du conteneur au lieu du chemin persistant. Elle peut aussi utiliser un profil, une variable d'environnement ou un répertoire de données différent de celui attendu.

Vérifiez si le chemin des données avant et après redémarrage est le même. Puis vérifiez si le dossier est soutenu par un montage ou seulement par la couche du conteneur.

Si l'application a été recréée, confirmez que le même volume ou montage lié a été attaché au nouveau conteneur.

Erreurs de permission refusée dans le répertoire des données

Permission refusée signifie que l'application voit le chemin mais ne peut pas effectuer l'action requise. Le problème peut venir de la propriété, des paramètres de montage en lecture seule, des étiquettes du système de fichiers ou d'une incompatibilité entre l'utilisateur hôte et l'utilisateur du conteneur.

Commencez par la vérification la plus simple : l'utilisateur de l'application peut-il créer un fichier test inoffensif dans le répertoire des données ? Sinon, inspectez le propriétaire et les permissions de ce chemin spécifique.

Évitez de résoudre ce problème en donnant un accès en écriture large à tout le répertoire hôte. Corrigez le chemin des données de l'application et l'utilisateur prévu de l'application.

Les fichiers générés sont enregistrés uniquement à l'intérieur du conteneur

Si les fichiers générés disparaissent après reconstruction, ils ont probablement été enregistrés à l'intérieur du conteneur au lieu d'un chemin monté sur l'hôte. Cela arrive souvent lorsque le répertoire de travail ou le répertoire de sortie de l'application n'est pas mappé.

Décidez où les fichiers générés doivent être placés. Montez ensuite ce dossier de sortie ou configurez l'application pour écrire dans un emplacement persistant existant.

Après avoir changé le chemin, générez un fichier test inoffensif et confirmez qu'il apparaît sur l'hôte.

Les paramètres du bot ou de la passerelle disparaissent après reconfiguration

Les paramètres de la passerelle peuvent disparaître si la configuration est stockée dans un chemin non persistant ou si l'application s'exécute sous un profil différent après redémarrage. La même chose peut arriver si une variable d'environnement est modifiée à un endroit mais que le conteneur en cours d'exécution utilise une autre valeur.

Vérifiez si la configuration de la passerelle, la référence du jeton du bot, la liste blanche et les paramètres du tableau de bord sont stockés à l'emplacement persistant attendu. Puis redémarrez la passerelle et confirmez que les paramètres restent actifs.

Si le bot fonctionne avant le redémarrage mais pas après, concentrez-vous sur la persistance et la configuration de l'environnement avant de changer le jeton.

Comment vérifier si les données de votre agent Hermes sont sécurisées

Une configuration sûre doit passer les vérifications de redémarrage, d'écriture, de sauvegarde et d'accès. Ces vérifications n'ont pas besoin d'être compliquées, mais elles doivent être répétées après des changements majeurs.

La configuration persiste après redémarrage

Modifiez un paramètre inoffensif, redémarrez le conteneur et vérifiez que le paramètre reste. Cela confirme que l'application écrit dans un stockage persistant.

Si le paramètre disparaît, ne continuez pas à ajouter plus de configuration. Corrigez d'abord le chemin des données.

Les journaux et fichiers générés apparaissent dans le dossier attendu sur l’hôte

Les journaux et fichiers générés doivent apparaître là où vous les attendez sur l’hôte. S’ils n’apparaissent que dans le conteneur, ils risquent d’être perdus lors de la reconstruction.

Vérifiez les deux côtés du montage. L’hôte et le conteneur doivent être d’accord sur les fichiers importants.

L’agent peut écrire dans les données de l’application sans erreurs de permission

L’agent doit pouvoir écrire dans son dossier de données d’application en tant qu’utilisateur prévu. Un test d’écriture réussi est plus utile que de simplement confirmer que le dossier existe.

Surveillez les erreurs de permission dans les journaux après le redémarrage. Certains problèmes de permission n’apparaissent que lorsque l’agent tente de mettre à jour la configuration, d’écrire une compétence, d’enregistrer un fichier généré ou de mettre à jour l’état de la passerelle.

Les fichiers de sauvegarde peuvent être localisés et restaurés

Une sauvegarde est incomplète tant que vous ne pouvez pas la localiser et la restaurer dans un emplacement de test. Au minimum, confirmez que la sauvegarde contient les données que vous souhaitiez protéger.

Pour les configurations importantes, restaurez la sauvegarde dans un dossier séparé ou une instance de test avant de vous y fier. Cela évite de découvrir des problèmes de restauration seulement après la perte de données.

L’accès au tableau de bord ou à la messagerie fonctionne toujours après un redémarrage

Après un redémarrage, vérifiez que l’accès au tableau de bord ou à la messagerie fonctionne toujours. Cela confirme que les données persistantes, les identifiants, les paramètres de la passerelle et l’accès réseau sont toujours alignés.

Si le tableau de bord fonctionne mais que la messagerie échoue, vérifiez les paramètres de la passerelle et l’accès au jeton. Si la messagerie fonctionne mais que les fichiers générés disparaissent, vérifiez le chemin de sortie et les montages.

Comment cela fonctionne dans un environnement réel de serveur domestique

Dans une configuration réelle de serveur domestique, la même logique de sécurité des données s’applique même lorsque le système offre un tableau de bord convivial. Vous devez toujours savoir quelles données doivent être conservées, où elles sont stockées, comment le conteneur les voit, quel utilisateur peut y écrire et comment les vérifier après un redémarrage.

Par exemple, le workflow de configuration de l’agent Hermes ZimaOS montre un chemin spécifique à l’appareil qui inclut la configuration du fournisseur de modèle, la mise en place de la passerelle Telegram, l’accès au conteneur Hermes, l’activation de l’environnement de l’application, la vérification du tableau de bord Web et le dépannage des problèmes de permissions ou de réponse du bot.

Pour les utilisateurs exécutant des applications Docker, des workflows d'agents et des services locaux sur une machine compacte toujours allumée, le serveur domestique ZimaBoard 2 est un exemple pertinent du type d’environnement serveur domestique léger où les dossiers persistants, les chemins des conteneurs, les permissions et l’extension de stockage doivent être planifiés ensemble. Ce n’est pas la seule configuration possible, mais elle correspond au type de workflow d’application auto-hébergée abordé dans ce guide.

La leçon générale est universelle : avant de confier un travail utile à un agent conteneurisé, assurez-vous que ses données importantes survivent au-delà du conteneur qui tourne aujourd'hui.

FAQ

Pourquoi mes données Hermes Agent ont-elles disparu après le redémarrage du conteneur ?

Un simple redémarrage ne devrait pas supprimer les données persistantes, mais l'application peut sembler réinitialisée si elle écrivait dans un chemin non persistant du conteneur. Les données peuvent aussi manquer si le conteneur a été recréé sans le même volume ou montage lié. Vérifiez le chemin hôte, le chemin du conteneur et le chemin réel des données de l'application avant de modifier d'autres paramètres.

Quelle est la différence entre un volume Docker et un montage lié (bind mount) ?

Un volume Docker est géré par Docker, tandis qu'un montage lié (bind mount) mappe un dossier hôte que vous choisissez dans le conteneur. Un volume est souvent propre pour les données gérées par l'application, tandis qu'un montage lié est plus facile à localiser directement sur l'hôte. Le meilleur choix dépend de si vous souhaitez un stockage géré par Docker ou un dossier visible sur l'hôte pour la sauvegarde et l'inspection.

Où dois-je stocker les données de l'application Hermes Agent sur un serveur domestique ?

Utilisez un dossier persistant dédié ou un volume Docker plutôt qu'un chemin temporaire dans le conteneur. L'emplacement doit être facile à sauvegarder, limité aux besoins de l'application et ne pas être mélangé avec des fichiers sensibles non liés. Le point le plus important est que le chemin attendu dans le conteneur par l'application doit réellement correspondre à ce stockage persistant.

Pourquoi le conteneur indique-t-il qu'un dossier n'existe pas ?

Le dossier peut exister sur l'hôte mais pas à l'intérieur du conteneur. Cela signifie généralement que le montage n'a pas été créé, que le chemin source est incorrect, que le chemin cible est incorrect ou que l'application cherche dans un chemin différent du conteneur. Vérifiez à la fois le côté hôte et le côté conteneur au lieu de créer un nouveau dossier à l'aveugle.

Dois-je exécuter Hermes Agent en root pour éviter les erreurs de permission ?

Exécuter en tant que root peut masquer l'erreur immédiate, mais cela peut créer des fichiers appartenant à root et augmenter les risques. Une approche plus sûre consiste à permettre à l'utilisateur de l'application prévu de lire et d'écrire uniquement dans le chemin des données nécessaires à l'application. Utilisez root uniquement pour des actions administratives ou de réparation spécifiques lorsque vous comprenez la modification.

À quelle fréquence dois-je sauvegarder les données de Hermes Agent ?

Sauvegardez avant les mises à jour, la reconstruction des conteneurs, les changements de chemin, la reconfiguration de la passerelle ou la migration vers un autre serveur. Pour une utilisation active, planifiez des sauvegardes régulières en fonction de la fréquence de modification des compétences, des paramètres, des fichiers générés ou des sessions. Une sauvegarde n'est fiable que lorsque vous avez confirmé que les fichiers peuvent être localisés et restaurés.