ProHoster > Blog > administration > Gør-det-selv Bare-Metal Provisioning, eller Automatisk klargøring af servere fra bunden

Gør-det-selv Bare-Metal Provisioning, eller Automatisk klargøring af servere fra bunden

Hej, jeg hedder Denis og et af mine aktivitetsområder er udvikling af infrastrukturløsninger hos X5. I dag vil jeg gerne dele med dig, hvordan du kan implementere et automatisk serverforberedelsessystem baseret på offentligt tilgængelige værktøjer. Efter min mening er dette en interessant, enkel og fleksibel løsning.

Gør-det-selv Bare-Metal Provisioning, eller Automatisk klargøring af servere fra bunden

Med forberedelse mener vi: gør en ny server ud af kassen til en fuldt konfigureret server med OS. Linux eller med ESXi hypervisor (installation af Windows-servere er ikke diskuteret i denne artikel).

Betingelser:

  • servere – servere, der skal konfigureres.
  • installationsserveren er hovedserveren, der leverer hele forberedelsesprocessen over netværket.

Hvorfor er automatisering nødvendig?

Lad os sige, at der er en opgave: massivt at forberede servere fra bunden, på et toppunkt - 30 om dagen. Servere fra forskellige producenter og modeller, forskellige operativsystemer kan være installeret på dem, og de kan have en hypervisor.

Hvilke operationer er inkluderet i opsætningsprocessen (uden automatisering):

  • tilslut et tastatur, mus, skærm til serveren;
  • konfigurer BIOS, RAID, IPMI;
  • opdatering af komponentfirmware;
  • implementere et filsystembillede (eller installer en hypervisor og kopier virtuelle maskiner);

Bemærk. Alternativt er OS-implementering mulig gennem installation med en autosvar-fil. Men dette vil ikke blive diskuteret i artiklen. Selvom du vil se nedenfor, er det ikke svært at tilføje denne funktionalitet.

  • konfigurere OS-parametre (værtsnavn, IP osv.).

Med denne tilgang udføres de samme indstillinger sekventielt på hver server. Effektiviteten af ​​et sådant arbejde er meget lav.

Essensen af ​​automatisering er at eliminere menneskelig deltagelse fra serverforberedelsesprocessen. Så meget som muligt.

Automatisering reducerer nedetid mellem operationer og gør det muligt at klargøre flere servere samtidigt. Sandsynligheden for fejl på grund af menneskelige faktorer er også stærkt reduceret.

Gør-det-selv Bare-Metal Provisioning, eller Automatisk klargøring af servere fra bunden

Hvordan konfigureres servere automatisk?

Lad os analysere alle faser i detaljer.

Du har en Linux-server, som du bruger som PXE-installationsserver. Tjenester er installeret og konfigureret på den: DHCP, TFTP.

Så vi starter serveren (som skal konfigureres) via PXE. Lad os huske, hvordan det fungerer:

  • Netværksstart er valgt på serveren.
  • Serveren indlæser netværkskortets PXE-ROM og kontakter installationsserveren via DHCP for at få en netværksadresse.
  • DHCP-installationsserveren udsteder en adresse, samt instruktioner til yderligere download via PXE.
  • Serveren indlæser netværksbootloaderen fra installationsserveren via PXE, yderligere indlæsning sker i henhold til PXE-konfigurationsfilen.
  • Opstarten sker baseret på de modtagne parametre (kerne, initramfs, monteringspunkter, squashfs-billede osv.).

Bemærk. Artiklen beskriver opstart via PXE via BIOS-tilstand. I øjeblikket implementerer producenter aktivt UEFI bootmode. For PXE vil forskellen være i konfigurationen af ​​DHCP-serveren og tilstedeværelsen af ​​en ekstra bootloader.

Lad os se på et eksempel på en PXE-serverkonfiguration (pxelinux-menu).

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

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

Kernen og initramf'erne på dette stadium er et mellemliggende Linux-billede, ved hjælp af hvilket den vigtigste forberedelse og konfiguration af serveren vil finde sted.

