🥇Bare-Metal-Provisionierung selbst gemacht oder automatische Serverbereitstellung von Grund auf

Hallo, ich bin Denis und eine meiner Tätigkeiten ist die Entwicklung von Infrastruktur-Lösungen bei X5. Heute möchte ich mit Ihnen teilen, wie man mit öffentlichen Tools ein automatisiertes System zur Servervorbereitung aufbauen kann. Meiner Meinung nach ist dies eine interessante, einfache und flexible Lösung.

Unter Vorbereitung versteht man: aus einem neuen Server „out of the box“ einen vollständig konfigurierten Server mit Linux-Betriebssystem oder mit dem Hypervisor ESXi zu erstellen (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 bereitstellt.
Warum ist Automatisierung erforderlich?

Angenommen, es gibt die Aufgabe, Server massenhaft von Grund auf vorzubereiten, im Höchstfall 30 pro Tag. Server verschiedener Hersteller und Modelle, auf denen unterschiedliche Betriebssysteme installiert werden können, und es kann ein Hypervisor vorhanden sein oder nicht.

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

eine Tastatur, eine Maus und einen Monitor mit dem Server verbinden;

BIOS, RAID, IPMI konfigurieren;
Firmware der Komponenten aktualisieren;
Firmware der Komponenten aktualisieren;
ein Dateisystem-Image bereitstellen (oder einen Hypervisor installieren und virtuelle Maschinen kopieren);

Hinweis. Alternativ kann das Betriebssystem über eine Installation mit einer Antwortdatei bereitgestellt werden. Dies wird jedoch nicht in diesem Artikel besprochen. Unten sehen Sie jedoch, dass es nicht schwierig ist, diese Funktionalität hinzuzufügen.

die Betriebssystemparameter konfigurieren (Hostname, IP, andere).

Bei diesem Ansatz werden dieselben Einstellungen nacheinander auf jedem Server vorgenommen. Die Effizienz dieser Arbeit ist sehr gering.

Das Wesen der Automatisierung besteht darin, menschliche Beteiligung am Prozess der Servervorbereitung auszuschließen. So weit wie möglich.

Dank der Automatisierung wird die Ausfallzeit zwischen den Vorgängen verringert und es wird ermöglicht, mehrere Server gleichzeitig vorzubereiten. Auch die Wahrscheinlichkeit von Fehlern aufgrund menschlicher Faktoren sinkt erheblich.

Wie erfolgt die automatische Serverkonfiguration?

Lassen Sie uns alle Schritte im Detail durchgehen.

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

Laden wir also den Server, der konfiguriert werden muss, über PXE. Lassen Sie uns erinnern, wie das funktioniert:

Beim Server wird die Netzwerkboot-Option ausgewählt.
Der Server lädt das PXE-ROM der Netzwerkkarte und kontaktiert den Installationsserver über DHCP, um die Netzwerkadresse zu erhalten.
Der DHCP-Installationsserver verteilt die Adresse sowie die Anweisung für das weitere Booten über PXE.
Der Server lädt den Netzwerkbootloader vom Installationsserver über PXE, das weitere Booten erfolgt gemäß der PXE-Konfigurationsdatei.
Das Booten erfolgt basierend auf den erhaltenen Parametern (Kernel, initramfs, Mount-Punkte, squashfs-Image usw.).

Hinweis: Der Artikel beschreibt das Booten über PXE im BIOS-Modus. Derzeit wird von Herstellern aktiv der UEFI-Bootmodus eingeführt. Der Unterschied für PXE liegt in der Konfiguration des DHCP-Servers und dem Vorhandensein eines zusätzlichen Bootloaders.

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

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 Menu
label mainmenu
    menu label ^Zurück zum Hauptmenü
    kernel menu.c32
    append pxelinux.cfg/default
label x5toolkit-auto // standardmäßig - 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 // zur Fehlersuche - 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="…"

Der Kernel und das Initramfs in dieser Phase sind ein vorläufiges Linux-Image, mit dem die Hauptvorbereitung und -konfiguration des Servers erfolgen wird.

Wie Sie sehen können, übergibt der Bootloader viele Parameter an den Kernel. Ein Teil dieser Parameter wird vom Kernel selbst verwendet. Einige können wir für unsere Zwecke nutzen. Darüber wird später gesprochen, und vorerst kann man sich einfach merken, dass alle übergebenen Parameter im vorläufigen Linux-Image über /proc/cmdline verfügbar sind.

Woher bekommt man den Kernel und das Initramfs?
Als Grundlage kann man jede Linux-Distribution wählen. Worauf wir bei der Auswahl achten:

Das Boot-Image muss universell sein (z. B. Treiber, Möglichkeit zur Installation zusätzlicher Tools);
Es wird wahrscheinlich notwendig sein, das initramfs anzupassen.

Wie haben wir das in unserer Lösung für X5 umgesetzt? Grundlage ist CentOS 7. Wir werden den folgenden Trick anwenden: Wir bereiten die zukünftige Struktur des Images vor, packen sie in ein Archiv und erstellen ein initramfs, in dem sich unser Archiv des Dateisystems befindet. Beim Laden des Images wird das Archiv im erstellten tmpfs-Bereich entpackt. So erhalten wir ein minimales, aber vollständiges Live-Linux-Image mit allen notwendigen Tools, bestehend aus nur zwei Dateien: 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

Somit haben wir den Kernel und das initramfs angegeben, die geladen werden sollen. Ergebnis ist, dass wir zu diesem Zeitpunkt, nachdem wir das Zwischen-Image von Linux per PXE geladen haben, die OS-Konsole erhalten.

Gut, aber jetzt müssen wir die Kontrolle an 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 fügen das Skript mount.sh zum Autostart hinzu. Dafür wird es notwendig sein, das initramfs zu modifizieren:

das initramfs entpacken (wenn wir die oben genannte Variante des initramfs verwenden, ist das nicht erforderlich)
Aktivieren Sie den Auto-Start-Code, der die über /proc/cmdline übergebenen Parameter analysiert und die Kontrolle weitergibt;
initramfs packen.

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

Das Image wird geladen, in dem im Auto-Start das Skript mount.sh startet. Im weiteren Verlauf analysiert das Skript mount.sh die übergebenen Parameter (script_cmd=) und startet das erforderliche 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

Links befindet sich das PXE-Menü, rechts – das Steuerungsschema.

Mit der Steuerungsübergabe sind wir fertig. Je nach Auswahl im PXE-Menü wird entweder das Auto-Setup-Skript oder die Debug-Konsole gestartet.

Im Fall der automatischen Konfiguration werden die erforderlichen Verzeichnisse vom Installationsserver eingebunden, in denen sich befinden:

Skripte;
gespeicherte BIOS/UEFI-Vorlagen verschiedener Server;
Firmware;
Utilities für Server;
Logs.

Anschließend übergibt das Skript mount.sh die Kontrolle an das Skript master-install.sh aus dem Skriptverzeichnis.

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

master-install
sharefunctions (gemeinsame Funktionen)
info (Informationsausgabe)
Modelle (Installationseinstellungen basierend auf dem Servermodell)
prepare_utils (Installation der notwendigen Utilities)
fwupdate (Firmware-Updates)
diag (einfache Diagnose)
biosconf (BIOS/UEFI-Konfiguration)
clockfix (Zeit auf dem Motherboard einstellen)
srmconf (Konfiguration der Remote-Management-Schnittstelle)
raidconf (Konfiguration der logischen Volumes)

einer von:

preinstall (Übergabe der Kontrolle an den OS- oder Hypervisor-Installer, z.B. ESXi)
merged-install (sofortiger Start der Entpackung 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. Es sind folgende Fragen relevant geworden:

Wie identifizieren wir den Server, den wir vorbereiten?
Mit welchen Tools und wie konfigurieren wir den Server?
Wie erhalten wir 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 finden Sie alles, was nötig ist: Vendor, Modell, Seriennummer. Wenn Sie sich nicht sicher sind, ob diese Informationen auf allen Servern vorhanden sind, können Sie sie anhand der MAC-Adresse identifizieren. Oder beide Möglichkeiten gleichzeitig, wenn die Vendoren der Server unterschiedlich sind und bei einigen Modellen die Informationen zur Seriennummer einfach fehlen.

Basierend auf den erhaltenen Informationen werden Netzwerkordner mit den Installationsservern verbunden und alles Notwendige (Utilities, Firmware usw.) geladen.

Mit welchen Tools und wie konfigurieren wir den Server?

Ich gebe einige Utilities für Linux für bestimmte Hersteller an. Alle Utilities sind auf den offiziellen Websites der Vendoren verfügbar.

Bei den Firmwares denke ich, ist alles klar. Normalerweise werden sie in Form von gepackten ausführbaren Dateien geliefert. Die ausführbare Datei überwacht den Firmware-Upgrade-Prozess und gibt einen Rückgabewert zurück.

BIOS und IPMI werden normalerweise über Templates konfiguriert. Falls erforderlich, kann das Template vor dem Bootvorgang bearbeitet werden.

Die RAID-Utilities einiger Vendoren können ebenfalls über ein Template konfiguriert werden. Wenn nicht, muss ein Konfigurationsskript geschrieben werden.

Der Ablauf der RAID-Konfiguration sieht meistens folgendermaßen aus:

Wir fordern die aktuelle Konfiguration an.
Falls bereits logische Arrays vorhanden sind, löschen wir sie.
Wir überprüfen, welche physischen Festplatten vorhanden sind und wie viele es sind.
Wir erstellen ein neues logisches Array. Den Prozess im Falle eines Fehlers abbrechen.

Wie erhalten wir die Einstellungen für einen bestimmten Server?

Angenommen, die Einstellungen aller Server werden auf dem Installationsserver gespeichert. In diesem Fall müssen wir zunächst entscheiden, wie die Einstellungen an den Installationsserver übertragen werden.

In der Anfangsphase können wir mit einfachen Textdateien auskommen. (Zukünftig kann eine Textdatei als Backup-Methode zur Übertragung der Einstellungen verwendet werden).

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

Die Zeilen werden zum Beispiel folgendermaßen aussehen:

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

Perspektivisch ist es jedoch besser, eine Datenbank zur Speicherung der Einstellungen, Zustände und Installationsprotokolle der Server zu verwenden.

Natürlich kommt man nicht ohne eine Datenbank aus, und es muss eine Client-Seite erstellt werden, über die die Einstellungen an die Datenbank übertragen werden. Dies umzusetzen ist komplizierter als bei einer Textdatei, aber in Wirklichkeit ist es nicht so schwierig, wie es scheint. Eine minimalistische Version des Clients, die einfach Daten an die Datenbank überträgt, können Sie durchaus selbst schreiben. Und die Client-Software kann später weiter verbessert werden (Berichte, Etikettendruck, Versenden von Benachrichtigungen und alles Weitere, was einem einfällt).

Wenn wir eine bestimmte Anfrage an die Datenbank stellen und die Seriennummer des Servers angeben, erhalten wir die notwendigen Parameter zur Serverkonfiguration.

Zudem müssen wir keine Sperren für den gleichzeitigen Zugriff erfinden, wie es bei einer Textdatei der Fall ist.

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

Jetzt wissen wir, wie:

einen Server über PXE zu laden;
die Kontrolle an unser Skript zu übergeben;
den Server, der vorbereitet werden muss, anhand der Seriennummer zu identifizieren;
den Server mit den entsprechenden Tools zu konfigurieren;
Übertragung der Einstellungen in die Datenbank des Installationsservers über die Client-Seite.

Wir haben herausgefunden, wie:

Der installierte Server erhält die erforderlichen Einstellungen aus der Datenbank;
Der gesamte Vorbereitungsfortschritt wird in der Datenbank festgehalten (Protokolle, Ereignisse, Statusflags).

Wie steht es um die verschiedenen Arten von installierter Software? Wie installiert man den Hypervisor, kopiert eine VM und konfiguriert alles?

Im Fall der Bereitstellung eines Dateisystemabbildes (Linux) auf Hardware ist alles ziemlich einfach:

Nach der Konfiguration aller Serverkomponenten wird das Abbild bereitgestellt.
Wir installieren den Bootloader Grub.
Wir führen Chroot aus und konfigurieren alles, was notwendig ist.

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

Wir organisieren die Übergabe der Kontrolle aus unserem Skript an den Hypervisor-Installer über eine Antwortdatei (Kickstart):
Wir löschen die aktuellen Partitionen auf der Festplatte.
Wir erstellen eine Partition mit einer Größe von 500 MB.
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 stehen: kernelopt=ks=ftp:///ks_esxi.cfg
Wir starten den Server neu.

Nach dem Neustart des Servers wird der ESXi-Installer von seiner Festplatte geladen. Alle erforderlichen 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-Adresse abrufen

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

# NFS Installationsserver verbinden

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

# Temporäre SSH-Einstellungen kopieren, für die Verwendung des SSH-Clients

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, wird vielleicht später benötigt

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

# Abrufen der Konfigurationseinstellungen unseres Servers

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

# Parameter guestinfo.esxihost.id setzen, Seriennummer angeben

echo "guestinfo.esxihost.id = "$SYSSN"" >> /vmfs/volumes/datastore1/VM1/VM1.vmx
echo "guestinfo.esxihost.id = "$SYSSN"" >> /vmfs/volumes/datastore1/VM2/VM2.vmx
...
# Datenbankinformationen aktualisieren

SYSNAME=$(esxcli hardware platform get | grep Product | sed 's/Product Name://' | sed 's/^ *//')
UUID=$(vim-cmd hostsvc/hostsummary | grep uuid | sed 's/ //g;s/,$//' | sed '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

An dieser Stelle wurde der Hypervisor installiert und konfiguriert, die virtuellen Maschinen wurden kopiert.

Wie konfiguriere ich jetzt die virtuellen Maschinen?

Wir haben ein wenig getrickst: Während der Installation haben wir die Einstellung guestinfo.esxihost.id = "$SYSSN" in die Datei VM1.vmx eingegeben und dabei 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 bedeutet, die VM kann sich identifizieren (sie kennt die Seriennummer des physischen Hosts), eine Anfrage an die Installationsserver-Datenbank stellen und die Einstellungen abrufen, die konfiguriert werden müssen. Dies wird in ein Skript gegossen, das beim Start des guestos vm automatisch ausgeführt werden soll (aber nur einmal: RunOnce).

Jetzt wissen wir, wie:

einen Server über PXE zu laden;
die Kontrolle an unser Skript zu übergeben;
den Server, der vorbereitet werden muss, anhand der Seriennummer zu identifizieren;
den Server mit den entsprechenden Tools konfigurieren;
die Einstellungen über den Client in die Datenbank des Installationsservers übertragen;
verschiedene Arten von Software konfigurieren, einschließlich der Bereitstellung des ESXi-Hypervisors und der Konfiguration der virtuellen Maschinen (alles automatisch).

Wir haben herausgefunden, wie:

Der installierte Server erhält die erforderlichen Einstellungen aus der Datenbank;
Der gesamte Vorbereitungsfortschritt wird in der Datenbank festgehalten (Protokolle, Ereignisse, Statusflags).

Fazit:

Ich denke, die Einzigartigkeit dieser Lösung liegt in der Flexibilität, Einfachheit, ihren Möglichkeiten und Universalität.

Bitte teilen Sie Ihre Meinung in den Kommentaren mit.

Quelle: habr.com

Bare-Metal Bereitstellung selbstgemacht: Automatische Servervorbereitung von Grund auf