SystemImager : concepts d’une solution d’automatisation de déploiement

SystemImager est un projet très abouti qui permet de gérer l'installation et le déploiement de logiciel et de distribution Linux, tout en s'appuyant des outils standards comme SSH et rsync. Il se distingue très nettement des outils comme Fedora kickstart et Debian debootstrap dans la mesure où il est capable de gérer plusieurs architectures et distributions différentes. D'autre part, la finesse des petites customisations et tout ce qui pourrait sortir du standard des dépôts est directement prise en compte et appliquée, sans avoir à se confronter aux fameux scripts de post-installation. En ce sens, cela fait de lui l'outil incontournable pour une gestion de parc uniforme et automatisée. Son fonctionnement est simple : il aspire dans un premier temps tout ou partie d'un système de fichier (on peut spécifier des exclusions ou même en créer un viable, via les outils du package) qu'il stocke tel quel au sein d'un dépôt d'image. Il s'agit ensuite de rebalancer l'arborescence, soit pour une installation complète, soit pour un alignement des version. Du fait que le système de fichier soit stocké en l'état, il est alors très facile de modifier et contrôler le contenu de l'image avant déploiement. La seule contrainte concerne les clients et requiert une parfaite adéquation dans le nombre de disques durs des noeuds sous la juridiction de SystemImager. La capacité peut varier, mais attention aux disques plus petits que ceux du GoldenClient. En effet, si l'on venait à balancer une install qui ne tiendrait pas sur le disque, cela ferait désordre. Pour pouvoir entrer dans les détails, il est nécessaire de définir les notions sur lesquelles s'appuie SystemImager.

Les éléments

L'image server

SystemImager a besoin d'un maître d'orchestre, appelé le serveur d'image, afin de pouvoir centraliser toute la partie gestion des images et des noeuds. Notre serveur contiendra donc tous les packages et toute la configuration nécessaire à SystemImager. La racine de SystemImager se situe au niveau de /var/lib/systemimager, et est enrichie de plusieurs éléments :

# ll /var/lib/systemimager/
total 28
-rw-r--r--  1 root root 14361 2010-06-29 11:13 clients.xml
drwxr-xr-x  9 root root  4096 2010-06-23 10:21 images/
drwxr-xr-x 55 root root  4096 2010-06-23 10:21 overrides/
drwxr-xr-x  4 root root  4096 2010-06-23 10:21 scripts/

Les explications relatives aux différents éléments seront fournies un peu plus loin. Afin de pouvoir distribuer les images correctement -et surtout lors du boot PXE-, le server devra regrouper le duo TFTP server et DHCP server. A noter que SystemImager permet de rapidement mettre en place une configuration complète de serveur de boot grâce à l'outil si_mkbootserver, intégré au package systemimager-server. Il existe plusieurs façons d'installer via SystemImager. PXE, comme nous l'avons mentionné un peu plus haut, Bittorent, ou par multicast. Ces variations sont à l'origine de certains packages qui ont été spécialement crée sur ces spécificités. A titre d'information, les packages intéressants sont :

systemimager-server : le core du serveur SystemImager,
systemimager-common : les outils qui vont avec,
systemimager-*boot-standard : les outils relatifs à la partie boot server, * regroupe i386 et x86_64

systemimager-server-flamethrower* : pour utiliser le mode multicast
systemimager-server-bittorrent : pour utiliser le mode BitTorrent.

Il va sans dire que, si vous projetez d'installer plusieurs distributions, il faudra assurer au niveau stockage des images. Même réflexion concernant la partie réseau, surtout si l'intention de virtualiser vous taraude. Le paramétrage fin de SystemImager se fait comme d'habitude, via un fichier de configuration : /etc/systemimager.conf, ou /etc/systemimager/systemimager.conf.

Les nodes

