Editions ENI Livres | Vidéos | e-Formations
Utilisation d’Ansible
Objectifs du chapitre et prérequis
Ansible est maintenant installé et vos serveurs sont prêts à accepter des connexions SSH via un système de clés. Il est temps de commencer à administrer vos machines.
1. Contexte et prérequis
Par la suite, Ansible sera déjà installé et disponible dans le contexte de l’utilisateur. Les échanges de clés sont déjà réalisés avec les serveurs distants.
2. Fichiers téléchargeables
Vous pouvez récupérer les exemples des répertoires inventaires et variables sur le repository GitHub suivant : https://github.com/EditionsENI/ansible
Vous pouvez également récupérer ces fichiers dans l’archive chapitre-02.tar.gz depuis la page Informations générales.
Ansible en mode ad hoc
Ansible est maintenant disponible et prêt pour les premiers tests. Le mode que vous verrez en premier est celui dans lequel chaque opération doit être spécifiée unitairement.
Ce mode convient parfaitement pour s’assurer que la communication se passe bien ou pour réaliser des opérations simples, comme par exemple la création d’un répertoire ou d’un utilisateur.
1. Création d’un fichier d’inventaire
Mais avant de partir sur le lancement d’Ansible sur des machines, il faut créer un fichier d’inventaire avec les machines à administrer. Ce fichier peut être écrit dans plusieurs formats comme par exemple :
-
format INI
-
format YAML
Le format INI est le format historique des inventaires Ansible. Dans les inventaires écrits avec ce format, chaque machine occupe une ligne. Ces machines peuvent également être regroupées à l’aide de sections. Ces aspects seront vus un peu plus loin.
Dans le cas des inventaires au format YAML, les machines sont regroupées dans des structures spécifiques qui seront vues plus loin dans le chapitre de présentation du format YAML.
Pour démarrer, créez un fichier rec-apache.inv (disponible dans les fichiers d’exercice). Ce dernier va contenir une seule ligne avec le nom de la machine rec-apache-1. En plus du nom de la machine, ajoutez la déclaration ansible_user=root (sur la même ligne). Vous indiquez ainsi que la connexion sur la machine se fera avec l’utilisateur root. Ci-dessous le contenu de ce fichier :
rec-apache-1 ansible_user=root Si vous avez fait vos échanges de clé avec...
Les autres outils d’Ansible : playbook et doc
Jusqu’à maintenant, vous vous êtes surtout servi d’Ansible en mode ad hoc pour vérifier la communication avec vos serveurs distants (module setup et ping) et éventuellement modifier le contenu d’un fichier (lineinfile).
Vous allez maintenant voir qu’il existe plusieurs utilitaires avec Ansible. Par la suite, vous verrez le mode playbook qui sera à privilégier la plupart du temps. Il existe également l’utilitaire ansible-doc qui sera également abordé.
Ce dernier vous offre la possibilité de consulter la documentation des différents modules sans avoir à vous connecter sur Internet sur le site officiel d’Ansible.
Reprenez la machine de recette apache rec-apache-1. Comme vous arrivez à communiquer avec cette machine et à réaliser une escalade en tant que root, vous allez y faire les opérations suivantes :
-
Installation du package apache.
-
Activation et démarrage du service apache.
-
Recopie d’un fichier à la racine du serveur.
Cette machine se base sur une distribution à base de RPM (Red Hat, Fedora ou CentOS). Dans ces cas-là, il faut appeler le module yum pour procéder à l’installation (dans le cas d’une distribution dérivée de Debian, il aurait fallu utiliser le module apt). Vous passerez en paramètre le nom du package à installer (-a name=httpd). Par défaut, le module installera le package, mais il est possible d’expliciter l’opération en ajoutant l’option state=present ou state=installed.
Pour connaître toutes les options d’un...
Quelques notions sur le format YAML
Avant d’aller plus loin dans la découverte d’Ansible, il faut connaître quelques notions sur le format YAML. En effet, ce format est utilisé par Ansible pour énormément de choses :
-
Les fichiers de variables (nom d’utilisateur, mot de passe, etc.).
-
La description des opérations à réaliser (notamment avec les playbooks).
-
Les inventaires et la configuration d’Ansible (depuis la version 2.4).
Pour l’essentiel, YAML permet d’écrire des structures de données. Ces données peuvent être spécifiées sous la forme de listes ou sous la forme de dictionnaires. Ce langage propose également plusieurs façons d’écrire les mêmes structures en fonction de ce que vous souhaitez mettre en avant : lisibilité ou compacité de votre description (même si généralement, il faut privilégier la lisibilité).
À noter que la notation au format JSON permet le même type de stockage (Ansible l’accepte également). Ces deux langages partagent énormément de caractéristiques communes étant donné que YAML est une extension du langage JSON. La principale différence entre JSON et la notation YAML réside surtout au niveau de la lisibilité.
1. Déclaration de variables simples
Le langage YAML sert à déclarer des variables. Par défaut, il n’y a aucune contrainte au niveau du nom des variables si ce n’est qu’il doit y avoir un nom suivi d’un deux-points (:) suivi d’un espace (‘ ‘). En revanche, Ansible n’accepte pas...
Introduction de la notion de playbook
La suite du chapitre sera consacrée à la ré-écriture de l’installation d’Apache de tout à l’heure. Les quatre commandes à passer étaient relativement complexes :
-
Passage des options de sécurité.
-
Options longues et nombreuses pour faire fonctionner les modules (utilisation de double quote pour les options et séparation à l’aide d’espaces).
-
Enchaînement manuel des commandes.
Toutes ces pratiques vont à l’encontre de la création de procédures simples et rapides facilement réutilisables. Autre problème, ces aspects ne sont pas implicites alors qu’il serait intéressant de les stocker quelque part (Git par exemple).
C’est là qu’intervient la notion de playbook pour répondre à ce type de situation.
Un playbook est un fichier au format YAML. Ce dernier va donner une liste d’instructions. Ces instructions sont passées à Ansible dans l’ordre de leur déclaration. L’avantage par rapport au mode ad hoc est que vous aurez ainsi tout décrit dans un fichier, y compris l’enchaînement des opérations.
1. Structure d’un playbook
Un playbook peut contenir énormément d’informations, mais la plupart du temps vous pouvez vous contenter d’un sous-ensemble relativement restreint. Ci-dessous, une liste des champs auxquels vous ferez forcément appel :
-
Le nom de playbook (champ name).
-
La liste de machines sur laquelle vous allez travailler (champ hosts).
-
Des options de gestion de la sécurité (optionnelles).
-
La gestion...
Combinaison avec Git
Vous avez découvert la notion de playbook. Avant d’aller plus loin, il paraît important d’aborder un élément crucial de ce type de projet : le stockage des scripts dans un gestionnaire de code source.
Ce chapitre présentera succinctement l’utilisation de Git. Attention : il ne s’agit en aucun cas d’un guide complet. Afin de compléter les points non abordés ici, le lecteur pourra se pencher sur les ouvrages traitant de ce sujet (gestion des branches, tags, etc.).
À noter que si vous avez déjà l’habitude d’utiliser un autre gestionnaire de code source (comme subversion par exemple), il est tout à fait possible d’adapter ces instructions.
1. Création du repository
Si vous disposez déjà d’un repository Git, passez directement au chapitre suivant.
Vous allez créer un emplacement de stockage Git pour votre configuration. Cette opération se fait à l’aide de la commande git init suivie du chemin où vous souhaitez déposer votre référentiel.
L’exemple ci-dessous fera appel au répertoire ~/infrastructure-as-a-code :
$ mkdir -p ~/infrastructure-as-a-code
$ git init ~/infrastructure-as-a-code
Initialized empty Git repository in /home/yannig/
infrastructure-as-a-code/.git/ Attention, en cas de panne, vous perdrez tout votre travail si vous n’avez pas communiqué vos travaux à l’extérieur.
C’est pourquoi il est recommandé d’ajouter un espace de stockage distant. Cette opération se fait à l’aide de l’instruction git remote add suivie...