Cette solution utilise les outils suivants :
- Cobbler pour le provisioning du système d'exploitation via PXE, la gestion DHCP et DNS ;
- Puppet pour le provisioning des fichiers de configuration sur les différentes machines ;
- Subversion pour l'historisation des versions de la configuration.
Je ne reviendrai pas sur l'utilisation de Puppet et Subversion qui ont été couverts récemment dans GNU/Linux Magazine (cf. Bibliographie). Je connaissais déjà Subversion et l'article sur Puppet nous a permis de débuter sur la gestion de configuration centralisée. Cela nous a permis de gagner beaucoup de temps pour le déploiement des nouvelles machines et la distribution des modifications de configuration. Et, au passage, nous avons entamé une démarche basée sur les méthodologies ITIL (Information Technology Infrastructure Library) avec la création d'une CMDB (Configuration Management DataBase).
ITIL est un ensemble de bonnes pratiques recensées par l'Office Britannique du Commerce pour la bonne gestion d'un système d'information. Ces bonnes pratiques ont pour objectif d'aider un organisme (public ou privé) à améliorer la stabilité de son SI, d'en réduire les coûts et les risques. Néanmoins, il ne s'agit pas d'une méthode miracle, mais plutôt d'un regroupement de pratiques guidées par le bon sens et un pragmatisme très anglo-saxon. L'une des pierres angulaires de ces bonnes pratiques est la mise en œuvre d'une base de données (pas forcément au sens technique du terme ; n'imaginez pas cela comme une base MySQL) regroupant les informations de configuration du système d'information. La finesse du détail de ces informations n'est pas prédéfinie par ITIL et dépend surtout de la maturité de la DSI sur ITIL, ainsi que des besoins : nous pouvons y trouver aussi bien un inventaire du matériel et des logiciels que des procédures de gestion de workflow métiers (un wiki est souvent un composant simple de CMDB). Dans notre cas, nous commençons « petit » par un inventaire de notre matériel (Cobbler) et de la configuration des systèmes d'exploitation Linux (Puppet). Pour plus d'information sur ITIL, je vous conseille le site de l'itSMF France [0] (Association de promotion d'ITIL en France).
Introduction sur Cobbler
Pour faire court, Cobbler [1] est un outil permettant de centraliser les informations liées à vos machines et de les déployer simplement. Ce couteau suisse de l'installation de machines permet de relier facilement une machine à une distribution (Linux, mais pas seulement), des dépôts de packages (RPM, mais pas seulement), un serveur DHCP et un serveur TFTP pour le boot PXE, un serveur DNS et un serveur hébergeant des machines virtuelles. Quand je dis « relier », il faut comprendre qu'il est capable d'endosser tous ces rôles ou de simplement s'interfacer avec. Dans cet article, j'ai fait le choix de vous en montrer un maximum et donc de configurer Cobbler pour qu'il gère des miroirs de dépôts de packages, l'arborescence du serveur TFTP, la configuration DHCP et la configuration DNS. Pour cela, Cobbler stocke les informations dans ses fichiers et génère des fichiers de configuration pour ces services en utilisant des templates ; le moteur de rendu pour les templates est Cheetah [2].
Le schéma ci-dessous vous montre les interactions de Cobbler avec son environnement. La terminologie sera explicitée au fur et à mesure de l'article.
Cobbler est issu de la communauté Fedora. À ce titre, il a débuté en permettant le déploiement des distributions Fedora, RedHat et CentOS. Néanmoins, il supporte de plus en plus de distributions. Je vous invite donc à consulter le site du projet [3] pour en savoir plus. La suite de cet article a été réalisée sur CentOS 5.2.
1. Installation et configuration de Cobbler
1.1. Installation de base
Pour commencer, nous installons les packages nécessaires :
yum install cobbler
Cette commande installe un certain nombre de dépendances, dont :
- httpd : pour mettre à disposition dépôts, kickstarts... et fournir une interface d'administration
- tftp-server : pour mettre à disposition les images systèmes pour l'installation via PXE
- rsync : pour mettre à jour les dépôts basés sur rsync.
Pour que Cobbler puisse fonctionner, nous devons définir quelques éléments de configuration dans le fichier /etc/cobbler/settings. Le premier à positionner est le nom du serveur sur lequel le serveur est amené à fonctionner ; dans notre cas, il s'agit de cobbler.local :
sed -i '/^server:/s/:.*$/: cobbler.local/' /etc/cobbler/settings
Le second paramètre est le mot de passe par défaut du compte root, dans un format chiffré, pour l'installation des machines. Vous pouvez vous baser sur les mots de passe stockés dans le fichier /etc/shadow :
sed -i '/^default_password_crypted:/s/:.*$/: "mot_de_passe_chiffre"/' /etc/cobbler/settings
Si vous utilisez le firewall de votre serveur, il suffit des règles iptables suivantes (le port est configurable dans /etc/cobbler/settings via la variable xmlrpc_port) :
iptables -A INPUT -i lo -p tcp -m state --state NEW -dport 25151 -j ACCEPT
Il suffit maintenant de démarrer le service cobblerd :
service cobblerd start
chkconfig cobblerd on
Maintenant que Cobbler a démarré avec une configuration simple, nous allons ajouter les fonctionnalités qui font sa puissance.
1.2. Configuration du service DHCP
La première fonctionnalité que nous implémentons est la gestion du service DHCP. Pour cela, nous commençons par installer les packages nécessaires :
yum install dhcp
Nous modifions ensuite la configuration de Cobbler pour qu'il prenne en charge le service DHCP :
sed -i '/^manage_dhcp:/s/:.*$/: 1/' /etc/cobbler/settings
Cobbler est capable de gérer les serveurs DHCP ISC et dnsmasq. Il suffit de modifier une option dans /etc/cobbler/modules.conf. Par défaut, c'est le serveur ISC qui est pris en charge, et, ça tombe bien, c'est celui que nous avons installé.
Le principal fichier à modifier est /etc/cobbler/dhcp.template ; en effet, Cobbler utilise ce fichier pour générer le fichier /etc/dhcpd.conf. La principale modification à y apporter concerne les informations réseau que nous souhaitons utiliser : adresse et masque du sous-réseau, routeur par défaut, serveur(s) DNS... Si vous avez quelque peu l'habitude du fichier /etc/dhcpd.conf, vous vous y retrouverez facilement.
Une fois la configuration adaptée à nos besoins, il suffit de redémarrer Cobbler et de le synchroniser. La synchronisation a pour effet de générer les fichiers de configuration à partir de la configuration de Cobbler.
service cobblerd restart
cobbler sync
Vous pouvez constater que le fichier /etc/dhcpd.conf a été généré et que le service dhcpd a été démarré. Vous n'avez plus besoin de vous soucier de ce service. Il a été « cobblerisé ». Assurons-nous qu'il sera lancé au prochain démarrage du serveur :
chkconfig dhcpd on
La règle IPTables à appliquer est la suivante :
iptables -A INPUT -i eth0 -p udp --dport 67:68 --sport 67:68 -j ACCEPT
1.3. Configuration du service DNS
Le serveur DNS que nous allons utiliser est le célèbre Bind. Il nous suffit donc de l'installer :
yum install bind
Configurons maintenant Cobbler pour qu'il gère le service DNS. Cobbler sait gérer les serveurs DNS Bind et dnsmasq. Par défaut, il gère Bind et c'est tant mieux : ça nous fera ça de moins à configurer ;) (au besoin, cela se configure dans /etc/cobbler/modules.conf). Il suffit d'activer la gestion du DNS et d'indiquer les zones que nous voulons gérer dans le fichier /etc/cobbler/settings. Dans notre cas, la zone s'appelle local et la zone inverse correspondante 10.0.0.0/24 :
sed -i '/^manage_dns:/s/:.*$/: 1/' /etc/cobbler/settings
sed -i '/^manage_forward_zones:/s/:.*/: ["local"]/' /etc/cobbler/settings
sed -i '/^manage_reverse_zones:/s/:.*/: ["10.0.0"]/' /etc/cobbler/settings
De la même façon que pour le service DHCP, Cobbler s'appuie sur des templates : /etc/cobbler/named.template et /etc/cobbler/zone.template. Le premier fichier gère la configuration globale de votre serveur Bind et le second vous permet de personnaliser vos zones. Une méthode élégante pour gérer des zones complexes est l'utilisation du répertoire /etc/cobbler/zone_templates : si vous déposez un fichier dont le nom correspond au nom d'une zone gérée par Cobbler, ce fichier sera utilisé comme template pour cette zone. Dés lors, en vous basant sur le fichier /etc/cobbler/zone.template, vous pouvez créer des fichiers plus complexes gérant les enregistrements CNAME, SRV, MX... Il suffit de les ajouter à la fin du fichier de template. Nous allons d'ailleurs utiliser cette méthode pour gérer notre zone local (cela n'est pas nécessaire pour les zones inverses) :
mkdir /etc/cobbler/zone_templates
cp /etc/cobbler/zone.template /etc/cobbler/zone_templates/local
Comme nous avons modifié le fichier /etc/cobbler/settings, nous devons redémarrer le service cobblerd, puis nous synchronisons Cobbler pour qu'il génère les fichiers de configuration :
service cobblerd restart
cobbler sync
Vous constater que, cette fois-ci, le service named a été démarré lors de la synchronisation. Vous pouvez aussi vérifier que la configuration est correcte dans les fichiers /etc/named.conf, /var/named/local et /var/named/10.0.0. Assurons-nous que le service sera lancé au prochain démarrage :
chkconfig named on
La règle IPTables à appliquer est la suivante :
iptables -A INPUT -i eth0 -d cobbler.local -p tcp -m state --state NEW --dport 53 -j ACCEPT
Les plus paranoïaques (dont je fais partie) auront pris soin de modifier /etc/cobbler/named.template pour que le service n'écoute que sur l'adresse IP du serveur.
1.4. Configuration du service TFTP
Le prochain service à configurer est le service TFTP. Cette fois, les packages utiles ont déjà été installés par Cobbler : tftp-server et xinetd. En effet, tftp-server n'est pas lui-même à l'écoute des requêtes. C'est xinetd qui les lui transmet.
Nous devons donc faire en sorte que le service xinetd accepte les requêtes TFTP et qu'il soit lancé au démarrage du serveur. Et ensuite, nous pouvons ajouter l'adresse du serveur TFTP dans la configuration de Cobbler (/etc/cobbler/settings) :
sed -i "/disable/s/= yes/= no/" /etc/xinetd.d/tftp
sed -i '/^next_server:/s/:.*/: cobbler.local/' /etc/cobbler/settings
service xinetd start ; chkconfig xinetd on
service cobblerd restart
cobbler sync
La règle IPTables à appliquer est la suivante :
iptables -A INPUT -i eth0 -d cobbler.local -p udp --dport 69 -j ACCEPT
Comme pour le service DNS, il est possible de limiter l'adresse d'écoute en ajoutant la ligne bind = cobbler.local au fichier /etc/xinetd.d/tftp.
1.5. Configuration du service HTTP
Le dernier composant à configurer est le serveur web Apache pour qu'il fournisse un accès API de Cobbler, ainsi qu'aux dépôts de packages. Cobbler s'appuie sur des webservices implémentés en Python et fournit deux fichiers de configuration pour le serveur Apache : /etc/httpd/conf.f/cobbler.conf et /etc/httpd/conf.f/cobbler_svc.conf. Par défaut, Apache inclut tous les fichiers du répertoire /etc/httpd/conf.d ; il n'est donc pas nécessaire de modifier la configuration d'Apache. Il suffit donc de démarrer Apache et de faire en sorte qu'il soit lancé au prochain démarrage du serveur :
service httpd start
chkconfig httpd on
La configuration d'un serveur Apache n'est pas l'objet de cet article, mais je vous conseille de vous plonger dans la documentation plutôt fournie disponible sur le site httpd.apache.org. Vous y apprendrez comment limiter l'accès à votre serveur, cloisonner l'application Cobbler dans un VirtualHost...
La règle IPTables à appliquer est la suivante :
iptables -A INPUT -i eth0 -d cobbler.local -p tcp -m state --state NEW --dport 80 -j ACCEPT
2. Injection massive de données dans Cobbler
Au cours des étapes précédentes, nous avons monté le squelette de Cobbler, et configuré les services qu'il gère. Nous allons pouvoir nous attaquer au peuplement de l'application. En effet, pour que Cobbler montre toute sa puissance, rien de mieux que de le voir en action.
Dans le monde de Cobbler, il existe 4 types d'objets principaux :
- Les dépôts qui sont des arborescences contenant des packages. Les utilisateurs Fedora connaissent bien le dépôt RPMFusion qui fournit, entre autres, des packages de logiciels non libres, et le dépôt « updates » qui contient les mises à jour.
- Les distributions qui correspondent aux médias d'installation. Une distribution est un instantané des packages d'un dépôt correspondant à une release du système d'exploitation.
- Les systèmes qui sont les descriptifs des machines gérées par Cobbler. On y trouve par exemple l'adresse MAC utilisée pour générer la configuration DHCP.
- Les profils qui font le lien entre tous ces éléments. Un profil est un ensemble de propriétés communes à plusieurs systèmes qui permettent de les grouper ; parmi ces propriétés, on trouve la distribution, le(s) dépôt(s) et le fichier Kickstart à utiliser pour installer le système.
- Les données à installer en priorité sont donc les dépôts et les distributions qui nous permettront d'installer des machines. Et, comme le volume de données peut vite être important, commençons rapidement...
2.1. Import du dépôt Updates de Centos 5.2 64bits
Comme il s'agit de l'opération la plus longue, nous commençons par ajouter un dépôt de packages RPM. Un mode de fonctionnement classique est d'utiliser notre serveur Cobbler comme un miroir local des dépôts officiels afin de limiter la consommation de bande passante lors des installations et mises à jour (ce qui est vraiment utile quand on a plusieurs dizaines de machines). Il est néanmoins possible de fournir simplement l'URL du dépôt (Cobbler gère plusieurs protocoles : HTTP, RSYNC...) avec l'option --mirror-locally=N pour que Cobbler ne fasse que référencer cette URL et l'intègre à la configuration des machines. Dans notre exemple, nous allons au bout du concept et nous créons un miroir du dépôt CentOS 5.2 - x86_64 - Updates ; les commandes sont assez explicites :
cobbler repo add --name=centos-5.2-server-x86_64-updates \
--mirror=http://ftp.free.fr/mirrors/ftp.centos.org/5.2/updates/x86_64/ \
--mirror-locally=Y
Si vous pensez manquer d'espace sur la partition contenant /var/www/cobbler, je vous conseille fortement de lire cette page du wiki [4] pour déplacer les données de Cobbler sans tout casser ; un déplacement de répertoire et un lien symbolique suffisent... alors n'hésitez pas.
Nous avons donc déclaré le dépôt ; il ne reste plus qu'à lancer la synchronisation :
cobbler reposync
En fonction du nombre de dépôts que vous avez déclarés et surtout de leur volume, l'opération peut prendre beaucoup de temps. Dans mon cas, le dépôt représente 3,8 Go sur disque et le téléchargement a pris environ 3 heures (c'est pas si mal). Bien entendu, nous souhaitons automatiser cette synchronisation pour rester à jour ; il suffit de rajouter une tâche cron à la fréquence qui vous convient (perso, une fois par semaine me convient) :
cat > /etc/cron.weekly/cobbler_reposync << EOF
#!/bin/bash
cobbler reposync --tries=3 --no-fail
EOF
chmod 0755 /etc/cron.weekly/cobbler_reposync
2.2. Import de la distribution CentOS 5.2 64bits
Nous avons installé notre serveur à partir du DVD de la distribution CentOS en version 64 bits et nous synchronisons le dépôt Updates associé. Alors, nous allons continuer sur cette voie pour notre exemple. Il existe une commande d'import qui prend en argument le nom que nous souhaitons donner à la distribution et le chemin dans lequel est stocké l'arborescence. Sur mon serveur, l'automount des médias amovibles est activé et il m'a donc suffi de lancer la commande suivante :
cobbler import --name=centos-5.2-server-x86_64 --mirror=/media/CentOS-5.2-x86_64-bin-DVD
L'opération n'est pas très longue et si vous êtes un peu habitué aux dépôts RPM (ou si vous avez regardé ce qui défile à l'écran lors de la synchronisation des dépôts), vous remarquerez que le chemin vers le contenu de la distribution est traité comme un dépôt. A la fin de l'importation, Cobbler analyse la structure du « dépôt » et crée automatiquement un (des) profil(s) pour cette distribution :
cobbler profile list
centos-5.2-server-x86_64
centos-5.2-server-xen-x86_64
Ces profils ne sont pas complets, mais forment un bon point de départ. Nous allons d'ailleurs tout de suite voir comment les enrichir. Au passage, vous remarquez qu'un profil xen a été créé. Il nous servira plus tard.
2.3. Personnalisation d'un profil
Les profils générés à l'import d'une distribution ont comme principal défaut de ne connaître que la distribution dont ils sont issus. Mais, nous ne pouvons pas leur en vouloir pour ça et nous allons les aider à s'améliorer. Tout d'abord, regardons les informations stockées dans un profil, à l'aide d'une option que vous trouverez assez vite indispensable :
cobbler profile report --name=centos-5.2-server-x86_64
profile : centos-5.2-server-x86_64
distro : centos-5.2-server-x86_64
...
kickstart : /var/lib/cobbler/kickstarts/default.ks
...
repos : []
...
Pour plus de lisibilité, j'ai limité le contenu affiché aux champs qui vont nous intéresser immédiatement. Les autres viendront plus tard. Chaque chose en son temps...
Nous observons donc que le champ distro a pour valeur le nom de la distribution dont le profil est issu (c'est rassurant) et qu'un fichier Kickstart est associé au profil. Par contre, aucun dépôt n'est associé. Nous remédions donc tout de suite à cela :
cobbler profile edit --name=centos-5.2-server-x86_64
--repos='centos-5.2-server-x86_64-updates'
Cette commande relativement simple a ajouté les deux dépôts dont nous sommes miroir. Notez simplement la syntaxe : lorsqu'un champ contient une liste de valeurs, il faut les mettre entre quotes et les séparer par une espace. Et nous pouvons vérifier le résultat :
cobbler profile report --name=centos-5.2-server-x86_64
profile : centos-5.2-server-x86_64
distro : centos-5.2-server-x86_64
...
kickstart : /var/lib/cobbler/kickstarts/default.ks
...
repos : [u'centos-5.2-server-x86_64-updates']
...
Les petits curieux seront déjà allés fouiller dans /var/lib/cobbler/kickstarts pour voir à quoi ressemble le fichier Kickstart associé au profil et ils sont probablement un peu déçus : en effet, le fichier default.ks ne contient aucune instruction. Bien sûr, les plus néophytes d'entre vous s'inquiètent, mais, soyez tout de suite rassurés. Il y a dans ce même répertoire un fichier Kickstart d'exemple qui est complètement fonctionnel : sample.ks. Je ne vous en expliquerai pas la syntaxe, car cela pourrait faire l'objet de deux articles (un sur Kickstart [5] et l'autre sur Cheetah (le moteur de templates utilisé)). Nous allons simplement faire en sorte que notre profil soit associé à ce Kickstart. Pour cela, il y a deux possibilités : renommer sample.ks en default.ks ou modifier le profil pour pointer sur sample.ks. Personnellement, j'utilise la première méthode, car le nom default.ks correspond parfaitement à mon besoin : un profil basique utilisable pour n'importe quelle machine, mais la seconde méthode est plus didactique :
cobbler profile edit --name=centos-5.2-server-x86_64 \
--kickstart=/var/lib/cobbler/kickstarts/sample.ks
Nous avons à présent un profil utilisable pour installer des machines. Il ne nous reste plus qu'à déclarer lesdites machines dans Cobbler. Comme j'aime bien la récursivité, je vais vous montrer comment déclarer le serveur sur lequel est installé Cobbler. En effet, il est basé sur la distribution et le dépôt que nous avons intégrés dans Cobbler. C'est parti !
2.4. Ajout du système cobbler.local
L'un des objectifs de Cobbler étant de centraliser les informations réseau de nos machines, la déclaration d'un système comporte nécessairement des informations sur ses caractéristiques réseau. Les caractéristiques système sont principalement liées au profil. Ainsi, la déclaration de notre serveur donne :
cobbler system add --name=cobbler --profile=centos-5.2-server-x86_64 \
--interface=eth0 --mac=00:1a:4d:59:21:d7 --static=1 \
--ip=10.0.0.11 --subnet=255.255.255.0 --gateway=10.0.0.2 \
--dns-name=cobbler.local --hostname=cobbler
Si nous décortiquons cette belle ligne de commande, nous retrouvons :
- la configuration du profil (et donc de la distribution, des dépôts et du fichier Kickstart) via l'option –profile ;
- la configuration DHCP via les options --hostname, --mac, --ip, --subnet et --gateway ;
- la configuration DNS via les options --dns-name et --ip.
Notre serveur est maintenant déclaré (la commande cobbler system report cobbler vous permet de le vérifier). Il ne manque plus que la génération des fichiers de configuration pour les différents services gérés par Cobbler :
cobbler sync
Vous pouvez constater dans /etc/dhcpd.conf et /var/named/local que la configuration du serveur a bien été intégrée dans les configurations des différents services, qui ont d'ailleurs été rafraîchis par Cobbler. Si vous rebootez le serveur en mode PXE, il sera réinstallé, mais ce n'est pas forcément ce que nous voulons. Je vous donne donc un tuyau pour éviter qu'une machine configurée dans son BIOS (ou sa ROM) pour démarrer en mode PXE ne boucle indéfiniment sur l'installation
cobbler system edit --name=cobbler --netboot-enabled=N
...et la page de man et le wiki renferment d'autres astuces utiles.
Bien, maintenant que vous avez une petite idée de ce que l'on peut faire avec Cobbler, faisons entrer en piste son colocataire : Koan...
3. (Ré)Installation d'un système
Vous savez déclarer une machine physique dans Cobbler et faire en sorte qu'elle démarre. Jusque-là, tout va bien. Mais aujourd'hui, votre patron vous demandera de vous pencher sur « les possibilités de rationalisation des coûts de production du système d'information au travers de la virtualisation » et vous vous lancerez dans la mise en production de gros serveurs avec plein de CPU et de mémoire pour héberger vos services dans des machines virtuelles. Et comme vous avez quand même un peu votre mot à dire sur le sujet, vous partez sur une solution basée sur Xen (disponible sur toutes les distributions Linux (ou presque))... Eh bien, Koan va vite devenir votre ami.
Vous pourrez aussi vous pencher sur KVM qui est intégré au noyau Linux depuis la version 2.6.20. Néanmoins, j'ai préféré rester sur Xen, car la distribution RedHat (pas mal utilisée en production (sans chercher de Troll)) n'a pas encore intégré KVM, pour des raisons de support du noyau, freezé en version 2.6.18.
Koan est un outil qui permet sur une machine cliente de réaliser des tâches liées au déploiement en utilisant les données de Cobbler. Ses fonctionnalités sont :
- l'installation de machines virtuelles sur un serveur hôte au travers de libvirt. Koan récupère les caractéristiques de la machine virtuelle à installer et s'appuie sur la libvirt pour la créer et l'installer automatiquement.
- la réinstallation d'une machine depuis cette même machine : Koan s'appuie sur les caractéristiques de la machine (physique ou virtuelle) pour générer une entrée Grub qui réinstallera la machine. C'est le pendant du boot PXE, mais pour une machine disposant d'un Grub fonctionnel.
Dans la suite, nous allons installer une machine virtuelle via Koan, puis la réinstaller, pour voir ces deux fonctionnalités en action.
3.1. Mise en place de Koan et des outils de virtualisation
Pour que cela puisse fonctionner, nous allons avoir besoin des outils de virtualisation. Leur installation est particulièrement simple :
yum install xen libvirt
chkconfig libvirtd on ; chkconfig xend on
vi /boot/grub/grub.conf
reboot
Pour Koan, l'installation est tout aussi simple :
yum install koan
Et voilà, vous avez tout ce dont vous avez besoin pour créer des machines virtuelles avec Koan.
3.2. Ajout du système virtuel dans la configuration
Si vous regardez la configuration des profils centos-5.2-server{,-xen}-x86_64 créés à l'import de la distribution, vous constaterez qu'il y a des champs commençant par virt. Ces champs sont les informations pour générer des machines virtuelles :
cobbler profile report --name=centos-5.2-server-xen-x86_64
profile : centos-5.2-server-xen-x86_64
...
virt bridge : xenbr0
virt cpus : 1
virt file size : 5
virt path :
virt ram : 512
virt type : xenpv
Les noms des champs sont explicites, mais je vais quand même vous les détailler un peu. Le champ virt type indique quel type de virtualisation utiliser : xenpv correspond à l'utilisation de Xen. Le champ virt bridge indique quel bridge virtuel utiliser pour relier nos machines virtuelles à la machine hôte : xenbr0 est le bridge par défaut créé par Xen. Les champs virt cpus et virt ram indiquent respectivement le nombre de processeurs et la quantité de mémoire à attribuer à la machine virtuelle ; par défaut, nous attribuons 1 processeur et 512 Mo de mémoire. Les champs virt file size et virt path indiquent la taille et l'emplacement du disque virtuel à attribuer à la machine virtuelle : par défaut, le système se voit attribuer 5 Go d'espace et le chemin n'est pas précisé pour que cela soit spécifié système par système.
Il s'agit des valeurs par défaut et nous allons les modifier un petit peu. Nous allons réduire la quantité de mémoire à 256 Mo, la taille du disque virtuel à 4 Go et spécifier un chemin par défaut pour stocker les disques virtuels.
cobbler profile edit --name=centos-5.2-server-xen-x86_64 \
--virt-ram=256 --virt-file-size=4 \
--virth-path=/var/lib/libvirt/images
La commande cobbler profile report centos-5.2-server-xen-x86_64 vous permet de vérifier que c'est appliqué. Nous pouvons maintenant associer un système virtuel :
cobbler system add --name=vmtest --profile=centos-5.2-server-xen-x86_64 \
--interface=eth0 --mac=ff:00:00:01:00:00 --static=1 \
--ip=10.0.0.100 --subnet=255.255.255.0 --gateway=10.0.0.2 \
--dns-name=vmtest.local --hostname=vmtest
Vous constatez que la déclaration est quasi identique à celle d'une machine physique. La seule différence se situe au niveau de l'adresse MAC qui est positionnée arbitrairement hors des adresses officielles (les adresses commençant par ff: n'ont pas été attribuées par l'IEEE). Personnellement, j'utilise les trois champs suivants pour identifier la machine (16777216 machines possibles !), le 5ème champ pour le numéro d'interface (00 pour eth0) et le 6ème champ pour le numéro d'interface fille (00:00 pour eth0, 00:01 pour eth0:1...), mais vous pouvez faire comme vous voulez...
Si vous regardez la configuration du système nouvellement déclaré, vous constatez que les champs virt ont pour valeur <<inherit>>. Cela vient du fait que notre déclaration de système n'a pas surchargé les valeurs définies dans le profil ; elles sont donc identiques à celles que nous avons positionnées dans le profil, ce qui tombe bien.
cobbler system report --name=vmtest
system : vmtest
profile : centos-5.2-server-xen-x86_64
...
virt cpus : <<inherit>>
virt file size : <<inherit>>
virt path : <<inherit>>
virt ram : <<inherit>>
virt type : <<inherit>>
...
interface : eth0
...
virt bridge :
Seul virt bridge n'est pas positionné et c'est parce que Cobbler ne souhaite pas relier l'interface au réseau sans que nous le spécifiions explicitement. Nous aurions pu le faire à la déclaration du système ; nous le corrigeons a posteriori très simplement :
cobbler system edit --name=vmtest \
--interface=eth0 --virt-bridge=xenbr0
cobbler sync
Nous sommes maintenant prêt à installer la machine virtuelle.
3.3. Installation du système virtuel via Koan
Je vous préviens tout de suite, ce n'est impressionnant que par sa simplicité :
koan --server=cobbler.local --system=vmtest --virt --nogfx
Cette commande indique à koan de se connecter au serveur cobbler.local, de récupérer les informations du système vmtest et de l'installer comme une machine virtuelle (--virt) sans périphérique d'affichage graphique (--nogfx). À l'écran, vous verrez quelques messages indiquant que le disque dur virtuel est créé, que le noyau et l'inirtd sont récupérés et que la machine virtuelle a démarré. Pour vous connecter à la console de cette machine virtuelle, il vous suffit de taper virsh console vmtest. Vous verrez défiler l'installation du système basée sur le Kickstart déclaré dans le profil.
3.4. Réinstallation du système via Koan
Allons un peu plus loin ! Vous avez écrit un fichier Kickstart qui installe de manière complètement automatisée un serveur Web (via des scripts de post-installation, par exemple) et vous voulez le tester sur la machine vmtest. Vous pouvez soit arrêter la machine virtuelle, la supprimer et la recréer comme vu précédemment, soit la réinstaller depuis elle-même. Pour cela, il vous suffit d'installer Koan sur vmtest et lancer la commande suivante :
koan --server=cobbler.local --system=vmtest --replace-self
Cette commande ajoute une ligne dans /boot/grub/grub.conf indiquant au système que, au prochain boot, il devra démarrer en utilisant le Kickstart déclaré dans le profil associé à vmtest. Cette méthode est aussi valable pour des machines physiques. Remasteriser un serveur devient dès lors un jeu d'enfant.
4. Pour aller plus loin
Comme indiqué en introduction, Cobbler peut se coupler à Puppet via le mécanisme d'External Nodes disponible dans Puppet. Ce mécanisme consiste à déporter la définition des nodes de Puppet dans une entité externe ; Cobbler implémente ce mécanisme au travers de l'attribut --mgmt-classes qui permet d'affecter des classes Puppet au système. Une page du wiki est dédiée [6] à l'implémentation de ce mécanisme. Je vous conseille vivement de parcourir le wiki qui répond à de nombreuses questions : gestion multi-réseau du DHCP, installation à partir d'images ISO (Windows par exemple), génération de CD/DVD à partir d'un profil...
Je vous parlais aussi en introduction de l'utilisation de Subversion pour gérer les versions de notre configuration. Nous avions déjà des dépôts Subversion pour certains projets internes et nous avons donc continué avec Subversion. Pour cela, il nous a suffi de versionner les répertoires /etc/cobbler et /var/lib/cobbler qui contiennent la configuration de Cobbler (pour Puppet, il faut versionner /etc/puppet).
Je tiens néanmoins à vous signaler une option de Cobbler permettant de versionner automatiquement la configuration avec Git [7] : positionner à 1 la variable scm_track_enabled dans le fichier /etc/cobbler/settings. Comme l’indique le commentaire figurant dans le fichier, cette option « active un trigger qui versionne tous les changements dans /var/lib/cobbler quand une opération d'ajout, d'édition ou de synchronisation est effectuée. Cela peut être utilisé pour faire un retour à des versions précédentes de la base de données, générer des flux RSS ou pour des besoins d'audit ou de sauvegarde. Git est le système de Gestion de Configuration Logicielle (Software Configuration Management (SCM) en anglais) recommandé pour cette fonctionnalité ». Il vous suffit donc d'installer Git (yum install git) et d'activer cette option.
Bibliographie
[0] Le site de l'itSMF : http://www.itsmf.fr/
[1] Site officiel de Cobbler : https://fedorahosted.org/cobbler/
[2] Cheetah website : http://www.cheetahtemplate.org/
[3] Cobbler : Support for other distros : https://fedorahosted.org/cobbler/wiki/SupportForOtherDistros
[4] Cobbler : Relocating your install : https://fedorahosted.org/cobbler/wiki/RelocatingYourInstall
[5] RedHat Documentation - Kickstart Installations : http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/ch-kickstart2.html
[6] Cobbler : Using Cobbler With ConfigManagement System : https://fedorahosted.org/cobbler/wiki/UsingCobblerWithConfigManagementSystem
[7] Article sur Puppet : « Les sysadmins jouent à la poupée », GLMF n°112.
[8] Article sur Subversion : « Gardez l'historique des changements de /etc grâce aux outils de suivi de version (svn, svnk) », GLMF n°115.
