Gör-det-själv Bare-Metal Provisioning, eller Automatisk förberedelse av servrar från grunden

Hej, jag heter Denis och ett av mina verksamhetsområden är utveckling av infrastrukturlösningar på X5. Idag skulle jag vilja dela med dig av hur du kan distribuera ett automatiskt serverförberedelsesystem baserat på allmänt tillgängliga verktyg. Enligt mig är detta en intressant, enkel och flexibel lösning.

Med förberedelse menar vi: förvandla en ny server ur lådan till en fullt konfigurerad server med OS. Linux eller med ESXi hypervisor (distributionen av Windows-servrar diskuteras inte i den här artikeln).

Villkor:

• servrar – servrar som behöver konfigureras.
• installationsservern är huvudservern som tillhandahåller hela förberedelseprocessen över nätverket.

Varför behövs automatisering?

Låt oss säga att det finns en uppgift: att massivt förbereda servrar från början, vid en topp – 30 per dag. Servrar från olika tillverkare och modeller, olika operativsystem kan vara installerade på dem, och kan ha en hypervisor eller inte.

Vilka operationer ingår i installationsprocessen (utan automatisering):

• ansluta ett tangentbord, mus, bildskärm till servern;
• konfigurera BIOS, RAID, IPMI;
• uppdatera komponentens firmware;
• distribuera en filsystemavbildning (eller installera en hypervisor och kopiera virtuella maskiner);

Notera. Alternativt är OS-distribution möjlig genom installation med en autosvarsfil. Men detta kommer inte att diskuteras i artikeln. Även om du kommer att se nedan att det inte är svårt att lägga till denna funktionalitet.

• konfigurera OS-parametrar (värdnamn, IP, etc.).

Med detta tillvägagångssätt utförs samma inställningar sekventiellt på varje server. Effektiviteten av sådant arbete är mycket låg.

Kärnan i automatisering är att eliminera mänskligt deltagande från serverförberedelseprocessen. Så mycket som möjligt.

Automatisering minskar driftstopp mellan operationer och gör det möjligt att tillhandahålla flera servrar samtidigt. Sannolikheten för fel på grund av mänskliga faktorer minskar också kraftigt.

Hur konfigureras servrar automatiskt?

Låt oss analysera alla steg i detalj.

Du har en Linux-server som du använder som PXE-installationsserver. Tjänster installeras och konfigureras på den: DHCP, TFTP.

Så vi startar servern (som måste konfigureras) via PXE. Låt oss komma ihåg hur det fungerar:

• Nätverksstart väljs på servern.
• Servern laddar nätverkskortets PXE-ROM och kontaktar installationsservern via DHCP för att få en nätverksadress.
• DHCP-installationsservern utfärdar en adress, samt instruktioner för vidare nedladdning via PXE.
• Servern laddar nätverksstarthanteraren från installationsservern via PXE, ytterligare laddning sker enligt PXE-konfigurationsfilen.
• Starten sker baserat på de mottagna parametrarna (kärna, initramfs, monteringspunkter, squashfs-bild, etc.).

Notera. Artikeln beskriver uppstart via PXE via BIOS-läge. För närvarande implementerar tillverkare aktivt UEFI bootmode. För PXE kommer skillnaden att vara i konfigurationen av DHCP-servern och närvaron av en extra bootloader.

Låt oss titta på ett exempel på en PXE-serverkonfiguration (pxelinux-menyn).

Fil 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 // переход на следующее меню

Fil 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=”…”

Kärnan och initramfs i detta skede är en mellanliggande Linux-avbildning, med hjälp av vilken den huvudsakliga förberedelsen och konfigurationen av servern kommer att ske.

Som du kan se skickar starthanteraren många parametrar till kärnan. Vissa av dessa parametrar används av själva kärnan. Och vi kan använda en del för våra egna syften. Detta kommer att diskuteras senare, men för nu kan du bara komma ihåg att alla parametrar som skickas kommer att vara tillgängliga i den mellanliggande Linux-avbildningen via /proc/cmdline.

Var kan jag få tag på dem, kernel och initramfs?
Som grund kan du välja vilken Linux-distribution som helst. Vad vi är uppmärksamma på när vi väljer:

• startavbildningen måste vara universell (tillgänglighet av drivrutiner, möjlighet att installera ytterligare verktyg);
• Troligtvis kommer du att behöva anpassa initramfs.

Hur görs detta i vår lösning för X5? CentOS 7 valdes som bas. Låt oss prova följande knep: förbered den framtida bildstrukturen, packa in den i ett arkiv och skapa en initramfs, i vilken det kommer att finnas vårt filsystemarkiv. När bilden laddas kommer arkivet att utökas till den skapade tmpfs-partitionen. På så sätt kommer vi att få en minimal, men fullfjädrad live linux-bild med alla nödvändiga verktyg, bestående av endast två filer: vmkernel och 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

