Script on Zwindler's Reflection

Déployer des machines virtuelles avec Ansible (VMware)

Tue, 20 Jun 2017 11:30:10 +0000

Déployer des VMs via Ansible ?

Depuis que j’automatise tout ce qui peut l’être sur mes machines virtuelles avec l’aide d’Ansible, il y avait une corde qui manquait encore à mon arc.

Jusqu’à présent, j’utilisais Ansible simultanément en tant qu’outil de déploiement de logiciel et aussi comme logiciel de « Configuration Management ».

Je m’explique :

A partir d’un template de machine virtuelle, je suis capable de déployer une configuration par défaut en fonction du rôle de la machine (au sens large du terme, que ce soit des fichiers ou de l’installation de packages).
Si jamais une modification de la configuration est faite, je suis capable de « pousser » cette modification sur toutes les machines d’un seul coup.
Et enfin, si jamais des modifications ont été réalisées (par exemple en cas d’erreur) sur une partie de mes machines, je suis capable de « corriger » tous les serveurs « non-compliant » SANS TOUCHER à ceux qui le sont (car mes playbooks sont idempotent, comme mon module pour centreon).

Pour autant, j’étais frustré de ne pas avoir encore trouvé le moyen d’aller encore un peu plus loin : provisionner les machines directement depuis Ansible.

Pourquoi ça coince

2 obstacles majeurs m’empêchaient d’aller au bout de la démarche.

Gather facts

D’abord parce que par défaut, si vous donnez une liste de serveurs à Ansible dans votre inventaire avec pour but de les déployer, Ansible va tenter de les se connecter à ces machines… qui n’existent pas encore !

ansible-playbook -l 192.168.100.103 zwindler_deploy.yml
PLAY [xxxxxxaaaaaaaaaaa] ********************************************************************************************************************************************************************
TASK [Gathering Facts] **********************************************************************************************************************************************************************
fatal: [192.168.100.103]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host 192.168.100.103 port 22: No route to host\r\n", "unreachable": true}
PLAY RECAP **********************************************************************************************************************************************************************************
192.168.100.103 : ok=0 changed=0 unreachable=1 failed=0

Dans ce cas précis, il faut donc dire à Ansible de ne pas essayer de s’y connecter dans un premier temps. J’ai mis un moment à trouver. Dans certains cas (comme pour alimenter un serveur centreon avec CLAPI), j’ai utilisé la fonction delegate_to.

Mais le mieux dans le cas présent consiste à utiliser les options suivantes au début de votre playbook :

gather_facts: false
connection: local

Grâce à ces deux options, vous pourrez indiquer à Ansible de ne pas faire l’opération gather_facts, étape préliminaire à l’exécution de tout playbook, et de ne même pas essayer de se connecter sur les futurs serveurs mais de tout exécuter localement.

Problem solved.

vsphere_guest versus vmware_guest

Mon deuxième problème était qu’il existe 2 groupes de modules pour VMware dans les modules Ansible, et que l’un des deux est abandonné ! Et bien sûr comme c’est le plus ancien, c’est celui qui remonte le plus dans les exemples/articles sur Internet ;-).

Dans un premier temps, j’avais fais des tests avec vsphere_guest. Bien que « fonctionnel », ce module intégré à la suite Ansible en version 1.6 nécessite en dépendance python et surtout pysphere. Or, pysphere n’est plus maintenu depuis 2013 !

Dans l’absolu, on peut très bien utiliser vsphere_guest pour provisionner des machines virtuelles. La dernière version normalement pour vSphere 5.0 fonctionne parfaitement sur vSphere 6.X. Un très bon exemple de ce que vous pouvez faire avec ce module est expliqué dans un article de EverythingShouldBeVirtual.

Pour autant, vous ne pourrez pas :

Réaliser de modifications sur la machine virtuelle si vous la copiez depuis un template
Réaliser des customisations côté OS

