L'aggiornamento della produzione Ubuntu inscatola cose da fare e da non fare

Ogni tanto accedo alle caselle di produzione web / db / tools e vedo il tipico messaggio:

30 pacchetti possono essere aggiornati. 16 aggiornamenti sono aggiornamenti di sicurezza.

La mia domanda è: come gestite tutti gli aggiornamenti sulle vostre scatole Ubuntu di produzione? Automatizzi questi aggiornamenti? Imposti tempi di fermo per loro? Il problema è che non si sa mai quando un aggiornamento romperà qualcosa, come forse un file di configurazione esistente, ecc.

L'altra parte di questo problema è che tenere il passo con le patch è "una buona cosa", ma le patch vengono rilasciate quasi quotidianamente. Quante interruzioni programmate bisogna fare se è disponibile una nuova patch di sicurezza ogni giorno?

Penso che un thread sulle risposte su come gestisci i tuoi aggiornamenti sarebbe molto utile.

Non c'è niente di speciale nel patchare Ubuntu su Windows, RHEL, CentOS, SuSE, debian, ecc.

Lo stato d'animo di base in cui devi essere presente durante la progettazione della procedura di patch è quello di supporre che qualcosa si rompa.

Alcune delle linee guida di base che tendo a usare quando si progetta una configurazione di patch sono:

• Utilizzare sempre un sistema locale per centralizzare internamente alla propria rete da cui sono installate le patch

Ciò può includere l'utilizzo di WSUS o mirroring di <your_os_here>una macchina di gestione delle patch interna. Preferibile uno che può interrogare centralmente e farti conoscere lo stato delle patch installate sui singoli computer.

• Pre-stage le installazioni - quando possibile - sulle macchine.

Quando è possibile, man mano che escono le patch, è necessario che il server centrale li copi nei singoli computer. Questo è davvero solo un risparmio di tempo in modo da non dover aspettare che scarichino E installino, devi solo dare il via all'installazione durante la finestra della patch.

• Ottieni una finestra di interruzione per installare le patch, potresti dover riavviare e probabilmente qualcosa si romperà. Assicurarsi che i portatori di interessi di tali sistemi siano consapevoli della presenza di patch distribuite. Preparati per le chiamate "this" non funziona.

In accordo con la mia teoria di base secondo cui le patch rompono le cose, assicurati di avere una finestra di interruzione per applicare le patch abbastanza a lungo per risolvere i problemi critici e possibilmente ripristinare la patch. Non è necessario che le persone sedute li testino dopo le patch. Personalmente mi affido fortemente ai miei sistemi di monitoraggio per farmi sapere che tutto funziona al livello minimo con cui possiamo farcela. Ma sii anche pronto a chiamare piccoli problemi fastidiosi quando le persone si mettono al lavoro. Dovresti sempre avere qualcuno in programma di essere lì pronto a rispondere al telefono - preferibilmente non il ragazzo che era in piedi fino alle 3 del mattino per riparare le scatole.

• automatizzare il più possibile

Come ogni altra cosa nell'IT, negli script, negli script e poi ancora negli script. Script il download del pacchetto, l'avvio dell'installazione, il mirror. Fondamentalmente vuoi trasformare le patch windows in un compito di baby-sitter che ha solo bisogno di un essere umano lì in caso le cose si rompano.

• Avere più finestre ogni mese

Questo ti dà la possibilità di non patchare alcuni server se per qualsiasi motivo non possono essere patchati nella "notte designata". Se non riesci a eseguirli la notte 1, richiedi che siano liberi la notte 2. Ti consente inoltre di mantenere sano il numero di server patchati allo stesso tempo.

Soprattutto tenere il passo con le patch! In caso contrario, ti ritroverai a dover applicare finestre di patch di 10+ ore molto grandi solo per tornare al punto in cui sei stato catturato. Introducendo ancora più punti in cui le cose potrebbero andare storte e rendendo più difficile trovare quale patch ha causato ed emettere.

L'altra parte di questo problema è che tenere il passo con le patch è "una buona cosa", ma le patch vengono rilasciate quasi quotidianamente. Quante interruzioni programmate bisogna fare se è disponibile una nuova patch di sicurezza ogni giorno?

Patching di un server una volta al mese o una volta ogni due mesi è - IMHO - un obiettivo molto realizzabile e accettabile. Più di questo, e beh, continuerai a correggere i server, molto meno e inizi a trovarti in situazioni in cui hai centinaia di patch che devono essere applicate per server.

Per quanto riguarda quante finestre ti servono al mese? Dipende dal tuo ambiente. Quanti server hai? Qual è il tempo richiesto per i tuoi severs?

