Aprovisionamento Bare-Metal de bricolaxe ou preparación automática de servidores desde cero

Ola, son Denis e unha das miñas áreas de actividade é o desenvolvemento de solucións de infraestruturas en X5. Hoxe gustaríame compartir contigo como podes implementar un sistema automático de preparación do servidor baseado en ferramentas dispoñibles publicamente. Na miña opinión, esta é unha solución interesante, sinxela e flexible.

Por preparación queremos dicir: converter un novo servidor fóra da caixa nun servidor totalmente configurado con SO. Linux ou co hipervisor ESXi (o despregue de servidores Windows non se trata neste artigo).

Condicións:

• servidores: servidores que precisan ser configurados.
• o servidor de instalación é o servidor principal que proporciona todo o proceso de preparación a través da rede.

Por que é necesaria a automatización?

Digamos que hai unha tarefa: preparar masivamente os servidores desde cero, nun pico: 30 por día. Poden estar instalados neles servidores de distintos fabricantes e modelos, diferentes sistemas operativos e poden ter ou non hipervisor.

Que operacións se inclúen no proceso de configuración (sen automatización):

• conectar un teclado, rato, monitor ao servidor;
• configurar BIOS, RAID, IPMI;
• actualizar o firmware dos compoñentes;
• implementar unha imaxe do sistema de ficheiros (ou instalar un hipervisor e copiar máquinas virtuais);

Nota. Alternativamente, a implantación do SO é posible mediante a instalación cun ficheiro de resposta automática. Pero isto non será discutido no artigo. Aínda que verás a continuación que engadir esta funcionalidade non é difícil.

• configurar os parámetros do sistema operativo (nome de host, IP, etc.).

Con este enfoque, as mesmas configuracións realízanse secuencialmente en cada servidor. A eficiencia deste traballo é moi baixa.

A esencia da automatización é eliminar a participación humana do proceso de preparación do servidor. Tanto como sexa posible.

A automatización reduce o tempo de inactividade entre as operacións e permite aprovisionar varios servidores á vez. Tamén se reduce moito a probabilidade de erros por factores humanos.

Como se configuran automaticamente os servidores?

Imos analizar todas as etapas en detalle.

Tes un servidor Linux que usas como servidor de instalación PXE. Os servizos están instalados e configurados nel: DHCP, TFTP.

Entón, arrancamos o servidor (que debe configurarse) a través de PXE. Lembremos como funciona:

• O arranque de rede está seleccionado no servidor.
• O servidor carga o PXE-ROM da tarxeta de rede e contacta co servidor de instalación a través de DHCP para obter un enderezo de rede.
• O servidor de instalación de DHCP emite un enderezo, así como instrucións para seguir descargando a través de PXE.
• O servidor carga o cargador de arranque de rede desde o servidor de instalación a través de PXE, a carga adicional prodúcese segundo o ficheiro de configuración PXE.
• O arranque prodúcese en función dos parámetros recibidos (kernel, initramfs, puntos de montaxe, imaxe squashfs, etc.).

Nota. O artigo describe o inicio mediante PXE a través do modo BIOS. Actualmente, os fabricantes están implementando activamente o modo de arranque UEFI. Para PXE, a diferenza estará na configuración do servidor DHCP e na presenza dun cargador de arranque adicional.

Vexamos un exemplo de configuración de servidor PXE (menú pxelinux).

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

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

O kernel e initramfs nesta fase son unha imaxe de Linux intermedia, coa axuda da cal terá lugar a preparación e configuración principal do servidor.

Como podes ver, o cargador de arranque pasa moitos parámetros ao núcleo. Algúns destes parámetros son usados ​​polo propio núcleo. E podemos usar algúns para os nosos propios fins. Isto comentarase máis adiante, pero polo momento só podes lembrar que todos os parámetros pasados ​​estarán dispoñibles na imaxe intermedia de Linux a través de /proc/cmdline.

Onde podo conseguilos, o núcleo e os initramfs?
Como base, podes escoller calquera distribución de Linux. No que prestamos atención ao elixir:

• a imaxe de arranque debe ser universal (dispoñibilidade de controladores, capacidade de instalar utilidades adicionais);
• O máis probable é que necesites personalizar o initramfs.

Como se fai isto na nosa solución para X5? Como base escolleuse CentOS 7. Probemos o seguinte truco: preparar a futura estrutura da imaxe, empaquetala nun arquivo e crear un initramfs, dentro do cal estará o noso arquivo do sistema de ficheiros. Ao cargar a imaxe, o arquivo expandirase á partición tmpfs creada. Deste xeito, obteremos unha imaxe de Linux en directo mínima, aínda que completa, con todas as utilidades necesarias, consistente só en dous ficheiros: vmkernel e 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

Así que especificamos o núcleo e initramfs que deberían cargarse. Como resultado, nesta fase, ao cargar a imaxe de Linux intermedia a través de PXE, recibiremos a consola do SO.