Personnellement, je travaille massivement avec des templates, qui sont ensuite agrémentés par des customisations via des playbooks Ansible. Mais j’ai besoin de customiser ces templates en fonction du contexte et je rechigne à faire la modification en 2 étapes. De plus, une fois déployée, j’ai quand même besoin de passer manuellement sur chacune des machines pour leur donner une adresse IP et un hostname unique par exemple.

Heureusement, VMware ne s’est pas contenté du VIPerl et de PowerCLI ! Depuis quelques années, il existe un module Python, maintenu par VMware, et qui est régulièrement étendu avec les nouvelles fonctionnalités de l’API : pyvmomi.

A partir de cet API python, un module Ansible plus récent a donc été créé, et vous allez le voir, les possibilités sont bien plus étendues.

Et la lumière fut

La liste des modules Ansible qui utilisent le module pyvmomi est assez impressionnant. Il s’agit de tous les modules qui commencent par vmware_ (vous pouvez trouver la liste sur la documentation officielle d’Ansible, dans la section VMware).

Deux d’entre eux ont particulièrement retenus mon attention, même s’il y en a plein d’autres intéressants :

vmware_guest qui permet de gérer les machines virtuelle
vmware_vm_shell qui permet d’exécuter des commandes directement sur l’OS invité de la VM (si elle dispose des VMware Tools)

Prérequis

Pour exécuter ces modules, vous avez besoin de 2 choses :

pyvmomi et ces dépendances (python 2.6+ et sphinx)

pip install pyvmomi sphinx

Ansible 2.2 minimum (mais plutôt 2.3 voire 2.4 !)

Sur le papier, le module « fonctionne » avec Ansible 2.2, l’actuelle version stable que vous pourrez trouvez sur tous les dépôts. Sauf que la plupart des fonction intéressantes n’apparaissent qu’avec la version 2.3 d’Ansible, pour l’instant uniquement disponible si vous compilez les sources !~~

La version disponible en ce moment est la 2.3.1. Il n’est donc plus nécessaire de compiler les sources, SAUF si vous voulez utiliser les nouvelles fonctionnalités du modules introduites dans la 2.4. Je laisse la procédure de compilation en fin d’article.

Et maintenant le playbook !

Voici un exemple de playbook qui :

Prompte pour un mot de passe administrateur pour se connecter au vCenter
Déploie une machine virtuelle depuis template

Ce déploiement dépend d’un certain nombre de variables qui peuvent être renseignées dans le fichier hosts tels que :

la taille du disque virtuel
le nombre de vCPU
la quantité de vRAM
l’ESXi ou le datastore destination
l’adresse IP de la VM
Une fois la VM créée, l’adresse IP et le hostname est configurée dans l’OS invité

cat zwindler_vmware_add_normal.yml
---
- hosts: all
gather_facts: false
connection: local
vars_prompt:
- name: "vsphere_password"
prompt: "vSphere Password"
- name: "notes"
prompt: "VM notes"
private: no
default: "Deployed with ansible"
tasks:
# get date
- set_fact: creationdate="{{lookup('pipe','date "+%Y/%m/%d %H:%M"')}}"
# Create a VM from a template
- name: create the VM
vmware_guest:
hostname: '{{ vsphere_host }}'
username: '{{ vsphere_user }}'
password: '{{ vsphere_password }}'
validate_certs: no
esxi_hostname: esxi_server
datacenter: 'ZWINDLER'
folder: A_DEPLOYER
name: '{{ inventory_hostname }}'
state: poweredon
guest_id: rhel7_64Guest
annotation: "{{ notes }} - {{ creationdate }}"
disk:
- size_gb: 150
type: thin
datastore: '{{ vsphere_datastore }}'
networks:
- name: server_network
ip: '{{ custom_ip }}'
netmask: 255.255.252.0
gateway: 192.168.100.1
dns_servers:
- 192.168.100.10
- 192.168.101.10
hardware:
memory_mb: 4096
num_cpus: 2
customization:
dns_servers:
- 192.168.100.10
- 192.168.101.10
domain : zwindler.fr
hostname: '{{ inventory_hostname }}'
template: tmpl-rhel-7-3-app
wait_for_ip_address: yes
- name: add to ansible hosts file
lineinfile:
dest: /etc/ansible/hosts
insertafter: '^\[{{ ansible_host_group }}\]'
line: '{{ inventory_hostname }}'