Les nodes sont les postes clients qui vont faire l'objet d'une installation automatisée par SystemImager. Ils sont rattachés préalablement à une image bien précise, et optionnellement à un ou plusieurs overrides. Accessoirement, ils disposent d'une entrée dans le fichier /etc/dhcpd.conf du serveur afin de pouvoir obtenir une adresse et pouvoir rapatrier, via TFTP par exemple, un noyau minimal qui se chargera de l'installation. Le paramétrage des clients et leur association à une image peut passer par si_addclients (c'est d'ailleurs historique)ou par si_clusterconfig. Je ne vous éplucherais pas toutes les options qui sont disponibles, sachez que vous pouvez absolument tout faire, grouper vos clients en liste FQDN, IP, avec un domainname qui leur pend, en interactif,... Bref, man est votre meilleur ami. On retrouve les informations relatives aux nodes dans le fichier /var/lib/systemimager/clients.xml. Point important, si_clusterconfig est un outil au-dessus de la gestion de node, c'est-à-dire qu'il définit l'ensemble de votre cluster en terme de groupe, de priorité, d'image, d'override, et de node.

Le GoldenClient

Le GoldenClient est un poste de même calibre que les nodes, et qui leur servira indirectement de référence. Il doit être installé et configuré manuellement et est à l'origine de l'image référente que vous déployerez. systemimager-common et systemimager-client devront être présents sur le GoldenClient.

Les images

Les images sont des répertoires chrootables qui contiennent l'intégralité du système de fichier à déployer sur les clients. Elles sont identifiées par un nom intelligible, fourni en entrée lors de leur récupération du GoldenClient. Toutes les images sont stockées sous la racine de SystemImager, c'est-à-dire sous /var/lib/systemimager/images. Gardez sous le coude si_lsimage pour les voir, si_rmimage pour les supprimer et surtout si_getimage pour en rapatrier une (oui, aussi si_mvimage et si_cpimage mais pas besoin de vous expliquer ce que ça vaut).

Les overrides

Parce qu'on ne va pas stocker plusieurs systèmes de fichiers juste pour une différence de configuration sur une poignée de fichiers, SystemImager a défini la notion d'override. Les overrides concernent les customisations appliquées à une image en particulier, il y peut donc y avoir plusieurs overrides pour une image. De la même façon que les images ont un nom, les overrides en disposent également d'un. Les overrides contiennent une portion de l'arborescence du système de fichier, qui diffère de celle proposée par l'image, et qui viendra écraser celle issue de l'image originale après que celle-ci ait été mise en place.

ls overrides/ide/
boot/  etc/

On retrouve les overrides sous /var/lib/systemimager/overrides, et pour les pousser sur les nodes, il vous suffit d'un si_pushoverrides.

Fonctionnement

Voila commence ça se passe... Premièrement, vous avez dû monter, à la sueur de votre front, votre petit serveur DHCP/TFTP/SystemImager. Deux-trois tips sympa qui vous permettront d'avancer rapidement : - si_mkdhcpserver / si_mkdhcpstatic, qui va vous arquer sur la configuration d'un DHCP opérationnel, - si_mkbootserver, pour l'aspect PXE / TFTP, - /etc/systemimager/systemimager.conf, pour la conf. Et puis on attaque le gros œuvre !

From Scratch ! L'installation automatisée

Le plus pénible d'abord. Prenez votre GoldenClient et, gentillement, patiemment, installez-le et configurez au poil toutes les options qui vont bien. Saupoudrez de systemimager-common et de systemimager-client, vos petits outils qui vous sauveront une énorme quantité de temps. N'oubliez pas de customiser le /etc/systemimager/client.conf pour tout ce qui est port d'adressage, exclude,... si_prepareclient va vous permettre de lancer tout ce qui va bien -rsync, fichiers,... afin que votre server SystemImager puisse récupérer l'image. En clair, il déduit de la conf actuelle toutes les informations utiles, dont le partitionnement des disques.

$ si_prepareclient  --server kaster
Welcome to the SystemImager si_prepareclient command.  This command may modify
the following files to prepare your golden client for having it's image
retrieved by the imageserver.  It will also create the /etc/systemimager
directory and fill it with information about your golden client.  All modified
files will be backed up with the .before_systemimager-4.1.6 extension.

/etc/services:
This file defines the port numbers used by certain software on your system.
Entries for rsync will be added if necessary.

/tmp/filerNi0f5:
This is a temporary configuration file that rsync needs on your golden client
in order to make your filesystem available to your SystemImager server.

inetd configuration:
SystemImager needs to run rsync as a standalone daemon on your golden client
until it's image is retrieved by your SystemImager server.  If rsyncd is
configured to run as a service started by inetd, it will be temporarily
disabled, and any running rsync daemons or commands will be stopped.  Then,
an rsync daemon will be started using the temporary configuration file
mentioned above.

See "si_prepareclient --help" for command line options.

Continue? (y/[n]): y
*********************************** WARNING ***********************************
This utility starts an rsync daemon that makes all of your files accessible
by anyone who can connect to the rsync port of this machine.  This is the
case until you reboot, or kill the 'rsync --daemon' process by hand.  By
default, once you use si_getimage to retrieve this image on your imageserver,
these contents will become accessible to anyone who can connect to the rsync
port on your imageserver.  See rsyncd.conf(5) for details on restricting
access to these files on the imageserver.  See the systemimager-ssh package
for a more secure method of making images available to clients.
*********************************** WARNING ***********************************

Continue? (y/[n]): y

Signaling xinetd to restart...
...
Using "sfdisk" to gather information about disk:
/dev/sda

[...]
>>> Choosing filesystem for new initrd:  cpio
>>> Creating new initrd from staging dir:  /tmp/.systemimager.0
>> cd /tmp/.systemimager.0 && find . ! -name "*~" | cpio -H newc --create | gzip -9 > /etc/systemimager/boot/initrd.img
123093 blocks
>> ls -l /etc/systemimager/boot/initrd.img
-rw-r--r-- 1 root root 44150730 Jul  1 16:02 /etc/systemimager/boot/initrd.img

>> Evaluating initrd size to be added in the kernel boot options
>> (e.g. /etc/systemimager/pxelinux.cfg/syslinux.cfg):
>>     suggested value -> ramdisk_size=71786.5

>>> Using kernel from:          /boot/vmlinuz-2.6.31.13-server-1mnb
>> ls -l /etc/systemimager/boot/kernel
-rw-r--r-- 1 root root 2748752 Jul  1 16:02 /etc/systemimager/boot/kernel

Starting or re-starting rsync as a daemon.....
done!

This client is ready to have its image retrieved.  You must now run
the "si_getimage" command on your imageserver.

Your client has been successfully prepared.  Boot kernel (copied from
this Linux distribution) and an initrd.img (generated by the
initrd_template package) can be found in /etc/systemimager/boot.

Automatically create configuration file for systemconfigurator:
>> /etc/systemconfig/systemconfig.conf

Ici, le transport se fera par rsync, mais il est possible d'utiliser rsync over SSH, BitTorrent, multicast,... Switchez sur votre serveur SystemImager et lancez le si_getimage qui va bien, avec -golden-client et image en entrée. En optionnel, des options sur des exclusions, les assignements IP, le comportement postinstallation (reboot, beep, shutdown,...), bref, de quoi bien jouer. Une fois l'image rapatriée, et mise au frais, si_clusterconfig -e pour organiser votre cluster -tel node va avec telle image, tel overrides,... Pour la petite idée de ce à quoi ça ressemble :

<?xml version='1.0' standalone='yes'?>
<xml>
<master>kaster</master>
<name>absolutely_all_nodes</name>
<override>override_for_absolutely_all_nodes</override>
<group>
<name>kluster.knBSD.overBSD</name>
<priority>1</priority>
<image>knBSD</image>
<override>overBSD</override>
<node>knod1</node>
</group>
<group>
<name>kluster.kDeb.overDeb</name>
<priority>2</priority>
<image>kDeb</image>
<override>overDeb</override>
<node>knod2,knod3,knod4</node>
</group>
</xml>

Tous vos nodes paramétrés bien comme il faut dans votre SystemImager, il ne vous reste plus qu'à forcer leur boot réseau avec si_mkclientnetboot...

