Come eseguire Hermes Agent su un server domestico senza perdere dati

Risposta rapida

Per eseguire Hermes Agent su un server domestico senza perdere dati, non fare affidamento solo sul filesystem interno del container come unico luogo dove risiedono configurazioni, competenze, log, file generati o impostazioni del gateway. Pianifica prima una cartella host persistente o un volume Docker, montalo nel percorso del container effettivamente usato dall'app, controlla la proprietà dei file e verifica che i dati esistano ancora dopo il riavvio o la riconfigurazione. Questo articolo si concentra sul problema comune in cui un container non trova una cartella a causa di problemi di mount del volume, permessi o mappatura dei percorsi.

Il flusso di lavoro più sicuro per i principianti è:

1. Identifica quali dati di Hermes Agent devono sopravvivere.
2. Scegli una cartella host dedicata o un volume gestito da Docker.
3. Mappa quello storage al percorso corretto nel container.
4. Conferma che l'utente dell'app possa scrivere su di essi.
5. Esegui il backup delle configurazioni importanti prima di aggiornamenti o ricostruzioni.
6. Riavvia e verifica che configurazioni, log, file generati e impostazioni del gateway siano ancora presenti.

Un container in esecuzione non garantisce automaticamente la sicurezza dei dati. I dati sono sicuri solo se memorizzati in una posizione persistente, scrivibile dall'utente corretto, sottoposti a backup quando necessario e verificati dopo il riavvio.

Perché i dati di Hermes Agent possono scomparire in una configurazione container

Le app containerizzate sono spesso facili da avviare e sostituire. Questo è utile per aggiornamenti, test e recupero, ma significa anche che tutto ciò che è memorizzato solo nel layer usa e getta del container può andare perso quando il container viene rimosso, ricreato o ricostruito.

Per un agente AI self-hosted, questo può influenzare più delle impostazioni di base. A seconda dell'uso, potresti dover considerare configurazioni del modello, competenze, file generati, log, impostazioni del gateway di messaggistica e altri stati dell'app.

Riavvii del container vs dati persistenti dell'app

Un normale riavvio del container non sempre elimina i dati. Se i dati sono memorizzati in un volume persistente o in una cartella host mappata correttamente, dovrebbero rimanere disponibili dopo il riavvio.

Il rischio si presenta quando file importanti esistono solo all'interno del layer scrivibile del container. Quel layer non è lo stesso di una posizione dati persistente pianificata. Se ricrei il container senza preservare o rimontare il percorso corretto, l'app potrebbe partire da zero o non trovare i file precedenti.

Perché eliminare o ricreare un container può far perdere lo stato non salvato

Eliminare o ricreare un container è diverso dal riavviarlo. Un container ricreato può usare un nuovo filesystem interno, nuove variabili d'ambiente o una diversa mappatura dei mount.

Se le impostazioni, le competenze, i log o gli output generati da Hermes Agent non sono mai stati scritti in una cartella o volume host persistente, potrebbero non essere presenti nel nuovo container. Ecco perché “l'app funzionava ieri” e “l'app si è resettata dopo l'aggiornamento” possono essere entrambe vere.

La pratica sicura è considerare la sostituzione del container come un evento a rischio di perdita dati, a meno che non si sia confermato dove sono memorizzati i dati dell'app.

Perché è necessario pianificare prima i percorsi host e i percorsi dei container

Un percorso host è dove i dati risiedono sul server domestico. Un percorso container è dove l'app vede quei dati dall'interno del container. Un mount di volume o bind mount collega questi due mondi.

Se il percorso host è corretto ma montato nel percorso container sbagliato, l'app potrebbe comportarsi come se la cartella non esistesse. Se il percorso container è corretto ma il percorso host è usa e getta, l'app potrebbe scrivere dati in un luogo non previsto.

Pianifica la mappatura prima di eseguire l'app, non dopo aver perso dati.

Quali Dati Dovresti Proteggere Prima di Eseguire Hermes Agent?

Prima di modificare un container, aggiornare un'immagine o riconfigurare un gateway, elenca i dati che sarebbe doloroso ricreare. Non tutti i file necessitano della stessa protezione, ma dovresti sapere quali file sono critici.