Så vi har specificerat kärnan och initramfs som ska laddas. Som ett resultat, i detta skede, genom att ladda den mellanliggande linux-bilden via PXE, kommer vi att ta emot OS-konsolen.

Bra, men nu måste vi överföra kontrollen till vår "automation".

Det kan göras så här.

Låt oss anta att vi efter att ha laddat bilden planerar att överföra kontrollen till mount.sh-skriptet.
Låt oss inkludera mount.sh-skriptet i autorun. För att göra detta måste du ändra initramfs:

• packa upp initramfs (om vi använder ovanstående initramfs-alternativ är detta inte nödvändigt)
• inkludera kod i start som kommer att analysera parametrarna som passerat genom /proc/cmdline och överföra kontrollen vidare;
• packa initramfs.

Notera. När det gäller X5-verktygslådan överförs laddningskontrollen till skriptet /opt/x5/toolkit/bin/hook.sh с помощью override.conf в getty tty1 (ExecStart=…)

Så, bilden laddas, där mount.sh-skriptet startar vid autorun. Därefter analyserar mount.sh-skriptet de passerade parametrarna (script_cmd=) under körning och startar det nödvändiga programmet/skriptet.

etikett verktygslåda-bil
kärna...
lägg till... nfs_toolkit_script=scripts/mount.sh script_cmd=master-install.sh

etikett verktygslåda-skal
kärna...
lägg till... nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash

Här till vänster finns PXE-menyn, till höger är styröverföringsdiagrammet.

Vi kom på överföringen av kontroll. Beroende på valet av PXE-menyn, startas antingen skriptet för automatisk konfiguration eller felsökningskonsolen.

Vid automatisk konfiguration monteras nödvändiga kataloger från installationsservern, som innehåller:

• manus;
• sparade BIOS/UEFI-mallar för olika servrar;
• fast programvara;
• serververktyg;
• loggar

Därefter överför mount.sh-skriptet kontrollen till master-install.sh-skriptet från skriptkatalogen.

Skriptträdet (den ordning som de lanseras) ser ut ungefär så här:

• master-installera
• sharefunctions (delade funktioner)
• info (informationsutgång)
• modeller (inställning av installationsparametrar baserat på servermodellen)
• prepare_utils (installation av nödvändiga verktyg)
• fwupdate (firmwareuppdatering)
• diag (elementär diagnostik)
• biosconf (BIOS/UEFI-inställningar)
• clockfix (ställ in tiden på moderkortet)
• srmconf (konfiguration av fjärrgränssnitt)
• raidconf (konfigurera logiska volymer)

en av:

• förinstallera (överför kontrollen till operativsystemet eller hypervisorinstallationsprogrammet, såsom ESXi)
• merged-install (omedelbar start av uppackning av bilden)

Nu vet vi:

• hur man startar en server via PXE;
• hur man överför kontrollen till ditt eget manus.

Låt oss fortsätta. Följande frågor blev aktuella:

• Hur identifierar jag servern vi förbereder?
• Vilka verktyg och hur man konfigurerar servern?
• Hur får man inställningar för en specifik server?

Hur identifierar jag servern vi förbereder?

Det är enkelt - DMI:

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

Allt du behöver finns här: leverantör, modell, serienummer. Om du inte är säker på att denna information finns på alla servrar kan du identifiera dem med deras MAC-adress. Eller på båda sätten samtidigt, om serverleverantörerna är olika och på vissa modeller finns det helt enkelt ingen information om serienumret.

Baserat på den mottagna informationen monteras nätverksmappar från installationsservern och allt som behövs laddas (verktyg, firmware, etc.).

Vilka verktyg och hur man konfigurerar servern?

Jag kommer att tillhandahålla verktyg för Linux för vissa tillverkare. Alla verktyg är tillgängliga på leverantörernas officiella webbplatser.

Med firmware tror jag att allt är klart. De kommer vanligtvis i form av paketerade körbara filer. Den körbara filen kontrollerar firmwareuppdateringsprocessen och rapporterar returkoden.

BIOS och IPMI konfigureras vanligtvis genom mallar. Vid behov kan mallen redigeras innan nedladdning.

RAID-verktyg från vissa leverantörer kan också konfigureras med hjälp av en mall. Om så inte är fallet måste du skriva ett konfigurationsskript.

Proceduren för att ställa in RAID är oftast som följer:

• Vi begär den aktuella konfigurationen.
• Om det redan finns logiska arrayer raderar vi dem.
• Låt oss titta på vilka fysiska diskar som finns och hur många det finns.
• Skapa en ny logisk array. Vi avbryter processen vid fel.

Hur får man inställningar för en specifik server?

Låt oss anta att inställningarna för alla servrar kommer att lagras på installationsservern. I det här fallet, för att svara på vår fråga, måste vi först bestämma hur vi ska överföra inställningarna till installationsservern.

Till en början kan du klara dig med textfiler. (I framtiden kanske du vill använda en textfil som en reservmetod för att överföra inställningar.)

Du kan "dela" en textfil på installationsservern. Och lägg till dess montering till mount.sh-skriptet.