si_mkclientnetboot --client=knod2 --netboot
[netboot] using the kernel and initrd.img for architecture: i386
[netboot] using the flavor: standard

...Et de les rebooter en PXE. si_pushinstall prend alors le contrôle des choses et le server va tout simplement redescendre par SSH, brute de force, l'image sur le node.

Les synchronisations

Evidemment, je vous avais parlé de SystemImager en tant qu'outil de déploiement d'OS, oui, mais de logiciel également. En soi, le processus est le même, il s'agit d'une synchronisation -initiée par le serveur SystemImager à destination des nodes- entre l'image assignée au node et le système de fichier du node en lui-même. Ce qui diffère, ce sont les outils.

si_pushupdate

L'outil adapté à tout ce qui doit découler d'une mise à jour de l'image référente. si_pushupdate va, ici via rsync, transférer tout ce qui manque du server aux nodes. Vu que c'est du rsync, la gestion de la bande passante est optimisée -on ne redescend pas absolument toute l'image-, malgré tout, le multicast est, à mon avis, beaucoup plus adapté à ce genre de redescente, surtout si vous avez beaucoup de node à mettre à jour.

si_pushupdate --server kaster --hosts="knod2"
knod2 : ======================= WARNING =================================
knod2 :  This command will update this host with the image: kDeb
knod2 :  and overrides (in order of importance):
knod2 :
knod2 :  overDeb, override_for_absolutely_all_nodes
knod2 :
knod2 :  Some files could be deleted or overwritten, so probably it is a
knod2 :  good idea to run this command with --dry-run before and stop the
knod2 :  production on this host.
knod2 : ======================= WARNING =================================
knod2 :
knod2 : Are you sure to continue? (y / N)? y
knod2 : [...]
knod2 : Excluding (filesystem ext2): /tmp
knod2 : >> Updating image from module kDeb...
knod2 : receiving incremental file list
knod2 : deleting .readahead_collect
knod2 : sent 86986 bytes  received 23829894 bytes  621217.66 bytes/sec
knod2 : total size is 10895198915  speedup is 455.54
knod2 : >> Updating image from module overrides/override_for_absolutely_all_nodes...
knod2 : Running bootloader...Kernel /boot/...

si_pushoverrides

Comme son nom l'indique, il s'agit en réalité non pas d'aligner le node avec son image mais avec ses overrides.

si_pushoverrides -v knod2
Building clients list...
Grouping clients by common overrides...
WARNING: in case of file overlaps the overrides will be distributed using the following order (first hit wins):
WARNING: -->
Performing the updates...
>> si_pcp -v    -n knod2 /var/lib/systemimager/overrides/overDeb/ /
knod2 :/: sending incremental file list
[...]
knod2 :/: sent 898 bytes  received 203 bytes  734.00 bytes/sec
knod2 :/: total size is 2510  speedup is 2.28

Le monitoring

Monitorer un node revient, sous SystemImager, à se faire une idée d'où il en est au niveau de l'installation. Pour cela, SystemImager exploite grandement /var/lib/systemimager/clients.xml et met à disposition 2 outils, l'un étant la version graphique de l'autre, il s'agit de si_monitor et si_monitortk.

Conclusion

SystemImager apporte donc une réponse simple, complète et très satisfaisante aux besoins d'automatisation d'installation et de déploiement. De par ce fait, il est tout-à-fait dans la ligne de mire des exploitation en cluster, et se marie très bien avec des systèmes de répartition de charge dans des environnements de calcul, comme c'est le cas pour OSCAR, Torque, MAUI, et autres. Attention toutefois, car même s'il correspond également au besoin d'uniformisation dans un parc constitué de postes de travail, il peut s'avérer que la synchronisation provoque des problèmes d'incohérence et d'instabilité au niveau de l'environnement graphique ou du noyau, selon ce qui a été mis à jour. Il est donc sage de l'utiliser avec parcimonie quand vous êtes en première ligne face à vos utilisateurs. Il ne vous reste plus qu'à vous en faire une idée par vous-même, et, pourquoi pas, l'adopter !