Bare-Metal-Provisionierung mit eigenen Händen oder Automatisierte Servervorbereitung von Grund auf

Hallo, ich bin Denis und eines meiner Tätigkeitsfelder ist die Entwicklung von Infrastrukturmaßnahmen bei X5. Heute möchte ich mit Ihnen teilen, wie man mit allgemein verfügbaren Werkzeugen ein automatisiertes Serversystem einrichten kann. Meiner Meinung nach ist dies eine interessante, einfache und flexible Lösung.

Unter Vorbereitung versteht man: einen neuen Server aus der Box in einen vollständig konfigurierten Server mit dem Betriebssystem Linux oder mit dem Hypervisor ESXi (Windows wird in diesem Artikel nicht behandelt). Server Server – Server, die konfiguriert werden müssen.

Begriffe:

• Installationsserver – der Hauptserver, der den gesamten Vorbereitungsprozess über das Netzwerk gewährleistet.
• Warum ist Automatisierung notwendig?

Angenommen, die Aufgabe besteht darin, Server massenhaft von Grund auf vorzubereiten, im Höchstfall – 30 pro Tag. Server unterschiedlicher Hersteller und Modelle, auf denen verschiedene Betriebssysteme installiert werden können, und es kann ein Hypervisor vorhanden sein oder auch nicht.

Welche Operationen gehören zum Konfigurationsprozess (ohne Automatisierung):

Tastatur, Maus und Monitor mit dem Server verbinden;

• BIOS, RAID, IPMI konfigurieren;
• Firmware der Komponenten aktualisieren;
• Abbild des Dateisystems bereitstellen (oder Hypervisor installieren und virtuelle Maschinen kopieren);
• Hinweis. Als Möglichkeit kann das Betriebssystem über die Installation mit einer Antwortdatei bereitgestellt werden. Dies wird jedoch im Artikel nicht behandelt. Obwohl Sie weiter unten sehen werden, dass es nicht schwierig ist, diese Funktionalität hinzuzufügen.

Betriebssystemparameter konfigurieren (Hostname, IP usw.).

• Bei diesem Ansatz werden die gleichen Einstellungen nacheinander auf jedem Server durchgeführt. Die Effizienz dieser Arbeit ist sehr gering.

Der Kern der Automatisierung besteht darin, die menschliche Beteiligung am Prozess der Servervorbereitung so weit wie möglich auszuschließen.

Dank der Automatisierung wird die Ausfallzeit zwischen den Operationen verkürzt und die Möglichkeit geschaffen, mehrere Server gleichzeitig vorzubereiten. Außerdem wird die Wahrscheinlichkeit von Fehlern aufgrund menschlicher Faktoren erheblich verringert.

Wie erfolgt die automatische Serverkonfiguration?

Lassen Sie uns alle Schritte im Detail durchgehen.

Sie haben einen Linux-Server, den Sie als PXE-Installationsserver verwenden. Auf diesem sind die Dienste DHCP und TFTP installiert und konfiguriert.

Laden wir also den Server (der konfiguriert werden muss) über PXE. Erinnern wir uns, wie das funktioniert:

Auf dem Server ist das Booten über das Netzwerk ausgewählt.

• Es wurde ein Netzwerkboot auf dem Server ausgewählt.
• Der Server lädt den PXE-ROM des Netzwerkkarten und kontaktiert den Installationsserver über DHCP, um eine Netzwerkadresse zu erhalten.
• Der DHCP des Installationsservers gibt eine Adresse sowie Anweisungen für das weitere Laden über PXE aus.
• Der Server lädt den Netzwerk-Loader vom Installationsserver über PXE, das weitere Laden erfolgt gemäß der PXE-Konfigurationsdatei.
• Die Ladung erfolgt basierend auf den erhaltenen Parametern (Kernel, initramfs, Mount-Punkte, squashfs-Image und weitere).

Hinweis. In diesem Artikel wird die PXE-Boot-Prozedur über den BIOS-Modus beschrieben. Derzeit wird aktiv von den Herstellern der UEFI-Bootmodus implementiert. Der Unterschied bei PXE liegt in der Konfiguration des DHCP-Servers und der Verfügbarkeit eines zusätzlichen Bootloaders.

Betrachten wir ein Beispiel für die Konfiguration eines PXE-Servers (pxelinux-Menü).

Datei pxelinux.cfg/default:

