Ist Puppet oder Chef für die Verwaltung einer sehr einfachen Serverkonfiguration in einer Umgebung mit mehreren Mandanten geeignet?

Dies bezieht sich auf Umgebungen mit mehreren Mandanten, z. B. ein kleines Hosting-Unternehmen.

Ist Puppet (oder ähnliches) eine geeignete Technologie, um grundlegende, aber kritische Massenänderungen zu berücksichtigen? Zum Beispiel:

• Aktualisieren von DNS-Resolvern (resolv.conf)
• SSH-Schlüssel einstellen
• Aktualisieren der NTP-Konfiguration
• Snmpd konfigurieren
• Bereitstellen von Überwachungsskripten wie SNMP Perl-Erweiterungen oder Nagios-Skripten

Meine Bedenken beziehen sich auf Sicherheit und Invasivität:

1. Ich möchte nicht, dass ein Server eine Konfiguration sieht, die er nicht sehen sollte
2. Ich mache mir Sorgen, dass ein Puppet-Master für Angriffe durch einen kompromittierten Server anfällig sein könnte
3. Ich möchte nicht, dass Puppet Änderungen vornimmt, die es nicht sollte, oder manuelle Änderungen, die auf dem Server vorgenommen wurden, rückgängig macht.

Ich sollte dies einschränken, indem ich sage, dass ich Puppet noch nie in der Produktion verwendet habe, sondern nur ein kurzes Spiel in einem Testlabor hatte, also denke ich möglicherweise falsch darüber nach!

Versuchen Sie Ansible (ansible.cc). Vielleicht ist es für dich. Auf Ihren Clients wird kein Agent ausgeführt. Es wächst sehr schnell.

Eine weitere sehr gute Alternative ist Salt Stack.

Ansible und Salt sind leicht zu verstehen. Sie können sie als Befehlszeilenprogramm verwenden, wenn Sie möchten, z. B. als verteilte Shell.

Ja, das ist sicherlich möglich. Die Entscheidung, ob Sie dies tun sollten oder nicht, liegt jedoch bei Ihnen.

In Bezug auf Ihre Fragen:

1) fair genug. Der Datenverkehr basiert auf SSL, daher ist die Zertifikatsverwaltung wichtig. Vertrauen Sie auch keinen „Fakten“, die der Kunde in Bezug auf seine Identität liefert, da diese vom Kunden geändert werden können. Sie möchten sich auf das SSL-Zertifikat des Clients verlassen, um die Authentifizierung des Servers bereitzustellen. Um ehrlich zu sein, wenn Sie Dinge wie Hiera richtig verwenden und große, auf Hostnamen basierende If-Blöcke in Ihrem Code vermeiden (was Sie wirklich sollten), wird es Ihnen gut gehen.

2) Es sollte nicht sein, vorausgesetzt, Sie halten es gepatcht. Bei richtiger Konfiguration gibt es nur einen kleinen Vektor, mit dem der Puppenspieler von den Clients angegriffen werden kann. Das heißt, die Auswirkungen, wenn es kompromittiert wurde, sind groß, also achten Sie darauf, es zu sperren.

3) Das ist wirklich ein Test- und Bereitstellungsproblem. Wenn Sie einen soliden Puppencode haben, werden Ihre Dateien nicht durcheinander gebracht. Es dauert eine Weile, bis das geklärt ist, aber für die Grundlagen (wie Sie sie brauchen) dauert es nicht lange.

Ist Puppet (oder ähnliches) eine geeignete Technologie, um grundlegende, aber kritische Massenänderungen zu berücksichtigen?

Ja, es kann auf diese Weise verwendet werden. Ich benutze es, um externe Client-Systeme zu unterstützen.

Ich möchte nicht, dass ein Server eine Konfiguration sieht, die er nicht sehen sollte

Wenn Sie Puppet verwenden, dürfen Sie das automatische Signieren dann nicht aktivieren. Mit Autosign können Hosts automatisch ein Zertifikat anfordern. Ihre Konfiguration und Berechtigungen werden mit ziemlicher Sicherheit direkt mit dem CN im Zertifikat verknüpft. Sie möchten nicht, dass zufällige Computer online gehen und behaupten können, dass sie tatsächlich das System mit all den geheimen Hochsicherheitsdaten sind.

Wenn Sie wirklich paranoid sind, können Sie die Einstellungen des Puppets-Dateiservers anpassen, um Freigaben zu erstellen, auf die nur einige Systeme zugreifen können. Der Dateiserverzugriff basiert auf den Zertifikaten.

