ProHoster > blog > administratie > Doe-het-zelf Bare-Metal Provisioning, of automatische voorbereiding van servers vanaf het begin

Doe-het-zelf Bare-Metal Provisioning, of automatische voorbereiding van servers vanaf het begin

Hallo, ik ben Denis en een van mijn werkgebieden is de ontwikkeling van infrastructuuroplossingen bij X5. Vandaag wil ik met u delen hoe u een automatisch servervoorbereidingssysteem kunt implementeren op basis van openbaar beschikbare tools. Naar mijn mening is dit een interessante, eenvoudige en flexibele oplossing.

Doe-het-zelf Bare-Metal Provisioning, of automatische voorbereiding van servers vanaf het begin

Met voorbereiding bedoelen we: een nieuwe server out-of-the-box ombouwen tot een volledig geconfigureerde server met OS. Linux of met de ESXi hypervisor (de inzet van Windows-servers wordt in dit artikel niet besproken).

termen:

  • servers – servers die moeten worden geconfigureerd.
  • installatieserver is de hoofdserver die het gehele voorbereidingsproces via het netwerk verzorgt.

Waarom is automatisering nodig?

Laten we zeggen dat er een taak is: servers vanaf het begin massaal voorbereiden, op een piek – 30 per dag. Servers van verschillende fabrikanten en modellen, verschillende besturingssystemen kunnen erop zijn geïnstalleerd en kunnen al dan niet een hypervisor hebben.

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

  • sluit een toetsenbord, muis en monitor aan op de server;
  • BIOS, RAID, IPMI configureren;
  • update componentfirmware;
  • een bestandssysteemimage implementeren (of een hypervisor installeren en virtuele machines kopiëren);

Opmerking. Als alternatief is OS-implementatie mogelijk via installatie met een auto-responsbestand. Maar dit wordt in het artikel niet besproken. Al zul je hieronder zien dat het toevoegen van deze functionaliteit niet moeilijk is.

  • configureer OS-parameters (hostnaam, IP, enz.).

Met deze aanpak worden dezelfde instellingen opeenvolgend op elke server uitgevoerd. De efficiëntie van dergelijk werk is erg laag.

De essentie van automatisering is het elimineren van menselijke participatie uit het servervoorbereidingsproces. Zo veel mogelijk.

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

Doe-het-zelf Bare-Metal Provisioning, of automatische voorbereiding van servers vanaf het begin

Hoe worden servers automatisch geconfigureerd?

Laten we alle fasen in detail analyseren.

Je hebt een Linux-server die je gebruikt als PXE-installatieserver. Er worden services op geïnstalleerd en geconfigureerd: DHCP, TFTP.

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

  • Netwerk opstarten is geselecteerd op de server.
  • 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 af, evenals instructies voor verder downloaden via PXE.
  • De server laadt de netwerkbootloader van de installatieserver via PXE, verder laden gebeurt volgens het PXE-configuratiebestand.
  • Het opstarten vindt plaats op basis van de ontvangen parameters (kernel, initramfs, mount points, squashfs image, enz.).

Opmerking. Het artikel beschrijft het opstarten via PXE via de BIOS-modus. Momenteel implementeren fabrikanten actief de UEFI-bootmode. Voor PXE zit het verschil in de configuratie van de DHCP-server 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 zijn in dit stadium een ​​tussenliggende Linux-image, met behulp waarvan de belangrijkste voorbereiding en configuratie van de server zal plaatsvinden.

Zoals je kunt zien, geeft de bootloader veel parameters door aan de kernel. Sommige van deze parameters worden door de kernel zelf gebruikt. En sommige kunnen we voor onze eigen doeleinden gebruiken. Dit zal later worden besproken, maar voor nu kun je gewoon onthouden dat alle doorgegeven parameters beschikbaar zullen zijn in de tussenliggende Linux-image via /proc/cmdline.

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

  • de opstartimage moet universeel zijn (beschikbaarheid van stuurprogramma's, mogelijkheid om extra hulpprogramma's te installeren);
  • Hoogstwaarschijnlijk moet u de initramfs aanpassen.

Hoe wordt dit gedaan in onze oplossing voor X5? Als basis werd gekozen voor CentOS 7. Laten we de volgende truc proberen: bereid de toekomstige afbeeldingsstructuur voor, verpak deze in een archief en maak een initramfs, waarin zich ons bestandssysteemarchief zal bevinden. Bij het laden van de afbeelding wordt het archief uitgebreid naar de gemaakte tmpfs-partitie. Op deze manier krijgen we een minimale, maar toch volwaardige 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 moeten worden geladen. Als resultaat zullen we in dit stadium, door het tussenliggende Linux-image via PXE te laden, de OS-console ontvangen.

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

