Présentation, installation, utilisation de Ansible
Présentation du contexte :
GSB (Galaxy Swiss Bourdin) est créé en 2009 par la fusion de Galaxy, expert en maladies virales, et Swiss Bourdin, spécialisé dans les médicaments classiques. Le siège administratif est a Paris, le social à Philadelphie. L’objectif est d’optimiser coûts et production en combinant leurs forces. L’entreprise compte 480 visiteurs médicaux en métropole et 60 en outre-mer, répartis en 6 zones.
Le besoin :
La DSI a décidé de mettre en place dans son infrastructure un service permettant l’automatisation de taches, la simplification de la gestion des serveurs, et l’optimisation d’opérations.
Solutions envisageables et retenues :
Differents solutions sont possible : Puppet, Chef, SaltStack, Ansible.
La solution retenue est Ansible, car il possède une grande communauté, est open source et il utilise le langague yaml qui est facile à lire.
Principe de fonctionnement :
Ansible est un outil permettant d’automatiser des taches. Il est capable d’exécuter des actions complexes ou répétitives, sur un grand nombre de machines en même temps.
Il est « agentless » ce qui signifie qu’il ne nécessite pas d’agents sur les machines clientes pour fonctionner. Il utilise le protocole SSH pour pousser les différentes taches sur les clients.
Il a été créé en 2012 par Michael DeHaan, un ingénieur logiciel.
Il dispose d’une large communauté qui créé, et partage des playbooks, modules et roles. Le site internet Ansible Galaxy en regroupe un grand nombre et les propose gratuitement.
Red Hat commercialise également en version commerciale sous le nom de Ansible Automation Platform, offrant des outils supplémentaires pour les grandes entreprises.
L’utilisation de Ansible se base sur trois notions principales :
- L’inventory : C’est l’inventaire des différents hôtes. Il est possible de créer des groupes d’hotes, sous-groupes, et de les nommer afin de pouvoir facilement les appeler dans des playbooks. Il peut être au format ini ou Yaml.
- Les roles : C’est une suite d’actions coordonnées permettant de réaliser un suite de tache dans un but précis ( exemple : installer Apache et le configurer )
- Les playbooks : Permet d’orchestrer l’utilisation des roles en indiquant lesquels utiliser sur quel host ou groupe d’host de l’inventory. Il fait le lien entre roles et inventory. Le format utilisé pour les playbook et YAML.
Schéma réseau actuel :

Schéma réseau attendu :

Installation :
Pour installer ansible, il suffit d’exécuter la commande suivante :
apt install ansible
Puis, pour vérifier la version installée, taper :
Ansible –version

Nous allons maintenant générer et faire l’échange de clefs SSH entre notre machine node manager ( la machine sur laquelle Ansible et installé) et un de nos managed node ( machine cliente).
Pour cela, executer les commandes suivantes :
ssh-keygen -t ed25519 (generation des cléfs)
ssh-copy-id ansible-«utilisateur»@ip_de_votre_machine
Puis tenter de se connecter sans password, si l’échange de clefs a réussie, la manipulation devrait fonctionner et aucun mot de passe ne devrait être demandé pour la connexion SSH.
Cette manipulation est à faire pour tous les managed nodes.
Il faut ensuite modifier le fichier inventaire et y inclure les IP, noms d’hotes de nos machines clientes.
Voici un exemple de fichier inventaire, nous avons deux groupes d’hotes, un nommé « linux », l’autre « webserveurs »

Pour finaliser la vérification et être sûr que les Playbooks seront correctement exécutés, nous pouvons effectuer la commande de vérification suivantes :
ansible all -i /etc/ansible/hosts -m ping

“SUCCESS” nous allons pouvoir exécuter des playbooks vers ses machines distantes.
Exécution d’un playbook
Voici un playbook, il permet l’installation d’Apache.

Pour l’exécuter, il faut taper la commande suivante :
ansible-playbook install-apache2.yaml -i hosts
– ansible-playbook permet d’indiquer que l’on veut exécuter un playbook
– Puis on indique le nom du playbook : install-apache2.yaml
– Puis le fichier inventaire que l’on veut utiliser avec -i

Lors de l’exécution d’un playbook, Ansible nous fait un retour d’état. Il nous indique si le playbook a correctement effectué les actions demandées ou pas. On peut voir sur l’image ci-dessus qu’Ansible n’a pas réussi à exécuter le playbook sur deux hôtes.
Il nous indique le pourquoi : « Failed to connect to the host via ssh: ssh: connect to host 192.168.110.64 port 22: No route to host », « unreachable »: true
Il n’a pas pu atteindre l’hôte via le port 22. Le problème était que les machines étaient éteintes.
Voilà le compte rendu final que nous donne Ansible après une bonne exécution :

Notre serveur ansible est fonctionnel, nous allons pouvoir l’utiliser pour d’autres projets.
Playbook pour déployer un serveur Squid fonctionnel :
Je vais vous présenter un Playbook qui permet de mettre en place un serveur Squid avec SquidGuard , et qui installe les services et configure le serveur pour faire fonctionner l’authentification active directory pour les comptes utilisateurs, le tout en un seul play.
Voici le playbook complet, le playbook avec les explications se trouve plus bas :


Explication du Playbook :




Voici le Tree du répertoire Ansible :
├── ansible.cfg
├── ansible.cfg.old
├── backupcisco.yaml
├── enablenetconf.yaml
├── fileserver.yaml
├── install-apache2.yaml
├── install-squid.yaml
├── inventory
│ ├── hosts
│ └── hosts.save
├── remove-apache2.yaml
├── roles
│ ├── chrony
│ │ ├── chrony.conf
│ │ └── install-chrony.yaml
│ ├── services
│ │ ├── install-rsync.yaml
│ │ ├── install-smb.yaml
│ │ ├── install-winbind.yaml
│ │ └── smb.conf
│ ├── squid
│ │ ├── copyconfsquid.yaml
│ │ ├── squid.conf
│ │ ├── squid.conf.save
│ │ └── squidGuard.conf
│ ├── update-upgrade.yaml
│ └── utility
│ └── blacklist.yaml
├── ssh-copy.yaml
Les roles utilisés :
Install Rsync : Install smb : Install chrony :



Download blacklitsts :

Conclusion + Evolution possible :
Le serveur est fonctionnel, il va permettre l’automatisation de tâches, l’envoie en parallèle d’actions sur un grand nombre de machines Linux ou même le déploiement de machines fonctionnelles comme vu avec le playbook Squid.
L’évolution possible et l’utilisation d’Ansible pour la gestion de switch Cisco.