Som du kan se, sender bootloaderen mange parametre til kernen. Nogle af disse parametre bruges af kernen selv. Og vi kan bruge nogle til vores egne formål. Dette vil blive diskuteret senere, men indtil videre kan du bare huske, at alle beståede parametre vil være tilgængelige i det mellemliggende Linux-billede via /proc/cmdline.

Hvor kan jeg få dem, kernel og initramfs?
Som grundlag kan du vælge enhver Linux-distribution. Hvad vi er opmærksomme på, når vi vælger:

  • boot-billedet skal være universelt (tilgængelighed af drivere, mulighed for at installere yderligere hjælpeprogrammer);
  • Mest sandsynligt bliver du nødt til at tilpasse initramf'erne.

Hvordan gøres dette i vores løsning til X5? CentOS 7 blev valgt som basis. Lad os prøve følgende trick: klargør den fremtidige billedstruktur, pak den ind i et arkiv og opret en initramfs, hvori der vil være vores filsystemarkiv. Når billedet indlæses, vil arkivet blive udvidet til den oprettede tmpfs-partition. På denne måde vil vi få et minimalt, men alligevel fuldgyldigt live linux-billede med alle de nødvendige hjælpeprogrammer, bestående af kun to filer: vmkernel og 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 specificeret kernen og initramf'erne, der skal indlæses. Som et resultat vil vi på dette stadium, ved at indlæse det mellemliggende linux-billede via PXE, modtage OS-konsollen.

Fantastisk, men nu skal vi overføre kontrollen til vores "automatisering".

Det kan gøres sådan.

Lad os antage, at efter indlæsning af billedet planlægger vi at overføre kontrol til mount.sh-scriptet.
Lad os inkludere mount.sh-scriptet i autorun. For at gøre dette skal du ændre initramf'erne:

  • udpak initramfs (hvis vi bruger ovenstående initramfs-indstilling, er dette ikke påkrævet)
  • inkludere kode i opstart, der vil analysere de parametre, der er gået gennem /proc/cmdline og overføre kontrol yderligere;
  • pak initramfs.

Bemærk. I tilfælde af X5-værktøjssættet overføres indlæsningskontrollen til scriptet /opt/x5/toolkit/bin/hook.sh с помощью override.conf в getty tty1 (ExecStart=…)

Så billedet er indlæst, hvor mount.sh scriptet starter ved autorun. Derefter analyserer mount.sh-scriptet de beståede parametre (script_cmd=) under udførelsen og starter det nødvendige program/script.

etiketværktøjssæt-auto
kerne...
tilføj... nfs_toolkit_script=scripts/mount.sh script_cmd=master-install.sh

etiketværktøjssæt-Shell
kerne...
tilføj... nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash

Gør-det-selv Bare-Metal Provisioning, eller Automatisk klargøring af servere fra bunden

Her til venstre er PXE-menuen, til højre er kontroloverførselsdiagrammet.

Vi fandt ud af overførsel af kontrol. Afhængigt af valget af PXE-menuen, startes enten autokonfigurationsscriptet eller fejlfindingskonsollen.

I tilfælde af automatisk konfiguration monteres de nødvendige mapper fra installationsserveren, som indeholder:

  • scripts;
  • gemte BIOS/UEFI-skabeloner til forskellige servere;
  • firmware;
  • serverværktøjer;
  • logs

Derefter overfører mount.sh scriptet kontrol til master-install.sh scriptet fra script biblioteket.

Scripttræet (den rækkefølge, de lanceres i) ser nogenlunde sådan ud:

  • master-installer
  • delefunktioner (delte funktioner)
  • info (informationsoutput)
  • modeller (indstilling af installationsparametre baseret på servermodellen)
  • prepare_utils (installation af nødvendige hjælpeprogrammer)
  • fwupdate (firmwareopdatering)
  • diag (elementær diagnostik)
  • biosconf (BIOS/UEFI-indstillinger)
  • clockfix (indstilling af tiden på bundkortet)
  • srmconf (konfiguration af fjerngrænsefladegrænseflade)
  • raidconf (konfiguration af logiske volumener)

en af:

  • preinstall (overførsel af kontrol til OS eller hypervisor-installationsprogrammet, såsom ESXi)
  • Merged-install (umiddelbar start af udpakning af billedet)

Nu ved vi:

  • hvordan man starter en server via PXE;
  • hvordan du overfører kontrol til dit eget script.


Lad os fortsætte. Følgende spørgsmål blev relevante:

  • Hvordan identificerer vi den server, vi forbereder?
  • Hvilke værktøjer og hvordan konfigureres serveren?
  • Hvordan får man indstillinger for en bestemt server?

Hvordan identificerer vi den server, vi forbereder?

Det er enkelt - DMI:

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

Alt hvad du behøver er her: leverandør, model, serienummer. Hvis du ikke er sikker på, at disse oplysninger findes på alle servere, kan du identificere dem ved deres MAC-adresse. Eller på begge måder på samme tid, hvis serverleverandørerne er forskellige, og på nogle modeller er der simpelthen ingen oplysninger om serienummeret.

Baseret på de modtagne oplysninger monteres netværksmapper fra installationsserveren, og alt nødvendigt indlæses (hjælpeprogrammer, firmware osv.).

Hvilke værktøjer og hvordan konfigureres serveren?

Jeg vil levere hjælpeprogrammer til Linux til nogle producenter. Alle hjælpeprogrammer er tilgængelige på de officielle websteder for leverandører.

Gør-det-selv Bare-Metal Provisioning, eller Automatisk klargøring af servere fra bunden

Med firmwaren tror jeg alt er klart. De kommer normalt i form af pakkede eksekverbare filer. Den eksekverbare fil styrer firmwareopdateringsprocessen og rapporterer returkoden.

BIOS og IPMI konfigureres normalt gennem skabeloner. Om nødvendigt kan skabelonen redigeres inden download.

RAID-værktøjer fra nogle leverandører kan også konfigureres ved hjælp af en skabelon. Hvis dette ikke er tilfældet, bliver du nødt til at skrive et konfigurationsscript.

Proceduren for opsætning af RAID er oftest som følger:

  • Vi anmoder om den aktuelle konfiguration.
  • Hvis der allerede er logiske arrays, sletter vi dem.
  • Lad os se på, hvilke fysiske diske der er til stede, og hvor mange der er.
  • Opret et nyt logisk array. Vi afbryder processen i tilfælde af fejl.

Hvordan får man indstillinger for en bestemt server?

Lad os antage, at indstillingerne for alle servere vil blive gemt på installationsserveren. I dette tilfælde, for at besvare vores spørgsmål, skal vi først beslutte, hvordan vi overfører indstillingerne til installationsserveren.

I første omgang kan du klare dig med tekstfiler. (I fremtiden vil du måske bruge en tekstfil som en reservemetode til at overføre indstillinger).

Du kan "dele" en tekstfil på installationsserveren. Og føj dens mount til mount.sh scriptet.

Linjerne vil for eksempel se sådan ud:

<serienummer> <værtsnavn> <undernet>

Disse linjer vil blive overført til filen af ​​ingeniøren fra hans arbejdsmaskine. Og så, når du opsætter en server, vil parametrene for en specifik server blive læst fra filen.

Men på lang sigt er det bedre at bruge en database til at gemme indstillinger, tilstande og logfiler for serverinstallationer.

En database alene er naturligvis ikke nok, og du skal oprette en klientdel ved hjælp af hvilke indstillinger, der overføres til databasen. Dette er sværere at implementere sammenlignet med en tekstfil, men faktisk er alt ikke så svært, som det ser ud til. Det er ganske muligt at skrive en minimal version af en klient, der blot selv overfører data til databasen. Og i fremtiden vil det være muligt at forbedre klientprogrammet i fri tilstand (rapporter, udskrivning af etiketter, afsendelse af notifikationer osv., der falder dig ind).

Ved at lave en specifik anmodning til databasen og specificere serverens serienummer, vil vi modtage de nødvendige parametre til konfiguration af serveren.

