Buone pratiche per la gestione degli aggiornamenti dei pacchetti per molti server CentOS

Come parte del mio lavoro gestisco alcune decine di server CentOS 5, usando il pupazzo per l'installazione principale. Circa la metà dei nostri server ha una configurazione standardizzata per l'hosting di vari siti di django, mentre il resto è un misto di applicazioni.

Sto gradualmente sistemando le nostre pratiche di hosting e ora sono arrivato al punto di capire come gestire gli aggiornamenti di sicurezza a livello di sistema operativo. Sono diffidente nei confronti di un semplice lavoro cron, yum -y updatema non voglio nemmeno dover girare ogni server in tempo e rivedere ogni pacchetto con gli aggiornamenti disponibili, poiché ciò richiederebbe un po 'di tempo.

Quindi mi chiedo se ci siano buone scorciatoie o pratiche di lavoro che minimizzino i rischi e minimizzino il tempo che devo dedicare. O per dirla in altro modo, ci sono strumenti o pratiche che possono automatizzare gran parte del lavoro e allo stesso tempo dare il controllo.

Passaggi che ho deciso finora:

• disabilita tutti i repository di terze parti e imposta il nostro repository in modo che io possa controllare quali aggiornamenti passano lì.
• abbiamo server di gestione temporanea per (la maggior parte) dei nostri server di produzione dove potrei fare dei test (ma quanti test sono sufficienti?)

Nota anche che ho esaminato il plug-in di sicurezza yum ma non funziona su CentOS .

Quindi, come gestite gli aggiornamenti per un numero significativo di server CentOS che eseguono un array eterogeneo di applicazioni?

Nella maggior parte dei miei ambienti, di solito è uno script kickstart e post-installazione per rendere il sistema principale aggiornato e aggiornato con gli aggiornamenti in quel momento. Di solito avrò un repository locale che si sincronizza con un mirror CentOS ogni giorno o ogni settimana. Tendo a congelare il pacchetto del kernel in qualsiasi momento al momento dell'installazione e ad aggiornare i pacchetti singolarmente o se necessario. Spesso, i miei server hanno periferiche che hanno driver strettamente collegati alle versioni del kernel, quindi è una considerazione.

CentOS 5 è maturato al punto in cui non sono necessari aggiornamenti costanti. Ma tieni anche presente che CentOS 5 si sta esaurendo. La velocità degli aggiornamenti è leggermente rallentata e la natura degli aggiornamenti è più in linea con le correzioni dei bug e meno sulle principali modifiche alle funzionalità.

Quindi, in questo caso specifico, la prima cosa che potresti fare è costruire un mirror / repository locale. Utilizzare la gestione della configurazione esistente per controllare l'accesso ai repository di terze parti. Forse pianificare una politica per aggiornare i servizi critici o rivolti al pubblico (ssh, http, ftp, dovecot, ecc.) Tutto il resto richiederà test, ma ho la sensazione che la maggior parte degli ambienti non funzioni con sistemi completamente aggiornati / patchati.

Ci sono molti strumenti che possono aiutarti in questo! È generale il sistema di pacchetti e quali pacchetti vanno dove viene gestito dalla gestione della configurazione. Questi strumenti di solito coprono più del semplice yum e dell'rpms, e ti faranno risparmiare tempo e prevenire molti mal di testa!

Lo strumento con cui ho più familiarità è il pupazzo che uso per gestire praticamente ogni configurazione nel mio ambiente. Ecco alcuni esempi di marionette per la gestione specifica di yum:

http://people.redhat.com/dlutter/puppet-app.html

Sono attualmente disponibili numerosi strumenti di gestione della configurazione, che hanno gruppi di utenti piuttosto grandi:

• Cfengine http://cfengine.com/cfengine3
• Puppet http://puppetlabs.com/puppet/puppet-difference/
• capocuoco http://wiki.opscode.com/display/chef/Home (alcune delle persone che conosco lo hanno implementato di recente e lo adorano)

L'implementazione di questi in un ambiente aggiungerà anni alla tua vita. Riduce il numero di mal di testa da sistemi mal configurati e consente un facile upgrade / aggiornamento. La maggior parte di questi strumenti può anche fornire alcune funzionalità a livello di audit che possono ridurre notevolmente i tempi di riparazione per errori di configurazione.

Per quanto riguarda la tua domanda sui test, ho utilizzato un ambiente di gestione temporanea a cui indirizziamo il caricamento di alcuni clienti (di solito clienti beta o un piccolo sottoinsieme del traffico di produzione). Di solito lasciamo che questo cluster esegua il nuovo codice per almeno un paio di giorni, fino a una settimana (a seconda della gravità della modifica) prima di implementarlo nella produzione. Di solito ho trovato che questa configurazione funziona meglio se provi a capire quanto tempo impiega la maggior parte degli errori a scoprire. Nei sistemi molto usati questo può essere una questione di ore, nella maggior parte degli ambienti che ho visto una settimana è abbastanza lungo per scoprire bug anche non comuni nella stadiazione / QA.

Una parte molto importante dei test è la replica di dati / utilizzo. Hai detto di avere versioni temporanee della maggior parte dell'hardware di produzione. Hanno anche copie identiche dei dati di produzione? Riesci a riprodurre qualsiasi carico di produzione contro di esso? Riesci persino a far parte del cluster di produzione usando il mirroring del traffico? Questo di solito diventa un compromesso diretto tra la quantità di risorse che l'azienda è disposta a spendere per test / QA. Più test meglio è, cerca di non auto-limitarti (entro limiti ragionevoli) e vedi cosa sosterrà l'azienda (quindi trova un modo per fare il 10% in più).