Installation de SaltStack depuis Git

Afin de provisionner dans vSphere avec Saltstack, il faut utiliser la branche de developpement.

On commence donc par un git clone :

git clone https://github.com/saltstack/salt.git

Une fois cela fait, on se déplace dans le répertoire nouvellement créé par le git, puis on installe les prérequis. Comme les développeurs de Saltstack sont des mecs (peut être des filles aussi) sympas, ils fournissent des fichiers de prérequis. Il suffi donc de le donner a manger a pip :


sudo pip install -r _requirements.txt <= prerequis SaltStack
sudo pip install -r cloud-requirements.txt <= prerequis Salt-Cloud
sudo pip install -r zeromq-requirements.txt <= prerequis SaltStack
sudo pip install -r dev_requirements_python26.txt <= prerequis SaltStack
sudo pip install -r dev_requirements_python27.txt <= prerequis SaltStack

Puis on lance l’installation :
sudo python setup.py install
Enfin, on verifie que le salt-master est up-to-date :

salt-master --version
salt-master 2014.7.0 (Helium)

Ok, une fois Saltstack a la dernière version, on va s’attaquer à la partie la plus compliquée. Pourquoi compliquée ? Car autant les documentations de Saltstack sont complètes, autant celle concernant vSphere est inexistante et le peu qui existe contient des erreurs…

Je ne reviendrai pas sur la partie configuration du master et connexion des minions car tout ça est expliqué dans la documentation. Je vais me concentrer sur les modifications à apporter pour pouvoir provisionner dans vSphere.

Environnement

Mon environnement est le suivant :

Salt: 2014.7.0
Python: 2.7.5 (default, Mar 9 2014, 22:15:05)
Jinja2: 2.7.3
M2Crypto: 0.22
msgpack-python: 0.4.2
msgpack-pure: 0.1.3
pycrypto: 2.6.1
libnacl: Not Installed
PyYAML: 3.11
ioflo: 0.9.39
PyZMQ: 14.3.1
RAET: Not Installed
ZMQ: 4.0.4
Mako: 1.0.0
Apache Libcloud: 0.15.1

OS : MacOSX
VSphere version : 5.1

Configuration

Cloud Provider

Afin de provisionner dans des environement de type « cloud », Salt s’appuie sur des fichiers de configurations se situant dans le dossier suivant /etc/salt/cloud.providers (celui-ci est a creer).
Il est evident que l’on peut stipuler plusieurs providers et donc provisionner des machines dans n’importe quel « cloud » avec les memes states.
Je vais donc creer mon provider comme ceci :

/etc/salt/cloud.providers.d/vsphere.conf
my_provider:
   provider: vsphere
   user: 'administrator'
   password: 'My_Password'
   url: 'https://vcenter.domaine.tld/sdk'  <= attention ici, cela depend de la version du vcenter ainsi que de votre implementation. Je vous invite a aller sur le ce bug pour voir les différentes possibilités de configuration.

Puis redemarrer le salt-master.
A partir de ce point, on peut se connecter a notre vsphere et lister par exemple les templates mis a disposition :

sudo salt-cloud --list-images=all
Password:
[INFO ] salt-cloud starting
my_provider:
    ----------
    vsphere:
        ----------
        Centosx64:
            ----------
            Name:
                Centosx64
        Windows2k8r2:
            ----------
            Name:
                Windows2k8r2

Maintenant que l’on peut lister, on va provsionner 🙂

Provsionning

Cloud Profiles

Par defaut Salt va regarder les profiles de machines auquel il a accès dans le fichier suivant /etc/salt/cloud.profiles.
Pour ma part n’ayant que deux templates, je n’ai créé que deux profiles :

centos_vsphere:
   provider: les-titans
   image: Centosx64
   folder: Production
   resourcepool: resgroup-47
windows_vsphere:
   provider: les-titans
   image: Windows2k8r2
   host: cloud-02.domain.tld
   folder: Saltstack
   datastore: Datastore-02

Je ne vais pas m’étendre sur les options car elles sont toutes expliquées et bien documentées dans le fichier /Library/Python/2.7/site-packages/pysphere/vi_virtual_machine.py » a partir de la ligne 402. Le seul souci est la détection du MOR, c’est l’objet géré par vSphere via son API. Pour l’instant Salt-Cloud n’arrive pas a retrouver le MOR du resourcePool et uniquement de celui-ci (ne me demandez pas pourquoi).
Il faut donc aller se palucher la récupération de cette information a la main comme expliqué dans ce bug.

