L’objectif de cet atelier était de déployer une infrastructure de génération d’images fresh install avec l’outil SaltStack.
Le travail a été divisé en 3 sous-ateliers :
- Générer une image master depuis l’ISO EOLE ;
- Générer une image EOLE depuis une Ubuntu cloud ;
- Déployer et configurer une image master existante.
Voici le compte rendu du troisième et dernier sous-atelier.
Déployer et configurer une image master existante
L’objectif était déployer avec Salt Cloud une machine virtuelle (VM) dans OpenNebula qui fournira un service qu’il faudra décrire à l’aide de SaltStack.
L’expérimentation a été menée en parallèle sur deux instances d’OpenNebula :
- Un serveur Hâpy : OpenNebula + libvirt + qemu-kvm ;
- Un serveur OpenNebula orchestrant 2 VMWare.
Installation d’une infrastructure SaltStack fonctionnelle
Configuration manuelle de l’infrastructure client/serveur pour établir la connexion SaltStack entre le serveur et le client :
- installation de Salt Master sur un poste dédié ;
- déploiement manuel d’une machine virtuelle ;
- installation et configuration de la partie cliente de SaltStack (minion) ;
- intégration du minion dans le master.
Configuration du Salt Master opérationnel pour orchestrer OpenNebula
La commande salt-cloud nécessite une configuration de provider :
- configuration de la partie provider de SaltStack pour OpenNebula dans /etc/salt/cloud.poviders.d/one.conf ;
- le mot de passe de l’utilisateur pour OpenNebula est stocké en clair dans ce fichier.
Déploiement d’une VM avec salt-cloud
- création d’un modèle de VM avec salt-cloud à l’aide d’un fichier template adapté et inspiré d’un template OpenNebula existant ;
- création d’un profil SaltStack de VM dans /etc/salt/cloud.profiles.d/ ;
- déploiement avec salt-cloud d’une VM utilisant le profil et le modèle créés précédemment →La VM se déploie et installe le client minion.
Il faut tout de même prendre quelques précautions :
- prévoir l’utilisation d’un proxy ;
- lors du déploiement de notre VM (Ubuntu), le système se met à jour au boot et il y a un problème de lock dpkg.
Utilisation des salt states pour fournir un service
Nous sommes partis d’une image VM Ubuntu fraîchement installée pour fournir un service HTTP :
- description du service à fournir dans /ets/salt/apache/init.sls ;
- modification du profil de VM pour indiquer d’utiliser le state apache ;
- déploiement de la VM avec Salt Cloud, le service HTTP est opérationnel.
Inclusion de Salt States
Le but était de fournir un service HTTP avec un fichier index.html personnalisé :
- création d’un nouveau state web_static avec l’inclusion du state apache ;
- référencement dans le nouveau state du fichier index.html à déployer ;
- modification du profil de VM pour indiquer d’utiliser le state web_static.
Utilisation de variables
Le but est de fournir des services paramétrables.
L’utilisation des Pillars nécessite :
- la configuration de salt-master pour indiquer le chemin de ces fichiers pillar ;
- la création d’une arborescence de fichiers (pillar) pour décrire les variables.
Nous avons créé une variable tracert ayant pour valeur traceroute afin de déployer une VM avec le paquet traceroute installé :
- création d’un state tracert faisant référence à la variable pillar tracert ;
- modification du profil de VM pour indiquer d’utiliser le state tracert ;
- déploiement de la VM avec Salt Cloud, le paquet est installé dans la VM.
Conclusion
Nous n’avons pas pu aller plus loin dans l’utilisation de SaltStack.
Dans l’objectif que nous nous étions fixé, il nous restait encore à explorer l’utilisation de variables pour templatiser les fichiers de configuration des logiciels.