🥇Zelf Bare-Metal Provisioning of automatische servervoorbereiding vanaf nul

Hallo, ik ben Denis en een van mijn activiteiten is het ontwikkelen van infrastructuuroplossingen bij X5. Vandaag wil ik graag met u delen hoe u een automatisch servervoorbereidingssysteem kunt implementeren op basis van openbaar beschikbare hulpmiddelen. Naar mijn mening is dit een interessante, eenvoudige en flexibele oplossing.

Voorbereiding betekent: een nieuwe server direct na het uitpakken omzetten in een volledig geconfigureerde server met een besturingssysteem. Linux of met de ESXi-hypervisor (casting) servers Windows (wordt niet in dit artikel besproken).

termen:

servers – servers die geconfigureerd moeten worden.
installatieserver – de hoofdserver die het volledige voorbereidingsproces via het netwerk verzorgt.

Waarom hebben we automatisering nodig?

Stel je voor dat er een taak is: het op grote schaal vanaf nul voorbereiden van servers, op piekmomenten - 30 per dag. Servers van verschillende fabrikanten en modellen, er kunnen verschillende besturingssystemen op geïnstalleerd zijn en er kan wel of geen hypervisor aanwezig zijn.

Welke handelingen zijn inbegrepen in het installatieproces (zonder automatisering):

sluit het toetsenbord, de muis en de monitor aan op de server;
BIOS, RAID en IPMI configureren;
firmware van componenten bijwerken;
een bestandssysteemimage implementeren (of een hypervisor installeren en virtuele machines kopiëren);

Opmerking. Als alternatief is implementatie van het besturingssysteem mogelijk via installatie met een automatisch antwoordbestand. Maar dit wordt in het artikel niet besproken. Zoals u hieronder zult zien, is het toevoegen van deze functionaliteit niet moeilijk.

OS-parameters configureren (hostnaam, IP, enz.).

Bij deze aanpak worden op elke server sequentieel dezelfde instellingen gemaakt. De efficiëntie van dit soort werk is zeer laag.

De essentie van automatisering is het elimineren van menselijke betrokkenheid bij het servervoorbereidingsproces. Zoveel mogelijk.

Automatisering vermindert de downtime tussen bewerkingen en maakt het mogelijk om meerdere servers tegelijkertijd in te richten. Ook de kans op fouten door menselijke factoren wordt aanzienlijk verkleind.

Hoe werkt automatische serverconfiguratie?

Laten we alle fasen eens in detail bekijken.

U hebt een Linux-server die u gebruikt als PXE-installatieserver. De volgende services zijn erop geïnstalleerd en geconfigureerd: DHCP, TFTP.

We starten dus de server (die geconfigureerd moet worden) op via PXE. Laten we nog eens kijken hoe het werkt:

Op de server is netwerkopstarten geselecteerd.
De server laadt de PXE-ROM van de netwerkkaart en maakt via DHCP contact met de installatieserver om een netwerkadres te verkrijgen.
De DHCP-installatieserver geeft een adres uit, evenals instructies voor verder opstarten via PXE.
De server laadt de netwerk-bootloader vanaf de installatieserver via PXE, waarna het laden plaatsvindt op basis van het PXE-configuratiebestand.
Het opstartproces is gebaseerd op de ontvangen parameters (kernel, initramfs, koppelpunten, squashfs-image, enz.).

Opmerking. Het artikel beschrijft het opstarten via PXE in de BIOS-modus. Momenteel zijn fabrikanten actief bezig met de implementatie van de UEFI-bootmodus. Bij PXE zit het verschil in de DHCP-serverconfiguratie en de aanwezigheid van een extra bootloader.

Laten we eens kijken naar een voorbeeld van een PXE-serverconfiguratie (pxelinux-menu).

Bestand pxelinux.cfg/default:

default menu.c32
prompt 0
timeout 100
menu title X5 PXE Boot Menu
LABEL InstallServer Menu
	MENU LABEL InstallServer
	KERNEL menu.c32
	APPEND pxelinux.cfg/installserver
LABEL VMware Menu
	MENU LABEL VMware ESXi Install
	KERNEL menu.c32
	APPEND pxelinux.cfg/vmware
LABEL toolkit // меню по умолчанию
	MENU LABEL Linux Scripting Toolkits
	MENU default
	KERNEL menu.c32
	APPEND pxelinux.cfg/toolkit // переход на следующее меню

Bestand pxelinux.cfg/toolkit:

prompt 0
timeout 100
menu title X5 PXE Boot Menu
label mainmenu
    menu label ^Return to Main Menu
    kernel menu.c32
    append pxelinux.cfg/default
label x5toolkit-auto // по умолчанию — автоматический режим
        menu label x5 toolkit autoinstall
        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 // для отладки - консоль
        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=”…”

De kernel en initramfs vormen in dit stadium een tussenliggend Linux-image, met behulp waarvan de belangrijkste voorbereiding en configuratie van de server plaatsvindt.

Zoals u kunt zien, geeft de bootloader veel parameters door aan de kernel. Sommige van deze parameters worden door de kernel zelf gebruikt. En een deel daarvan kunnen we voor onze eigen doeleinden gebruiken. Dit wordt later besproken, maar onthoud voor nu dat alle doorgegeven parameters beschikbaar zullen zijn in de tussenliggende Linux-image via /proc/cmdline.

Waar kan ik ze krijgen, kernel en initramfs?
Als basis kunt u elke Linux-distributie kiezen. Waar moet je op letten bij het kiezen:

het opstartimage moet universeel zijn (beschikbaarheid van drivers, mogelijkheid om extra hulpprogramma's te installeren);
Waarschijnlijk moet u de initramfs aanpassen.

Hoe doen we dit in onze oplossing voor X5? We hebben als basis gekozen. CentOS 7. Laten we de volgende truc eens proberen: bereid de toekomstige imagestructuur voor, pak deze in een archief en maak een initramfs aan met daarin ons bestandssysteemarchief. Wanneer de image opstart, wordt het archief uitgepakt in de nieuw aangemaakte tmpfs-partitie. Op deze manier krijgen we een minimale, maar volledig functionele, live Linux-image met alle benodigde hulpprogramma's, bestaande uit slechts twee bestanden: vmkernel en 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

We hebben dus de kernel en initramfs gespecificeerd die geladen moeten worden. Nadat we in dit stadium de tussenliggende Linux-image via PXE hebben geladen, ontvangen we de OS-console.

Geweldig, maar nu moeten we de controle overdragen aan onze ‘automatisering’.

Dit kan als volgt worden gedaan.

Laten we aannemen dat we na het laden van de afbeelding de controle willen overdragen aan het mount.sh-script.
Laten we het script mount.sh opnemen in autorun. Hiervoor moet de initramfs worden aangepast:

pak initramfs uit (als we de bovenstaande initramfs-optie gebruiken, is dit niet vereist)
opnemen in de opstartcode die de parameters analyseert die via /proc/cmdline worden doorgegeven en de controle daaraan doorgeeft;
initramfs inpakken.

Opmerking. In het geval van de X5-toolkit wordt de downloadcontrole overgedragen aan het script /opt/x5/toolkit/bin/hook.sh с помощью override.conf в getty tty1 (ExecStart=…)

De afbeelding wordt geladen en bij het opstarten wordt het script mount.sh gestart. Vervolgens analyseert het script mount.sh de overgedragen parameters (script_cmd=) tijdens de uitvoering en start het het vereiste programma/script.

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

label toolkit-schelp
kernel …
toevoegen... nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash

Links ziet u het PXE-menu en rechts het diagram voor de controle-overdracht.

We hebben de overdracht van controle geregeld. Afhankelijk van de menukeuze in PXE wordt het script voor automatische configuratie of de debugconsole gestart.

Bij automatische configuratie worden de benodigde mappen vanaf de installatieserver aangekoppeld. Deze mappen bevatten:

scripts;
opgeslagen BIOS/UEFI-sjablonen voor verschillende servers;
firmware;
serverhulpprogramma's;
logboeken.

Vervolgens draagt het script mount.sh de besturing vanuit de scriptdirectory over aan het script master-install.sh.

De scriptboom (de volgorde waarin ze worden gestart) ziet er ongeveer zo uit:

master-installatie
deelfuncties (gedeelde functies)
info (informatie-uitvoer)
modellen (installatieparameters instellen op basis van het servermodel)
prepare_utils (installatie van de benodigde hulpprogramma's)
fwupdate (firmware-update)
diag (elementaire diagnostiek)
biosconf (BIOS/UEFI-instellingen)
clockfix (tijd instellen op het moederbord)
srmconf (configuratie van externe interface)
raidconf (configuratie van logische volumes)

een van:

pre-installatie (controle overdragen aan het OS of hypervisor-installatieprogramma, zoals ESXi)
merged-install (directe start van het uitpakken van de image)

Nu weten we:

hoe je een server opstart via PXE;
hoe u de controle aan uw eigen script kunt overdragen.

Laten we verdergaan. De volgende vragen zijn relevant geworden:

Hoe kunnen we de server identificeren die we voorbereiden?
Welke hulpprogramma's en hoe configureer ik de server?
Hoe krijg ik instellingen voor een specifieke server?

Hoe kunnen we de server identificeren die we voorbereiden?

Het is simpel - DMI:

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

Hier is alles wat u nodig hebt: leverancier, model, serienummer. Als u niet zeker weet of deze informatie op alle servers aanwezig is, kunt u ze identificeren aan de hand van hun MAC-adres. Of beide methoden tegelijkertijd, als de serverleveranciers verschillen en bij sommige modellen de serienummerinformatie simpelweg ontbreekt.

Op basis van de ontvangen informatie worden netwerkmappen vanaf de installatieserver gekoppeld en wordt alles wat nodig is (hulpprogramma's, firmware, enz.) geladen.

Welke hulpprogramma's en hoe configureer ik de server?

Ik zal Linux-hulpprogramma's leveren voor enkele fabrikanten. Alle nutsvoorzieningen zijn beschikbaar op de officiële websites van de leveranciers.

Met de firmware is alles volgens mij duidelijk. Meestal worden ze geleverd als uitvoerbare bestanden. Het uitvoerbare bestand bestuurt het firmware-updateproces en rapporteert de retourcode.

BIOS en IPMI worden meestal geconfigureerd via sjablonen. Indien nodig kunt u de sjabloon bewerken voordat u deze uploadt.

De RAID-hulpprogramma's van sommige leveranciers kunnen ook worden geconfigureerd met behulp van een sjabloon. Als dit niet het geval is, moet u een installatiescript schrijven.

De RAID-installatieprocedure verloopt doorgaans als volgt:

De huidige configuratie opvragen.
Als er al logische arrays bestaan, wissen we deze.
Laten we eens kijken welke fysieke schijven er aanwezig zijn en hoeveel er zijn.
Maak een nieuwe logische array. Indien er een fout optreedt, onderbreken wij het proces.

Hoe krijg ik instellingen voor een specifieke server?

Laten we aannemen dat de instellingen van alle servers op de installatieserver worden opgeslagen. Om onze vraag te kunnen beantwoorden, moeten we eerst beslissen hoe we de instellingen naar de installatieserver overbrengen.

In eerste instantie kunt u prima met tekstbestanden werken. (In de toekomst kunt u het tekstbestand gebruiken als back-upmethode voor het overzetten van instellingen.)

U kunt een tekstbestand op de installatieserver 'delen'. En voeg de montage toe aan het mount.sh script.

De regels zien er bijvoorbeeld zo uit:

Deze regels worden door de engineer vanaf zijn werkmachine naar het bestand overgebracht. En vervolgens worden bij het configureren van de server de parameters voor een specifieke server uit het bestand gelezen.

Op de lange termijn is het echter beter om de database te gebruiken voor het opslaan van instellingen, statussen en serverinstallatielogboeken.

Uiteraard is één database niet voldoende, er zal een clientgedeelte aangemaakt moeten worden, met behulp waarvan de instellingen naar de database worden overgebracht. Dit is lastiger te implementeren dan een tekstbestand, maar het is eigenlijk niet zo moeilijk als het lijkt. Het is heel goed mogelijk om zelf een minimale versie van de client te schrijven die de gegevens eenvoudig naar de database overzet. In de toekomst zal het mogelijk zijn om het clientprogramma in de gratis modus te verbeteren (rapporten, labels afdrukken, meldingen versturen en alles wat u maar kunt bedenken).

Door een specifieke aanvraag te doen bij de database en het serienummer van de server op te geven, ontvangen wij de benodigde parameters voor het configureren van de server.

Bovendien hoeven we geen sloten te verzinnen voor gelijktijdige toegang, zoals bij een tekstbestand.

We kunnen het installatielogboek in alle fasen naar de database schrijven en het installatieproces beheren via gebeurtenissen en vlaggen van de voorbereidingsfasen.

Nu weten we hoe:

de server opstarten via PXE;
controle overdragen aan ons script;
de server die voorbereid moet worden identificeren aan de hand van het serienummer;
configureer de server met de juiste hulpprogramma's;
instellingen overbrengen naar de installatieserverdatabase met behulp van het clientgedeelte.

We kwamen erachter hoe:

de geïnstalleerde server ontvangt de benodigde instellingen uit de database;
De voortgang van alle voorbereidingen wordt vastgelegd in de database (logboeken, gebeurtenissen, fasevlaggen).

Hoe zit het met de verschillende soorten software die u installeert? Hoe installeer ik een hypervisor, kopieer ik een VM en configureer ik alles?

Als u een bestandssysteemimage (Linux) op hardware wilt implementeren, is alles vrij eenvoudig:

Nadat alle servercomponenten zijn geconfigureerd, implementeren we de image.
De grub-bootloader installeren.
We creëren chroot en configureren alles wat nodig is.

Hoe u de controle overdraagt aan het OS-installatieprogramma (met ESXi als voorbeeld).

We organiseren de overdracht van de controle van ons script naar het hypervisor-installatieprogramma met behulp van het autoresponsbestand (kickstart):
We verwijderen de huidige partities op de schijf.
Maak een partitie van 500 MB groot.
Wij markeren het als opstartbaar.
Formatteren naar FAT32.
We kopiëren de ESXi-installatiebestanden naar de root.
Syslinux installeren.
Kopieer syslinux.cfg naar /syslinux/

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

Kopieer mboot.c32 naar /syslinux.
In boot.cfg zou kernelopt=ks=ftp:// moeten staan /ks_esxi.cfg
Start de server opnieuw op.

Nadat de server opnieuw is opgestart, wordt het ESXi-installatieprogramma vanaf de harde schijf geladen. Alle benodigde installatiebestanden worden in het geheugen geladen en vervolgens begint de installatie van ESXi op basis van het opgegeven automatische antwoordbestand.

Hier zijn een paar regels uit het automatische antwoordbestand ks_esxi.cfg:

%firstboot --interpreter=busybox
…
# получаем серийный номер

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

# получаем IP

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

# подключаем NFS инсталл-сервера

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

# копируем временные настройки ssh, для использования ssh-клиента

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

# копируем ovftool, для развертывания ВМ сейчас, плюс возможно пригодится позже

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

# развертываем ВМ

/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

# получаем строку с настройками нашего сервера

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
...
# генерируем скрипт настройки сети

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

# задаем параметр guestinfo.esxihost.id, указываем в нем серийный номер

echo "guestinfo.esxihost.id = "$SYSSN"" >> /vmfs/volumes/datastore1/VM1/VM1.vmx
echo "guestinfo.esxihost.id = "$SYSSN"" >> /vmfs/volumes/datastore1/VM2/VM2.vmx
...
# обновляем информацию в базе

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

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

# настраиваем сеть и перезагружаемся

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

In deze fase wordt de hypervisor geïnstalleerd en geconfigureerd en worden virtuele machines gekopieerd.

Hoe stel ik nu virtuele machines in?

We hebben een beetje vals gespeeld: tijdens de installatie hebben we de parameter guestinfo.esxihost.id = "$SYSSN" in het bestand VM1.vmx ingesteld en daarin het serienummer van de fysieke server opgegeven.

Na het opstarten heeft de virtuele machine (waarop het vmware-tools-pakket is geïnstalleerd) toegang tot deze parameter:

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

Dat wil zeggen dat de VM zichzelf kan identificeren (hij kent het serienummer van de fysieke host), een verzoek kan doen aan de database van de installatieserver en de parameters kan ontvangen die geconfigureerd moeten worden. Dit alles wordt geformatteerd in een script dat automatisch moet worden gestart wanneer de guestos-VM start (maar slechts één keer: RunOnce).

Nu weten we hoe:

de server opstarten via PXE;
controle overdragen aan ons script;
de server die voorbereid moet worden identificeren aan de hand van het serienummer;
configureer de server met de juiste hulpprogramma's;
instellingen overbrengen naar de installatieserverdatabase met behulp van het clientgedeelte;
diverse soorten software configureren, waaronder het implementeren van de esxi-hypervisor en het configureren van virtuele machines (alles automatisch).

We kwamen erachter hoe:

de geïnstalleerde server ontvangt de benodigde instellingen uit de database;
De voortgang van alle voorbereidingen wordt vastgelegd in de database (logboeken, gebeurtenissen, fasevlaggen).

De bottom line:

Ik geloof dat het unieke van deze oplossing ligt in de flexibiliteit, eenvoud, mogelijkheden en veelzijdigheid.

Schrijf in de reacties wat u ervan vindt.

Bron: www.habr.com