default menu.c32
prompt 0
timeout 100
menu title X5 PXE Boot Menü
LABEL InstallServer Menü
	MENU LABEL InstallServer
	KERNEL menu.c32
	APPEND pxelinux.cfg/installserver
LABEL VMware Menü
	MENU LABEL VMware ESXi Installieren
	KERNEL menu.c32
	APPEND pxelinux.cfg/vmware
LABEL toolkit // Standardmenü
	MENU LABEL Linux Scripting Toolkits
	MENU default
	KERNEL menu.c32
	APPEND pxelinux.cfg/toolkit // Wechsel zum nächsten Menü

Datei pxelinux.cfg/toolkit:

prompt 0
timeout 100
menu title X5 PXE Boot Menü
label mainmenu
    menu label ^Zurück zum Hauptmenü
    kernel menu.c32
    append pxelinux.cfg/default
label x5toolkit-auto // Standard - Automatischer Modus
        menu label x5 Toolkit Autoinstallation
        menu default
        kernel toolkit/tkcustom-kernel
        append initrd=toolkit/tk-initramfs.gz quiet net.ifnames=0 biosdevname=0 nfs_toolkit_ip=192.168.200.1 nfs_toolkit_path=tftpboot/toolkit nfs_toolkit_script=scripts/mount.sh script_cmd=master-install.sh CMDIS2="…"
label x5toolkit-shell // Für Debugging - Konsole
        menu label x5 Toolkit Shell
        kernel toolkit/tkcustom-kernel
        append initrd=toolkit/tkcustom-initramfs.gz quiet net.ifnames=0 biosdevname=0 nfs_toolkit_ip=192.168.200.1 nfs_toolkit_path=tftpboot/toolkit nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash CMDIS2="…"

Kernel und initramfs sind in diesem Stadium ein Zwischenergebnis eines Linux-Images, mit dem die grundlegende Vorbereitung und Konfiguration des Servers durchgeführt wird.

Wie Sie sehen, übergibt der Bootloader viele Parameter an den Kernel. Ein Teil dieser Parameter wird vom Kernel selbst verwendet. Einige davon können wir jedoch für unsere eigenen Zwecke nutzen. Darüber wird später erläutert, und vorerst können Sie sich einfach merken, dass alle übergebenen Parameter im Zwischenergebnis des Linux-Images über /proc/cmdline verfügbar sind.

Woher bekommt man Kernel und initramfs?
Als Grundlage kann jeder Linux-Distribution gewählt werden. Worauf wir bei der Auswahl achten:

• Das Boot-Image sollte universell sein (Verfügbarkeit von Treibern, Möglichkeit zur Installation zusätzlicher Tools);
• Wahrscheinlich wird es notwendig sein, das initramfs anzupassen.

Wie wird das in unserer Lösung für X5 gemacht? Als Basis wurde CentOS 7 gewählt. Wir werden folgendes tricksen: Wir bereiten die zukünftige Struktur des Images vor, packen sie in ein Archiv und erstellen ein initramfs, in dem unser Archiv des Dateisystems enthalten ist. Während des Bootens des Images wird das Archiv in das zu erstellende tmpfs-Verzeichnis entpackt. So erhalten wir ein minimales, aber voll funktionsfähiges Live-Image von Linux mit allen notwendigen Dienstprogrammen, das aus nur zwei Dateien besteht: vmkernel und initramfs.

#создаем директории: 

mkdir -p /tftpboot/toolkit/CustomTK/rootfs /tftpboot/toolkit/CustomTK/initramfs/bin

#подготавливаем структуру:

yum groups -y install "Minimal Install" --installroot=/tftpboot/toolkit/CustomTK/rootfs/
yum -y install nfs-utils mariadb ntpdate mtools syslinux mdadm tbb libgomp efibootmgr dosfstools net-tools pciutils openssl make ipmitool OpenIPMI-modalias rng-tools --installroot=/tftpboot/toolkit/CustomTK/rootfs/
yum -y remove biosdevname --installroot=/tftpboot/toolkit/CustomTK/rootfs/

# подготавливаем initramfs:

wget https://busybox.net/downloads/binaries/1.31.0-defconfig-multiarch-musl/busybox-x86_64 -O /tftpboot/toolkit/CustomTK/initramfs/bin/busybox
chmod a+x /tftpboot/toolkit/CustomTK/initramfs/bin/busybox
cp /tftpboot/toolkit/CustomTK/rootfs/boot/vmlinuz-3.10.0-957.el7.x86_64 /tftpboot/toolkit/tkcustom-kernel

# создаем /tftpboot/toolkit/CustomTK/initramfs/init (ниже содержание скрипта):

#!/bin/busybox sh
/bin/busybox --install /bin
mkdir -p /dev /proc /sys /var/run /newroot
mount -t proc proc /proc
mount -o mode=0755 -t devtmpfs devtmpfs /dev
mkdir -p /dev/pts /dev/shm /dev/mapper /dev/vc
mount -t devpts -o gid=5,mode=620 devpts /dev/pts
mount -t sysfs sysfs /sys
mount -t tmpfs -o size=4000m tmpfs /newroot
echo -n "Extracting rootfs... "
xz -d -c -f rootfs.tar.xz | tar -x -f - -C /newroot
echo "done"
mkdir -p /newroot/dev /newroot/proc /newroot/sys
mount --move /sys  /newroot/sys
mount --move /proc /newroot/proc
mount --move /dev  /newroot/dev
exec switch_root /newroot /sbin/init

# упаковываем rootfs и initramfs:

cd /tftpboot/toolkit/CustomTK/rootfs
tar cJf /tftpboot/toolkit/CustomTK/initramfs/rootfs.tar.xz --exclude ./proc --exclude ./sys --exclude ./dev .
cd /tftpboot/toolkit/CustomTK/initramfs
find . -print0 | cpio --null -ov --format=newc | gzip -9 > /tftpboot/toolkit/tkcustom-initramfs-new.gz

So haben wir den Kernel und das initramfs angegeben, die geladen werden sollen. Infolgedessen erhalten wir in diesem Schritt, indem wir ein Zwischen-Image von Linux über PXE laden, die OS-Konsole.

Ausgezeichnet, aber jetzt müssen wir die Kontrolle über unsere „Automatisierung“ übergeben.

Das kann so gemacht werden.

Angenommen, nach dem Laden des Images planen wir, die Kontrolle an das Skript mount.sh zu übergeben.
Wir aktivieren das Skript mount.sh beim Systemstart. Dazu muss das initramfs modifiziert werden:

• initramfs entpacken (wenn wir die oben beschriebene initramfs-Variante verwenden, ist dies nicht erforderlich)
• Code für die Autostart einfügen, der die übergebenen Parameter über /proc/cmdline analysiert und die Kontrolle weitergibt;
• initramfs verpacken.

Hinweis. Im Fall des X5-Toolkits wird die Bootkontrolle an das Skript übergeben. /opt/x5/toolkit/bin/hook.sh с помощью override.conf в getty tty1 (ExecStart=…)

So wird ein Image geladen, in dem beim Autostart das Skript mount.sh gestartet wird. Das Skript mount.sh analysiert während seiner Ausführung die übergebenen Parameter (script_cmd=) und startet das benötigte Programm/Skript.

label toolkit-auto
kernel …
append … nfs_toolkit_script=scripts/mount.sh script_cmd=master-install.sh

label toolkit-shell
kernel …
append … nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash

Hier auf der linken Seite – das PXE-Menü, auf der rechten – das Schema zur Übergabe der Kontrolle.

Mit der Kontrolle sind wir durch. Je nach Auswahl im PXE-Menü wird entweder das Skript zur automatischen Konfiguration oder die Konsole für das Debugging gestartet.

Bei der automatischen Konfiguration werden die erforderlichen Verzeichnisse vom Installationsserver gemountet, die Folgendes enthalten:

• Skripte;
• gespeicherte BIOS/UEFI-Vorlagen verschiedener Server;
• Firmware;
• Dienstprogramme für Server;
• Protokolle.

Danach übergibt das Skript mount.sh die Kontrolle an das Skript master-install.sh aus dem Verzeichnis mit den Skripten.

Die Struktur der Skripte (Reihenfolge ihrer Ausführung) sieht ungefähr so aus:

• master-install
• sharefunctions (gemeinsame Funktionen)
• info (Ausgabe von Informationen)
• models (Konfiguration der Installationsparameter basierend auf dem Servermodell)
• prepare_utils (Installation der erforderlichen Dienstprogramme)
• fwupdate (Firmware-Updates)
• diag (elementare Diagnostik)
• biosconf (BIOS/UEFI-Einstellungen)
• clockfix (Zeiteinstellung auf der Hauptplatine)
• srmconf (Einstellungen für die Remote-Schnittstelle)
• raidconf (Einstellungen für logische Laufwerke)

einer von:

• preinstall (Übergabe der Kontrolle an den OS- oder Hypervisor-Installer, z. B. ESXi)
• merged-install (direkter Start des Entpackens des Images)

Jetzt wissen wir:

• wie man den Server über PXE bootet;
• wie man die Kontrolle an ein eigenes Skript übergibt.

Lassen Sie uns fortfahren. Die folgenden Fragen sind relevant geworden:

• Wie identifizieren wir den Server, den wir vorbereiten?
• Mit welchen Tools und wie konfigurieren wir den Server?
• Wie erhält man die Einstellungen für einen bestimmten Server?

Wie identifizieren wir den Server, den wir vorbereiten?

Das ist einfach – DMI:

dmidecode –s system-product-name
dmidecode –s system-manufacturer
dmidecode –s system-serial-number

Hier gibt es alles, was benötigt wird: Anbieter, Modell, Seriennummer. Wenn Sie sich nicht sicher sind, dass diese Informationen auf allen Servern vorhanden sind, können Sie sie auch über die MAC-Adresse identifizieren. Oder auf beide Arten gleichzeitig, wenn die Anbieter der Server unterschiedlich sind und bei einigen Modellen die Seriennummer einfach nicht verfügbar ist.

Basierend auf den erhaltenen Informationen werden die Netzwerkordner vom Installationsserver gemountet und alles Notwendige (Tools, Firmware usw.) wird geladen.

Mit welchen Tools und wie konfigurieren wir den Server?

Ich werde Tools für Linux für einige Hersteller anführen. Alle Tools sind auf den offiziellen Websites der Anbieter verfügbar.

Bei Firmware denke ich, dass alles klar ist. Normalerweise werden sie in Form von gepackten ausführbaren Dateien geliefert. Die ausführbare Datei steuert den Firmware-Update-Prozess und meldet den Rückgabecode.

BIOS und IPMI werden normalerweise über Vorlagen konfiguriert. Bei Bedarf kann die Vorlage vor dem eigentlichen Booten bearbeitet werden.

RAID-Tools einiger Anbieter können ebenfalls über Vorlagen konfiguriert werden. Wenn das nicht der Fall ist, muss ein Konfiguration-Skript geschrieben werden.

Der Ablauf zur RAID-Konfiguration ist meist wie folgt:

• Wir fordern die aktuelle Konfiguration an.
• Wenn bereits logische Arrays vorhanden sind – löschen wir diese.
• Wir prüfen, welche physikalischen Laufwerke vorhanden sind und wie viele es sind.
• Wir erstellen ein neues logisches Array. Wir brechen den Prozess im Fehlerfall ab.

Wie erhält man die Einstellungen für einen bestimmten Server?

Nehmen wir an, die Einstellungen aller Server werden auf dem Installationsserver gespeichert. In diesem Fall müssen wir zunächst klären, wie die Einstellungen an den Installationsserver übergeben werden.

In der Anfangsphase kann man problemlos mit Textdateien auskommen. (In Zukunft kann man die Textdatei als Backup-Methode zur Übertragung von Einstellungen verwenden).

Es ist möglich, eine Textdatei auf dem Installationsserver zu "teilen" und ihr Einbindung in das Skript mount.sh hinzuzufügen.

Die Zeilen werden beispielsweise so aussehen:

Diese Zeilen werden von einem Ingenieur von seinem Arbeitsplatzrechner in die Datei übertragen. Bei der Konfiguration des Servers werden die Parameter für den spezifischen Server dann aus der Datei gelesen.

Langfristig ist es allerdings besser, eine Datenbank zur Speicherung von Einstellungen, Zuständen und Installationsprotokollen der Server zu verwenden.

Natürlich kommt man nicht ohne eine Datenbank aus, und es wird notwendig sein, einen Client zu erstellen, über den die Einstellungen in die Datenbank übertragen werden. Dies umzusetzen ist komplizierter als mit einer Textdatei, aber es ist tatsächlich nicht so schwierig, wie es scheint. Eine Minimalversion des Clients, der einfach Daten in die Datenbank überträgt, kann man problemlos selbst schreiben. Weitere Verbesserungen der Client-Software können später in einem freien Modus vorgenommen werden (Berichte, Etikettendruck, Benachrichtigungen senden und alles, was einem einfällt).

Wenn man eine bestimmte Anfrage an die Datenbank stellt und die Seriennummer des Servers angibt, erhält man die notwendigen Parameter zur Konfiguration des Servers.

Außerdem müssen wir keine Sperren für den gleichzeitigen Zugriff erfinden, wie im Fall einer Textdatei.

Das Konfigurationsprotokoll können wir in allen Phasen in die Datenbank schreiben und den Installationsprozess über Ereignisse und Flags der Vorbereitungsschritte steuern.

Jetzt wissen wir, wie:

• den Server über PXE zu starten;
• die Kontrolle an unser Skript zu übergeben;
• den Server, der vorbereitet werden soll, anhand der Seriennummer zu identifizieren;
• den Server mit den entsprechenden Dienstprogrammen zu konfigurieren;
• die Einstellungen über den Client in die Datenbank des Installationsservers zu übertragen.

Wir haben herausgefunden, wie:

• der zu installierende Server die notwendigen Einstellungen aus der Datenbank erhält;
• der gesamte Fortschritt der Vorbereitung in der Datenbank festgehalten wird (Protokolle, Ereignisse, Flags der Phasen).

Wie sieht es mit verschiedenen Arten von zu installierender Software aus? Wie installiert man einen Hypervisor, kopiert eine VM und konfiguriert alles?

Im Fall der Bereitstellung eines Dateisystem-Images (linux) auf Hardware ist alles recht einfach:

• Nach der Konfiguration aller Serverkomponenten setzen wir das Image ein.
• Wir installieren den Bootloader grub.
• Wir führen chroot durch und richten alles Notwendige ein.

Wie man die Kontrolle an den OS-Installer übergibt (am Beispiel von ESXi).

• Wir organisieren die Übergabe der Kontrolle von unserem Skript an den Hypervisor-Installer mithilfe der Antwortdatei (kickstart):
• Wir löschen die aktuellen Partitionen auf der Festplatte.
• Wir erstellen eine Partition mit einer Größe von 500MB.
• Wir kennzeichnen sie als bootfähig.
• Wir formatieren sie in FAT32.
• Wir kopieren die Installationsdateien von ESXi in das Wurzelverzeichnis.
• Wir installieren syslinux.
• Wir kopieren syslinux.cfg nach /syslinux/

default esxi
prompt 1
timeout 50
label esxi
kernel mboot.c32
append -c boot.cfg

• Wir kopieren mboot.c32 nach /syslinux.
• In boot.cfg sollte kernelopt=ks=ftp:///ks_esxi.cfg stehen.
• Server neu starten.

Nach dem Neustart des Servers wird der ESXi-Installer von der Festplatte geladen. Alle notwendigen Installationsdateien werden in den Speicher geladen, und dann beginnt die Installation von ESXi gemäß der angegebenen Antwortdatei.

Hier sind einige Zeilen aus der Antwortdatei ks_esxi.cfg:

%firstboot --interpreter=busybox
…
# Seriennummer abrufen

SYSSN=$(esxcli hardware platform get | grep Serial | awk -F " " '{print $3}')

# IP abrufen

IPADDRT=$(esxcli network ip interface ipv4 get | grep vmk0 | awk -F " " '{print $2}')
LAST_OCTET=$(echo $IPADDRT | awk -F'.' '{print $4}')

# NFS Installationsserver anschließen

esxcli storage nfs add -H is -s /srv/nfs_share -v nfsshare1

# Temporäre SSH-Einstellungen für den SSH-Client kopieren

mv /etc/ssh /etc/ssh.tmp
cp -R /vmfs/volumes/nfsshare1/ssh /etc/
chmod go-r /etc/ssh/ssh_host_rsa_key

# ovftool kopieren, um die VM jetzt bereitzustellen, könnte auch später nützlich sein

cp -R /vmfs/volumes/nfsshare1/ovftool /vmfs/volumes/datastore1/

# VM bereitstellen

/vmfs/volumes/datastore1/ovftool/tools/ovftool --acceptAllEulas --noSSLVerify --datastore=datastore1 --name=VM1 /vmfs/volumes/nfsshare1/VM_T/VM1.ova vi://root:esxi_password@127.0.0.1
/vmfs/volumes/datastore1/ovftool/tools/ovftool --acceptAllEulas --noSSLVerify --datastore=datastore1 --name=VM2 /vmfs/volumes/nfsshare1/VM_T/VM2.ova vi://root:esxi_password@127.0.0.1

