L'aggiornamento della produzione di Ubuntu racchiude le cose da fare e da non fare

Soluzione 1:

Non c'è niente di speciale nell'applicare patch a Ubuntu rispetto a Windows, RHEL, CentOS, SuSE, debian, ecc.

Lo stato mentale di base in cui devi trovarti quando progetti la tua procedura di patch è presumere che qualcosa verrà pausa.

Alcune delle linee guida di base che tendo ad usare durante la progettazione di una configurazione di patch sono:

• Utilizza sempre un sistema locale per centralizzare internamente la tua rete da cui vengono installate le patch

Ciò può includere l'utilizzo di WSUS o mirror di <your_os_here> a una macchina di gestione delle patch interna. Preferibile uno che possa interrogare centralmente e farti conoscere lo stato delle patch installate sulle tue singole macchine.

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

Quando è possibile, man mano che le patch escono, chiedi al server centrale di copiarle sulle singole macchine. Questo è davvero solo un risparmio di tempo in modo da non dover aspettare che vengano scaricati E installati, devi solo avviare l'installazione durante la finestra della patch.

• Ottieni una finestra di interruzione in cui installare le patch, potresti dover riavviare e probabilmente qualcosa si romperà. Assicurati che le parti interessate di questi sistemi siano a conoscenza della distribuzione di patch. Preparati alle chiamate "questo" non funziona.

In linea 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 da risolvere i problemi critici ed eventualmente ripristinare la patch. Non hai necessariamente bisogno di avere persone sedute lì a testare dopo le patch. Personalmente faccio molto affidamento sui miei sistemi di monitoraggio per farmi sapere che tutto funziona al livello minimo che possiamo farla franca. Ma preparati anche a piccoli problemi fastidiosi da affrontare quando le persone si mettono al lavoro. Dovresti sempre avere qualcuno programmato per essere lì pronto a rispondere al telefono, preferibilmente non il ragazzo che è stato sveglio fino alle 3 del mattino ad aggiustare le scatole.

• automatizzare il più possibile

Come tutto il resto nell'IT, script, script e poi script ancora. Script il download del pacchetto, l'avvio dell'installazione, il mirror. Fondamentalmente vuoi trasformare le finestre di patch in un incarico di baby sitter che ha solo bisogno di un essere umano lì nel caso in cui le cose si rompano.

• Avere più finestre ogni mese

Questo ti dà la possibilità di non applicare patch ad alcuni server se per qualsiasi motivo non possono essere patchati "la notte stabilita". Se non puoi eseguirli la notte 1, richiedi che siano liberi la notte 2. Inoltre ti consente di mantenere il numero di server con patch corretti contemporaneamente.

La cosa più importante è tenere il passo con le patch! In caso contrario, ti ritroverai a dover eseguire finestre di patch di oltre 10 ore solo per tornare al punto in cui sei stato raggiunto. Introducendo ancora più punti in cui le cose potrebbero andare storte e rendendo molto più difficile trovare quale patch ha causato e problema.

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 pianificate si devono effettuare se ogni giorno è disponibile una nuova patch di sicurezza?

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

Per quanto riguarda quante finestre hai bisogno di un mese? Dipende dal tuo ambiente. Quanti server hai? Qual è il tempo di attività richiesto per i tuoi server?

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

Trova una frequenza adatta a te e al tuo ambiente.

Una cosa da tenere a mente è che essere aggiornati al 100% è impossibile obiettivo da raggiungere:non lasciare che il tuo dipartimento di sicurezza ti dica diversamente. Fai del tuo meglio, non restare troppo indietro.

Soluzione 2:

Cose da fare:

1. Fai un backup
2. Assicurati che sia un backup ripristinabile (anche se questi due sono punti generali)
3. Prova a dirigere il traffico lontano dalla casella di produzione durante l'upgrade.
4. Cerca di avere un metodo di accesso fuori banda nel caso in cui tutto vada storto, KVM, console seriale, accesso locale o mani remote.
5. Esegui il test su un server, quindi assicurati che tutto funzioni, prima di distribuire gli aggiornamenti su più server
6. Usa il pupazzo se puoi per assicurarti che i numeri di versione siano gli stessi su più server. (Puoi anche usarlo per forzare gli aggiornamenti)
7. Su un server di prova, confronta le versioni dei file di configurazione con quelle nuove (aggiornamento installato) e assicurati che nulla possa seriamente danneggiare le cose. Mi sembra di ricordare che dpkg chiedesse prima di installare nuove versioni diverse 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 @3influence!)
2. Aggiornamento di MySQL su server di database molto grandi (il riavvio potrebbe richiedere molto tempo)
3. Eseguire tutti i tuoi server contemporaneamente (specialmente i kernel)
4. Fare qualsiasi cosa che potrebbe cambiare /etc/networks (perché potresti perdere la connettività)
5. Aggiornamenti automatici che potrebbero fare quanto sopra senza che tu sia lì per controllare che tutto sia a posto.

Soluzione 3:

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

Soluzione 4:

Le nostre macchine Ubuntu eseguono tutte versioni LTS.

Installiamo automaticamente tutti gli aggiornamenti, certo non è una "best practice", ma siamo un negozio relativamente piccolo e non disponiamo di 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.

Soluzione 5:

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

1. Mantieni una serie di test di accettazione che verificano tutti i percorsi critici nel nostro software
2. Installa automaticamente gli aggiornamenti di sicurezza ogni mattina alle 4 del mattino ed esegui immediatamente i test di accettazione. Se qualcosa fallisce, viene chiamato un tecnico e ha tutto il tempo per sistemare le cose o tornare indietro prima delle 9:00. Finora è successo solo due volte in cinque anni:LTS è ben collaudato e stabile.
3. Ridistribuiamo automaticamente la nostra intera infrastruttura ogni settimana (su digitalocean) con implementazioni blu/verdi, che mantengono tutti i pacchetti alle versioni più recenti. Se una nuova distribuzione non supera i test di accettazione, la distribuzione viene sospesa 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.