Cosa sono i server immutabili?

Ci sono alcune domande sui server immutabili , come:

• Come implementare il modello di server immutabile senza perdere la capacità di fare post mortem?
• Quale ruolo svolgono gli strumenti di gestione della configurazione in un'infrastruttura immutabile?

Sembra ovvio che abbia a che fare con i server (quella parte che ottengo). E solo digerendo la grammatica dell'immutabile , penso che abbia qualcosa a che fare con "non è possibile silenziare ". Se questa ipotesi è vicina, non avrei idea di cosa esattamente non possa essere disattivato (e dubito che abbia a che fare con le schede audio o qualcosa del genere ...).

Le mie domande :

• Che cosa è in realtà un "server immutabile" (nel contesto di DevOps)?
• Perché sono usati?

Immutabilità è un termine spesso usato nei circoli informatici, che in genere si riduce a "impossibile cambiare dopo la creazione". Viene in genere utilizzato in riferimento al parallelismo, concorrenza e sicurezza dei thread.

La discussione su questo argomento è affascinante, ma generalmente si può trovare altrove su StackTranslate.it . Sto resistendo alla tentazione di immergerci qui. Il concetto chiave "non è possibile cambiare dopo la creazione".

Immagina se, su Amazon, distribuisci un servizio web inserendolo in una Machine Image (AMI - un'istanza pre-costruita che puoi ripetere il provisioning ripetutamente). Si collega a un database back-end tramite credenziali che esce da un registro all'avvio. Scarica i log in uno strumento di registrazione come Splunk. Per il normale funzionamento quotidiano, non hai motivo di entrare in questa casella. Se è necessario ridimensionare tale servizio, è sufficiente creare più istanze di tale AMI e regolare un bilanciamento del carico. La riduzione è semplicemente la distruzione di istanze e bilanciamento del carico.

Per l'operazione quotidiana, questa casella non ha motivo di cambiare . Possiamo semplicemente accendere di più dall'AMI.

Cosa succede quando è necessario fornire una patch di sicurezza a livello di sistema operativo? Questo è quando hai una decisione da prendere ... crei una nuova AMI con la patch installata e ridistribuisci tutte le istanze in esecuzione, o fai ssh in immagini esistenti e aggiorni la patch? Ci sono molte persone che vogliono semplicemente entrare. Gli aderenti all '"architettura immutabile" mi hanno appena urlato per aver persino suggerito che una cosa del genere fosse possibile.

Gli immutabilisti (se esiste una parola del genere) sostengono la cottura del nuovo ami. Sostengono la rimozione di tutte le ragioni per ssh in una macchina di sempre. Sostengono che qualsiasi configurazione specifica della macchina dovrebbe avvenire all'avvio di quella macchina estraendo i dettagli di configurazione da un repository. Questa è la massima espressione di "bestiame, non di animali domestici".

L'architettura immutabile riguarda in particolare le configurazioni della macchina che non hanno motivo di cambiare dopo la creazione dell'immagine della macchina . Se qualcosa deve cambiare, crea una nuova immagine di istanza, spegni la vecchia, fai apparire la nuova.

Le tecnologie cloud hanno spostato la frontiera tra hardware e software in modo che molte operazioni tecniche precedentemente cittadine esclusive del mondo hardware siano anch'esse oggetto del regno del software. Gli ambienti informatici condivisi potrebbero essere vecchi quanto i computer stessi ¹ ma le tecnologie cloud potrebbero diffonderli offrendo metafore comode e familiari per interagire con loro: gli utenti cloud riservano un'istanza, un computer completo o un mimo, mentre gli ambienti informatici condivisi più vecchi hanno tutte le impostazioni possibili di limitazioni ingombranti e "il tuo programma deve essere caricato su quel server FTP, verrà eseguito in ambiente X (di solito con una versione di 10 anni di qualsiasi software che si desidera utilizzare), per un massimo di 60 minuti" potrebbe sembrare familiare agli utenti precedenti o effettivi dei centri di calcolo.

La conseguenza pratica di questo spostamento è che le procedure di implementazione possono ora essere rappresentate da artefatti software. (Le procedure di distribuzione sono le istruzioni che spiegano come configurare un'infrastruttura, con database, web server o qualunque cosa appartenga a questa infrastruttura, insieme alla rete su cui vengono eseguiti.) Equipaggiato con questi nuovi obiettivi, la manutenzione manuale dei server sembra quasi patching manuale del codice di produzione - che è solo in rare occasioni una cosa desiderabile. La manutenzione manuale è suscettibile di introdurre discrepanze tra i sistemi effettivamente in esecuzione in produzione e il codice che descrive questi sistemi, il che a sua volta significa comportamento irreproducibile e analisi di bug impossibile, correzione di due bug e altre calamità.

Il modello di server immutabile è solo la trasposizione per le operazioni cloud del mantra sopra, in base al quale dovremmo evitare la manutenzione manuale dei programmi in esecuzione. Invece di configurare manualmente i server, il modello di server immutabile consiglia di automatizzare questa configurazione.

Aromi di implementazione

Mentre l'idea generale del modello di server immutabile è abbastanza chiara, ci sono molte sfumature di implementazione. Ad esempio, alcuni approcci suggeriscono di non aggiornare affatto i server ma di sostituire sistematicamente i server. Questo perché l'aggiornamento produce una situazione in cui una distribuzione è costituita da server che sono stati avviati in diversi momenti distinti e che hanno attraversato diversi processi di aggiornamento distinti, il che implica un insieme disomogeneo di server e può portare a sottili differenze nel modo in cui i server gestiscono i loro lavori. Un secondo punto di variazione popolare è la disciplina relativa all'accesso remoto ai server. Ad alcuni piace disabilitare l'accesso amministrativo remoto completo ai server, al fine di garantire che la manutenzione manuale non avvenga mai.

Nota storica

Per quanto ne so, il termine "server immutabile" è stato reso popolare da Kief Morris, ma l'idea stessa è molto più antica. Nel 1999 le jail di FreeBSD hanno già reso popolare l'idea di automatizzare completamente la configurazione degli ambienti di elaborazione usa e getta, è così che ho iniziato a implementare il modello di "server immutabile" molti anni prima di sentire questo nome per descrivere questa tecnica.

L'immutabilità, sotto forma di immutabilità fisica basata su CD-ROM, è stata anche una misura popolare per produrre sistemi di elaborazione affidabili. Questo non deve essere confuso con il modello di server immutabile.

I server immutabili sono server su cui non è possibile apportare modifiche (se non idealmente aggiornamenti e patch di sicurezza). Invece di modificare il software sul server, si esegue lo spooling di un nuovo server con il software desiderato e quindi si termina quello precedente.

Questo concetto aiuta a garantire che test, sviluppo e server QA siano tutti identici, il che è importante per molteplici ragioni al di fuori dell'ambito di questa domanda. Un altro vantaggio dei server immutabili è la possibilità di eseguire il rollback dell'applicazione su un server più vecchio. Ad esempio, ho bisogno di cambiare K sul server di produzione 1, quindi eseguo lo spooling del server 2 e cambio K. Ora dopo 10 minuti, noto che K ha rotto qualcosa con la mia applicazione, piuttosto che doverlo riparare subito che potrebbe richiedere ore e potenzialmente causando tempi di inattività per i miei clienti, reindirizzo il traffico al server 1, mentre capisco cosa non va in 2.

La migliore spiegazione può essere trovata (come sempre) nell'articolo bliki di Martin Fowler su Immutable Server .

Un server, sia esso hardware o un server virtuale nel cloud, di solito ha un sistema operativo e un'applicazione in esecuzione su di esso.

Spesso l'applicazione e i componenti del sistema operativo richiedono la configurazione e l'applicazione delle modifiche. Ad esempio patch di sicurezza, distribuzione di nuove versioni dell'applicazione e modifiche alla configurazione.

Se si considera che qualsiasi modifica è una mutazione sullo stato del server, il termine immutableinizia a dare più senso. Significa che non sono consentite mutazioni su tale server.

Spesso accade quando le persone sono coinvolte nella modifica dello stato del server, che si tratti di una distribuzione di una versione, di una modifica della configurazione o di un percorso di sicurezza. Il risultato è un server che non funziona più come previsto. Ad esempio, l'applicazione potrebbe non essere in esecuzione ora a causa di un'errata configurazione, ecc.

Ecco perché viene stabilita una pratica per la creazione di server immutabili . Con server immutabili , viene creata un'immagine di un server con tutte le configurazioni, le patch e le versioni dell'applicazione raggruppate. Quindi l' immagine del server può essere utilizzata per creare server in vari ambienti.

Il primo ambiente in cui viene utilizzata tale immagine , sarebbe un ambiente in cui l'immagine può essere testata per funzionare. Vengono rilevate eventuali anomalie e solo allora una tale immagine può essere promossa in un ambiente di produzione per sostituire i server lì con la nuova versione (che è noto per funzionare bene).

Una volta automatizzato il processo di creazione delle immagini e promozione delle immagini, si ottiene un processo a prova di fallimento che comporta uno sforzo umano molto ridotto e una probabilità molto bassa di introdurre guasti nel servizio.

Spesso i server immutabili non includono nemmeno alcun modo per "inserirli", come ad esempio manca il server ssh. In questo caso, spesso accade anche che tutta la metrologia di un server (metriche, registri) sia spedita a sistemi esterni come un database di metriche o un servizio di aggregazione dei registri.

Con i contenitori (vedi: Docker ) esiste anche un processo per creare immagini e quindi generarle in contenitori in esecuzione. Questi sono abbastanza spesso sostituiti da nuovi contenitori basati su immagini aggiornate e non sono mai mutati. Ciò significa che nessun essere umano entra nel contenitore per "riparare qualcosa" introducendo un cambiamento.

Cominciamo con l'inverso, che cos'è un server mutabile?

Tradizionalmente, un'infrastruttura server mutabile è quella che viene continuamente modificata e aggiornata sul posto. È possibile proteggere la shell al suo interno, aggiornare i pacchetti, configurarlo, installare i servizi e distribuire ad esso un nuovo codice. Questo è ciò che lo rende mutevole, puoi mutarlo o modificarlo.

Un'infrastruttura immutabile è un altro paradigma dell'infrastruttura in cui i server non vengono mai modificati dopo essere stati distribuiti. Se qualcosa deve essere aggiornato, riparato o modificato in qualche modo, vengono forniti nuovi server creati da un'immagine comune con le modifiche appropriate per sostituire quelli vecchi. Dopo essere stati convalidati, vengono messi in uso e quelli vecchi vengono disattivati.

Perché sono usati? I vantaggi di un'infrastruttura immutabile sono maggiore coerenza e affidabilità nella propria infrastruttura e un processo di distribuzione più semplice e prevedibile e mitiga i problemi comuni del server nell'infrastruttura mutevole, come i tempi di inattività del server o altro.

Ma devi sapere come effettuare il provisioning in modo efficiente tramite automazioni di distribuzione complete e provisioning rapido dei server.

Immagina di estrarre bitcoin, non vorresti alcun tempo di inattività se il tuo server si arrestasse in modo anomalo, avresti bisogno di eseguirne il backup il più velocemente possibile, quindi si suppone che un'infrastruttura immutabile sia la soluzione.