Provisioning Bare-Metal à faire soi-même ou préparation de serveur automatique à partir de zéro

Bonjour, je suis Denis et l’un de mes domaines d’activité est le développement de solutions d’infrastructure en X5. Aujourd'hui, je voudrais partager avec vous comment vous pouvez déployer un système de préparation de serveur automatisé basé sur des outils accessibles au public. À mon avis, c'est une solution intéressante, simple et flexible.



Par préparation, on entend: faire d'un nouveau serveur prêt à l'emploi, un serveur entièrement configuré avec OS Linux ou avec l'hyperviseur ESXi (la diffusion de serveur Windows n'est pas abordée dans cet article).

Termes :

  • serveurs - serveurs qui doivent être configurés.
  • serveur d'installation - le serveur principal qui fournit l'ensemble du processus de préparation sur le réseau.

Pourquoi avez-vous besoin d'automatisation?


Disons qu'il y a un problème: préparer en masse le serveur à partir de zéro, au pic - 30 par jour. Des serveurs de différents fabricants et modèles, différents systèmes d'exploitation peuvent y être installés, un hyperviseur peut ou non exister.

Quelles opérations sont incluses dans le processus de configuration (sans automatisation):

  • connectez le clavier, la souris et le moniteur au serveur;
  • configurer le BIOS, RAID, IPMI;
  • mettre à niveau le firmware des composants;
  • déployer une image de système de fichiers (ou installer un hyperviseur et copier des machines virtuelles);

Remarque. Alternativement, le déploiement du système d'exploitation est possible grâce à l'installation avec un fichier de réponse automatique. Mais cela ne sera pas discuté dans l'article. Bien que vous puissiez voir ci-dessous, l'ajout de cette fonctionnalité est facile.

  • configurer les paramètres du système d'exploitation (nom d'hôte, IP, etc.).

Avec cette approche, les mêmes paramètres sont effectués séquentiellement sur chaque serveur. L'efficacité d'un tel travail est très faible.

L'essence de l'automatisation consiste à exclure l'implication humaine du processus de préparation du serveur. Autant que possible.

Grâce à l'automatisation, les temps d'arrêt entre les opérations sont réduits et il devient possible de préparer plusieurs serveurs en même temps. La probabilité d'erreurs dues au facteur humain est également considérablement réduite.



Comment les serveurs sont-ils configurés automatiquement?


Nous analyserons toutes les étapes en détail.

Vous disposez d'un serveur Linux que vous utilisez comme serveur d'installation PXE. Les services y sont installés et configurés: DHCP, TFTP.

Donc, nous chargeons le serveur (qui doit être configuré) par PXE. Rappelez-vous comment cela fonctionne:

  • Le serveur sélectionné pour démarrer sur le réseau.
  • Le serveur charge la PXE-ROM de la carte réseau et contacte le serveur d'installation via DHCP pour obtenir l'adresse réseau.
  • DHCP du serveur d'installation donne l'adresse, ainsi que des instructions pour un téléchargement ultérieur via PXE.
  • Le serveur télécharge le chargeur de démarrage réseau à partir du serveur d'installation via PXE, le téléchargement se poursuit en fonction du fichier de configuration PXE.
  • Le téléchargement s'effectue en fonction des paramètres reçus (noyau, initramfs, points de montage, image squashfs, etc.).

Remarque. Cet article décrit le démarrage PXE via le mode BIOS. Actuellement, les fabricants introduisent activement le mode de démarrage UEFI. Pour PXE, la différence sera dans la configuration du serveur DHCP et la présence d'un chargeur de démarrage supplémentaire.

Prenons un exemple de configuration de serveur PXE (menu pxelinux).

Fichier pxelinux.cfg / défaut:

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 //    

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

Le noyau et initramfs à ce stade sont une image linux intermédiaire, à l'aide de laquelle la préparation et la configuration de base du serveur auront lieu.