Het kan zo worden gedaan.

Laten we aannemen dat we na het laden van de afbeelding van plan zijn de besturing over te dragen aan het mount.sh-script.
Laten we het mount.sh-script opnemen in autorun. Om dit te doen, moet u de initramfs wijzigen:

  • initramfs uitpakken (als we de bovenstaande initramfs-optie gebruiken, is dit niet vereist)
  • neem code op bij het opstarten die de parameters analyseert die via /proc/cmdline worden doorgegeven en de controle verder overdraagt;
  • pack initramfs.

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

De afbeelding wordt dus geladen, waarbij het script mount.sh begint bij autorun. Vervolgens analyseert het mount.sh-script de doorgegeven parameters (script_cmd=) tijdens de uitvoering en start het benodigde programma/script.

labeltoolkit-auto
kernel...
toevoegen... nfs_toolkit_script=scripts/mount.sh script_cmd=master-install.sh

labeltoolkit-schelp
kernel...
toevoegen... nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash

Doe-het-zelf Bare-Metal Provisioning, of automatische voorbereiding van servers vanaf het begin

Links ziet u het PXE-menu, rechts het besturingsoverdrachtsdiagram.

We hebben de overdracht van de controle ontdekt. Afhankelijk van de keuze van het PXE-menu wordt het automatische configuratiescript of de foutopsporingsconsole gestart.

In het geval van automatische configuratie worden de benodigde mappen vanaf de installatieserver aangekoppeld, die het volgende bevatten:

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

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

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 noodzakelijke hulpprogramma's)
  • fwupdate (firmware-update)
  • diag (elementaire diagnostiek)
  • biosconf (BIOS/UEFI-instellingen)
  • clockfix (de tijd instellen op het moederbord)
  • srmconf (interfaceconfiguratie op afstand)
  • raidconf (logische volumes configureren)

een van de:

  • vooraf installeren (controle overdragen aan het besturingssysteem of hypervisorinstallatieprogramma, zoals ESXi)
  • merged-install (onmiddellijke start van het uitpakken van de image)

Nu weten we:

  • hoe een server op te starten via PXE;
  • hoe u de controle overdraagt ​​aan uw eigen script.


Laten we doorgaan. De volgende vragen werden relevant:

  • 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 eenvoudig - DMI:

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

Alles wat u nodig heeft, is hier: leverancier, model, serienummer. Als u er niet zeker van bent dat deze informatie op alle servers aanwezig is, kunt u deze identificeren aan de hand van hun MAC-adres. Of op beide manieren tegelijkertijd, als de serverleveranciers verschillend zijn en er op sommige modellen eenvoudigweg geen informatie over het serienummer is.