Una regola utile è: proteggi tutto ciò che memorizza identità, accesso, configurazione, flussi di lavoro appresi o output che non puoi rigenerare facilmente.

Configurazione dell'Agente e Impostazioni del Provider del Modello

Le impostazioni del modello di solito includono la scelta del provider, i valori dell'endpoint, i nomi dei modelli, le opzioni relative al contesto e l'accesso API. Se queste impostazioni vengono perse, l'agente potrebbe avviarsi ma non rispondere correttamente.

Conserva la configurazione del modello in un percorso dati persistente dell'app, non in una sessione shell temporanea. Se la configurazione è fornita tramite variabili d'ambiente, conserva una copia sicura del file compose, del file env o delle note di distribuzione.

Proteggi anche qualsiasi scelta di configurazione che determina come l'agente usa gli strumenti terminali o i gateway di messaggistica.

Memoria dell'App, Sessioni, Competenze e Stato di Esecuzione

I dati dell'agente Hermes possono includere più di un file di configurazione. La struttura dati delle competenze Hermes spiega che le competenze risiedono in ~/.hermes/skills/, che è la fonte primaria di verità per le competenze bundle, installate dal hub e create dall'agente. Descrive anche lo stato correlato come manifesti bundle, bundle di competenze, configurazione del tap del hub, scritture di competenze in sospeso e impostazioni di configurazione.

Questo è importante perché le competenze create dall'agente possono diventare memoria procedurale riutilizzabile. Se il percorso montato è sbagliato, potresti perdere non solo le impostazioni ma anche i flussi di lavoro che l'agente ha imparato o le competenze che hai installato.

Tratta le competenze, i bundle, le scritture in sospeso e lo stato relativo al profilo come dati persistenti dell'agente.

Download, File Generati, Log e Output degli Strumenti

I file generati sono facili da trascurare. Un agente può creare piani, script, report, screenshot, log o file scaricati durante l'uso normale.

Questi file possono essere salvati nello spazio di lavoro attivo, nella directory di lavoro del backend, nella directory home dell'app o in un percorso di output montato. Se quella posizione è solo all'interno del container, i file potrebbero scomparire quando il container viene rimosso.

Per un uso pratico, decidi dove i file generati dovrebbero apparire sul server host e verifica che il container scriva lì.

Chiavi API, token bot e variabili d’ambiente

I segreti non sono dati ordinari delle app. Chiavi API, token bot, password della dashboard e variabili d’ambiente necessitano sia di persistenza che di protezione.

Non salvare segreti in cartelle di output generate casualmente o in directory condivise ampie. Tienili in un percorso di configurazione controllato con accesso limitato.

Una buona configurazione per la gestione dei segreti dovrebbe rispondere a:

• dove il segreto è memorizzato;
• quale utente può leggerlo;
• se è incluso nei backup;
• se il backup è criptato o controllato nell’accesso;
• come il segreto può essere ruotato se esposto.

Percorso host vs percorso container vs mount dei volumi

Questo è il concetto chiave dietro la maggior parte dei problemi “il container non trova la cartella” e “i dati sono scomparsi dopo il riavvio”. Un container può vedere solo ciò che esiste all’interno del proprio filesystem o ciò che è stato montato.

Usa La Mappa di Sopravvivenza dei Dati dell’Agente per organizzare la configurazione prima di risolvere i problemi.