Ich möchte nicht, dass Puppet Änderungen vornimmt, die es nicht sollte, oder manuelle Änderungen, die auf dem Server vorgenommen wurden, rückgängig macht.

Es gibt verschiedene Ansätze, um lokale Änderungen zuzulassen.

Eine Methode, die ich häufig verwende, ist unten. Wenn Sie eine Liste an a übergeben source, probiert die Puppe grundsätzlich jedes Element in der Liste aus. Also füge ich das erste Element in der Liste hinzu, um auf eine lokale Datei zu verweisen.

  file { '/etc/ssh/sshd_config':
    ensure => present,
    source => ["/etc/ssh/sshd_config_local",
               "puppet:///modules/ssh/$ssh_config_file"],
    ...
  }

Eine andere Möglichkeit wäre, Symlinks zu verwenden. Wenn jemand die Puppenversion verwenden möchte, verknüpft er sie mit der Puppenversion einer Datei. Wenn sie ihre Konfiguration lokal pflegen möchten, erstellen sie keinen Symlink.

  file { '/etc/ssh/sshd_config_puppet':
    ensure => present,
    source => "puppet:///modules/ssh/$ssh_config_file",
    ...
  }

Die andere Möglichkeit besteht darin, Augeas zu verwenden, um Änderungen auf Zeilenebene vorzunehmen, anstatt ganze Dateien zu ändern. Seien Sie sehr konservativ in Bezug auf das, was Sie ändern.

3> In Puppet oder einem solchen Werkzeug gibt es kein automatisches Rückgängigmachen. Sie müssen expliziten Code schreiben, um rückgängig zu machen. Darüber hinaus können Sie die Umgebungsfunktion von Puppet untersuchen, ein Testlabor einrichten, in dem neuer Code getestet wird (möglicherweise VMs), und die Codeüberprüfung verwenden.

Ich möchte nicht, dass Puppet Änderungen vornimmt, die es nicht sollte, oder manuelle Änderungen, die auf dem Server vorgenommen wurden, rückgängig macht.

Für Konfigurationsdateien, die mit dem Dateityp Puppets erstellt wurden, kann dies durch Folgendes erreicht werden:

replace => false,

Ich verwende das, um einige Konfigurationsdateien zu generieren, wenn eine Anwendung zum ersten Mal auf einem Server bereitgestellt wird, aber dann werden alle Änderungen an dieser Konfigurationsdatei nicht von Puppet überschrieben.

Dies widerspricht jedoch der Philosophie von Puppet, ein idempotentes Bereitstellungsskript zu sein.

Wenn Sie können, ist es möglicherweise besser, separate, vom Administrator bearbeitbare Dateien zu haben, die nicht von Puppet verwaltet werden und in den Dateien enthalten sind, die von Puppet verwaltet werden.

Puppet funktioniert am besten für viele Server mit identischer Konfiguration. Sie schreiben beispielsweise die gesamte Konfiguration eines gemeinsam genutzten Webservers, der von Ihrem Unternehmen bereitgestellt wird, und erstellen dann N Instanzen dieses Servers. Danach ist es sehr einfach, Änderungen an allen Instanzen gleichzeitig vorzunehmen (z. B. wenn Sie feststellen, dass AllowOverride für alle virtuellen Apache-Hosts geändert werden muss). Sie können auch alle Konfigurationsinformationen an einem einzigen Ort speichern und unter Versionskontrolle stellen. Im perfekten Fall können Sie einen Hardwarefehler beheben, indem Sie den defekten Host wegwerfen, durch einen neuen ersetzen, denselben Hostnamen festlegen und das erforderliche Zertifikat signieren. Alles andere könnte von Puppet erledigt werden.

Wenn Sie jedoch fast keine Konfigurationsfreigabe zwischen zwei Hosts haben, ist die Verwendung von Puppet möglicherweise weniger produktiv als die manuelle Konfiguration. Auch die manuelle Verwaltung der Hälfte der Serverkonfiguration mit Puppet und der anderen Hälfte ist möglicherweise nicht sehr sinnvoll.

Zusammenfassung : Wenn Sie eine einheitliche und strukturierte Konfiguration für die zu verwaltenden Hosts erstellen können, ist Puppet Ihr bester Freund. Wenn Sie jedoch jeden Dienst (Host, virtueller Host, Datenbank) verwalten müssen, wird Puppet nicht hinzugefügt viel Wert.