Provisioning dans vSphere avec SaltStack

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

 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *