HestiaCP genera configurazioni per domini e servizi che gestisce. Se un playbook Ansible modifica gli stessi file senza rispettare quel processo, un rebuild del pannello può cancellare il lavoro oppure il playbook può annullare una modifica fatta dal pannello.
Nei runbook Romiltec la regola è usare prima i comandi nativi Hestia per le funzionalità del pannello. L’automazione deve rendere quel flusso ripetibile, mantenendo chiaro chi produce ogni configurazione e come verificarla.
Assegnare una responsabilità a ciascun file
Per un dominio distinguerei dati gestiti da Hestia, template selezionato e configurazione generata. Una modifica fatta direttamente al risultato del template può funzionare fino alla successiva rigenerazione.
Hestia documenta i template web personalizzati. Se serve una variante, userei un nome distinto e la procedura prevista per assegnarla, evitando di modificare i template predefiniti che gli aggiornamenti possono sostituire.
Ansible può distribuire questi file e richiamare operazioni native, oltre a gestire componenti esterni al pannello. Il confine non è “non toccare mai nginx”: è evitare che due strumenti si considerino entrambi proprietari indipendenti della stessa configurazione.
Lo stato desiderato deve includere ciò che gira
Un file corretto su disco non dimostra che il servizio lo abbia caricato. Per una configurazione nuova prevederei validazione, reload quando appropriato e verifica del comportamento dopo il reload.
Gli handler aiutano a eseguire l’operazione quando cambia un task che li notifica. Non sostituiscono però il controllo dello stato attivo: se file e runtime divergono per un intervento precedente, un task che non cambia il file può non richiamare l’handler.
Per un parametro del kernel confronterei valore persistente e valore effettivo. Per un sito controllerei risposta pubblica, pool PHP selezionato e un’operazione rappresentativa. Il contenitore di test deve riprodurre i vincoli rilevanti: una verifica in Docker non dimostra automaticamente il comportamento dei sysctl su LXC.
Check mode e diff hanno limiti precisi
La documentazione Ansible descrive check mode come simulazione per i moduli che lo supportano. Alcuni task vengono saltati; altri dipendono da risultati che in quella modalità non sono disponibili.
# Esempio: inventario e playbook già definiti e revisionati
ansible-playbook -i inventory/hosts.yml site.yml --check --diff --limit nodo_testPrima di lanciarlo controllerei eventuali task con check_mode: false: possono eseguire modifiche anche durante il check. L’esecuzione normale avviene senza --check; non esiste un flag generale --apply da aggiungere.
Il diff può esporre segreti nei file. Per i task sensibili servono impostazioni appropriate, come diff: false e protezione dei log quando necessaria. Conservare una password in un vault non impedisce che il suo valore finisca nell’output di un task scritto male.
Dimostrare l’idempotenza su un caso utile
Proverei una prima applicazione, una seconda senza cambiamenti attesi e una modifica intenzionale. Il secondo giro dovrebbe lasciare stabile ciò che è già corretto; il terzo dovrebbe aggiornare soltanto il perimetro previsto.
Non imposterei changed_when: false per far sparire rumore senza aver capito la semantica del comando. Allo stesso modo, sopprimere un errore con failed_when: false può trasformare un fallimento operativo in un report verde.
Nel collaudo includerei un rebuild Hestia del dominio di prova. Se la personalizzazione scompare o Ansible ripristina dati superati, il conflitto di responsabilità è ancora presente.
Distribuire con un criterio di arresto
Userei un nodo rappresentativo per il primo passaggio e poi gruppi limitati. Le opzioni di esecuzione Ansible, tra cui serial, permettono di controllare il rollout; il numero adatto dipende dalla ridondanza e dal carico.
Definirei quali controlli fermano il lotto successivo e quale configurazione precedente è recuperabile. La presenza di un handler di restart non è una promessa di assenza di disservizio.
Nel report finale mi interessano host raggiunti, modifiche effettive, errori e verifiche funzionali. Un’automazione utile lascia a chi mantiene la fleet una risposta leggibile su cosa è cambiato e perché, senza costringerlo a ricostruirla tra centinaia di righe di output.