Dovresti eseguire aggiornamenti automatici

Sto gestendo i server web Centos di produzione. Voglio sapere quali sono le migliori pratiche per l'esecuzione degli aggiornamenti. Dovrei automatizzare questo con yum-cron o yum-updatesd? Oppure c'è il pericolo che gli aggiornamenti interrompano i siti, quindi sarebbe meglio aggiornare su un server di prova e quindi eseguire gli aggiornamenti manualmente settimanalmente?

La maggior parte dei server utilizza solo i repository ufficiali ma alcuni hanno il repository atomico per i moduli PHP che altrimenti non sarebbero disponibili. Cosa c'è di meglio in questo caso? posso impostare yum per usare Atomic solo per i moduli PHP? Non voglio che tutto si aggiorni ai roba più sanguinosa in Atomic, mi fiderei piuttosto di Centos (o davvero Red Hat) per mantenere i miei server stabili e sicuri.

Ci sono pro e contro in entrambi i modi e devi davvero lavorare attraverso l'architettura del tuo sistema per sapere qual è il modo migliore per te. Qualunque percorso segua, dovresti capire perché hai scelto quel metodo e quali sono gli svantaggi in modo da poterli compensare.

Ecco alcune cose da considerare:

• Gli aggiornamenti di sicurezza devono sempre essere applicati in un modo o nell'altro e prima piuttosto che successivamente. Se il tuo server non riceve aggiornamenti di sicurezza applicati in modo tempestivo per qualsiasi motivo, correggi le tue abitudini di amministratore di sistema.

• Gli aggiornamenti di Distro sono generalmente buoni, specialmente se provengono da fonti ufficiali. Se ti senti a disagio nell'applicarli, forse non stai usando la migliore distribuzione per le tue esigenze. Dovresti usare una distro che corrisponda alla tua metodologia. In altre parole, uno di cui ti puoi fidare degli aggiornamenti per essere nel tuo interesse. Se si muovono troppo velocemente o apportano modifiche al software che rompono le tue cose, probabilmente dovresti utilizzare una distribuzione diversa.

• Gli aggiornamenti possono danneggiare i tuoi contenuti. Il passaggio a un software più recente potrebbe violare il codice se si utilizzavano funzionalità obsolete o si scrivevano solo elementi non validi. È necessario prendere in considerazione un'architettura di sistema che consenta di testare il prodotto sugli aggiornamenti prima di eseguirli su sistemi di produzione.

• Se si utilizzano le funzionalità di aggiornamento automatico, è necessario disporre sempre di un modo per ripristinare le configurazioni di lavoro note. Le istantanee di sistema complete possono essere un salvavita se un aggiornamento interrompe il prodotto su un sistema di produzione.

Questa non è una lista esaustiva, solo alcune cose per farti pensare. Alla fine, questa non è una decisione che nessun altro può prendere per te. Sei l'amministratore. Conosci i tuoi sistemi. Conosci la tua distribuzione.

Sono d'accordo al 100% con ciò che Caleb ha già detto. Alcune altre tacche specifiche di CentOS da parte mia:

La distribuzione si basa su RedHat e le sue patch. Queste patch sono state testate molto bene e negli ultimi 4 anni in cui abbiamo usato CentOS 5 con oltre 50 server non c'è mai stata una patch difettosa.

MA: Sebbene applichiamo automaticamente tutte le patch quotidianamente ai server che eseguono solo elementi di distribuzione, avviamo i server di produzione (dopo l'aggiornamento di glibc o del kernel) solo dopo aver eseguito i nostri sistemi di test in quella configurazione un paio di giorni.

Per altri repository li specchiamo su una directory di gestione temporanea. Queste patch vengono prima applicate ai server di test. Se è dimostrato che nulla si rompe, attiviamo la directory di gestione temporanea e la copiamo in un repository di produzione.

Il patching automatico ha l'effetto collaterale di riavviare spesso i componenti con patch, quindi se li hai configurati in modo errato dopo l'avvio, il riavvio fallirà.