A partir là, vous pouvez tout faire :)

Juste une petite limitation que je n’ai malheureusement pas encore pu contourner : à la suite de la création de la VM, vous ne pourrez pas « enchainer » sur un autre playbook (par exemple pour vous connecter sur la machine pour ajouter un service). Vous devrez passez par un second playbook.

La raison principale à ceci est qu’on a spécifié « connection local » et « gather facts » à faux pour que ça ne plante pas au début. Du coup le playbook ne s’exécuterait pas sur la bonne machine.

EDIT : la solution à ce problème est disponible sur l’article suivant !

Liens utiles

Le module pause peut être utile dans certain cas, même si je n’en suis pas fan dans un environnement type « production ».

docs.ansible.com/ansible/pause_module.html

Également, je vais bientôt faire un article sur le module dédié a Proxmox dans les semaines qui viennent !!

docs.ansible.com/ansible/proxmox_kvm_module.html

Nouvelles fonctionnalités

En attendant donc que la ~~2.3~~ 2.4 soit distribuée partout, voici l’erreur que vous risquez d’avoir si vous utilisez les fonctions linked_clone ou snapshot_src :~~

ansible-playbook zwindler_vmware_add_micro.yml
vSphere Password:
VM notes [Deployed with ansible]:
PLAY [ansible_node] **********************************************************
TASK [create the VM] ***********************************************************
fatal: [ansible_node]: FAILED! => {"changed": false, "failed": true, "msg": "unsupported parameter for module: linked_clone"}
PLAY RECAP *********************************************************************
ansible_node : ok=0 changed=0 unreachable=0 failed=1

Voici la marche suivre pour compiler et installer la version 2.4 d’Ansible via les sources :

git clone https://github.com/ansible/ansible
cd ansible
make
make install
ansible --version
ansible 2.4.0

Réinventons la roue : j’automatise des actions via SSH+mdp avec un script expect

Thu, 11 Aug 2016 17:30:13 +0000

Dans quels cas ne pas utiliser ce script expect

Attention : je met en ligne ce script juste pour information. Cela peut aussi être utile si vous avez un besoin spécifique qui nécessite l’utilisation du binaire expect.

Si vous avez très rapidement besoin de réaliser sur un ensemble de serveur un tâche répétitive via SSH, le mieux est de jeter un œil vers Ansible. Les modules sont nombreux, les possibilités infinies, la facilité du langage déconcertante. Et contrairement aux autres (puppet, chef, salt), c’est sans agent !

Alors pourquoi j’ai pris du temps pour développer un script expect ?

Il y a deux ans, j’ai été chargé de réaliser une petite étude sur Puppet, un gestionnaire de configuration qui permet de définir un standard pour un groupe de machine. Un exemple simple est la gestion du NTP. En prenant le temps d’apprendre, on peut assez facilement définir sous Puppet un template qui stipule que tous les serveurs Linux doivent avoir le démon NTPd installé et opérationnel avec le bon fichier de configuration.

Pour autant, la nécessité de déployer des agents sur des centaines de serveurs et le langage un peu pompeux (pour le néophyte que j’étais) m’avait freiné. Car bien sûr, j’avais besoin TOUT de suite de quelque chose d’opérationnel, je n’avais pas le temps de :

Mettre en production un serveur puppet
Déployer les agents sur les machines
Tester mes templates avant de passer la modification sur tous les serveurs

Une solution simple aurait été de déposer une clé SSH sur tous les serveurs et de réaliser une simple boucle. Dans le même temps, certains de mes collègues étaient en train de travailler sur ce sujet précis. Pour préserver la paix de l’openspace, je ne souhaitais pas leur marcher sur les pieds.

Pour résoudre dans l’immédiat mon problème, j’ai utilisé expect.