Modulo del framework	Domanda chiave	Cosa ti aiuta a decidere	Focus su configurazione / risoluzione problemi
Inventario dei dati	Quali dati devono sopravvivere al riavvio o alla ricreazione del container?	Quali configurazioni, competenze, log, download, token e file generati necessitano protezione	Previene il trattamento dei dati importanti dell’agente come stato usa e getta
Percorso di persistenza	Dove dovrebbero risiedere i dati persistenti sull’host?	Se usare una cartella host dedicata, un volume Docker o un bind mount	Previene il reset dei dati dopo la ricreazione del container
Mappatura del mount	Il percorso host è correttamente mappato nel percorso del container?	Se l’app può effettivamente vedere la cartella prevista	Aiuta a diagnosticare errori di cartella mancante e percorso di destinazione errato
Confine dei permessi	Quale utente possiede i dati montati e quale utente li scrive?	Se i file sono di proprietà dell’utente host, dell’utente del container, dell’utente dell’app o di root	Aiuta a risolvere il problema del permesso negato senza rendere tutto di proprietà root
Confine del backup	Cosa deve essere sottoposto a backup prima di aggiornamenti o riconfigurazioni?	Quali dati sono critici e quali temporanei	Previene la perdita di configurazioni, competenze, sessioni, token e impostazioni del gateway
Validazione del riavvio	I dati esistono ancora dopo il riavvio o l’aggiornamento?	Se la configurazione è effettivamente duratura	Trasforma “funziona” in un controllo di sicurezza ripetibile

Cosa memorizza il server host

Il server host memorizza le cartelle reali, i dischi e le posizioni di archiviazione gestite da Docker. Se usi un bind mount, scegli una cartella host specifica. Se usi un volume Docker nominato, Docker sceglie e gestisce la posizione di archiviazione.

Questa distinzione è importante perché la visibilità dell’host influisce su backup e migrazione. Una cartella montata con bind può essere più facile da individuare e copiare per un principiante. Un volume nominato può essere più pulito per i dati delle app gestite da Docker, ma devi comunque sapere come ispezionarlo o eseguirne il backup.

Scegli lo stile di archiviazione in base alla necessità di cartelle host leggibili dall’uomo, persistenza delle app gestita da Docker o un percorso di backup controllato.

Cosa può vedere il container

Il container vede il proprio filesystem interno e qualsiasi percorso montato. Non vede automaticamente tutte le cartelle sul tuo server domestico.

La guida al bind mount di Docker mostra come una directory host può apparire all'interno di un container in un percorso di destinazione e come le modifiche ai file possono riflettersi tra host e container quando il mount è corretto.

Questa è l'idea principale: all'app non importa dove esiste un file sull'host a meno che il file non sia montato nel percorso che l'app utilizza.

Come i mount di volume mantengono i dati dell'app persistenti

Un mount persistente offre all'app un luogo stabile dove scrivere dati oltre la vita di un singolo container. Per i dati dell'app, questa è spesso la differenza tra "sicuro al riavvio" e "solo per la durata del container".

Il mount deve corrispondere al percorso dati previsto dall'app. Se l'app scrive in una cartella interna ma monti una cartella diversa, i dati potrebbero comunque finire in uno storage temporaneo.

Una buona configurazione persistente dovrebbe definire:

• la cartella host o il volume nominato;
• il percorso target del container;
• se il mount è in lettura-scrittura o solo in lettura;
• quali dati dell'app appartengono lì;
• come il percorso sarà sottoposto a backup.

Perché una mappatura errata del percorso causa errori di cartella mancante

Una mappatura errata spesso sembra un problema di cartella mancante. La cartella può esistere sull'host, ma il container non può vederla. Oppure il container può avere una cartella nel percorso previsto, ma non è collegata alla cartella host che intendevi.

I sintomi comuni includono:

• l'app dice che una cartella non esiste;
• i file generati appaiono all'interno del container ma non sull'host;
• i log scompaiono dopo la ricostruzione del container;
• la configurazione si resetta dopo l'aggiornamento;
• modifichi una cartella host ma l'app continua a usare vecchie impostazioni;
• gli script di backup vengono eseguiti ma non includono i dati reali dell'app.

Quando ciò accade, controlla insieme il percorso host e il percorso del container. Non ispezionare solo un lato.

Come eseguire Hermes Agent senza perdere dati

L'obiettivo non è solo avviare Hermes Agent. L'obiettivo è assicurarsi che i dati a cui tieni sopravvivano a riavvii, aggiornamenti, ricostruzioni e riconfigurazioni.

Passo 1: Scegliere una cartella dati host dedicata

Scegli una cartella dati host prima di eseguire o ricostruire il container. Deve essere facile da identificare, facile da eseguire il backup e non mescolata con file personali non correlati.

Una cartella dedicata riduce il rischio perché puoi vedere cosa appartiene all'app. Evita anche di montare l'intera directory home o altre cartelle sensibili nel container.

Una cartella dati pratica sull'host dovrebbe essere:

• specifico per l'app;
• al di fuori dei percorsi di download temporanei;
• incluso nel tuo piano di backup;
• non condiviso ampiamente con servizi non correlati;
• scrivibile solo dagli utenti o servizi che necessitano di accesso.

Passo 2: Montare la cartella dati nel container

Monta la cartella dati dell'host nel percorso del container previsto dall'app. Questo è il momento in cui si creano o si prevengono molti problemi di perdita di dati.

Per un bind mount, il percorso host è scelto da te e il percorso di destinazione è dove appare all'interno del container. Per un volume nominato, Docker gestisce la posizione sul lato host.

Non dare per scontato che l'app usi automaticamente una cartella montata. Conferma che il target montato corrisponda al percorso dati reale dell'app.

Passo 3: Conferma che il container usa il percorso dati dell'app previsto

Dopo il mount, controlla il percorso dall'interno del container. Una cartella può esistere sull'host ma essere invisibile all'app se non è montata correttamente.

La convalida più semplice è creare o individuare un file di test innocuo da un lato e confermare che appare dall'altro lato. Poi verifica che l'app scriva file di configurazione reali, log o file generati nello stesso percorso persistente.

Questo passo è particolarmente importante prima di aggiornamenti o migrazioni.

Passo 4: Controlla la proprietà dei file e i permessi di scrittura

Un mount corretto può comunque fallire se l'app non può scriverci. Gli errori di permesso spesso accadono quando i file sono creati da root ma l'app viene eseguita successivamente come un utente diverso.

Controlla la proprietà prima di modificare ampiamente i permessi. La soluzione corretta è solitamente permettere all'utente dell'app previsto di leggere e scrivere nella specifica cartella dati dell'app, non dare a ogni processo il controllo completo su ampie directory host.

Se vedi permesso negato, identifica:

1. il percorso host montato;
2. il percorso target del container;
3. l'utente che esegue l'app;
4. il proprietario del file;
5. se il mount è di sola lettura;
6. se un percorso di backup o esportazione è anche scrivibile.

Passo 5: Tieni segreti e file di configurazione fuori dai percorsi usa e getta

I segreti e i file di configurazione non dovrebbero risiedere solo in cartelle temporanee, directory di output generate o nella cronologia shell ad hoc. Se usi variabili d'ambiente, conserva il file di deployment o il file env in una posizione persistente e controllata.

Evita di mescolare segreti con log o artefatti generati. I log possono essere condivisi per la risoluzione dei problemi, mentre i segreti non dovrebbero mai essere condivisi casualmente.

Se esegui il backup dei segreti, proteggi il backup. Un backup che espone chiavi API o token del bot crea un tipo diverso di rischio.

Passo 6: Riavvia il container e verifica che i dati esistano ancora

Dopo la configurazione, riavvia il container e verifica se i dati importanti sono ancora presenti. Questo è il test più pratico della persistenza.

Non fermarti a “il container si avvia.” Conferma che:

• le impostazioni del modello esistono ancora;
• le competenze o lo stato dell'app rimangono visibili;
• i log continuano nel luogo previsto;
• i file generati appaiono sull'host;
• le impostazioni del gateway o del bot funzionano ancora;
• possono essere localizzati i file di backup.

Una configurazione che supera la convalida al riavvio è molto più sicura di una che ha superato solo la prima installazione.

Permessi, backup e confini di sicurezza

La sicurezza dei dati dipende da tre confini: chi può scrivere, cosa viene salvato nel backup e cosa l'agente è autorizzato a toccare. Questi confini sono particolarmente importanti per gli agenti self-hosted perché possono creare file, modificare flussi di lavoro o interagire con strumenti.

Perché i permessi utente del container sono importanti