Comme vous pouvez le voir, le chargeur de démarrage transmet de nombreux paramètres au noyau. Certains de ces paramètres sont utilisés par le noyau lui-même. Et nous pouvons en utiliser à nos propres fins. Cela sera décrit plus tard, mais pour l'instant, vous pouvez simplement vous rappeler que tous les paramètres passés seront disponibles dans l'image linux intermédiaire via / proc / cmdline.

Où les trouver, le noyau et les initramfs?
Comme base, vous pouvez choisir n'importe quelle distribution Linux. Ce à quoi nous prêtons attention lors du choix:

  • l'image de démarrage doit être universelle (pilotes disponibles, possibilité d'installer des utilitaires supplémentaires);
  • très probablement, les initramfs devront être personnalisés.

Comment cela se fait-il dans notre solution pour X5? CentOS 7 a été choisi comme base. Faisons l'astuce suivante: préparer la future structure de l'image, l'intégrer dans l'archive et créer des initramfs, à l'intérieur desquels sera notre archive de système de fichiers. Lors du chargement de l'image, l'archive sera déployée dans la section tmpfs créée. Ainsi, nous obtenons une image live-linux minimale, mais à part entière avec tous les utilitaires nécessaires, composée de seulement deux fichiers: vmkernel et 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

Nous avons donc spécifié un noyau et des initramfs qui devraient être chargés. En conséquence, à ce stade, en téléchargeant l'image linux intermédiaire via PXE, nous obtenons la console OS.

Très bien, mais maintenant nous devons transférer le contrôle à notre «automatisation».

Cela peut être fait comme ça.

Supposons qu'après le chargement de l'image, nous prévoyons de transférer le contrôle au script mount.sh.
Nous incluons le script mount.sh dans l'exécution automatique. Pour ce faire, vous devez modifier initramfs:

  • décompressez initramfs (si nous utilisons la version ci-dessus d'initramfs, ce n'est pas obligatoire)
  • inclure dans le code de démarrage qui analysera les paramètres passés via / proc / cmdline et transférera le contrôle plus loin;
  • pack initramfs.

Remarque. Dans le cas de la boîte à outils X5, le contrôle de démarrage est transféré au script. /opt/x5/toolkit/bin/hook.sh override.conf getty tty1 (ExecStart=…)

L'image est donc chargée, dans laquelle le script mount.sh démarre au démarrage. Ensuite, le script mount.sh en cours d'analyse analyse les paramètres passés (script_cmd =) et lance le programme / script nécessaire.

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

label toolkit- shell
kernel ...
append ... nfs_toolkit_script = scripts / mount.sh script_cmd = / bin / bash



Ici sur le côté gauche se trouve le menu PXE , à droite, le schéma de transfert de contrôle.

Avec le transfert de contrôle, nous l'avons compris. Selon le choix du menu PXE, le script de réglage automatique ou la console de débogage est lancé.

Dans le cas d'une configuration automatique, les répertoires nécessaires du serveur d'installation sont montés, dans lesquels il y a:

  • scripts;
  • modèles BIOS / UEFI enregistrés de divers serveurs;
  • firmware;
  • utilitaires pour serveurs;
  • journaux.

Ensuite, le script mount.sh transfère le contrôle au script master-install.sh à partir du répertoire scripts.

