Gli strumenti di gestione della configurazione (Puppet, Chef) sono in grado di mantenere aggiornati i pacchetti installati?

Questa è probabilmente una semplice domanda per quelli di voi che già eseguono strumenti di gestione della configurazione. Gli strumenti di gestione della configurazione come Puppet o Chef sono l'approccio giusto per mantenere aggiornati i pacchetti installati?

Supponiamo che io abbia diversi server, principalmente basati su Debian e Ubuntu. Gli strumenti di gestione della configurazione semplificano l'aggiornamento dei pacchetti installati dai repository quando arrivano aggiornamenti di sicurezza o correzioni di bug?

Attualmente eseguo "aggiornamenti automatici" per consentire ai sistemi di installare automaticamente gli aggiornamenti di sicurezza, ma devo comunque collegarmi ai server ed eseguirli aptitude update && aptitude safe-upgradeogni tanto. Naturalmente questo diventa noioso, noioso e soggetto a errori tanto più server ci sono.

Strumenti come Puppet o Chef sono l'approccio giusto per mantenere aggiornati i pacchetti installati? Qualcuno di voi usa questi strumenti per evitare l'esecuzione manuale aptitudeo un equivalente su 15 server? Sono abbastanza sicuro che la risposta a queste domande sia "Sì, certo!"

Ma dove posso trovare ulteriori informazioni su questo particolare caso d'uso? Non ho ancora avuto il tempo di studiare a fondo Puppet o Chef, e i libri di cucina o le lezioni di esempio mostrano solo esempi più o meno banali di installazione di un pacchetto particolare, come ssh. Hai qualche risorsa da consigliare, oltre alla documentazione ufficiale (ovviamente, studierò i documenti una volta che so quali, se del caso, degli strumenti sono giusti per me).

Puppet (sono abbastanza sicuro che lo faccia anche lo chef) si collega ai repository di software apt-get / yum . Dal momento che fanno il duro lavoro di capire quali pacchetti sono disponibili, ciò significa ensure => latestche funziona solo per Ubuntu / CentOS / Debian. Finché hai impostato correttamente i file appropriati ( /etc/apt/sources.list, ecc.).

Puoi farlo con le marionette, oppure:

ensure => latest,

o

ensure=> "1.0.2",

per specificare la versione più recente / richiesta. vale a dire

package { apache2: ensure => "2.0.12-2" }
package { apache2: ensure => latest }

Ciò significa almeno che è possibile specificare la stessa versione su tutti i sistemi, oltre a impedire ai server di (potenzialmente pericolosamente) aggiornarsi automaticamente. Ho usato questo metodo in produzione su diversi siti e funziona molto bene.

Eseguire aggiornamenti non presidiati mi spaventa un po ', soprattutto se stanno aggiornando pacchetti mission-critical, kernel, librerie mysql, apache, ecc. Soprattutto se lo script di installazione potrebbe voler riavviare il servizio!

Penso che questa sia probabilmente la domanda sbagliata. Sicuramente l'utilizzo di strumenti di gestione della configurazione come Puppet e Chef per mantenere la propria infrastruttura è un enorme passo avanti rispetto al tentativo di fare tutto manualmente. Il problema di mantenere aggiornate e sincronizzate le versioni del pacchetto non è quello che nessuno di questi strumenti risolve direttamente. Per automatizzare correttamente, è necessario sottoporre i repository dei pacchetti stessi al proprio controllo.

Il modo in cui lo faccio è mantenere un repository Yum dedicato (per Redhat / Fedora / CentOS; un repository APT per Debian / Ubuntu) che contiene i pacchetti a cui tengo per un determinato sito. Queste saranno generalmente le dipendenze dell'applicazione stessa (Ruby, PHP, Apache, Nginx, librerie e così via) e pacchetti critici per la sicurezza.

Dopo aver impostato questa impostazione (in genere è possibile eseguire il mirroring dei pacchetti richiesti dal repository upstream per iniziare) è possibile utilizzare la sintassi "sure => latest" di Puppet per assicurarsi che tutte le macchine siano aggiornate con il repository.

Sarebbe saggio utilizzare un repository di "gestione temporanea" per consentire di testare le versioni aggiornate dei pacchetti prima di distribuirli allegramente alla produzione. Questo viene fatto facilmente con Puppet senza alcuna duplicazione di codice utilizzando i modelli di repository.

L'automazione del controllo delle versioni dei pacchetti ti incoraggia fortemente a sincronizzare tutti i tuoi sistemi di produzione, poiché mantenere più repository e pacchetti per diverse distribuzioni del sistema operativo, versioni e architetture di macchine richiede molto tempo e probabilmente porterà a tutti i tipi di problemi e incompatibilità oscuri.

