Sind Konfigurationsmanagement-Tools (Puppet, Chef) in der Lage, installierte Pakete auf dem neuesten Stand zu halten?

Dies ist wahrscheinlich eine einfache Frage für diejenigen unter Ihnen, die bereits Konfigurationsverwaltungstools ausführen. Sind Konfigurationsmanagement-Tools wie Puppet oder Chef der richtige Ansatz, um installierte Pakete auf dem neuesten Stand zu halten?

Angenommen, ich führe eine Reihe von Servern aus, die hauptsächlich auf Debian und Ubuntu basieren. Erleichtern Konfigurationsverwaltungstools das Aktualisieren von Paketen, die aus den Repositorys installiert wurden, wenn Sicherheitsupdates oder Fehlerkorrekturen verfügbar sind?

Momentan führe ich "unbeaufsichtigte Upgrades" aus , damit die Systeme automatisch Sicherheitsupdates installieren, aber ich muss immer noch eine Verbindung zu den Servern herstellen und diese von Zeit zu Zeit ausführen aptitude update && aptitude safe-upgrade. Das wird natürlich langweilig, mühsam und fehleranfällig, je mehr Server es gibt.

Sind Tools wie Puppet oder Chef der richtige Ansatz, um installierte Pakete auf dem neuesten Stand zu halten? Verwendet einer von Ihnen diese Tools, um zu vermeiden, dass sie manuell ausgeführt werden, aptitudeoder einen entsprechenden Vorgang auf 15 Servern? Ich bin mir ziemlich sicher, dass die Antwort auf diese Fragen "Ja, natürlich!" Ist.

Aber wo finde ich weitere Informationen zu diesem bestimmten Anwendungsfall? Ich hatte noch keine Zeit, Puppet oder Chef ausführlich zu studieren, und die Beispielkochbücher oder -klassen zeigen nur mehr oder weniger triviale Beispiele für die Installation eines bestimmten Pakets, wie z. B. ssh. Haben Sie Ressourcen, die Sie empfehlen können, abgesehen von der offiziellen Dokumentation (ich werde natürlich die Dokumentation studieren, sobald ich weiß, welche der Tools für mich geeignet sind, falls welche vorhanden sind)?

Puppet (da bin ich mir ziemlich sicher, dass der Chefkoch das auch tut) passt zu Ihren apt-get / yum- Software-Repositories. Da sie das Schwergewicht darauf legen, herauszufinden, welche Pakete verfügbar sind, ensure => latestfunktioniert dies nur für Ubuntu / CentOS / Debian. Solange Sie die entsprechenden Dateien korrekt eingerichtet haben ( /etc/apt/sources.listusw.).

Du kannst es mit einer Puppe machen, du machst entweder:

ensure => latest,

oder

ensure=> "1.0.2",

um die neueste / erforderliche Version anzugeben. dh

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

Dies bedeutet zumindest, dass Sie auf allen Systemen die gleiche Version angeben und verhindern können, dass sich Server (möglicherweise gefährlich) automatisch aktualisieren. Ich habe diese Methode in der Produktion an mehreren Standorten verwendet und sie funktioniert sehr gut.

Das Ausführen von unbeaufsichtigten Upgrades macht mir ein bisschen Angst, besonders wenn sie geschäftskritische Pakete, Kernel, MySQL-Bibliotheken, Apache usw. aktualisieren. Besonders wenn das Installationsskript den Dienst möglicherweise neu starten möchte!

Ich denke, das ist wahrscheinlich die falsche Frage. Die Verwendung von Konfigurationsmanagement-Tools wie Puppet und Chef zur Wartung Ihrer Infrastruktur ist sicherlich ein großer Fortschritt, wenn Sie versuchen, alles manuell zu erledigen. Das Problem, Ihre Paketversionen auf dem neuesten Stand und synchron zu halten, wird mit keinem dieser Tools direkt gelöst. Um dies ordnungsgemäß zu automatisieren, müssen Sie die Paket-Repositorys selbst unter Ihre Kontrolle bringen.

Die Art und Weise, wie ich das mache, ist ein dediziertes Yum-Repo (für Redhat / Fedora / CentOS; ein APT-Repository für Debian / Ubuntu), das die Pakete enthält, die mir für eine bestimmte Site wichtig sind. Dies sind im Allgemeinen die Abhängigkeiten der Anwendung selbst (Ruby, PHP, Apache, Nginx, Bibliotheken usw.) und sicherheitskritische Pakete.

Sobald Sie dies eingerichtet haben (normalerweise können Sie die erforderlichen Pakete zunächst nur vom Upstream-Repo aus spiegeln), können Sie mithilfe der Puppet-Syntax "verify => latest" sicherstellen, dass alle Ihre Maschinen mit dem Repo auf dem neuesten Stand sind.

Es ist ratsam, ein "Staging" -Repo zu verwenden, um aktualisierte Versionen von Paketen zu testen, bevor sie in die Produktion ausgelagert werden. Mit Puppet ist dies mithilfe von Repository-Vorlagen problemlos möglich, ohne dass Code dupliziert werden muss.

Die Automatisierung der Paketversionierung ermutigt Sie dringend, alle Ihre Produktionssysteme zu synchronisieren, da die Verwaltung mehrerer Repos und Pakete für verschiedene Betriebssystemdistributionen, -versionen und -maschinenarchitekturen sehr zeitaufwendig ist und wahrscheinlich zu allen möglichen undurchsichtigen Problemen und Inkompatibilitäten führt.