Op basis van de ontvangen informatie worden netwerkmappen vanaf de installatieserver aangekoppeld en wordt al het benodigde geladen (hulpprogramma's, firmware, enz.).

Welke hulpprogramma's en hoe configureer ik de server?

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

Doe-het-zelf Bare-Metal Provisioning, of automatische voorbereiding van servers vanaf het begin

Met de firmware denk ik dat alles duidelijk is. Ze komen meestal in de vorm van verpakte uitvoerbare bestanden. Het uitvoerbare bestand bestuurt het firmware-updateproces en rapporteert de retourcode.

BIOS en IPMI worden meestal geconfigureerd via sjablonen. Indien nodig kan de sjabloon vóór het downloaden worden bewerkt.

RAID-hulpprogramma's van sommige leveranciers kunnen ook worden geconfigureerd met behulp van een sjabloon. Als dit niet het geval is, dan zul je een configuratiescript moeten schrijven.

De procedure voor het instellen van RAID is meestal als volgt:

  • Wij vragen de huidige configuratie op.
  • Als er al logische arrays zijn, wissen we deze.
  • Laten we eens kijken welke fysieke schijven aanwezig zijn en hoeveel er zijn.
  • Maak een nieuwe logische array. Bij een fout 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. In dit geval moeten we, om onze vraag te beantwoorden, eerst beslissen hoe we de instellingen naar de installatieserver willen overbrengen.

In eerste instantie kun je rondkomen met tekstbestanden. (In de toekomst wilt u wellicht een tekstbestand gebruiken als reservemethode voor het overbrengen van instellingen.)

U kunt een tekstbestand “delen” op de installatieserver. En voeg de mount ervan toe aan het mount.sh-script.

De lijnen zien er bijvoorbeeld zo uit:

<serienummer> <hostnaam> <subnet>

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

Maar op de lange termijn is het beter om een ​​database te gebruiken om instellingen, statussen en logs van serverinstallaties op te slaan.

Natuurlijk is een database alleen niet voldoende en moet u een clientgedeelte maken met behulp waarvan de instellingen naar de database worden overgebracht. Dit is moeilijker te implementeren vergeleken met een tekstbestand, maar in feite is alles niet zo moeilijk als het lijkt. Het is heel goed mogelijk om een ​​minimale versie van een client te schrijven die eenvoudigweg zelf gegevens naar de database overbrengt. En in de toekomst zal het mogelijk zijn om het clientprogramma in de gratis modus te verbeteren (rapporten, labels afdrukken, meldingen verzenden, enz. die in je opkomen).

Door een specifiek verzoek in te dienen bij de database en het serienummer van de server op te geven, ontvangen we de benodigde parameters voor het configureren van de server.

Bovendien hoeven we geen vergrendelingen te bedenken voor gelijktijdige toegang, zoals het geval is bij een tekstbestand.

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

Nu weten we hoe:

  • start de server op via PXE;
  • de controle overdragen aan ons script;
  • identificeer de server die moet worden voorbereid aan de hand van het serienummer;
  • configureer de server met behulp van de juiste hulpprogramma's;
  • breng instellingen over naar de database van de installatieserver met behulp van het clientgedeelte.

Wij ontdekten hoe:

  • de geïnstalleerde server ontvangt de benodigde instellingen uit de database;
  • alle voortgang van de voorbereiding wordt vastgelegd in de database (logs, evenementen, 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?

In het geval van het implementeren van een bestandssysteemimage (Linux) op hardware, is alles vrij eenvoudig:

  • Nadat we alle servercomponenten hebben ingesteld, implementeren we de image.
  • Installeer de grub-bootloader.
  • We chrooten en configureren alles wat nodig is.

Hoe u de besturing kunt overdragen aan het besturingssysteeminstallatieprogramma (met ESXi als voorbeeld).

  • We organiseren de overdracht van de controle van ons script naar het hypervisor-installatieprogramma met behulp van het automatische responsbestand (kickstart):
  • We verwijderen de huidige partities op de schijf.
  • Maak een partitie met een grootte van 500 MB.
  • We markeren het als opstartbaar.
  • Formaat 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.
  • Boot.cfg zou kernelopt=ks=ftp:// moeten hebben /ks_esxi.cfg
  • Start de server opnieuw op.

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

Hier zijn een paar regels uit het autoresponse-bestand 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:[email protected]
/vmfs/volumes/datastore1/ovftool/tools/ovftool --acceptAllEulas --noSSLVerify --datastore=datastore1 --name=VM2 /vmfs/volumes/nfsshare1/VM_T/VM2.ova vi://root:[email protected]

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

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 dit stadium wordt de hypervisor geïnstalleerd en geconfigureerd en worden virtuele machines gekopieerd.

Hoe nu virtuele machines configureren?

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 aangegeven.

Nu, na het starten, heeft de virtuele machine (met het vmware-tools-pakket 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 indienen bij de database van de installatieserver en de parameters kan ontvangen die moeten worden geconfigureerd. Dit is allemaal gecompileerd in een script, dat automatisch moet worden gestart wanneer guestos vm start (maar één keer: RunOnce).

Nu weten we hoe:

  • start de server op via PXE;
  • de controle overdragen aan ons script;
  • identificeer de server die moet worden voorbereid aan de hand van het serienummer;
  • configureer de server met behulp van de juiste hulpprogramma's;
  • instellingen overbrengen naar de database van de installatieserver met behulp van het clientgedeelte;
  • verschillende soorten software configureren, waaronder het inzetten van de esxi-hypervisor en het configureren van virtuele machines (allemaal automatisch).

Wij ontdekten hoe:

  • de geïnstalleerde server ontvangt de benodigde instellingen uit de database;
  • alle voortgang van de voorbereiding wordt vastgelegd in de database (logs, evenementen, fasevlaggen).


De bottom line:

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

Напишите, пожалуйста, в комментариях, что вы думаете.

Bron: www.habr.com

Voeg een reactie