Tutti questi consigli si applicano ugualmente alle gemme di Ruby, alle uova di Python e ad altri sistemi di pacchetti che è possibile utilizzare.

Ho scritto un piccolo tutorial su Puppet che dovrebbe aiutarti a metterti subito in funzione con Puppet. È possibile distribuire una definizione repository personalizzata sui propri computer utilizzando Puppet come primo passo per tenere sotto controllo le versioni dei pacchetti.

Mentre Puppet / Chef sono possibili contendenti per questa funzionalità, per farli mantenere tutto aggiornato sul sistema richiede tipi personalizzati o elencando ogni pacchetto (comprese le librerie di sistema sottostanti come libc6) come risorse ensure => latest. Per il caso specifico degli aggiornamenti automatizzati del pacchetto, potresti voler esaminare il cron-aptpacchetto, che fa anche quello che vuoi.

Questa domanda è vecchia, ma pensavo di rispondere in modo aggiornato poiché una risposta attualmente esistente non era disponibile in quel momento.

Se stai usando un burattino o uno chef, cerca in mcollective. È uno strumento molto carino per i ragazzi delle marionette che ti consente di inviare comandi a gruppi di server. http://docs.puppetlabs.com/mcollective/

Ha anche un plugin apt, che può essere usato per fare un aggiornamento apt su qualsiasi numero di server: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt

Mi rendo conto che è un po 'tardi per la tua domanda originale, ma qui è nello spirito di "meglio tardi che mai".

Uso Cfengine 3 per farlo su diversi server. Specifico un elenco esplicito di pacchetti per l'aggiornamento automatico, evitando così di aggiornare tutti i pacchetti senza fare molta attenzione. Funziona benissimo e cfengine 3 è molto leggero.

Ecco un frammento promettente dalla mia configurazione di cfengine:

    packages:
            "apache2"
                    package_method => "apt",
                    package_policy => "update";

Spero che sia di aiuto.

Sono d'accordo con Jonathan. L'approccio di Cfengine 3 è utile perché puoi controllare tutti gli aspetti della gestione dei pacchetti senza dover ricodificare a basso livello.

Usiamo burattino + apt-dater.

Puoi anche usare strumenti di gestione dei pacchetti come Canonicals Landscape progettato per gestire e monitorare i sistemi Ubuntu / Debian. Gestisce più sistemi, consente di aggiornarli contemporaneamente e offre alcune funzionalità di monitoraggio di base.

Aggiornamenti di sicurezza

Generalmente penso che sia più semplice usare Ansible o simile per configurare il robusto pacchetto di aggiornamenti automatici per Ubuntu / Debian (o yum-cronper RHEL / CentOS). Puoi usare Puppet, Chef o altri strumenti, ma parlerò di Ansible qui.

• unattended-upgrades può essere utilizzato per effettuare aggiornamenti non di sicurezza contemporaneamente, se si preferisce, il che è molto più semplice che eseguire un comando via Ansible ogni giorno.

• unattended-upgradessi occupa degli aggiornamenti automatici ogni giorno ed è normalmente vincolato solo agli aggiornamenti di sicurezza (per aumentare la stabilità). Se il server necessita di un riavvio dopo l'aggiornamento, questo strumento può riavviarsi automaticamente in un determinato momento.

Se i tuoi riavvii sono più complessi, unattended upgradespossono inviarti e-mail e crea anche /var/run/reboot-required, in modo che Ansible (o simile) possa gestire i riavvii in un momento adatto (ad es. Riavvio a rotazione di un cluster di server Web o DB per evitare tempi di inattività, in attesa di ciascuno server per diventare disponibile su una determinata porta TCP prima di continuare).

Puoi usare ruoli Ansible come jnv.unattended-upgrade per sistemi Ubuntu / Debian, o il semplice ma efficace geerlingguy.security , che copre anche RHEL / CentOS (e rafforza la configurazione SSH).

Se gli aggiornamenti rapidi della sicurezza sono meno importanti, potresti prima sottoporli a un processo di prova su server meno importanti ed eseguire il unattended-upgradecomando quando i test mostrano che non ci sono problemi - tuttavia è abbastanza raro che le correzioni di sicurezza orientate al server causino problemi, nel mio Esperienza.

Aggiornamenti generali

Aggiornamenti diversi dalla sicurezza dovrebbero passare attraverso un normale processo di integrazione e test continuo, per garantire che le cose non si rompano.

Ho visto aptitude safe-upgradecausare seri problemi sui server in passato, quindi è meglio non eseguirlo automaticamente, mentre gli aggiornamenti di sicurezza sono generalmente abbastanza sicuri.