Derudover behøver vi ikke komme med låse til samtidig adgang, som det er tilfældet med en tekstfil.

Vi kan skrive konfigurationsloggen til databasen på alle stadier og kontrollere installationsprocessen gennem hændelser og flag i forberedelsesstadierne.

Nu ved vi hvordan:

  • boot serveren via PXE;
  • overføre kontrol til vores script;
  • identificere den server, der skal forberedes, ved dens serienummer;
  • konfigurere serveren ved hjælp af de relevante hjælpeprogrammer;
  • overføre indstillinger til installationsserverdatabasen ved hjælp af klientdelen.

Vi fandt ud af hvordan:

  • den installerede server modtager de nødvendige indstillinger fra databasen;
  • alle forberedelser registreres i databasen (logfiler, begivenheder, sceneflag).

Hvad med de forskellige typer software, du installerer? Hvordan installerer man en hypervisor, kopierer en VM og konfigurerer det hele?

I tilfælde af implementering af et filsystembillede (linux) til hardware, er alt ganske enkelt:

  • Efter opsætning af alle serverkomponenterne implementerer vi billedet.
  • Installer grub bootloader.
  • Vi chroot og konfigurerer alt, hvad der er nødvendigt.

Sådan overføres kontrol til OS-installationsprogrammet (ved at bruge ESXi som eksempel).

  • Vi organiserer overførslen af ​​kontrol fra vores script til hypervisor-installationsprogrammet ved hjælp af den automatiske svarfil (kickstart):
  • Vi sletter de nuværende partitioner på disken.
  • Opret en partition med en størrelse på 500MB.
  • Vi markerer den som bootbar.
  • Formater til FAT32.
  • Vi kopierer ESXi installationsfilerne til roden.
  • Installation af syslinux.
  • Kopier syslinux.cfg til /syslinux/

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

  • Kopier mboot.c32 til /syslinux.
  • Boot.cfg skal have kernelopt=ks=ftp:// /ks_esxi.cfg
  • Genstart serveren.

Når serveren er genstartet, vil ESXi-installationsprogrammet downloades fra serverens harddisk. Alle nødvendige installationsfiler vil blive indlæst i hukommelsen, og derefter begynder ESXi-installationen i henhold til den angivne autosvar-fil.

Her er et par linjer fra autosvar-filen 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

På dette stadium er hypervisoren installeret og konfigureret, og virtuelle maskiner kopieres.

Hvordan konfigurerer man virtuelle maskiner nu?

Vi snød lidt: under installationen satte vi parameteren guestinfo.esxihost.id = "$SYSSN" i VM1.vmx-filen og angav serienummeret på den fysiske server i den.

Nu, efter start, kan den virtuelle maskine (med vmware-tools-pakken installeret) få adgang til denne parameter:

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

Det vil sige, at VM'en vil være i stand til at identificere sig selv (den kender serienummeret på den fysiske vært), lave en anmodning til installationsserverdatabasen og modtage de parametre, der skal konfigureres. Dette er alt sammen kompileret til et script, som skal startes automatisk, når guestos vm starter (men én gang: RunOnce).

Nu ved vi hvordan:

  • boot serveren via PXE;
  • overføre kontrol til vores script;
  • identificere den server, der skal forberedes, ved dens serienummer;
  • konfigurere serveren ved hjælp af de relevante hjælpeprogrammer;
  • overføre indstillinger til installationsserverdatabasen ved hjælp af klientdelen;
  • konfigurere forskellige typer software, herunder implementering af esxi hypervisor og konfiguration af virtuelle maskiner (alt sammen automatisk).

Vi fandt ud af hvordan:

  • den installerede server modtager de nødvendige indstillinger fra databasen;
  • alle forberedelser registreres i databasen (logfiler, begivenheder, sceneflag).


Den nederste linje:

Jeg mener, at det unikke ved denne løsning ligger i dens fleksibilitet, enkelhed, muligheder og alsidighed.

Skriv gerne i kommentarerne, hvad du synes.

Kilde: www.habr.com

Tilføj en kommentar