« We do not forgive, we do not forget, … »

Pour ceux qui ne connaissent pas l’outil, il s’agit d’un binaire qui permet d’automatiser des tâches en fonction du retour renvoyé par le terminal. Cela peut être utile pour réaliser un ensemble de tâche sur via des outils tels que FTP (ou TFTP pour des switchs dans cet exemple (lien mort, j’utilise Internet Archive)). Et un script bash classique dans lequel vous ne pourrez **pas ** entrer un mot de passe (le prompt du mot de passe nécessite un « vrai » terminal). Expect lui peut le faire.

Deuxième avantage d’expect, il existe un langage de script qui permet d’automatiser relativement facilement vos actions avec des structures conditionnelles de base. J’ai rédigé un script qui m’a permis de copier des fichiers sur un liste de triplet de type hostname;username;password;.

Je l’ai mis à disposition sur Github et voici comment cela fonctionne.

Dans cet exemple je modifie le fichier repository yum sur un (seul) serveur distant et je nettoie le cache de yum.

./expect.us scp serveur_distant root votremotdepasseenclair source/newrepo_el7.1.repo /etc/yum.repos.d/newrepo_el7.1.repo
./expect.us ssh serveur_distant root votremotdepasseenclair "yum clean all"

Et dans cet exemple, le met à jour le fichier resolv.conf sur une liste de serveur avec un csv

#!/bin/bash
for line in `cat expect_dns_no_nm.csv`
do
hostname=`echo $line | cut -d";" -f1`
username=`echo $line | cut -d";" -f2`
password=`echo $line | cut -d";" -f3`
./expect.us ssh $hostname $username $password "cp /etc/resolv.conf /etc/resolv.conf.20151103"
./expect.us scp $hostname $username $password source/resolv.conf /etc/resolv.conf
done

Le mot de la fin

Entre le moment où j’ai écris le script et aujourd’hui où j’écris cet article (oui j’ai toujours du retard), j’ai découvert Ansible. Quand j’écrivais expect.us je savais que je réinventais la roue.

Depuis que j’utilise Ansible mon travail au quotidien a complètement changé.

Dans le cas où vous souhaitez automatiser des tâches et que vous êtes pressés par le temps, allez absolument voir Ansible.

Piloter Nagios (API) à travers le nagios.cmd

Thu, 21 Jul 2016 12:00:55 +0000

I command thee, Nagios

Pas la peine de vous faire l’affront de vous présenter Nagios ! Si vous tombez sur cet article, c’est probablement que vous connaissez déjà l’outil et que vous cherchez juste à automatiser des tâches à l’aide d’une API ou d’un CLI pour étendre les fonctionnalités par défaut.

Car au delà de la configuration manuelle par fichier de configuration (ou via une interface web si vous utilisez Centreon par exemple), et l’interface web, il y a peu de moyens pour interagir avec Nagios.

Par manque de documentation, je me souviens avoir notamment galéré pour récupérer des statistiques de santé de Nagios. Alors qu’en fait il existe un binaire nagiostats ! Même s’il n’est pas forcément super facilement exploitable, c’est quand même un bon début…

Et donc, même si ce n’est pas du tout mis en avant par Nagios, OUI, il existe une méthode pour interagir avec le processus Nagios via des lignes de commandes. Mais je vous préviens tout de suite, il va falloir fouiller les docs archivées !

Petite explication de la façon dont Nagios fonctionne

Nagios est une application monolithique écrite en C. L’interface graphique de Nagios est présentée par un serveur web apache à l’aide de scripts CGI. Je ne sais pas si le fait que l’interface de Nagios soit si … « austère » (qui à dit « moche » ?) est une limitation liée aux choix technologique ou un réel choix ergonomique.

Troll à part, il faut comprendre que par défaut, il n’y a pas de méthode native pour faire communiquer Apache et l’application en C. La méthode la plus simple sous Unix consiste alors à passer par un fichier particulier : un pipe nommé. Sans rentrer dans les détails techniques :