Xenial, pero agora necesitamos transferir o control á nosa "automatización".

Pódese facer así.

Supoñamos que despois de cargar a imaxe pensamos transferir o control ao script mount.sh.
Imos incluír o script mount.sh na execución automática. Para iso terás que modificar o initramfs:

• desempaquetar initramfs (se usamos a opción initramfs anterior, isto non é necesario)
• incluír código no inicio que analizará os parámetros pasados ​​por /proc/cmdline e transferirá máis o control;
• paquete initramfs.

Nota. No caso do kit de ferramentas X5, o control de carga transfírese ao script /opt/x5/toolkit/bin/hook.sh с помощью override.conf в getty tty1 (ExecStart=…)

Entón, cárgase a imaxe, na que o script mount.sh comeza coa execución automática. A continuación, o script mount.sh analiza os parámetros pasados ​​(script_cmd=) durante a execución e inicia o programa/script necesario.

kit de ferramentas para etiquetas -automático
núcleo...
append...nfs_toolkit_script=scripts/mount.sh script_cmd=master-install.sh

kit de ferramentas para etiquetas -cuncha
núcleo...
append...nfs_toolkit_script=scripts/mount.sh script_cmd=/bin/bash

Aquí á esquerda está o menú PXE, á dereita o diagrama de transferencia de control.

Descubrimos a transferencia de control. Dependendo da elección do menú PXE, lánzase o script de configuración automática ou a consola de depuración.

No caso de configuración automática, os directorios necesarios son montados dende o servidor de instalación, que conteñen:

• guións;
• modelos de BIOS/UEFI gardados para varios servidores;
• firmware;
• utilidades do servidor;
• rexistros

A continuación, o script mount.sh transfire o control ao script master-install.sh desde o directorio de scripts.

A árbore de scripts (a orde na que se inician) ten un aspecto similar ao seguinte:

• master-install
• sharefunctions (funcións compartidas)
• información (saída de información)
• modelos (definición de parámetros de instalación en función do modelo de servidor)
• prepare_utils (instalación das utilidades necesarias)
• fwupdate (actualización de firmware)
• diag (diagnóstico elemental)
• biosconf (configuración de BIOS/UEFI)
• clockfix (axustar a hora na placa base)
• srmconf (configuración da interface remota)
• raidconf (configuración de volumes lóxicos)

un de:

• preinstalación (transferindo control ao instalador do sistema operativo ou do hipervisor, como ESXi)
• merged-install (inicio inmediato de desempaquetar a imaxe)

Agora sabemos:

• como iniciar un servidor mediante PXE;
• como transferir o control ao teu propio script.

Continuemos. As seguintes preguntas resultaron relevantes:

• Como identificar o servidor que estamos a preparar?
• Que utilidades e como configurar o servidor?
• Como obter a configuración dun servidor específico?

Como identificar o servidor que estamos a preparar?

É sinxelo - DMI:

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

Todo o que necesitas está aquí: vendedor, modelo, número de serie. Se non está seguro de que esta información estea presente en todos os servidores, pode identificalos polo seu enderezo MAC. Ou de ambos os xeitos ao mesmo tempo, se os provedores do servidor son diferentes e nalgúns modelos simplemente non hai información sobre o número de serie.

En función da información recibida, desde o servidor de instalación montan carpetas de rede e cárgase todo o necesario (utilidades, firmware, etc.).

Que utilidades e como configurar o servidor?

Proporcionarei utilidades para Linux para algúns fabricantes. Todas as utilidades están dispoñibles nos sitios web oficiais dos provedores.

Co firmware, creo que está todo claro. Normalmente veñen en forma de ficheiros executables empaquetados. O ficheiro executable controla o proceso de actualización do firmware e informa do código de retorno.

BIOS e IPMI adoitan configurarse mediante modelos. Se é necesario, o modelo pódese editar antes de descargalo.

As utilidades RAID dalgúns provedores tamén se poden configurar mediante un modelo. Se non é o caso, terás que escribir un script de configuración.

O procedemento para configurar RAID adoita ser o seguinte:

• Solicitamos a configuración actual.
• Se xa hai matrices lóxicas, borrámolas.
• Vexamos que discos físicos hai e cantos hai.
• Crea unha nova matriz lóxica. Interrompemos o proceso en caso de erro.

Como obter a configuración dun servidor específico?

Supoñamos que a configuración de todos os servidores se almacenará no servidor de instalación. Neste caso, para responder á nosa pregunta, primeiro debemos decidir como transferir a configuración ao servidor de instalación.

Ao principio, podes facelo con ficheiros de texto. (No futuro, pode querer usar un ficheiro de texto como método alternativo para transferir a configuración.)

Podes "compartir" un ficheiro de texto no servidor de instalación. E engade o seu montaxe ao script mount.sh.

As liñas, por exemplo, terán o seguinte aspecto:

