Come aggiornare yum / aptitude safe-upgrade di molti host?

Puppet è, in realtà, solo un'utilità di gestione della configurazione, non uno strumento di automazione. Se desideri un'automazione adeguata, allora ti consigliamo di guardare mcollective che è iniziato come uno strumento di terze parti e ora è stato portato sotto l'egida dei laboratori di burattini. Non avendo lavorato con mcollective, non posso davvero parlare di quanto bene gestirebbe anche questo, ma la mia comprensione è che funziona meglio come meccanismo di esecuzione di attività arbitrarie, che non funzionerà altrettanto bene quando si tenta di eseguire attività ripetute regolarmente .

Credo che il modo migliore per farlo sarebbe sviluppare gli script e il processo con cui si desidera aggiornare, quindi utilizzare il burattino per eliminare le configurazioni. Quindi poniti le seguenti domande.

1. Con che frequenza desidero aggiornare le macchine?
2. Voglio che si riavviino automaticamente quando viene installato un nuovo kernel o voglio solo una notifica?
3. Dovremmo eseguire comandi speciali durante gli aggiornamenti?
4. Ho abbastanza sistemi per cui gli aggiornamenti dovrebbero essere scaglionati?

Quando inizi a costruire la configurazione e a rispondere a queste domande, probabilmente troverai altro che verrà fuori dal tuo ambiente specifico. Per un esempio specifico quello che faccio è questo:

• Per la maggior parte dei miei sistemi gli aggiornamenti sono una volta alla settimana, tramite cron job. A seconda dello scopo e dell'ambiente, alcuni sistemi sono molto più frequenti.
• La maggior parte dei sistemi si riavvia automaticamente, alcuni sistemi (a seconda dello scopo) inviano tramite e-mail un promemoria per il riavvio. Questo viene gestito attraverso un cron job che controlla il file vmlinuz con la versione più alta in /boot rispetto all'output di uname -r
• Dopo essere stato bruciato dall'aggiornamento di glibc da RHEL 5.3->5.4, mi assicuro di aggiornare yum, poi glibc, quindi tutto il resto.
• Poiché tutto questo è gestito da cron job, ho dormito con tempi casuali tra ogni esecuzione di yum. Ogni host può impiegare tra i 5 e i 45 minuti per essere completato, il che svolge un ragionevole lavoro di distribuzione del carico.

Tutto questo è contenuto in due file, le due voci cron (aggiornamenti e controllo del kernel) memorizzate in /etc/cron.d e lo script di aggiornamento. Lo sto facendo con uno script di shell dall'aspetto sempre più disordinato che accetta argomenti della riga di comando per eseguire l'aggiornamento o il controllo del kernel e se riavviare o meno. Puppet gestisce quindi questi due file. Dato che hai a che fare con entrambi i sistemi basati su rpm e dpkg, probabilmente creerei due script o creerei un do_update separato funzioni per le due versioni e ciascuna chiamata con una diversa opzione della riga di comando. Quindi puoi inviare lo script giusto controllando operatingsystem fact nella tua dichiarazione di file, o modellizza la voce cron e usa lo stesso fatto per decidere quale switch usare.

Utilizzando uno script ben collaudato, questo metodo ha funzionato molto bene. Abbastanza bene, infatti, che questa configurazione è stata utilizzata con successo per alcuni anni per gestire centinaia di sistemi. Di tanto in tanto vedremo intoppi quando i pacchettizzatori del kernel inizieranno ad aggiungere sempre più livelli di versioni minori ai file e le routine di confronto si interromperanno.

Lo stesso burattino non è lo strumento per questo lavoro. Puppetlabs ha uno strumento separato chiamato MCollective, che è simile a Capistrano, Fabric e Func.

Esiste un agente MCollecive chiamato Packages Agent che è in grado di eseguire aggiornamenti yum, tra gli altri tipi di gestione dei pacchetti.

Hai detto che parte della tua infrastruttura esegue Ubuntu. Forse dovresti dare un'occhiata al pacchetto degli aggiornamenti automatici.

Se i vostri host sono host RHEL, potreste voler dare un'occhiata a RHN Satellite. Altrimenti potrebbe valere la pena dare un'occhiata a Spacewalk ** (vedi nota sotto). Sono progettati per gestire le copie locali dei repository dei pacchetti upstream e per facilitare la gestione dei sistemi registrati sul server di RHN Satellite. È possibile pianificare l'aggiornamento dei pacchetti in un momento specifico o, se è stato abilitato OSAD, gli aggiornamenti possono essere pianificati in tempo reale nella GUI Web di RHN Satellite/Spacewalk.

Alcune persone hanno scritto di seguito usando il pupazzo, ci sono alcuni blog e pagine web scritte su come integrare Puppet con RHN Satellite.

IN ALTERNATIVA....

Se sei più interessato a guardare un progetto emergente che alla fine sostituirà RHN Satellite, puoi dare un'occhiata al Progetto Katello. Katello contiene molti progetti che fanno parte del prodotto CloudForms di Red Hat e si dice che sia l'upstream per l'eventuale sostituzione di RHN Satellite. Infatti Katello integra Puppet tramite l'uso di Foreman. Vale sicuramente la pena considerare Katello a lungo termine rispetto a Spacewalk (ma non RHN Satellite ancora a causa dell'abbonamento/supporto).

** Nel mio post ho fatto riferimento sia a RHN Satellite che a Spacewalk come RHN Satellite per semplificare le cose. La vera distinzione sta nel tempo o nel fatto che tu abbia sistemi RHEL, in tal caso avrai bisogno di RHN Satellite in quanto può essere scaricato da RHN in modo supportato, Spacewalk sarebbe per gli utenti che utilizzano una ricostruzione di RHEL o Fedora (capisco Spacewalk potrebbe supportare anche Debian, ma personalmente non ne so molto.) Pertanto durante la ricerca di informazioni potrebbe essere necessario cercare Spacewalk e/o RHN Satellite