Gli ambienti più piccoli che sono 9x5 possono probabilmente cavarsela con una finestra patch al mese. I grandi negozi 24x7 potrebbero averne bisogno di due. 24x7x365 molto grandi potrebbero aver bisogno di una finestra mobile ogni settimana per avere una serie diversa di server patchati ogni settimana.

Trova una frequenza che funzioni per te e il tuo ambiente.

Una cosa da tenere a mente è che il 100% aggiornato è un obiettivo impossibile da raggiungere - non lasciare che il tuo dipartimento di sicurezza ti dica diversamente. Fai del tuo meglio, non rimanere troppo indietro.

Cose da fare:

1. Fai un backup
2. Assicurati che sia un backup ripristinabile (anche se, questi due sono punti generali)
3. Cerca di indirizzare il traffico lontano dal box di produzione durante l'aggiornamento.
4. Prova ad avere un metodo di accesso fuori banda nel caso in cui tutto vada storto, KVM, console seriale, accesso locale o mani remote.
5. Prova su un server, quindi assicurati che tutto funzioni, prima di distribuire gli aggiornamenti su più server
6. Utilizzare le marionette se è possibile assicurarsi che i numeri di versione siano gli stessi su più server. (Puoi anche usarlo per forzare gli aggiornamenti)
7. Su un server di prova, differisci le versioni dei file di configurazione rispetto a quelle nuove (aggiornamento installato) e assicurati che nulla possa danneggiare seriamente le cose. Mi sembra di ricordare dpkg chiedendo prima di installare nuove versioni che differiscono da quelle attualmente installate.

Cose da evitare:

1. Aggiornamenti a metà giornata o alle 09:00 di lunedì mattina o alle 17:00 di venerdì pomeriggio! (grazie @ 3influenza!)
2. Aggiornamento di MySQL su server di database molto grandi (il riavvio potrebbe richiedere molto tempo)
3. Fare tutti i tuoi server contemporaneamente (specialmente i kernel)
4. Fare qualcosa che potrebbe cambiare / etc / networks (perché potresti perdere la connettività)
5. Aggiornamenti automatici che potrebbero fare quanto sopra senza che tu sia lì per verificare che tutto sia OK.

Un altro punto degno di nota: se sei abituato a Windows, rimarrai sorpreso dal fatto che la maggior parte degli aggiornamenti di Linux non richiede tempi di inattività o riavvio. Alcuni lo fanno, come gli aggiornamenti del kernel. Ma gli aggiornamenti che richiedono il riavvio o i tempi di inattività sono in genere contrassegnati come tali e possono essere gestiti su una pianificazione separata.

Le nostre macchine Ubuntu eseguono tutte le versioni LTS.

Installiamo automaticamente automaticamente tutti gli aggiornamenti, assicurandoci che non siano "best practice", ma siamo un negozio relativamente piccolo e non abbiamo un ambiente di test / sviluppo / produzione per ogni singolo servizio. Gli aggiornamenti LTS sono generalmente abbastanza ben testati e comunque minimamente invasivi.

L'aggiornamento a una nuova versione è ovviamente un po 'più complicato.

Ci occupiamo degli aggiornamenti nel modo seguente per i sistemi Ubuntu LTS:

1. Maitain una serie di test di collaudo che controllano tutti i percorsi critici nel nostro software
2. Installa gli aggiornamenti di sicurezza senza sorveglianza alle 4 del mattino ogni mattina ed esegui immediatamente i test di accettazione. Se qualcosa non riesce, un ingegnere viene chiamato e ha un sacco di tempo per sistemare le cose o tornare prima delle 9:00. Questo è successo finora solo due volte in cinque anni - LTS è ben collaudato e stabile.
3. Ridistribuiamo automaticamente la nostra intera infrastruttura ogni settimana (su digitalocean) con distribuzioni blu / verdi, che mantengono tutti i pacchetti alle ultime versioni. Se una nuova distribuzione non supera i test di accettazione, la distribuzione rimane in attesa fino a quando un tecnico non può eseguire il debug del problema.

Il prossimo passo logico per noi è eliminare le informazioni sulla sessione in memoria in modo da poter semplicemente ridistribuire l'infrastruttura ogni giorno o anche più volte al giorno senza influire sui clienti ed eliminare il passaggio (2).

Questo approccio richiede poca manutenzione ed evita completamente le finestre di manutenzione.

Una cosa che consiglierei è la gestione dei rollback dei pacchetti. Vedi Transazioni e rollback con Debian per un suggerimento su come farlo, poiché a volte hai bisogno di una soluzione rapida per un aggiornamento che rompe qualcosa.