Was sollte NICHT mit Puppen gemanagt werden?

Ich lerne mich durch das Konfigurationsmanagement im Allgemeinen und verwende Puppet , um es im Besonderen zu implementieren, und frage mich, welche Aspekte eines Systems, falls überhaupt, nicht mit Puppet verwaltet werden sollten .

Als Beispiel nehmen wir normalerweise an, dass Hostnamen bereits eingerichtet sind, bevor das System an die Marionettenverwaltung ausgeliehen wird. Grundlegende IP-Konnektivität, zumindest in dem Netzwerk, das zum Erreichen des Puppenmeisters verwendet wird, muss funktionieren. Es ist verlockend, Puppet zum automatischen Erstellen von DNS-Zonendateien zu verwenden, aber DNS-Reverse-Pointer sollten bereits vorhanden sein, bevor das Ding gestartet wird, oder Zertifikate werden lustig.

Also sollte ich die IP-Konfiguration von Puppet weglassen? Oder sollte ich es einrichten, bevor ich Puppet zum ersten Mal starte, aber trotzdem IP-Adressen mit Puppet verwalten? Was ist mit Systemen mit mehreren IPs (z. B. für WAN, LAN und SAN)?

Was ist mit IPMI ? Sie können die meisten, wenn nicht sogar alle Einstellungen mit ipmitool vornehmen , um den Konsolenzugriff (physisch, seriell über LAN, Remote-KVM usw.) zu verhindern, sodass die Automatisierung mit Puppet möglich ist. Aber die Überprüfung des Status bei jedem Lauf eines Marionettenagenten klingt für mich nicht cool, und der einfache Zugriff auf das System ist etwas, das ich mir wünschen würde, bevor ich etwas anderes tue.

Eine andere ganze Geschichte handelt von der Installation von Updates. Ich gehe nicht auf diesen speziellen Punkt ein, es gibt bereits viele Fragen zu SF und viele verschiedene Philosophien zwischen verschiedenen Sysadmins. Ich selbst habe beschlossen, Puppet keine Dinge aktualisieren zu lassen (z. B. nur ensure => installed) und Aktualisierungen manuell vorzunehmen , wie wir es bereits gewohnt sind, und die Automatisierung dieser Aufgabe einem späteren Tag zu überlassen, an dem wir uns mit Puppet besser auskennen (z. B. indem wir MCollective hinzufügen ) die Mischung).

Das waren nur ein paar Beispiele, die mir gerade in den Sinn kamen. Gibt es einen Aspekt des Systems, der von der Marionette nicht erreicht werden sollte? Oder anders ausgedrückt: Wo liegt die Grenze zwischen dem, was zum Zeitpunkt der Bereitstellung eingerichtet und "statisch" im System konfiguriert werden sollte, und dem, was über das zentrale Konfigurationsmanagement abgewickelt wird?

Allgemeine Regel: Wenn Sie die Konfigurationsverwaltung verwenden, verwalten Sie alle Aspekte der Konfiguration, die Sie können. Je mehr Sie zentralisieren, desto einfacher ist es, Ihre Umgebung zu skalieren.

Spezifische Beispiele (aus der Frage entfernt, alle Erzählungen "Deshalb möchten Sie es verwalten"):

IP-Netzwerkkonfiguration

OK, sicher, Sie haben eine Adresse / ein Gateway / eine NS auf dem Computer konfiguriert, bevor Sie sie in das Rack geworfen haben. Ich meine, wenn du es nicht tust, wie würdest du Puppet laufen lassen, um den Rest der Konfiguration zu erledigen?

Angenommen, Sie fügen Ihrer Umgebung einen weiteren Nameserver hinzu und müssen alle Computer aktualisieren. Möchten Sie nicht, dass Ihr Konfigurationsverwaltungssystem dies für Sie erledigt?

Oder sagen Sie, Ihre Firma wird übernommen, und Ihre neue Muttergesellschaft fordert Sie auf, von Ihrer 192.168.0.0/24-Adresse zu 10.11.12.0/24 zu wechseln, damit sie in ihr Nummerierungssystem passt.

Oder du bekommst plötzlich einen massiven Regierungsvertrag - Nur, dass du IPv6 RIGHT FREAKIN 'NOW aufdrehen musst oder der Deal ist gescheitert ...

Anscheinend möchten wir die Netzwerkkonfiguration verwalten ...

IPMI-Konfiguration

Genau wie bei IP-Adressen müssen Sie dies vor dem Einsetzen des Geräts in das Rack einrichten. Es ist nur vernünftig, IPMI, Remotekonsole usw. auf jedem Computer zu aktivieren, der über die entsprechenden Funktionen verfügt, und diese Konfigurationen funktionieren nicht nicht viel ändern ...

... Bis zu dieser hypothetischen Übernahme, die ich oben in der IP-Konfiguration erwähnt habe - Der Grund, warum Sie gezwungen waren, diese 192.168-Netzadressen zu räumen, ist, dass dies IPMI-Land gemäß Ihren neuen Firmenoberhäuptern ist und Sie alle Ihre IPMI-Karten aktualisieren müssen JETZT, weil sie auf dem reservierten IP-Bereich von jemandem herumtrampeln.