All diese Ratschläge gelten gleichermaßen für Ruby-Edelsteine, Python-Eier und andere Verpackungssysteme, die Sie möglicherweise verwenden.

Ich habe ein kleines Puppet-Tutorial geschrieben, das Ihnen helfen soll, Puppet schnell zum Laufen zu bringen. Sie können Ihren Maschinen eine benutzerdefinierte Repodefinition bereitstellen, indem Sie Puppet als ersten Schritt verwenden, um die Paketversionen unter Kontrolle zu bringen.

Während Puppet / Chef möglich Anwärter für diese Funktionalität sind, um sie halten alles , was auf dem System up-to-date entweder Typen Brauch erfordert oder jedes Paket Auflistung (einschließlich zugrunde liegenden Systembibliotheken wie libc6) als Ressourcen mit ensure => latest. Für den speziellen Fall automatisierter Paketaktualisierungen möchten Sie möglicherweise einen Blick auf das cron-aptPaket werfen , das genau das tut, was Sie möchten.

Diese Frage ist alt, aber ich dachte, ich würde sie aktuell beantworten, da eine derzeitige Antwort damals nicht verfügbar war.

Wenn Sie Marionette oder Chef benutzen, schauen Sie in mcollective. Es ist ein sehr nettes Tool der Puppetlabs, mit dem Sie Befehle an Servergruppen senden können. http://docs.puppetlabs.com/mcollective/

Es hat auch ein Apt-Plugin, mit dem ein Apt-Update auf einer beliebigen Anzahl von Servern durchgeführt werden kann: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt

Mir ist klar, dass dies für Ihre ursprüngliche Frage etwas spät ist, aber hier im Sinne von "Besser spät als nie".

Ich benutze Cfengine 3, um dies auf mehreren Servern zu tun. Ich gebe eine explizite Liste von Paketen für die automatische Aktualisierung an, um zu vermeiden, dass alle Pakete aktualisiert werden, ohne etwas vorsichtig zu sein. Es funktioniert super und cfengine 3 ist sehr leicht.

Hier ist ein Versprechungsschnipsel aus meiner Cfengine-Konfiguration:

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

Hoffe das hilft.

Ich stimme Jonathan zu. Der Cfengine 3-Ansatz ist nützlich, da Sie alle Aspekte der Paketverwaltung steuern können, ohne auf einer niedrigen Ebene neu codieren zu müssen.

Wir benutzen Puppet + Apt-Dater.

Sie können auch Paketverwaltungstools wie Canonicals Landscape verwenden, mit denen Ubuntu / Debian-Systeme verwaltet und überwacht werden können. Es verwaltet mehrere Systeme, ermöglicht die gleichzeitige Aktualisierung und bietet einige grundlegende Überwachungsfunktionen.

Sicherheitsupdates

Im Allgemeinen denke ich, dass es am einfachsten ist, Ansible oder Ähnliches zu verwenden, um das robuste Paket für unbeaufsichtigte Upgrades für Ubuntu / Debian (oder yum-cronfür RHEL / CentOS) einzurichten . Sie können Puppet, Chef oder andere Tools verwenden, aber ich werde Ansible hier diskutieren.

• unattended-upgrades kann verwendet werden, um nicht sicherheitsrelevante Updates gleichzeitig durchzuführen, was viel einfacher ist, als jeden Tag einen Befehl über Ansible auszuführen.

• unattended-upgradeskümmert sich täglich um automatische Updates und ist normalerweise nur auf Sicherheitsupdates beschränkt (um die Stabilität zu erhöhen). Wenn der Server nach dem Update neu gestartet werden muss, kann dieses Tool zu einem bestimmten Zeitpunkt automatisch neu gestartet werden.

Wenn Ihre Neustarts komplexer sind, unattended upgradeskönnen Sie eine E-Mail senden und es wird eine E-Mail erstellt /var/run/reboot-required, sodass Ansible (oder ein ähnliches Unternehmen) die Neustarts zu einem geeigneten Zeitpunkt verwalten kann (z. B. fortlaufende Neustarts eines Clusters von Web- oder DB-Servern, um Ausfallzeiten zu vermeiden, und auf jeden warten kann Server an einem bestimmten TCP-Port verfügbar sein, bevor Sie fortfahren).

Sie können Ansible-Rollen wie jnv.unattended-upgrades für Ubuntu / Debian-Systeme oder die einfache, aber effektive geerlingguy.security verwenden , die auch RHEL / CentOS abdeckt (und die SSH-Konfiguration sichert ).

Wenn schnelle Sicherheitsupdates weniger wichtig sind, können Sie sie zuerst auf weniger wichtigen Servern einem Testprozess unterziehen und den unattended-upgradeBefehl ausführen, sobald Tests ergeben, dass keine Probleme vorliegen Erfahrung.

Allgemeine Updates

Andere Updates als Sicherheitsupdates sollten einen normalen kontinuierlichen Integrations- und Testprozess durchlaufen, um sicherzustellen, dass nichts kaputt geht.

Ich habe aptitude safe-upgradein der Vergangenheit schwerwiegende Probleme auf Servern festgestellt, daher ist es am besten, dies nicht automatisch auszuführen, während Sicherheitsupdates im Allgemeinen recht sicher sind.