L'arbre de script (l'ordre de leur lancement) ressemble à ceci:

  • installation principale
  • sharefunctions (fonctions communes)
  • info (sortie d'informations)
  • modèles (définition des paramètres d'installation en fonction du modèle de serveur)
  • prepare_utils (installation des utilitaires nécessaires)
  • fwupdate (mise à jour du firmware)
  • diag (diagnostic élémentaire)
  • biosconf (configuration BIOS / UEFI)
  • clockfix (réglage de l'heure sur la carte mère)
  • srmconf (configuration de l'interface distante)
  • raidconf (configuration des volumes logiques)

un des:

  • préinstallation (transfert du contrôle au programme d'installation du système d'exploitation ou de l'hyperviseur, par exemple ESXi)
  • fusion-installation (démarrage direct du déballage de l'image)

Maintenant, nous savons:

  • comment démarrer le serveur via PXE;
  • comment transférer le contrôle sur votre propre script.

Nous allons continuer. Les problèmes suivants sont devenus pertinents:

  • Comment identifier le serveur que nous préparons?
  • Quels utilitaires et comment configurer le serveur?
  • Comment obtenir les paramètres d'un serveur spécifique?

Comment identifier le serveur que nous préparons?


C'est simple - DMI:

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

Il a tout ce dont vous avez besoin: un fournisseur, un modèle, un numéro de série. Si vous n'êtes pas sûr que ces informations soient présentées sur tous les serveurs, vous pouvez les identifier par adresse MAC. Ou dans les deux sens en même temps si les fournisseurs de serveurs sont différents et sur certains modèles, les informations sur le numéro de série ne sont tout simplement pas disponibles.

Sur la base des informations reçues, les dossiers réseau du serveur d'installation sont montés et tout le nécessaire est chargé (utilitaires, firmware, etc.).

Quels utilitaires et comment configurer le serveur?


Je vais donner des utilitaires pour Linux pour certains fabricants. Tous les utilitaires sont disponibles sur les sites Web officiels des fournisseurs.



Avec le firmware, je pense que tout est clair. Ils viennent généralement dans des exécutables emballés. Le fichier exécutable contrôle le processus de mise à jour du micrologiciel et signale un code retour.

Le BIOS et IPMI sont généralement configurés via des modèles. Si nécessaire, le modèle peut être modifié avant le chargement.

Les utilitaires RAID pour certains fournisseurs peuvent également être configurés en fonction du modèle. Si ce n'est pas le cas, vous devrez écrire un script de configuration.

La procédure de configuration du RAID est le plus souvent la suivante:

  • Nous demandons la configuration actuelle.
  • S'il existe déjà des tableaux logiques, nous les effaçons.
  • Nous regardons quels disques physiques sont présents et combien d'entre eux.
  • Créez un nouveau tableau logique. Nous interrompons le processus en cas d'erreur.

Comment obtenir les paramètres d'un serveur spécifique?


Supposons que tous les paramètres du serveur soient stockés sur le serveur d'installation. Dans ce cas, pour répondre à notre question, vous devez d'abord décider: comment transférer les paramètres vers le serveur d'installation.

Au début, il est tout à fait possible de faire avec des fichiers texte. (À l'avenir, vous pouvez utiliser un fichier texte comme moyen de sauvegarde pour transférer les paramètres).

Vous pouvez "partager" un fichier texte sur le serveur d'installation. Et ajoutez-le au script mount.sh.

Les lignes ressembleront, par exemple, à ceci:

<numéro de série> <nom d'hôte> <sous-réseau>

Ces lignes seront transférées dans le fichier par l'ingénieur depuis sa machine de travail. Et puis, lors de la configuration du serveur, les paramètres d'un serveur spécifique seront lus dans le fichier.

Mais, à l'avenir, il est préférable d'utiliser la base de données pour stocker les paramètres, les états et les journaux d'installation du serveur.

Bien sûr, une base de données ne peut pas le faire, et vous devrez créer une partie client, à l'aide de laquelle les paramètres seront transférés dans la base de données. C'est plus difficile à mettre en œuvre qu'un fichier texte, mais ce n'est pas aussi difficile qu'il y paraît. La version minimale du client, qui transfèrera simplement les données à la base de données, est tout à fait faisable pour vous écrire. À l'avenir, il sera possible d'améliorer le programme client également en mode libre (rapports, impression d'étiquettes, envoi de notifications, etc., quoi que l'on pense).

Après avoir fait une demande spécifique à la base de données et en indiquant le numéro de série du serveur, nous obtenons les paramètres nécessaires à la configuration du serveur.

De plus, nous n'avons pas besoin d'inventer des verrous pour un accès simultané, comme c'est le cas avec un fichier texte.

Nous pouvons écrire le journal de configuration à toutes les étapes de la base de données et contrôler le processus d'installation à travers les événements et les drapeaux des étapes de préparation.

Maintenant, nous savons comment:

  • charger le serveur via PXE;
  • transférer le contrôle sur notre script;
  • identifier le serveur à préparer par numéro de série;
  • configurer le serveur avec les utilitaires appropriés;
  • transférer les paramètres vers la base de données du serveur d'installation à l'aide de la partie client.

J'ai découvert comment:

  • le serveur installé reçoit les paramètres nécessaires de la base de données;
  • tous les progrès de la préparation sont enregistrés dans la base de données (journaux, événements, indicateurs de stade).

Qu'en est-il des différents types de logiciels installés? Comment installer un hyperviseur, copier une VM et configurer tout cela?


Dans le cas du déploiement d'une image de système de fichiers (linux) sur du matériel, tout est assez simple:

  • Après avoir configuré tous les composants du serveur, déployez l'image.
  • Installez le chargeur de démarrage grub.
  • Nous faisons chroot et configurons tout ce qui est nécessaire.

Comment transférer le contrôle vers le programme d'installation du système d'exploitation (en utilisant ESXi comme exemple).

  • Nous organisons le transfert de contrôle de notre script vers le programme d'installation de l'hyperviseur à l'aide du fichier de réponse automatique (kickstart):
  • Supprimez les partitions actuelles sur le disque.
  • Créez une partition de 500 Mo.
  • Nous le marquons comme démarrage.
  • Format en FAT32.
  • Nous copions les fichiers d'installation ESXi à la racine.
  • Installez syslinux.
  • Copiez syslinux.cfg dans / syslinux /

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

  • Copiez mboot.c32 dans / syslinux.
  • Dans boot.cfg, il devrait y avoir kernelopt = ks = ftp: // <IP du serveur d'installation> /ks_esxi.cfg
  • Redémarrez le serveur.

Après le redémarrage du serveur, le programme d'installation ESXi démarre à partir de son disque dur. Tous les fichiers d'installation nécessaires seront chargés en mémoire et l'installation d'ESXi commencera, selon le fichier de réponse automatique spécifié.

Voici quelques lignes du fichier de réponse automatique 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

À ce stade, un hyperviseur est installé et configuré, les machines virtuelles sont copiées.

Comment configurer des machines virtuelles maintenant?

Nous avons un peu triché: lors de l'installation, nous avons défini le paramètre guestinfo.esxihost.id = "$ SYSSN" dans le fichier VM1.vmx, indiqué le numéro de série du serveur physique.

Maintenant, après le démarrage, la machine virtuelle (avec le package vmware-tools installé) peut accéder à ce paramètre:

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

Autrement dit, la machine virtuelle pourra s'identifier (elle connaît le numéro de série de l'hôte physique), faire une demande à la base de données du serveur d'installation et obtenir les paramètres qui doivent être configurés. Tout cela est exécuté dans un script qui devrait être lancé automatiquement au démarrage de guestos vm (mais une fois: RunOnce).

Maintenant, nous savons comment:

  • charger le serveur via PXE;
  • transférer le contrôle sur notre script;
  • identifier le serveur à préparer par numéro de série;
  • configurer le serveur avec les utilitaires appropriés;
  • transférer les paramètres vers la base de données du serveur d'installation à l'aide de la partie client;
  • Configurez différents types de bons de commande, notamment le déploiement de l'hyperviseur esxi et la configuration des machines virtuelles (et tout cela automatiquement).

J'ai découvert comment:

  • le serveur installé reçoit les paramètres nécessaires de la base de données;
  • tous les progrès de la préparation sont enregistrés dans la base de données (journaux, événements, indicateurs de stade).

Conclusion:

je crois que le caractère unique de cette solution réside dans sa flexibilité, sa simplicité, ses capacités et sa polyvalence.

Veuillez écrire dans les commentaires ce que vous en pensez.

All Articles