Raderna kommer till exempel att se ut så här:

<serienummer> <värdnamn> <undernät>

Dessa rader kommer att överföras till filen av ingenjören från sin arbetsmaskin. Och sedan, när du ställer in en server, kommer parametrarna för en specifik server att läsas från filen.

Men på lång sikt är det bättre att använda en databas för att lagra inställningar, tillstånd och loggar för serverinstallationer.

Naturligtvis räcker det inte med enbart en databas utan du kommer behöva skapa en klientdel med hjälp av vilken inställningar som kommer att överföras till databasen. Detta är svårare att implementera jämfört med en textfil, men i själva verket är allt inte så svårt som det verkar. Det är fullt möjligt att skriva en minimal version av en klient som helt enkelt överför data till databasen själv. Och i framtiden kommer det att vara möjligt att förbättra klientprogrammet i fritt läge (rapporter, skriva ut etiketter, skicka aviseringar etc. som du tänker på).

Genom att göra en specifik begäran till databasen och ange serverns serienummer kommer vi att få de nödvändiga parametrarna för att konfigurera servern.

Dessutom behöver vi inte komma med lås för samtidig åtkomst, som är fallet med en textfil.

Vi kan skriva konfigurationsloggen till databasen i alla skeden och styra installationsprocessen genom händelser och flaggor från förberedelsestadierna.

Nu vet vi hur:

• starta upp servern via PXE;
• överföra kontrollen till vårt manus;
• identifiera servern som behöver förberedas genom dess serienummer;
• konfigurera servern med hjälp av lämpliga verktyg;
• överföra inställningar till installationsserverdatabasen med hjälp av klientdelen.

Vi fick reda på hur:

• den installerade servern tar emot de nödvändiga inställningarna från databasen;
• alla förberedelser registreras i databasen (loggar, händelser, scenflaggor).

Hur är det med de olika typerna av programvara du installerar? Hur man installerar en hypervisor, kopierar en virtuell dator och konfigurerar allt?

När det gäller att distribuera en filsystemavbildning (linux) till hårdvara är allt ganska enkelt:

• Efter att ha ställt in alla serverkomponenter distribuerar vi bilden.
• Installera grub bootloader.
• Vi chrotar och konfigurerar allt som behövs.

Hur man överför kontrollen till OS-installationsprogrammet (med ESXi som exempel).

• Vi organiserar överföringen av kontroll från vårt skript till hypervisorinstallationsprogrammet med hjälp av den automatiska svarsfilen (kickstart):
• Vi tar bort de nuvarande partitionerna på disken.
• Skapa en partition med en storlek på 500MB.
• Vi markerar den som startbar.
• Formatera till FAT32.
• Vi kopierar ESXi-installationsfilerna till roten.
• Installerar syslinux.
• Kopiera syslinux.cfg till /syslinux/

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

• Kopiera mboot.c32 till /syslinux.
• Boot.cfg bör ha kernelopt=ks=ftp:// /ks_esxi.cfg
• Starta om servern.

När servern har startat om kommer ESXi-installationsprogrammet att laddas ner från serverns hårddisk. Alla nödvändiga installationsfiler kommer att laddas in i minnet och sedan börjar ESXi-installationen, enligt den angivna autosvarsfilen.

Här är några rader från autosvarsfilen 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

I detta skede är hypervisorn installerad och konfigurerad, och virtuella maskiner kopieras.

Hur konfigurerar man virtuella maskiner nu?

Vi fuskade lite: under installationen satte vi parametern guestinfo.esxihost.id = "$SYSSN" i filen VM1.vmx och angav serienumret för den fysiska servern i den.

Nu, efter start, kan den virtuella maskinen (med paketet vmware-tools installerat) komma åt denna parameter:

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

Det vill säga, den virtuella datorn kommer att kunna identifiera sig själv (den känner till serienumret på den fysiska värden), göra en begäran till installationsserverdatabasen och ta emot parametrarna som behöver konfigureras. Allt detta kompileras till ett skript, som bör startas automatiskt när guestos vm startar (men en gång: RunOnce).

Nu vet vi hur:

• starta upp servern via PXE;
• överföra kontrollen till vårt manus;
• identifiera servern som behöver förberedas genom dess serienummer;
• konfigurera servern med hjälp av lämpliga verktyg;
• överföra inställningar till installationsserverdatabasen med hjälp av klientdelen;
• konfigurera olika typer av programvara, inklusive att distribuera esxi hypervisor och konfigurera virtuella maskiner (allt automatiskt).

Vi fick reda på hur:

• den installerade servern tar emot de nödvändiga inställningarna från databasen;
• alla förberedelser registreras i databasen (loggar, händelser, scenflaggor).

Summan av kardemumman:

Jag tror att det unika med denna lösning ligger i dess flexibilitet, enkelhet, möjligheter och mångsidighet.

Skriv gärna i kommentarerna vad du tycker.

Källa: will.com