Auswirkungen der Verwendung von VMware-Vorlagen und -Klonen für die Bereitstellung von Linux-Servern anstelle von PXE

Die Verwendung der VMware-Vorlagen zum Erstellen neuer VMs scheint Geschwindigkeitsvorteile zu haben. Ich bin jedoch besorgt über mögliche weniger offensichtliche Auswirkungen auf Sicherheit und Flexibilität. Zum Beispiel:

• Erster Start generierte Schlüssel
• VMware-proprietäre Methoden zum Konfigurieren von Servereinstellungen (IPs, Hostname usw.)

Hat jemand in einem Shop, der fast ausschließlich aus VMware besteht und bei dem ein Großteil von Linux RHEL-basierte Distributionen sind, einige Probleme bei der Bereitstellung aus Vorlagen festgestellt? Wie wäre es mit Bedenken beim Klonen?

Übrigens: Unabhängig von der anfänglichen Bereitstellungsmethode wird es hauptsächlich als Bootstrap für Puppet für den Rest der Konfiguration verwendet.

Abhängig von der Umgebung und Ihrem Bereitstellungsprozess ist das erneute Erstellen möglicherweise schneller als die Verwendung von VMware-Vorlagen und der Funktion zum Klonen von Vorlagen .

Ich habe in einer großen Linux-fokussierten VMware-Umgebung gearbeitet, in der der Bereitstellungsprozess nicht so automatisiert war, wie er hätte sein sollen. Wir haben uns auf vSphere-Vorlagen von RHEL-Systemen verlassen, aber nach dem ersten Klon war einiges an manueller Arbeit erforderlich.

Vorlagenvorteile:

• Vorlagen sind gut, wenn Sie andere Anwendungen, Konfigurationseinstellungen und Dinge, die außerhalb der Reichweite der Konfigurationsverwaltung liegen, in die Vorlage backen. ( zB ein komplexer Oracle-Anwendungsstapel )
• Die Klonzeit hängt von Ihrer Speicher- und vSphere-Infrastruktur ab. Ich habe sehr langsame und ressourcenintensive Klonjobs gesehen.
• Wenn Sie beispielsweise Red Hat / CentOS / Debian / Ubuntu verwenden, können Sie den sys-unconfigBefehl nutzen , um ein System vor dem Templating zu "dekonfigurieren". Dies ist das Linux-Äquivalent zu Microsoft Sysprepund entfernt Netzwerkschnittstellenregeln, SSH-Schlüssel, Netzwerkeinstellungen usw.
• Die IP-Zuweisungstools von VMware sind in Ordnung und mit den gängigen Linux-Betriebssystemen kein allzu großes Problem.

Vorteile der PXE / Kickstart-Bereitstellung:

• Normalerweise schneller als Template / Cloning, vorausgesetzt, Sie haben ein lokales Repository und ein Net Boot Image.
• Flexibler, da Sie Änderungen an Ihren Images / Master vornehmen können, ohne die Vorlage in eine VM konvertieren, ändern, neu konvertieren und klonen zu müssen.
• Am besten in Verbindung mit einer Konfigurationsmanagementlösung.

Letztendlich hängt es von Ihrer Anwendung ab und davon, wie viel zusätzliche Arbeit nach der ersten Installation des Betriebssystems erforderlich ist. Ich habe einen hybriden Ansatz gewählt und Klone für die komplexesten Instanzen und Neubauten über ein Bereitstellungssystem für Routinesysteme verwendet. Sie schließen sich nicht gegenseitig aus.

Die Einzelheiten hängen von der Verteilung ab, aber ich gebe Ihnen einige CentOS / RHEL-Dinge, die Sie beim Erstellen Ihrer Vorlage beachten sollten.

• Löschen Sie die Schlüssel in /etc/ssh/
• Entfernen Sie die SUBSYSTEM- Zeilen /etc/udev/rules.d/70-persistent-net.rules, die sich auf Ihre Netzwerkkarten beziehen

Beide werden beim ersten Start neu generiert.

Sie benötigen eine Möglichkeit, Updates auszuführen, nachdem Sie die Vorlage bereitgestellt haben.

Mit vSphere können Sie das Netzwerk und den Hostnamen definieren. Als Puppet-Benutzer kann ich den Puppet-Client zusammen mit einem Standard einfach in meiner Vorlage installieren puppet.conf. Wenn ich mehrere Umgebungen verwende, benötige ich für jede Umgebung eine andere Vorlage.

Wenn Sie eine Vorlage ändern, müssen Sie daran denken, die obigen Dateien zu entfernen.

Persönlich ist die Bereitstellung von Vorlagen zwar geringfügig schneller, ich bevorzuge jedoch die Bereitstellung von PXE, da diese flexibler ist.

Schauen Sie sich das Vorbereiten von Linux-Vorlagen-VMs und den Post-It-Verweis an. Erstellen eines Puppet-Ready-Images (CentOS / Fedora) . Vielleicht hilft das.

Übrigens: Ihre Idee, JeOS-VMs bereitzustellen und sie dann mithilfe von Puppet an eine Datenbank, ein Web oder einen anderen Server anzupassen, gefällt mir sehr gut.

Ein weiterer Pluspunkt für den Kickstart von Linux-VMs ist, dass Hosts bei der Installation automatisch vollständig gepatcht werden (die VMs erhalten die neuesten Pakete aus den lokalen Repositorys).

Sie können natürlich dasselbe erreichen, wenn Sie Ihre Vorlagen auf dem neuesten Stand halten, aber das habe ich in den Umgebungen, an denen ich gearbeitet habe, nicht gesehen.

Der% post-Abschnitt unserer Kickstart-Dateien (ja, wir haben mehrere, je nachdem, was für Systeme wir installieren, wie z. B. 32 oder 64 Bit) installiert nur den cfengine-Agenten und von dort aus werden Hosts von cfengine verwaltet.

Ich habe es nicht geplant, aber ich bezweifle, dass das Klonen schneller ist, sobald die Infrastruktur vorhanden ist. Wenn ja, können Sie auch echte Hosts installieren ;-)

Für Debian-basierte Systeme haben wir FAI verwendet , was auch fantastisch ist.