OK, es ist ein bisschen weit hergeholt, aber wie Sie sagten - alles kann mit verwaltet ipmitoolwerden. Warum sollte Puppet nicht das Tool ausführen und die Konfiguration bestätigen, während es alle anderen Aufgaben ausführt? Ich meine, es wird nichts schaden, also können wir auch IPMI mit einbeziehen ...

Aktualisierung

Software-Updates sind eher eine Grauzone - In meiner Organisation haben wir Puppet daraufhin untersucht und festgestellt, dass es "schmerzlich fehlt", und verwenden es daher radmindfür diesen Zweck. Es gibt keinen Grund, warum Puppet Radmind nicht anrufen kann. Wenn wir zur Konfigurationsverwaltung zu Puppet migrieren, passiert genau das!

Das Wichtigste dabei ist, dass alle Ihre Updates auf standardmäßige Weise installiert werden (entweder als Standard im gesamten Unternehmen oder als Standard innerhalb von Plattformen). Es gibt keinen Grund, warum Puppet Ihren Update-Prozess nicht starten sollte, solange Sie ihn gründlich getestet haben alles, um sicherzustellen, dass Puppet nichts durcheinander bringt.
Es gibt auch keinen Grund, warum Puppet kein Werkzeug anrufen kann, das besser für diese Aufgabe geeignet ist, wenn Sie festgestellt haben, dass Puppet selbst keine gute Arbeit leisten kann ...

Das Rad nicht neu erfinden.

Ja, Sie können über 50 virtuelle Marionetten-Benutzerressourcen verfügen und diese nach Bedarf in Ihren Modulen implementieren. Wenn Sie dies jedoch können, verwenden Sie LDAP.

Ich spreche aus bitterer Erfahrung. Obwohl ldap hier noch keine Option ist.

Ein anderes Beispiel ist das Verschieben von Hostdateien, anstatt nur DNS zu verwenden.

• Puppet ist kein Orchestrierungssystem. Speziell:
  • Puppet eignet sich nicht gut für die VM-Orchestrierung, da VMs einen eigenen Lebenszyklus haben, der beachtet werden sollte.
  • Puppet eignet sich nicht gut für die Verwaltung von Anwendungsversionen und für komplexe Upgrades. Standalone-Puppet-Läufe könnten dafür ausgenutzt werden, aber dann hat zumindest Puppet nicht die Kontrolle, sondern es sind Ihre Wrapper-Skripte oder ein menschlicher Roboter, was in Ordnung ist.
• Puppet ist kein gutes Benutzerverwaltungssystem (Es muss jeden Benutzereintrag, auch gelöschte Benutzer, verwalten, um effektiv zu sein. Finden Sie also eine andere Lösung.)
• Puppet ist keine gute Konfigurationsdatenbank (schauen Sie sich an, wie Sie eine externe Datenbank und einen ENC, Hiera oder einen ähnlichen Klebstoff verwenden)

Natürlich können Sie all diese Dinge mit Puppet machen. Aber es ist einfach nicht die beste Lösung für sie. Manchmal solltest du den Hammer weglegen und nach einem Schraubenschlüssel suchen.

Puppet ist jedoch außerordentlich gut darin, die Basiskonfiguration für eine Maschine beizubehalten und die Tools zu installieren, mit denen Sie VMs ausführen und Orchestrierung, Benutzerverwaltung usw. freigeben können.

Ich bin größtenteils mit Voretaq7 einverstanden, aber mit ein paar Einschränkungen.

• Ich konfiguriere die IP-Adressierung selten in Puppet, es sei denn, das System verwendet DHCP (ich gehe davon aus, dass die meisten großen "Cloud" -Anbieter dies tun). Ich hatte Situationen, in denen ich Netzwerkkonfigurationen mit Puppet gebrochen habe, diese aber nicht mit Puppet korrigieren konnte, weil der Knoten keine Möglichkeit hatte, den Puppetmaster zu kontaktieren.

• Ich bin ziemlich fest davon überzeugt, dass das Update-Management in die Hände der System-Tools gehört, und ich sehe es nicht als eine Verbesserung an, Puppet als verherrlichten Cron zu verwenden.

In meinem Fall habe ich ein Bootstrap-Skript, das die minimale Systemkonfiguration (Ubuntu) lädt: Ruby, Rubygems, Build-Essential, Git usw. Meine Puppet-Manifeste werden unter Versionskontrolle gehalten und ich klone einfach das Repository. Von dort geht mein Bootstrap-Skript von einer hostname --shortgültigen Annahme aus und versucht dies puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.

Zur Beantwortung Ihrer Frage:

• Meine Skripte setzen eine grundlegende Netzwerkkonnektivität (DNS, IP) voraus und verwalten oder ändern diese nicht.
• Meine Skripte gehen davon aus, dass die Identität der Maschine korrekt ist, und ändern sie nicht.
• Meine Skripte übernehmen Rubin / Rubygems / Git vorhanden ist, aber Sie es danach verwalten.

Denken Sie, Sie brauchen keine Marionette für die Netzwerkkonfiguration. Es ist in der Regel einmal konfiguriert. Sie können auch Mist bekommen, wenn Sie einen Fehler mit IP oder MAC oder etwas Ähnlichem haben, das die Puppe mit sich bringt.