Best practice per gli aggiornamenti automatici di Linux

Stiamo lavorando su un modo per eseguire aggiornamenti automatici per i nostri server basati su RHEL / RHEL.

Idea iniziale: Usando Puppet, disabilitiamo i repository predefiniti e puntiamo ai nostri. Quindi, utilizziamo ensure => latestper i pacchetti che vogliamo aggiornare automaticamente.

Problema: stiamo assistendo al riavvio di alcuni servizi dopo un aggiornamento (duh).

Domanda: Qualcuno ha qualche consiglio su come automatizzare meglio gli aggiornamenti e le strategie di Linux sulla mitigazione del riavvio automatico dei servizi? Preferiremmo una soluzione che includesse Puppet ma, se avessimo bisogno di usare un altro servizio, non sarebbe un problema.

modificare

Possibile soluzione: ho presentato una soluzione che implementa molti dei suggerimenti di @ voretaq7 e @ewwhite. Sembra che questa sia la strada che sto percorrendo per il momento. Se hai altri suggerimenti, commenta o invia una risposta.

La tua strategia di aggiornamento generale è valida: hai un repository locale (che suppongo testerai in un ambiente di sviluppo) e aggiorni tutto in base a quel repository (presumo bene noto).

La cosa di riavvio del servizio è inevitabile: se il codice sottostante è cambiato, è necessario riavviare il servizio affinché la modifica abbia effetto. In caso contrario, si possono verificare conseguenze peggiori (l'esecuzione del codice non sincronizzato con una libreria condivisa porta a un arresto anomalo dell'applicazione).
Nel mio ambiente considero le finestre di patch trimestrali come trimestrali "REBOOT TUTTE LE COSE!" anche windows. Il vantaggio di tale politica è che sai che i tuoi server torneranno dopo un riavvio e sai che funzioneranno correttamente (perché li testerai regolarmente).

Il mio miglior consiglio è di pianificare le versioni del software (forse questo significa che dovrete attivarle "manualmente" con le marionette) e avvisare i vostri utenti dei tempi di manutenzione / inattività pianificati.
In alternativa (o come parte di questo) è possibile configurare la ridondanza nel proprio ambiente in modo da poter riavviare alcune macchine o servizi e fornire comunque servizio agli utenti finali. Ciò potrebbe non eliminare completamente eventuali interruzioni, ma può aiutare a minimizzarle.

La ridondanza aggiunta ti protegge anche in caso di guasti hardware, che sono inevitabili su una scala temporale abbastanza lunga.

C'è necessariamente un problema con il riavvio di un servizio dopo un aggiornamento del pacchetto? Test su piccola scala prima di distribuire per vedere se ci sono problemi. Di recente ho avuto un brutto problema con il pacchetto rpmforge di DenyHosts . In realtà ha cambiato la posizione della sua configurazione e le directory di lavoro tra le revisioni da un aggiornamento yum. Questo è un comportamento totalmente indesiderato. In genere, all'interno della stessa revisione di RHEL, non ci sono troppi problemi, ma non si può mai essere sicuri senza testare e osservare da vicino gli effetti.

Un'altra opzione è quella di aggiornare selettivamente i servizi. Hai sempre bisogno degli ultimi pacchetti, per esempio? Ciò risale alla comprensione dei motivi per l'esecuzione degli aggiornamenti. Qual è il vero obiettivo?

Il vantaggio di eseguire il proprio repository è che è possibile organizzare rilasci o implementazioni e gestire la pianificazione. Cosa succede se si dispone di una periferica hardware o di un fornitore di software che richiede RHEL 5.6 e si romperà sotto 5.7? Questo è uno dei vantaggi della gestione dei tuoi pacchetti.

@Beaming Mel-Bin

La semplificazione eliminerà la necessità di utilizzare ssh per gli strumenti ad anello, per avviare / arrestare il pupazzo.

Prima di tutto dovrai cambiare i tuoi manifest per includere una variabile chiamata "noop" il cui valore proviene dall'ENC.

Quindi avresti qualcosa del genere in una classe:

noop => $noop_status

Dove noop_statusè impostato nella tua ENC. Quando si imposta il valore di noop_statusa true, manifest si eseguirà solo in modalità noop.

Se hai 100 o 1000 host, puoi utilizzare un ENC come Dashboard o Foreman che ti consente di modificare i parametri di massa per molti host, ereditandoli a livello di "Hostgroup" o "Dominio". È quindi possibile impostare il valore su "false" per un numero limitato di host di test, sovrascrivendo il valore Hostgroup.

Con ciò, tutte le modifiche vengono applicate solo agli host selezionati.

La modifica di un parametro in una posizione centrale può influire su un numero qualsiasi di host, senza la necessità di attivare / disattivare le marionette con ssh per gli strumenti del ciclo. Puoi dividere i tuoi host in più gruppi per sicurezza / gestione.

Si noti inoltre che invece di codificare in modo rigido i numeri di versione del pacchetto nei manifest, è possibile inserirli nell'ENC. E proprio come sopra, puoi applicare in modo selettivo le modifiche e gestire le implementazioni.

Se vuoi più granularità (e complessità) puoi anche avere parametri per classe, simili noop_status_apacheClasse così via.

Questo potrebbe essere più difficile da gestire se si fanno includelezioni in altre classi.

Possibile soluzione basata sulla risposta di @ voretaq7:

1. Numeri di versione del codice fisso dei pacchetti nei puppetmanifest e gestione dei pacchetti nel nostro repository.

2. Quando richiediamo che una nuova versione di un pacchetto faccia qualcosa che offre (es. Miglioramenti della sicurezza, funzionalità richieste dai nostri clienti, ecc.), Scarichiamo il pacchetto nel repository.

3. Testare il pacchetto aggiornato su un server di prova.

4. Una volta testato l'aggiornamento, utilizzare qualcosa di simile funco psshper disattivare l' puppetagente sui nodi interessati.

5. Aggiorna i puppetmanifest per assicurarti che la nuova versione del pacchetto sia installata sui nodi interessati.

6. Infine, esegui puppet agent --onetime && rebootsul server utilizzando funcopssh

Si prega di commentare e farmi sapere se si individuano eventuali carenze in questa soluzione o qualcosa che potrebbe essere semplificato.