Wo ich gerade arbeite, müssen wir den Linux-Teil unserer Serverfarm verwalten, der nur etwas über 300 Linux-Server umfasst. Dies umfasst hauptsächlich HP Proliants, gefolgt von IBM 3850s, einigen IBM Blades, VMware ESX und einigen KVM für unsere internen Verwaltungsserver.
Cobbler
Wir haben uns Cobbler angesehen, aber das Problem war, dass Cobbler sehr RHEL / Red Hat-spezifisch ist. Wir müssen RHEL und SLES mindestens unterstützen und Ubuntu ist als nächstes dran.
Marionette
Wir haben Puppet in Betracht gezogen, haben uns jedoch später dagegen entschieden, da es von Ruby abhängt, was bedeutet, dass ein Upgrade von Ruby unser Managementsystem möglicherweise beschädigen könnte.
hotwire
Wir verwenden Hotwire (intern entwickelt, aber Open Source) und das seit einigen Jahren. Erstens werden die zu erstellenden Systeme inventarisiert, dh das Rechenzentrum, das Rack, die Hardware, das Betriebssystem, das Netzwerk usw. werden inventarisiert, und zweitens erfolgt die schnelle Erstellung und Bereitstellung. Sobald das System erstellt ist, wird das Inventar durch die automatische Inventarisierung von hotwire synchronisiert, während es von cfengine verwaltet wird. Hotwire kennt die Server-Hardware, indem es über Python- Dmidecode mit den SMBIOS / DMI-Daten im BIOS spricht .
Die Bonuspunkte sind, dass Inventar und Erstellungsprozess in einem zusammengefasst werden, sodass weniger verwaltet werden muss, und die Live-Inventar-Funktion ist großartig, da wir wissen, ob etwas nicht ganz stimmt.
Die Nachteile sind, dass die Benutzeroberfläche immer noch poliert werden muss, und es gibt hier und da Fehler, aber die Entwicklung ist immer noch heiß, und gemeldete Fehler werden relativ schnell behoben.
cfengine
Wir verwenden Cfengine, weil es außer Cfengine und Puppet nichts anderes gibt. Tatsächlich ist es ein gutes Tool, aber "gut" nur in Abhängigkeit davon, wie gut Ihre Richtlinien sind. Wenn Sie gefährliche Richtlinien festlegen, kann ein kleiner Fehler eine Menge Schaden anrichten. Zum Beispiel "modifizieren" wir Dateien nicht, wir ersetzen sie entweder oder wir tun es nicht. Außerdem haben alle ersetzten Dateien einen Header, der jeder Person, die sie bearbeitet, mitteilt, dass sie beim nächsten Start ersetzt werden (sie wird stündlich über cron ausgeführt).
Die Konfiguration und alle Dateien, die von cfengine an die Server gesendet werden, werden ebenfalls in einem SCM gespeichert. Wenn möglich, überprüfen wir die Syntax mithilfe von Post-Commit-Hooks. Wenn dies fehlschlägt, wird das Commit abgelehnt. Dies ist für nette Anwendungen wie Apache einfach, für die meisten Unternehmensanwendungen jedoch nicht so einfach.