Puppet je ve skutečnosti jen nástroj pro správu konfigurace, nikoli nástroj pro automatizaci. Pokud chcete řádnou automatizaci, pak se budete chtít podívat na mcollective, který začal jako nástroj třetí strany a nyní se dostal pod záštitu loutkových laboratoří. Jelikož jsem nepracoval s mcollective, nemohu skutečně mluvit o tom, jak dobře by to zvládl, ale rozumím tomu, že nejlépe funguje jako libovolný mechanismus provádění úkolů, který nebude fungovat tak dobře, když se pokoušíte dělat pravidelně se opakující úkoly. .
Věřím, že nejlepším způsobem, jak to udělat, by bylo vyvinout skripty a proces, pomocí kterého chcete aktualizovat, a pak použít loutku k vytlačení konfigurací. Položte si tedy následující otázky.
- Jak často chci, aby se počítače aktualizovaly?
- Chci, aby se automaticky restartovaly, když je nainstalováno nové jádro, nebo chci jen upozornění?
- Měli bychom během aktualizací spouštět nějaké speciální příkazy?
- Mám dostatek systémů, aby aktualizace měly být rozloženy?
Když začnete sestavovat konfiguraci a odpovídat na tyto otázky, pravděpodobně najdete další, které vyjdou z vašeho konkrétního prostředí. Pro konkrétní příklad, co dělám, je toto:
- U většiny mých systémů jsou aktualizace jednou týdně prostřednictvím úlohy cron. V závislosti na účelu a prostředí jsou některé systémy mnohem častější.
- Většina systémů se restartuje automaticky, některé systémy (v závislosti na účelu) odešlou e-mailem upomínku na restart. To je řešeno pomocí úlohy cron, která kontroluje soubor vmlinuz s nejvyšším číslem verze v
/bootproti výstupuuname -r - Poté, co jsem se spálil aktualizací glibc z RHEL 5.3->5.4, ujistím se, že aktualizuji yum, pak glibc a pak vše ostatní.
- Vzhledem k tomu, že to vše spouštějí úlohy cron, mám mezi každým spuštěním yum spánku s náhodnými časy. Dokončení každého hostitele může trvat 5 až 45 minut, což je přiměřená práce při rozložení zátěže.
To vše je obsaženo ve dvou souborech, dvou záznamech cron (aktualizace a kontrola jádra) uložených v /etc/cron.d a skript aktualizace. Dělám to pomocí stále chaoticky vypadajícího skriptu shellu, který používá argumenty příkazového řádku k provedení aktualizace nebo kontroly jádra a zda se má nebo nemá restartovat. Puppet pak spravuje tyto dva soubory. Protože máte co do činění se systémy založenými na rpm i dpkg, pravděpodobně bych vytvořil buď dva skripty, nebo vytvořil samostatné do_update funkce pro dvě varianty a každá volá jiným přepínačem příkazového řádku. Pak můžete buď vysunout správný skript zaškrtnutím operatingsystem faktu ve vaší deklaraci souboru nebo šablonujte záznam cron a použijte stejný fakt k rozhodnutí, který přepínač použít.
Pomocí dobře otestovaného skriptu se tato metoda osvědčila velmi dobře. Ve skutečnosti dost dobře, že toto nastavení bylo úspěšně používáno již několik let ke zpracování stovek systémů. Občas se setkáme s škytavkou, když baliči jádra začnou do souborů přidávat další a další úrovně vedlejších verzí a srovnávací rutina se dusí.
Loutka sama o sobě není nástrojem pro tuto práci. Puppetlabs má samostatný nástroj nazvaný MCollective, který je podobný Capistrano, Fabric a Func.
Existuje agent MCollecive nazvaný Packages Agent, který je schopen kromě jiných typů správy balíčků provádět skvělé aktualizace.
Zmínil jste, že část vaší infrastruktury běží na Ubuntu. Možná byste se měli podívat na balíček unattended-upgrades.
Pokud jste hostiteli RHEL, možná se budete chtít podívat na RHN Satellite. Jinak Spacewalk možná stojí za shlédnutí **(viz poznámka níže). Jsou navrženy pro správu lokálních kopií upstreamových úložišť balíčků a pro usnadnění správy systémů registrovaných na RHN Satellite serveru. Aktualizace balíčků můžete naplánovat na konkrétní čas, nebo pokud jste povolili OSAD, lze aktualizace naplánovat v blízké době v RHN Satellite/Spacewalk Web GUI.
Někteří lidé publikovali pomocí loutky níže, existuje několik blogů a webových stránek o tom, jak integrovat Puppet s RHN Satellite.
ALTERNATIVNĚ....
Pokud máte větší zájem podívat se na vznikající projekt, který nakonec nahradí RHN Satellite, můžete se podívat na projekt Katello. Katello obsahuje mnoho projektů, které jsou součástí produktu CloudForms společnosti Red Hat a říká se, že jsou předchůdcem pro případnou náhradu RHN Satellite. Ve skutečnosti Katello integruje Puppet pomocí Foremana. Dlouhodobý pohled na Katello rozhodně stojí za zvážení přes Spacewalk (ale zatím ne RHN Satellite kvůli předplatnému/podporě).
** Satelit RHN i Spacewalk jsem ve svém příspěvku označil jako satelit RHN, abych to usnadnil. Skutečný rozdíl spočívá v počasí nebo ne, máte systémy RHEL, pokud je tomu tak, budete potřebovat satelit RHN, protože jej lze podporovaným způsobem stahovat z RHN, Spacewalk by byl pro uživatele používající přestavbu RHEL nebo Fedora (rozumím Spacewalk může podporovat i Debian, ale osobně o tom moc nevím.) Proto při hledání informací může být nutné hledat Spacewalk nebo RHN Satellite