L’utilisateur clique sur un lien lié à une action (comme acquitter une alerte)
D’un côté, le script CGI écrit des commandes dans ce fichier fictif qu’est le pipe nommé
De l’autre, au lieu que les commandes soient écrites sur disques, elles sont envoyées directement dans le processus Nagios qui les interprété.

Eurêka, j’ai trouvé mon premier exemple !

A partir de là, on a trouvé la solution. Il est donc possible d’émuler le comportement de la GUI pour réaliser des actions en ligne de commande. Il suffit d’écrite dans le pipe nommé la bonne commande.

Forcément, on est par contre limité aux actions qu’on pourrait faire via la GUI. Typiquement, vous ne pourrez pas faire un script pour ajouter des hôtes à chaud. Ce type d’actions ne sont possibles qu’en modifiant la configuration texte, pas de miracle…

Ça peut quand même être très utile. En astreinte, des administrateurs (rebelles) désactivaient les notifications des services qui les dérangeaient… Les fourbes ! Voilà un petit script pour réactiver tous les mardi matin les alertes appartenant au groupe de services « Services en astreinte ».

#!/bin/bash
#Script permettant de reactiver les notifications Nagios des services du groupe
#"Service_en_Astreinte" au cas ou elles auraient ete desactivees
################################################################################
now=`date +%s`
COMMANDFILE='/usr/local/nagios/var/rw/nagios.cmd'
SERVICEGROUP='Services_en_Astreinte'
/usr/bin/printf "[%lu] ENABLE_SERVICEGROUP_SVC_NOTIFICATIONS;$SERVICEGROUP\n" $now > $COMMANDFILE

Et un petit cron

# Reinitialisation des notifications sur le groupe Service_en_astreinte (le mardi en HO)
30 10 * * 2 /scripts/reset_production_notifications.sh

Pour trouver la liste des commandes disponibles, vous pouvez soit cliquer sur tous les boutons de l’interface graphique tout en surveillant le nagios.log (c’est comme ça que j’ai trouvé mes premières commandes ;-)), soit fouiller le site de Nagios pour retrouver les archives de la v2.

old.nagios.org/developerinfo/externalcommands/commandlist.php

Deuxième exemple

En fouillant le site, je suis tombé sur une autre commande qui m’a paru très utile. Après avoir installé un nouveau site, j’ai voulu vérifier que l’envoi des notifications fonctionnaient bien sur les services important. Pour le tester, j’aurai pu créer un service à positionner exprès en CRITICAL. Cependant je préfère cette solution qui se base sur la commande SEND_CUSTOM_SVC_NOTIFICATION.

SEND_CUSTOM_SVC_NOTIFICATION

Command Format:

SEND_CUSTOM_SVC_NOTIFICATION;;;;;

Description:

Allows you to send a custom service notification. Very useful in dire situations, emergencies or to communicate with all admins that are responsible for a particular service. When the service notification is sent out, the $NOTIFICATIONTYPE$ macro will be set to « CUSTOM ». The field is a logical OR of the following integer values that affect aspects of the notification that are sent out: 0 = No option (default), 1 = Broadcast (send notification to all normal and all escalated contacts for the service), 2 = Forced (notification is sent out regardless of current time, whether or not notifications are enabled, etc.), 4 = Increment current notification # for the service(this is not done by default for custom notifications). The comment field can be used with the $NOTIFICATIONCOMMENT$ macro in notification commands.

Et le script qui va avec :

#!/bin/sh
now=`date +%s`
commandfile='/usr/local/nagios/var/rw/nagios.cmd'
/usr/bin/printf "[%lu] SEND_CUSTOM_SVC_NOTIFICATION;SERVER1;/var;0;Test_notifier;Petit coucou de la part de ma nouvelle installation!\n" $now > $commandfile

Avec ce petit script, j’ai bien reçu ma notification de la part du service /var de SERVER1 !

Il y a bien sûr plein d’autres scripts qu’on peut imaginer, avec les actions sur les acquittements, les commentaires, les rechecks, les actions externes, … Je vous laisse y penser !