Come implementare il modello di server immutabile senza perdere la capacità di fare post mortem?

Il modello di server immutabile è una disciplina di distribuzione che favorisce la riproducibilità delle distribuzioni. È caratterizzato dal fatto che " un server che una volta distribuito non viene mai modificato, ma semplicemente sostituito con una nuova istanza aggiornata " e l'implementazione di questa disciplina richiede un'automazione della distribuzione del server. Questa automazione presenta numerosi vantaggi operativi, uno dei più importanti è consentire la sostituzione rapida e affidabile di istanze difettose in un'infrastruttura. Questa automazione implica anche che la distribuzione del server è descritta da artefatti software con versione ed è soggetta a miglioramenti iterativi.

Un aspetto popolare delle implementazioni di questa disciplina è la rimozione dei metodi di accesso remoto al server una volta avviato (in particolare rimozione dell'accesso SSH). La rimozione dell'accesso remoto è un modo semplice per garantire che la configurazione del server corrisponda alla configurazione preparata dall'automazione della distribuzione.

Tuttavia, quando si studiano le cause di un errore del software in un periodo post mortem , basarsi su un monitoraggio strutturato non è sempre sufficiente e potrebbe essere necessario l'accesso remoto alla macchina. È una situazione pratica comune che il monitoraggio del server non copre tutte le fonti di errore o che il monitoraggio può essere compromesso dall'errore del server stesso, il che sarebbe probabilmente il caso se il server esaurisce la memoria o raggiunge il limite del processo.

Come implementare il modello di server immutabile senza perdere la capacità di fare post mortem?

Prima di tutto, rimuovere ssh su un server immutabile non garantisce che non ci saranno cambiamenti, è più che, poiché non dovrebbe essere necessario cambiare qualcosa, riduci la superficie di attacco rimuovendo un canale di accesso remoto.

Un modo per mantenere una sorta di post mortem è la centralizzazione dei log. Ci sono una miriade di metodi per ottenerlo, stack ELK, Splunk, syslog ...

Un altro modo più grezzo per mantenere un post mortem per un server immutabile è quello di avere uno script sul processo di spegnimento (un fallimento del server immutabile sarebbe l'arresto e un nuovo spin up per sostituirlo) per raccogliere un core dump del programma, un dump della memoria e inviarli a un sistema remoto per l'analisi insieme alla maggior parte dei registri.

Il vantaggio principale di questa soluzione è che si ottengono solo informazioni di sistema non riuscite al momento del problema, consentendo di raccogliere informazioni più grandi rispetto a riceverle periodicamente.

È difficile essere più specifici su come raggiungere questo obiettivo, ogni distribuzione ha un modo per ottenere le cose e non ho un esempio generico.

Il fatto che non si disponga dell'accesso SSH non significa che non sia possibile accedere alla macchina. Molto probabilmente lo eseguirai su qualche operatore cloud, dove puoi anche fare quanto segue:

• scattare un'istantanea della macchina. Potresti semplicemente scattare un'istantanea della scatola prima di distruggerla, per un'analisi successiva.
• accedere alla macchina tramite la console. Probabilmente dovrai avere la password di root per questo, ma alcuni provider cloud possono iniettare una password di root casuale per l'accesso alla console in qualsiasi momento.

Si tratta essenzialmente di un accesso "fisico" al tuo computer e sarà disponibile anche se rimuovi altri tipi di accesso. Tuttavia, potresti limitare anche queste interfacce.

A parte questo, come ha affermato @Tensibai, la cosa migliore da fare è impostare correttamente la registrazione e il monitoraggio, quindi ogni volta che dovrai fare un post mortem, ci sono abbastanza dati disponibili per farlo.