I permessi utente del container decidono se l'app può leggere e scrivere i suoi dati. Se l'app viene eseguita come un utente ma la cartella montata è di proprietà di un altro utente, le operazioni di scrittura potrebbero fallire.

Ecco perché eseguire un comando di setup come root può creare un problema successivo. Root può creare file con successo, ma l'utente normale dell'app potrebbe non riuscire a modificarli.

Correggi i permessi a livello della cartella dati dell'app. Evita modifiche ampie ai permessi che espongono file dell'host non correlati.

Perché dovresti evitare di eseguire tutto come root

Root può bypassare molte restrizioni, ma questo non lo rende un default sicuro. Eseguire tutto come root può creare file di proprietà root, nascondere problemi di permessi e dare all'app più accesso del necessario.

Per la maggior parte dei flussi di lavoro di app self-hosted, root dovrebbe essere usato solo per passaggi amministrativi specifici. La configurazione di routine dell'app dovrebbe essere eseguita come l'utente previsto dell'app o del contenitore, quando possibile.

Un modello più sicuro è il principio del minimo privilegio: concedi all'app l'accesso in scrittura solo alle cartelle di cui ha bisogno.

Quando usare mount in sola lettura o cartelle limitate

Usa mount in sola lettura quando l'agente deve ispezionare i file ma non modificarli. Usa cartelle scrivibili limitate quando l'agente deve creare output ma non deve toccare directory personali o di sistema ampie.

Questo è particolarmente utile quando vuoi che l'agente generi report, piani o script senza dargli accesso in scrittura a tutti i file del server.

Un design con cartelle limitate riduce l'impatto degli errori. Rende anche i backup più semplici perché sai quale cartella contiene lo stato dell'app e quale contiene gli output generati.

Come eseguire il backup dei dati dell'agente prima di aggiornamenti o riconfigurazioni

Esegui il backup dei dati importanti dell'app prima di cambiare immagini del contenitore, percorsi di mount, impostazioni del gateway o profili. Un backup è utile solo se sai cosa include e come ripristinarlo.

La comunità Docker discussione sui permessi di backup del volume mostra un modello comune di errore per l'utente: un percorso può esistere, ma le operazioni di backup o scrittura possono comunque fallire a causa di restrizioni su permessi, proprietà, etichettatura o mount.

Usa questo come promemoria per testare i backup, non solo per crearli. Un piano di backup dovrebbe includere sia la creazione del backup che la verifica del ripristino.

Problemi comuni e come risolverli

Quando mancano i dati di Hermes Agent, non reinstallare immediatamente l'app. Prima identifica quale livello ha fallito: inventario dati, percorso di persistenza, mappatura del mount, limite di permessi, limite di backup o convalida del riavvio.

Il contenitore non riesce a trovare una cartella montata

Questo di solito significa che il percorso esiste in un livello ma non nell'altro. La cartella dell'host potrebbe non essere montata, il percorso di destinazione del contenitore potrebbe essere errato o l'app potrebbe cercare altrove.

Controlla in questo ordine:

1. Conferma che la cartella esista sull'host.
2. Conferma che il contenitore abbia il mount.
3. Conferma il percorso di destinazione all'interno del contenitore.
4. Conferma che l'app sia configurata per utilizzare quel percorso di destinazione.
5. Conferma che l'utente dell'app può leggere la cartella.
6. Conferma che il mount è stato ricreato dopo aver cambiato le impostazioni di compose o run.

Non risolvere questo creando cartelle casuali all'interno del container. Questo potrebbe far sparire temporaneamente l'errore lasciando però i dati in uno storage temporaneo.

I dati dell'app si resettano dopo il riavvio

Se i dati si resettano dopo il riavvio, l'app potrebbe scrivere nel filesystem interno del container invece che nel percorso persistente. Potrebbe anche usare un profilo, una variabile d'ambiente o una directory dati diversa da quella prevista.

Verifica se il percorso dei dati prima e dopo il riavvio è lo stesso. Poi controlla se la cartella è supportata da un mount o solo dallo strato del container.

Se l'app è stata ricreata, conferma che lo stesso volume o bind mount è stato collegato al nuovo container.