# Abruf der Serverkonfiguration

ssh root@is "mysql -h'192.168.0.1' -D'servers' -u'user' -p'secretpassword' -e "SELECT ... WHERE servers.serial='$SYSSN'"" | grep -v ^$ | sed 's/NULL//g' > /tmp/servers
...
# Skript zur Netzwerkkonfiguration generieren

echo '#!/bin/sh' > /vmfs/volumes/datastore1/netconf.sh
echo "esxcli network ip interface ipv4 set -i=vmk0 -t=static --ipv4=$IPADDR --netmask=$S_SUB || exit 1" >> /vmfs/volumes/datastore1/netconf.sh
echo "esxcli network ip route ipv4 add -g=$S_GW -n=default || exit 1" >> /vmfs/volumes/datastore1/netconf.sh
chmod a+x /vmfs/volumes/datastore1/netconf.sh

# Setzen des Parameters guestinfo.esxihost.id auf die Seriennummer

echo "guestinfo.esxihost.id = "$SYSSN"" >> /vmfs/volumes/datastore1/VM1/VM1.vmx
echo "guestinfo.esxihost.id = "$SYSSN"" >> /vmfs/volumes/datastore1/VM2/VM2.vmx
...
# Informationen in der Datenbank aktualisieren

SYSNAME=$(esxcli hardware platform get | grep Product | sed 's/Product Name://;s/^ *//')
UUID=$(vim-cmd hostsvc/hostsummary | grep uuid | sed 's/ //g;s/,$//'; s/^uuid="//;s/"$//')
ssh root@is "mysql -D'servers' -u'user' -p'secretpassword' -e "UPDATE servers ... SET ... WHERE servers.serial='$SYSSN'""
ssh root@is "mysql -D'servers' -u'user' -p'secretpassword' -e "INSERT INTO events ...""

# SSH-Einstellungen zurückgeben

rm -rf /etc/ssh
mv /etc/ssh.tmp /etc/ssh

# Netzwerk konfigurieren und neu starten

esxcli system hostname set --fqdn=esx-${G_NICK}.x5.ru
/vmfs/volumes/datastore1/netconf.sh
reboot

In diesem Schritt wurde der Hypervisor installiert und konfiguriert, die virtuellen Maschinen wurden kopiert.

Wie konfiguriert man nun die virtuellen Maschinen?

Wir haben ein wenig geschummelt: Während der Installation haben wir den Parameter guestinfo.esxihost.id = "$SYSSN" in der Datei VM1.vmx gesetzt und die Seriennummer des physischen Servers angegeben.

Jetzt kann die virtuelle Maschine (mit installiertem vmware-tools-Paket) beim Start auf diesen Parameter zugreifen:

ESXI_SN=$(vmtoolsd --cmd "info-get guestinfo.esxihost.id")

Das heißt, die VM wird in der Lage sein, sich selbst zu identifizieren (sie kennt die Seriennummer des physischen Hosts), eine Anfrage an die Datenbank des Installationsservers zu stellen und die Parameter zu erhalten, die konfiguriert werden müssen. Das alles wird in einem Skript formuliert, das automatisch beim Start der guestos VM ausgeführt werden soll (aber nur einmal: RunOnce).

Jetzt wissen wir, wie:

• den Server über PXE zu starten;
• die Kontrolle an unser Skript zu übergeben;
• den Server, der vorbereitet werden soll, anhand der Seriennummer zu identifizieren;
• den Server mit den entsprechenden Dienstprogrammen konfigurieren;
• Einstellungen über die Client-Software an die Datenbank des Installationsservers übermitteln;
• verschiedene Arten von Software konfigurieren, einschließlich der Bereitstellung des Hypervisors ESXi und der Konfiguration virtueller Maschinen (alles automatisiert).

Wir haben herausgefunden, wie:

• der zu installierende Server die notwendigen Einstellungen aus der Datenbank erhält;
• der gesamte Fortschritt der Vorbereitung in der Datenbank festgehalten wird (Protokolle, Ereignisse, Flags der Phasen).

Fazit:

Ich glaube, die Einzigartigkeit dieser Lösung liegt in ihrer Flexibilität, Einfachheit, ihren Möglichkeiten und ihrer Vielseitigkeit.

Bitte teilen Sie in den Kommentaren mit, was Sie denken.

Quelle: habr.com