<número de serie> <nome de host> <subrede>

Estas liñas serán trasladadas ao ficheiro polo enxeñeiro dende a súa máquina de traballo. E despois, ao configurar un servidor, os parámetros dun servidor específico leranse dende o ficheiro.

Pero, a longo prazo, é mellor usar unha base de datos para almacenar configuracións, estados e rexistros das instalacións do servidor.

Por suposto, unha base de datos por si só non é suficiente e terás que crear unha parte do cliente coa axuda da cal se transferirá a configuración á base de datos. Isto é máis difícil de implementar en comparación cun ficheiro de texto, pero de feito, todo non é tan difícil como parece. É moi posible escribir unha versión mínima dun cliente que simplemente transferirá os datos á base de datos. E no futuro será posible mellorar o programa cliente en modo libre (informes, impresión de etiquetas, envío de notificacións, etc. que se ocorra).

Facendo unha solicitude específica á base de datos e especificando o número de serie do servidor, recibiremos os parámetros necesarios para configurar o servidor.

Ademais, non necesitaremos crear bloqueos para o acceso simultáneo, como é o caso dun ficheiro de texto.

Podemos escribir o rexistro de configuración na base de datos en todas as fases e controlar o proceso de instalación mediante eventos e bandeiras das fases de preparación.

Agora sabemos como:

• iniciar o servidor a través de PXE;
• transferir o control ao noso guión;
• identificar o servidor que debe ser preparado polo seu número de serie;
• configurar o servidor mediante as utilidades adecuadas;
• transferir a configuración á base de datos do servidor de instalación mediante a parte cliente.

Descubrimos como:

• o servidor instalado recibe a configuración necesaria da base de datos;
• todo o progreso da preparación está rexistrado na base de datos (rexistros, eventos, bandeiras de etapa).

Que pasa cos distintos tipos de software que instalas? Como instalar un hipervisor, copiar unha máquina virtual e configuralo todo?

No caso de implementar unha imaxe do sistema de ficheiros (linux) ao hardware, todo é bastante sinxelo:

• Despois de configurar todos os compoñentes do servidor, despregamos a imaxe.
• Instala o cargador de arranque grub.
• Realizamos o chroot e configuramos todo o que sexa necesario.

Como transferir o control ao instalador do SO (usando ESXi como exemplo).

• Organizamos a transferencia de control do noso script ao instalador do hipervisor mediante o ficheiro de resposta automática (kickstart):
• Eliminamos as particións actuais do disco.
• Crea unha partición cun tamaño de 500 MB.
• Marcámolo como de arranque.
• Formato a FAT32.
• Copiamos os ficheiros de instalación de ESXi na raíz.
• Instalando syslinux.
• Copia syslinux.cfg en /syslinux/

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

• Copia mboot.c32 en /syslinux.
• Boot.cfg debería ter kernelopt=ks=ftp:// /ks_esxi.cfg
• Reiniciamos o servidor.

Despois de reiniciar o servidor, o instalador de ESXi descargarase do disco duro do servidor. Todos os ficheiros de instalación necesarios cargaranse na memoria e, a continuación, comezará a instalación de ESXi, segundo o ficheiro de resposta automática especificado.

Aquí tes algunhas liñas do ficheiro de resposta automática 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

Nesta fase, o hipervisor está instalado e configurado, e as máquinas virtuais son copiadas.

Como configurar máquinas virtuais agora?

Enganamos un pouco: durante a instalación establecemos o parámetro guestinfo.esxihost.id = "$SYSSN" no ficheiro VM1.vmx e indicamos o número de serie do servidor físico nel.

Agora, despois de iniciar, a máquina virtual (co paquete vmware-tools instalado) pode acceder a este parámetro:

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

É dicir, a máquina virtual poderá identificarse (coñece o número de serie do host físico), realizar unha solicitude á base de datos do servidor de instalación e recibir os parámetros que hai que configurar. Todo isto está compilado nun script, que debería iniciarse automaticamente cando se inicia guestos vm (pero unha vez: RunOnce).

Agora sabemos como:

• iniciar o servidor a través de PXE;
• transferir o control ao noso guión;
• identificar o servidor que debe ser preparado polo seu número de serie;
• configurar o servidor mediante as utilidades adecuadas;
• transferir a configuración á base de datos do servidor de instalación usando a parte cliente;
• configurar varios tipos de software, incluíndo a implantación do hipervisor esxi e a configuración de máquinas virtuais (todo automaticamente).

Descubrimos como:

• o servidor instalado recibe a configuración necesaria da base de datos;
• todo o progreso da preparación está rexistrado na base de datos (rexistros, eventos, bandeiras de etapa).

A liña inferior:

Creo que a singularidade desta solución reside na súa flexibilidade, sinxeleza, capacidades e versatilidade.

Escribe nos comentarios o que pensas.

Fonte: www.habr.com