Enfin, on va pouvoir provisionner une ou plusieurs machines dans notre vSphere comme ceci ( en parallèle ou non, man salt-cloud 😉 ) :

sudo salt-cloud -p centos_vsphere web1
[INFO ] Creating Cloud VM web1 web2 web3
...
[DEBUG ] clone_kwargs are set to {'datastore': None,
'folder': 'Saltstack',
'host': None,
'name': 'web1',
'resourcepool': 'resgroup-47',
'template': False}
[DEBUG ] VM web1 is created, waiting for it to boot
[DEBUG ] Attempting function

Et voila, la ou les machines sont créés \o/ . Maintenant le Salt-Master va essayer de se connecter afin d’installer le salt-minion et intégrer les machines dans son trousseau Une fois cela fait, il ne reste plus qu’à balancer ses services dessus. Si c’est pas beau la vie !

Dans un autre article je vais expliquer comment créer des maps, ce qui permettra de provisionner un groupe de machines afin de monter rapidement des POC ou des infrastructures en un minimum de temps.

Références :
Cloud Profiles
Cloud Providers

 

A chaque version de Zimbra, de nouvelles fonctionnalités apparaissent sans que l’annonce soit faite.
Dans la version 7 de Zimbra, deux scripts ont fait leurs apparitions : vmware-appmonitor et vmware-heartbeat.
Le premier est l’exécutable développé par VMware permettant le dialogue avec l’hôte physique grâce aux vmware tools, le second est, quant à lui, un script de vérification applicatif. Dans notre cas celui-ci vérifie que les composants de Zimbra fonctionne correctement.
Si ceux-ci sont « OK » alors, le script renvoi à vSphere le statut « OK » via l’applicatif vmware-appmonitor.
Si un des services critique est « KO » alors le script renvoi l’erreur au vSphere qui au bout de 3 fois (paramétrage par défaut), redémarre la machine.

Attention, ne pas mettre en production ceci est à des fins de tests !

Mise en place

Dans un premier temps, vérifiez que votre cluster vSphere comprend bien l’option de surveillance d’application.

Puis connectez-vous a votre serveur Zimbra et exécutez les commandes suivantes :

1. sed -i -e '146 s/^/#/' -e '145 s/^#//' /opt/zimbra/libexec/vmware-heartbeat

2. echo "export LD_LIBRARY_PATH=/opt/zimbra/lib" >> /opt/zimbra/.bashrc

Explication

1. Par défaut le script de check retourne en permanence OK au vSphere, on modifie donc celui-ci pour qu’il exécute zmcontrol et retourne la bonne valeur.

2. Lorsque l’on exécute le scipt en tant qu’utilisateur Zimbra, celui-ci n’a pas le chemin vers les dépendances. On ajoute donc le chemin dans le PATH.

On peut maintenant lancer le script.

su - zimbra

/opt/zimbra/libexec/vmware-heartbeat start

Si l’on veut suivre l’exécution du script, on peut regarder dans /opt/zimbra/log/vmware-heartbeat.log. Si tout ce passe bien, alors vous aurez quelque chose comme ça :

Fri Jul  6 20:10:16 2012: Checking ZCS status
Fri Jul  6 20:10:25 2012: Sending heartbeat to VM

Nous allons provoquer un arret de service de Zimbra :
su - zimbra
ldap stop

Dans le fichier de log vous verrez que le service ne retourne rien, c’est au bout de trois fois que le script renvoi au vSphere de redémarrer la machine.

Unable to determine enabled services from ldap.
Enabled services read from cache. Service list may be inaccurate.
Mon Jul  9 01:37:47 2012: Checking ZCS status
Unable to determine enabled services from ldap.
Enabled services read from cache. Service list may be inaccurate.
Mon Jul  9 01:38:12 2012: Checking ZCS status
Unable to determine enabled services from ldap.
Enabled services read from cache. Service list may be inaccurate.

Au niveau du vSphere vous aurez l’erreur suivante :

Et le serveur sera redémarré dans la foulée !

Cette fonctionnalité est intéressante, mais n’est pas encore mure. En effet, elle vérifie l’intégralité  des services via la commande zmcontrol, celle-ci est relativement longue et c’est pour cela qu’elle est commenté dans le script d’origine.

Ce script nous montre un bout de ce que sera la prochaine version de Zimbra.