Après m’être étendu sur Docker et sa facilité de déploiement pour les stacks complexes, je vais vous parler d’Ansible pour rajouter une couche d’automatisation aux déploiements.

La première chose à faire est de vous mettre un lab à disposition, quelques VMs feront l’affaire, et comme d’habitude je me concentrerai sur des CentOs 7+.

Ansible est une solution en ligne de commande qui ne s’appuie pas sur l’installation d’agent sur le machines cibles, mais bosse uniquement par la voie (royale) de SSH. Pour cela Ansible est bien plus facile a appréhender que les concurrents (Puppet, Chef, CFEngine, …) et tout aussi puissant.

Avant de commencer, je suis obliger de vous mettre en garde sur le développement rapide (trop) d’Ansible et des versions associées de python. Une installation via les package risque de vous causer quelques désagréments.

[cyklodev_summary]

Installation du serveur de déploiement

La version 2.4+ a supprimer le support des python 3.5-, du coup mieux vaut l’installer via pip.

yum update
yum -y install python36u python36u-devel python36u-pip python36u-setuptools python36u-libs
pip3.6 install ansible

Vérification de la version

[Zeph@ans ]$ ansible --version
ansible 2.4.1.0
  config file = 
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /bin/ansible
  python version = 3.6.3 (default, Oct 11 2017, 18:17:37) [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)]

La première chose qui saute à l’œil c’est que le fichier de configuration n’est pas défini. Je vais donc copier celui du package et le mettre à un emplacement standard.

[Zeph@ans ]# mkdir /etc/ansible
[Zeph@ans ]# cp /usr/lib/python3.6/site-packages/ansible/galaxy/data/container_enabled/tests/ansible.cfg /etc/ansible/ansible.cfg

Voila une configuration minimal utilisable :

[Zeph@ans ]$ mkdir /etc/ansible
[defaults]
inventory=./inventory
log_path = /var/log/ansible.log
deprecation_warnings=True
[privilege_escalation]
[paramiko_connection]
[ssh_connection]
[persistent_connection]
connect_timeout = 30
connect_retries = 30
connect_interval = 1
[accelerate]
[selinux]
[colors]
[diff]

On relance Ansible pour voir ma mise à jour du fichier de configuration.

[Zeph@ans ]$ ansible --version
ansible 2.4.1.0
  config file = /etc/ansible/ansible.cfg
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /bin/ansible
  python version = 3.6.3 (default, Oct 11 2017, 18:17:37) [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)]

Ansible dans la pratique

Envvars

Les variables d’environnement permettent de surcharger les valeurs par défaut.

ANSIBLE_CONFIG: pour mettre votre fichier dans une chemin spécifique
ANSIBLE_INVENTORY: le fichier host sur lequel Ansible se base (très proche d’un fichier /etc/hosts)
ANSIBLE_ROLES_PATH: le chemin ou les rôles seront définis (s’il n’y a pas de répertoire rôles dans le répertoire courant)

La documentation liste toutes les variables disponibles.

Au minimum il vous faudra un fichier de configuration et un fichier d’inventaire. Avec ça en main vous pourrez tester la connectivité vers vos cibles.

Hosts

Le fichier hosts peut être défini comme cela

[Zeph@ans ]$ cat hosts.inc
[groupe]
vm1 ansible_ssh_host=192.168.1.11
vm2 ansible_ssh_host=192.168.1.12

On a donc 2 machines qui sont définies (vm1, vm2) avec leurs adresses IP respectives.
Il faut encore tester la connexion ssh vers ces hosts, elle doit se faire via les échanges de clés RSA pour éviter de taper le mot de passe.
Vous pouvez vous inspirer de la la fonction ssh-pwdless.

[Zeph@ans ]$ ssh 192.168.1.11

Si votre SSH fonctionne avec authentification par clé, il est temps d’utiliser Ansible.

[Zeph@ans ]$ ansible all -m ping

Extension des possibilités

Vous avez la possibilité de spécifier un user.

[Zeph@ans ]$ ansible all -m ping -u root

Vous avez aussi la possibilité de spécifier un fichier host .

[Zeph@ans ]$ ansible -i hosts.inc all -m ping -u root

Et même de préciser une seule machine (ne pas oublier la virgule)

[Zeph@ans ]$ ansible -l vm1, -m ping -u root

Playbook

Les playbooks sont les enchainements de commandes que l’on va exécuter sur les hosts précédemment définis. Ils sont écrits en YAML, un langage identé, qui est extensible par de nombreuses variables.

[Zeph@ans ]$ vi info.yml

---
- hosts: groupe
  remote_user: root
  tasks:
  - name: This is a debug message
    debug:
      msg: "System {{ inventory_hostname }} has uuid {{ ansible_product_uuid }} AND {{hostvars[inventory_hostname]['ansible_default_ipv4']['address']}}"

Dans l’ordre on définit le groupe (ou le host), le user qui sera utilisé et les taches qu’on va exécuter. Il suffit ensuite d’exécuter le playbook avec la commande suivante:

[Zeph@ans ]$ ansible-playbook info.yml

PLAY [groupe] **************************************************************************************************************************************************************************************

TASK [Gathering Facts] **************************************************************************************************************************************************************************
ok: [vm1]
ok: [vm2]

TASK [This is a debug message] ******************************************************************************************************************************************************************
ok: [vm1] => {
    "msg": "System vm1 has uuid 564D8BA1-6D62-CE03-318A-CC15E2B4A4F7 AND 192.168.1.11"
}
ok: [vm1] => {
    "msg": "System vm2 has uuid 564D27AE-7D47-53B7-130B-A496A71046D8 AND 192.168.1.12"
}

PLAY RECAP **************************************************************************************************************************************************************************************
vm1		           : ok=2    changed=0    unreachable=0    failed=0   
vm2		           : ok=2    changed=0    unreachable=0    failed=0   

Vous avez maintenant toute liberté pour utiliser tous les modules Ansible disponibles.