Errori di permesso negato nella directory dei dati

Permesso negato significa che l'app vede il percorso ma non può eseguire l'azione richiesta. Il problema può essere la proprietà, le impostazioni di montaggio in sola lettura, le etichette del filesystem o una discrepanza tra utente host e utente container.

Inizia con il controllo più semplice: l'utente dell'app può creare un file di test innocuo nella directory dei dati? In caso contrario, controlla il proprietario e i permessi di quel percorso specifico.

Evita di risolvere questo dando accesso in scrittura ampio all'intera directory dell'host. Correggi il percorso dei dati dell'app e l'utente previsto dell'app.

I file generati sono salvati solo all'interno del container

Se i file generati scompaiono dopo la ricostruzione, probabilmente sono stati salvati all'interno del container invece che in un percorso montato sull'host. Questo accade spesso quando la directory di lavoro o la directory di output dell'app non sono mappate.

Decidi dove devono essere salvati i file generati. Poi monta quella cartella di output o configura l'app per scrivere in una posizione persistente esistente.

Dopo aver cambiato il percorso, genera un file di test innocuo e conferma che appare sull'host.

Impostazioni del bot o del gateway scompaiono dopo la riconfigurazione

Le impostazioni del gateway possono scomparire se la configurazione è memorizzata in un percorso non persistente o se l'app viene eseguita con un profilo diverso dopo il riavvio. Lo stesso può accadere se una variabile d'ambiente viene modificata in un punto ma il container in esecuzione usa un valore diverso.

Verifica se la configurazione del gateway, il riferimento al token del bot, la whitelist e le impostazioni della dashboard sono memorizzate nella posizione persistente prevista. Poi riavvia il gateway e conferma che le impostazioni rimangono attive.

Se il bot funziona prima del riavvio ma non dopo, concentrati sulla persistenza e sulla configurazione dell'ambiente prima di cambiare il token.

Come verificare se i dati del tuo agente Hermes sono al sicuro

Una configurazione sicura dovrebbe superare i controlli di riavvio, scrittura, backup e accesso. Questi controlli non devono essere complicati, ma dovrebbero essere ripetuti dopo modifiche importanti.

La configurazione persiste dopo il riavvio

Modifica un'impostazione innocua, riavvia il container e verifica che l'impostazione rimanga. Questo conferma che l'app sta scrivendo su uno storage persistente.

Se l'impostazione scompare, non continuare ad aggiungere altre configurazioni. Prima correggi il percorso dei dati.

I Log e i File Generati Appaiono nella Cartella Prevista sull’Host

I log e i file generati dovrebbero apparire dove ti aspetti sull’host. Se appaiono solo all’interno del container, potrebbero andare persi durante la ricostruzione.

Controlla entrambi i lati del mount. Host e container dovrebbero concordare sui file importanti.

L’Agent Può Scrivere nei Dati App Senza Errori di Permesso

L’agent dovrebbe poter scrivere nella sua cartella dati app come utente previsto. Un test di scrittura riuscito è più utile che confermare semplicemente che la cartella esiste.

Controlla gli errori di permesso nei log dopo il riavvio. Alcuni problemi di permessi appaiono solo quando l’agent tenta di aggiornare la configurazione, scrivere una skill, salvare un file generato o aggiornare lo stato del gateway.

I File di Backup Possono Essere Localizzati e Ripristinati

Un backup è incompleto finché non puoi localizzarlo e ripristinarlo in una posizione di test. Al minimo, conferma che il backup contiene i dati che intendevi proteggere.

Per configurazioni importanti, ripristina il backup in una cartella separata o in un’istanza di test prima di affidarti a esso. Questo evita di scoprire problemi di ripristino solo dopo la perdita dei dati.

Accesso alla Dashboard o alla Messaggistica Funziona Ancora Dopo il Riavvio

Dopo il riavvio, verifica che l’accesso alla dashboard o alla messaggistica funzioni ancora. Questo conferma che i dati persistenti, le credenziali, le impostazioni del gateway e l’accesso alla rete sono ancora allineati.

Se la dashboard funziona ma la messaggistica fallisce, controlla le impostazioni del gateway e l’accesso al token. Se la messaggistica funziona ma i file generati scompaiono, verifica il percorso di output e i mount.

Come Funziona in un Ambiente Reale di Server Domestico

In una configurazione reale di server domestico, la stessa logica di sicurezza dei dati si applica anche quando il sistema fornisce una dashboard amichevole. È comunque necessario sapere quali dati devono sopravvivere, dove sono memorizzati, come il container li vede, quale utente può scriverci e come verificarli dopo il riavvio.

Ad esempio, il flusso di lavoro di configurazione ZimaOS Hermes Agent mostra un percorso specifico per dispositivo che include la configurazione del provider di modelli, l’impostazione del gateway Telegram, l’accesso al container Hermes, l’attivazione dell’ambiente app, il controllo della Web Dashboard e la risoluzione di problemi di permessi o risposte del bot.

Per gli utenti che eseguono app Docker, flussi di lavoro agent e servizi locali su una macchina compatta sempre accesa, ZimaBoard 2 server domestico è un esempio rilevante del tipo di ambiente server domestico leggero in cui cartelle persistenti, percorsi dei container, permessi ed espansione dello storage devono essere pianificati insieme. Non è l’unica configurazione possibile, ma corrisponde al tipo di flusso di lavoro di app self-hosted discusso in questa guida.

La lezione generale è portabile: prima di affidare a un agente containerizzato un lavoro utile, assicurati che i suoi dati importanti sopravvivano oltre il container che sta girando oggi.

FAQ

Perché i miei dati di Hermes Agent sono scomparsi dopo il riavvio del container?

Un semplice riavvio non dovrebbe cancellare i dati persistenti, ma l'app potrebbe sembrare resettata se stava scrivendo in un percorso container non persistente. I dati potrebbero anche mancare se il container è stato ricreato senza lo stesso volume o bind mount. Controlla il percorso host, il percorso container e il percorso dati effettivo dell'app prima di modificare altre impostazioni.

Qual è la differenza tra un volume Docker e un bind mount?

Un volume Docker è gestito da Docker, mentre un bind mount mappa una cartella host scelta da te all'interno del container. Un volume è spesso pulito per i dati gestiti dall'app, mentre un bind mount è più facile da individuare direttamente sull'host. La scelta migliore dipende dal fatto che tu voglia uno storage gestito da Docker o una cartella host visibile per backup e ispezione.

Dove dovrei memorizzare i dati dell'app Hermes Agent su un server domestico?

Usa una cartella persistente dedicata o un volume Docker invece di un percorso temporaneo del container. La posizione dovrebbe essere facile da eseguire il backup, limitata alle esigenze dell'app e non mescolata con file sensibili non correlati. Il punto più importante è che il percorso container previsto dall'app deve effettivamente mappare a quella memoria persistente.

Perché il container dice che una cartella non esiste?

La cartella potrebbe esistere sull'host ma non all'interno del container. Questo di solito significa che il mount non è stato creato, il percorso di origine è sbagliato, il percorso di destinazione è sbagliato o l'app sta cercando in un percorso container diverso. Controlla sia il lato host che il lato container invece di creare una nuova cartella a caso.

Devo eseguire Hermes Agent come root per evitare errori di permessi?

Eseguire come root può nascondere l'errore immediato, ma può creare file di proprietà di root e aumentare il rischio. Un approccio più sicuro è permettere all'utente dell'app previsto di leggere e scrivere solo nel percorso dati richiesto dall'app. Usa root solo per azioni amministrative o di riparazione specifiche quando comprendi la modifica.

Con quale frequenza dovrei eseguire il backup dei dati di Hermes Agent?

Esegui il backup prima di aggiornamenti, ricostruzioni del container, modifiche ai percorsi, riconfigurazioni del gateway o migrazioni su un altro server. Per un uso attivo, programma backup regolari in base alla frequenza con cui cambiano le competenze, le impostazioni, i file generati o le sessioni. Un backup non è affidabile finché non hai confermato che i file possono essere trovati e ripristinati.