Ansible

Projet tuteuré
2016-2017 Page 1
Sommaire
Introduction ................................................................................................................................. 3
I-Description du projet .................................................................................................................. 3
I.1-Contexte et justification........................................................................................................ 3
I.2-Problématique ..................................................................................................................... 4
II-Analyse du projet....................................................................................................................... 4
II.1-C’est quoi Ansible ?.............................................................................................................. 4
II.2-Pourquoi Ansible ?............................................................................................................... 5
III-Fonctionnement........................................................................................................................ 5
III.1-Protocole SSH..................................................................................................................... 5
III.2-Fichier inventaire de Ansible ............................................................................................... 6
III.3-Patterns............................................................................................................................. 7
III.4-Commande ad-hoc ............................................................................................................. 8
III.5-Les playbooks....................................................................................................................10
IV-Réalisation...............................................................................................................................16
IV.1-Installation de Ansible .......................................................................................................16
IV.2-Architecture......................................................................................................................17
IV.3-Déploiement.....................................................................................................................17
Déploiement I..............................................................................................................................17
Installationet configuration d’un serveur ngnix .............................................................................17
Déploiement II ...........................................................................................................................25
Configurer Apache Utilisation Ansible sur Ubuntu....................................................................25
Étape 1 - Configuration Ansible............................................................................................25
Étape 2 - Création d'un Playbook.........................................................................................26
Étape 3 - Installation de Apache...........................................................................................27
Étape 4 - Configuration des modules Apache.....................................................................29
Étape 5 - Configuration des options Apache .......................................................................31
Étape 6 - Configuration des hôtes virtuels...........................................................................33
Créons uneconfiguration de l'hôte virtuel.............................................................................33
Utilisons des variables de template......................................................................................34
Ajoutons un module Template.............................................................................................34
Activons l'hôte virtuel...........................................................................................................35
Empêcher le travail supplémentaire.....................................................................................35

Projet tuteuré
2016-2017 Page 2
Playbook final apache.yml................................................................................................35
Étape 7 - Utilisation d'un référentiel Git pour notre site Web..............................................37
Conclusion...................................................................................................................................39
REFERENCE..................................................................................................................................40

Projet tuteuré
2016-2017 Page 3
Introduction
Le présent document entre dans le cadre de réalisation du projet tuteuré de
Licence professionnelle en « Maintenance et Réseaux Informatiques » au Centre
Informatique et de Calcul à l’université de Lomé.
Les systèmes informatiques sont devenus des outils indispensables au
fonctionnement des entreprises. Ils sont aujourd’hui déployés dans tous les secteurs
professionnels, à savoir, le secteur bancaire, les assurances, la médecine et d’autres.
Au fur et à mesure que l’entreprise s’agrandit, le nombre de projets qui
apparaissent augmente. Par conséquent, le nombre de serveurs à gérer par
l’administrateur augmente de jours en jours par rapport au nombre de projets qui
apparaissent. Ainsi l’administrateur a plusieurs serveurs à gérer. Ces serveurs
peuvent être virtuels ou physiques.
Dès lors, l’administrateur a besoin d’un outil efficace pour pouvoir effectuer
plus facilement les tâches d’administration tels que l’installation d’un logiciel, l’arrêt
et le redémarrage d’un service, automatisation des mises à jours, effectuer les
configurations, créer des utilisateurs en plus d’autres à distance sur plusieurs
serveurs parallèlement. Ce qui évitera à l’administrateur de se déplacer sur chaque
serveur pour faire des configurations.
Dans ce document nous utiliserons Ansible qui est une plate-forme logicielle
libre pour effectuer les tâches d’administration à distance à travers le protocole
sécurisé SSH.
Ce document est structuré en quatre parties :
 Dans la première partie nous allons faire une description du projet
 Dans la deuxième nous ferons une analyse du projet
 Dans la troisième partie nous étudierons le fonctionnement de Ansible
 Et enfin dans la quatrième partie nous exposerons notre réalisation.
I-Descriptiondu projet
I.1-Contexte et justification
Administrer c’est de gérer quelque chose. Nous pouvons dire que administrer
un système informatique c’est la gestion d’un parc informatique. Qu’il soit en

Projet tuteuré
2016-2017 Page 4
entreprise ou en situation d’utilisation personnelle, l’administrateur système
effectue des tâches communes : Installer, configurer et faire évoluer le matériel :
une nouvelle carte réseau, un nouveau disque ; Installer les applications :
installation sur un ou plusieurs postes en même temps ; gérer les utilisateurs :
ce qui comprend l’ajout, la suppression d’un profil, la mise en place de
quotas, la gestion des droits spécifiques ou par groupe et en plus sécuriser le
système : par les mises à jours liées à la distribution ainsi que celles liées aux
applications, par les sauvegardes régulières des données.Depuis le début de
l'informatique en réseau, le déploiement et la gestion fiables restent un défi.
Historiquement, les administrateurs système ont généralement gérer les serveurs,
installer des logiciels, modifier des configurations et administrer des services
manuellement. Mettre en place un serveur manuellement peut rapidement s'avérer
pénible, surtout si nous avons plusieurs machines à configurer de la même manière.
La virtualisation des serveurs a aussi considérablement augmenté la tâche d’un
administrateur ou d’une équipe d'administrateurs. Face au nombre de serveurs qui
augmente au fil des années dans l’entreprise, ce serait fastidieux de se déplacer sur
les serveurs un à un pour leurs configurations et surtout si le serveur est sur un site
distant. Le fait de se déplacer sur les serveurs entraîne une perte de temps et par
conséquent le retard dans le service offert aux utilisateurs. Ansible est un outil de
gestion de Configuration et de déploiement, permettant d'automatiser simplement et
efficacement la mise en place d'infrastructures complexes.
I.2-Problématique
Le problème qui se pose et de trouver une solution pour effectuer les tâches
d’administration de façon efficace, éliminer les contraintes géographiques, gagner du
temps en gérant plusieurs serveurs en même temps c’est-à-dire de façon parallèle.
II-Analyse du projet
Une solution pour une gestion optimisée des serveurs d’une entreprise est :
Ansible.
II.1-C’est quoi Ansible ?
Ansible est un outil de pilotage de systèmes, sans agent, faisant partie de la famille
des outils DevOps. Il permet de simplifier des opérations d’orchestration complexes,
de faire du management de configuration centralisé sur un grand nombre de
machines. Il permet également le pilotage de plateformes Cloud telles qu’Amazon
Web Services ou OpenStack. Il est un moteur d'automatisation informatique
radicalement simple qui automatise la gestion de configuration, le déploiement
d'application, intra-orchestration de services. Il utilise YAML qui est un langage très
simple qui permet de décrire les travaux d'automatisation d'une manière simple qui

Projet tuteuré
2016-2017 Page 5
se rapproche du pur anglais. Les modules Ansible fonctionnent via JSON. Ansible est
extensible avec des modules qu’on peut écrire dans n’importe quel langage de
programmation.
II.2-Pourquoi Ansible ?
Ansible a plusieurs avantages dont nous citons quelques uns :
 Gagnez du temps et être plus productif
 Éliminer les tâches répétitives
 Moins d'erreurs
 Améliorer la collaboration et la satisfaction professionnelle
 surmonter la complexité
 Plus de ressources pour l'innovation
III-Fonctionnement
III.1-Protocole SSH
Ansible utilise le protocole SSH pour communiquer de façon sécurisée
avec les machines à configurer. Ainsi pour utiliser ansible, il faut installer openssh
et générer une clé sur la machine contrôleur qui sera ensuite copiée sur les serveurs
distants sur lesquels est installé aussi le serveur openssh. Ces étapes peuvent être
réalisées de la façon suivante :
Installation de openssh sur les machines :
$ sudo apt-get install openssh-server
$ sudo apt-get install openssh-client
Remplissage du fichier /etc/hosts sur la machine contrôleur : supposons qu’on a
quatre machines à gérer. On aura dans le fichier /etc/hosts de la machine contrôleur
par exemple ceci :
192.168.1.2 webserver1
192.168.1.3 webserver2
192.168.1.4 appserver
192.168.1.5 mailserver

Projet tuteuré
2016-2017 Page 6
Génération de la clé sur la machine contrôleur :
$ ssh-keygen
Copie de la clé sur les serveurs distants :
$ ssh-copy-id webserver1
$ ssh-copy-id webserver2
$ ssh-copy-id appserver
$ ssh-copy-id mailserver
Apres cette configuration, on pourra ensuite se connecter aux serveurs de
façon sécurisée.
III.2-Fichier inventaire de Ansible
Le fichier inventaire de ansible comporte ou contient les hôtes du réseau. Ces
hôtes peuvent être uniques ou groupés en utilisant les crochets. Le fichier inventaire
par défaut est /etc/ansible/hosts. Par ce fichier, ansible peut travailler sur plusieurs
systèmes d’une infrastructure en même temps. Nous pouvons spécifier un fichier
d'inventaire différent en utilisant l'option -i <chemin> sur la ligne de commande.
Nous pouvons également utiliser plusieurs fichiers d'inventaire en même temps.
Ce fichier peut se présenter de la façon suivante :
Appserver
[servers]

Projet tuteuré
2016-2017 Page 7
webserver1
webserver2
appservver
mailserver
[webservers]
webserver1
webserver2
Explication du fichier :
Dans ce fichier nous avons appserver comme nom d’hôte. Nous avons aussi deux
groupes : [servers] et [webservers]. Le groupe [servers] contient tous les serveurs du
réseau pendant que nous avons mis dans le groupe [webservers] les serveurs web.
Notons cette répartition est faite par l’administrateur selon ses besoins et le but qu’il
poursuit. Un serveur peut appartenir à plusieurs groupes.
III.3-Patterns
Patterns dans ansible est la façon dont nous décidons gérer les hôtes du réseau. Cela
signifie que nous décidons de quel hôte nous voulons communiquer.
Pour utiliser Ansible, nous devons savoir comment dire à Ansible de communiquer
avec les hôtes qui sont dans le fichier inventaire. Ce ci est fait en désignant
particulièrement le nom des hôtes ou un groupe de serveurs.
Les patterns suivants sont équivalents et cible tous les hôtes du fichier inventaire :
all
*
Il est aussi possible d’adresser un hôte spécifique ou des hôtes par leur nom :
webserver1
appserver
192.168.1.5
192.168.1.*
Les patterns suivants adressent un ou plusieurs groups. Les groupes sont séparés par
deux points. Ce qui veut dire que le serveur peut être dans l’un des groupes.
webservers

Projet tuteuré
2016-2017 Page 8
servers:webservers
On peut exclure les serveurs qui sont à la fois dans le groupe servers et webservers
servers:!webservers
On peut spécifier l’intersection des deux groupes en faisant :
servers:&webservers
On peut référencer les hôtes en utilisant les syntaxes suivants :
*.example.com
*com
one*.com:dbservers
Nous pouvons cibler les hôtes par leurs positions dans un groupe.
Supposons nous avons le groupe suivant :
[webservers]
Cobweb
Webbing
weber
Nous pouvons référencer les hôtes par le groupe de la façon suivante :
webservers[0] # ==cobweb
webservers[1] # ==webbing
webservers[2] # ==weber
webservers[0:1] # == cobweb, webbing
III.4-Commande ad-hoc
Une commande ad-hoc est une commande qu’on peut taper pour faire quelque chose
de rapide, mais qu’on ne veut pas enregistrer. D'une manière générale, la vraie
puissance de Ansible réside dans les playbooks mais nous pouvons utiliser les
commandes ad hoc pour de petite et simple tâche. Donnons quelques exemples :
D’une manière générale une commande ad-hoc Ansible se présente sous cette forme :
ansible < HOST_GROUP > -m <module_name> -a <arguments>

Projet tuteuré
2016-2017 Page 9
Explication:
ansible: est une commande
< HOST_GROUP > : représente les hôtes sur lesquels on veut exécuter la
commande
-m : permet de spécifier un module.
-a : permet de spécifier les arguments
ansible webservers -m ping
Cette commande va exécuter le module de ping vers les serveurs qui sont dans le
groupe webservers.
Commande ad-hoc en utilisant le module de copie:
ansible webservers -m copy -a "src=/root/ansible.txt dest=/tmp/" -f 2
On copie le fichier "/root/ansible.txt" placé sur la machine ansible à tous les hôtes
définis dans " webservers " dans /tmp pour tous les hôtes. Le -f 2 option indique à
ansible d’ouvrir deux processus pour exécuter cette option.
Commande ad-hoc en utilisant le module file:
En utilisant le module de fichier, on peut également modifier les propriétés des
fichiers sur les hôtes.
ansible all -m file -a "dest=/tmp/ansibletest.sh mode=755"
Définit l'autorisation de fichier à 755 sur tous les hôtes pour le fichier
/tmp/ansibletest.sh
ansible all -m file -a "dest=/tmp/monster state=directory mode=755"
Ceci créera le répertoire /tmp/monster sur tous les hôtes avec 755 autorisations.
ansible all -m file -a "dest=/tmp/monster state=absent"
Ceci supprimera le répertoire "/tmp /monster" récursivement

Projet tuteuré
2016-2017 Page 10
Commande ad hoc en utilisant le module de gestion de packtage:
ansible all -m yum -a "name=docker state=latest"
S’assurer que le paquetage docker est le dernier.
Commande ad hoc en utilisant le module de gestion des utilisateurs:
Le module "utilisateur" de Ansible peut être utilisé pour ajouter et supprimer des hôtes du
système facilement. Pour ajouter un utilisateur, nous devons envoyer un mot de passe chiffré
comme indiqué ci-dessous.
ansible all -m user -a 'name=monster
password=$6$random_salt$BnOQxEG8Gk2rzFYwoWXjr59zLVYzwshvca5oV0PtU8fAfT4a571
evgca.E0hLnYNCdfq//zw9YyQN33QtztI10'
On peut supprimer un utilisateur de cette manière
ansible all -m user -a "name=monster state=absent"
Pour supprimer le répertoire d'accueil des utilisateurs après avoir supprimé
l'utilisateur, le module 'fichier' peut être utilisé comme indiqué ci-dessous
ansible all -m file -a "dest=/home/monster state=absent"
Commande ad hoc en utilisant le module de gestion des services:
ansible webservers -m service -a "name=httpd state=started"
Ceci va s’assurer si le service httpd est en cours d’execution
ansible webservers -m service -a "name=httpd state=restarted"
Ceci va s’assurer si le service httpd est redémarré
III.5-Les playbooks
Les playbooks sont l'une des principales caractéristiques d’Ansible. Ils disent à
Ansible ce qu'il faut exécuter. Ils sont comme une liste de tâches que Ansible doit
exécuter. Chaque tâche se connecte en interne à un morceau de code appelé module.

Projet tuteuré
2016-2017 Page 11
Les playbooks sont exprimés en format YAML qui est très faciles à lire, alors que les
modules sont un morceau de code qui peut être écrit dans n'importe quelle langage
avec la condition que sa sortie doit être au format JSON. Nous pouvons avoir
plusieurs tâches énumérées dans un playbook et ces tâches seraient exécutées en
série par Ansible. Les jeux d’instructions sont exécutés séquentiellement de haut en
bas. Toutefois, on peut effectuer l'exécution conditionnelle des tâches afin qu'elles
puissent être ignorées si les conditions ne sont pas remplies. Autrement dit, les
playbooks sont la base d'un système de déploiement de gestion de configuration de
plusieurs machines. Ils sont la configuration, le déploiement et le langage
d’orchestration de Ansible. Ils peuvent décrire une politique qu’on veut que les
systèmes distants respectent, ou un ensemble d'étapes dans un processus
informatique général.
Les playbooks de Ansible sont constitués d'une ou plusieurs jeux d’instructions. Un
jeu se compose de trois sections:
La section cible qui définit les hôtes sur lesquels le jeu sera exécuté, et la façon dont
il sera exécuté. C’est là où nous mettons le nom d'utilisateur SSH et d'autres
paramètres liés à SSH.
La section variable qui définit les variables, qui seront mis à la disposition du jeu
en exécution.
La section des tâches qui répertorie tous les modules dans l'ordre que nous voulons
qu'ils soient gérés par Ansible
La commande pour exécuter un playbook est ansible-playbook
Exemple de playbook : example.yml
- - -
- hosts: webservers
user: root
vars:
apache_version: 2. 6
motd_warning: ' WARNING: Use by ACME Employees ONLY'
testserver: yes
tasks:
- name: setup a MOTD
copy:
dest: /etc/motd
content: "{{ motd_warning }}"
Nous pouvons inclure autant de jeu d’instruction que nous voulons dans un fichier
YAML unique. Les fichiers YAML commencent avec --- et contiennent de
nombreuses valeurs et listes de clés. En YAML indentation des lignes est utilisée

Projet tuteuré
2016-2017 Page 12
pour indiquer imbrication variable à l'analyseur, ce qui rend également le fichier plus
facile à lire.
Explication des différentes parties du fichier :
La sectioncible
La section cible ressemble à l'extrait de code suivant:
- hosts: webservers
user: root
Ceci est une version incroyablement simple, mais susceptible d'être tout ce qu'il faut
dans la plupart des cas. Chaque jeu existe dans une liste. Selon la syntaxe YAML, la
ligne doit commencer par un tiret. Les hôtes sur lesquels un jeu sera exécuté doivent
être mentionnés dans la valeur des hôtes. Cette valeur utilise la même syntaxe que
celui utilisé lors de la sélection des hôtes en utilisant la ligne de commande Ansible.
Dans la dernière ligne, l'utilisateur indique au playbook d’Ansible, l’utilisateur
auquel il doit se connecter sur la machine distante.
Les autres lignes que nous pouvons fournir dans cette section sont les suivantes:
sudo: on peut mettre ‘yes’ pour cette option si nous voulons que ansible utilise sudo
pour devenir root une fois connecter aux machines dans le jeu.
user: Ceci définit le nom d'utilisateur pour se connecter à la machine à l' origine,
avant d'exécuter sudo si configuré.
sudo_user: Ceci est l'utilisateur que Ansible va essayer et devenir en utilisant sudo
connection: Cela nous permet de dire Ansible le protocole de transport à utiliser
pour se connecter à l'hôte distant.
gather_facts: Ansible exécutera automatiquement le module d'installation sur les
hôtes distants à moins que nous le disons pas.
La section variable
Ici, nous pouvons définir des variables applicables à l'ensemble du jeu sur
toutes les machines.
Les variables dans un playbook sont définies par la clé vars. Cette clé prend une paire
clé-valeur, où la clé est le nom de la variable et la valeur est la valeur réelle de la
variable. Cette variable remplacera les autres variables qui sont définies par un
fichier de variable global ou à partir d'un fichier d'inventaire.
Nous pouvons faire de sorte qu’Ansible demande les variables si elles n’ont pas été
saisies dans la ligne de commande. Ceci permet de rendre plus facilement
maintenable les jeux d’instructions et nous évite modifier les mêmes choses dans

Projet tuteuré
2016-2017 Page 13
plusieurs parties de la pièce. Cela nous permet également d'avoir tout le jeu stocké en
haut, où nous pouvons facilement le lire et le modifier sans se soucier de ce que le
reste du jeu fait.
Les variables dans cette section d'un jeu peuvent être remplacées par des actions de
la machine (ceux qui sont définis par modules), mais ils remplacent eux-mêmes les
faits que nous avons définis dans notre inventaire. Donc, ils sont utiles pour définir
les défauts que nous pourrions collecter dans un module plus tard, mais ils ne
peuvent pas être utilisés pour maintenir les valeurs par défaut pour les variables
d'inventaire, car elles remplaceront ces valeurs par défaut.
Les déclarations de variables, qui se produisent dans la section vars, ressemblent aux
valeurs dans la cible et contient un dictionnaire YAML ou une liste. Un exemple
ressemble au fragment de code suivant:
vars:
apache_version: 2. 6
motd_warning: ' WARNING: Use by ACME Employees ONLY'
testserver: yes
Les variables peuvent également être chargées à partir de fichiers YAML externes en
donnant à Ansible une liste de variable fichiers à charger. Cela se fait d'une manière
similaire en utilisant la directive vars_files. Ensuite nous pouvons tout simplement
fournir le nom d'un autre fichier YAML qui contient son propre dictionnaire. Ceci
veut dire qu’au lieu de stocker les variables dans le même fichier, elles peuvent être
stockées et distribuées séparément, ce qui nous permet de partager notre playbook
avec d'autres.
En utilisant vars_files, les fichiers ressemblent à l'extrait de code suivant dans notre
manuel:
vars_files:
conf/country-AU.yml
conf/datacenter-SYD.yml
conf/cluster-mysql.yml
Dans l'exemple précédent, Ansible recherche le pays-UA.yml, datacenter-SYD.yml
et Cluster-mysql.yml dans le dossier conf par rapport au chemin du playbook.
Chaque fichier YAML ressemble à l'extrait de code suivant:
- - -
ntp: ntp1. au. example. com
TZ: Australia/Sydney
Enfin, nous pouvons faire de sorte qu’Ansible demande à l'utilisateur pour chaque
variable interactivement. C'est utile lorsque nous avons des variables que nous ne
voulons pas rendre disponibles pour l'automatisation, exigent une contribution

Projet tuteuré
2016-2017 Page 14
humaine. Un exemple où cela est utile est lorsque vous demandez les mots de passe
utilisés pour décrypter les clés secrètes des serveurs HTTPS.
Nous pouvons demander à Ansible de demander des variables avec l'extrait de code
suivant:
vars_prompt:
- name: https_passphrase
prompt: Key Passphrase
private: yes
Dans l'exemple précédent, https_passphrase est l'endroit où les données saisies
seront stockées. L'utilisateur sera invité à mettre le Key Passphrase, et comme private
est défini sur yes, la valeur ne sera pas imprimée sur l'écran lorsque l'utilisateur y
entre.
Nous pouvons utiliser des variables, des faits et des variables d'inventaire à l'aide de
{{variablename}}.On peut même se référer à des variables complexes, comme les
dictionnaires, avec une notation par points. Pour exemple une variable nommée
httpd, avec une clé nommée maxclients, sera accessible comme {{Httpd. Les clients
de Max }}. Cela fonctionne avec les faits du module de configuration trop. Par
exemple, nous pouvons obtenir l'adresse IPv4 d'une interface réseau nommée eth0 en
utilisant {{Ansible_eth0. Ipv4. adresse }}. Les variables qui sont définies dans la
section variable ne survivent pas entre différentes même manuel. Toutefois, les faits
recueillis par le module d'installation ou par set_fact ne. Cela signifie que si nous
exécutons un deuxième jeu sur les mêmes machines, ou un sous-ensemble des
machines dans un jeu antérieur, nous pouvons placer gather_facts dans la section
cible à false. La mise en place du module peut parfois prendre un certain temps à
s’executé, ce qui peut considérablement accélérer les jeux, surtout dans les jeux où la
série est réglée à une valeur faible.
La section des tâches
La section de tâche est la dernière section de chaque jeu. Il contient une liste d'actions
que nous voulons qu’Ansible effectue dans l'ordre que nous voulons qu'ils soient
effectués. Il existe plusieurs styles dans lesquels nous pouvons exprimer les
arguments de chaque module. L'extrait de code suivant est une section de tâches
ressemblant à trois styles montrés:
tasks:
- name: install apache
action: yum name=httpd state=installed
- name: configure apache
copy: src=files/httpd. conf dest=/etc/httpd/conf/httpd. conf
- name: restart apache
service:
name: httpd
state: restarted

Projet tuteuré
2016-2017 Page 15
Nous voyons ici les trois différents styles de syntaxe utilisés pour installer, configurer
et démarrer le serveur Web Apache comme il sera le cas sur une machine CentOS. La
première tâche nous montre comment installer Apache en utilisant la syntaxe
originale, ce qui nous oblige à appeler le module comme le premier dans une clé
d'action. La deuxième tâche copie le fichier de configuration d'Apache en utilisant le
deuxième style de la tâche. Dans ce style, on utilise le nom du module à l’action et sa
valeur devient simplement son argument. Enfin, la dernière tâche, le troisième style,
montre comment utiliser le module de service pour redémarrer Apache. Dans ce
style, nous utilisons le module comme la clé, mais nous fournissons les arguments en
tant que dictionnaire YAML.
Cela peut être pratique lorsque nous fournissons un grand nombre d'arguments à un
seul module, ou si le module veut les arguments sous une forme complexe. Ce
dernier style devient rapidement la manière préférée d'écrire car un nombre croissant
de modules nécessitent des arguments complexes.
Notons que les noms ne sont pas requis pour les tâches. Cependant, ils font de la
documentation et nous nous référons à chaque tâche plus tard, si nécessaire.
Les noms sont également envoyés à la console lorsque le playbook est exécuté, de
sorte que l'utilisateur peut dire ce qui se passe.
La section des gestionnaires
La section des gestionnaires est syntaxiquement la même que la section de tâche et
prend en charge le même format pour appeler les modules. Les gestionnaires ne sont
appelés que lorsque la tâche à laquelle ils ont été appelés, enregistre que quelque
chose a changé pendant l'exécution. Pour déclencher un gestionnaire, nous ajoutons
une clé de notification à la tâche avec la valeur définie au nom de la tâche.
Les gestionnaires sont exécutés s'ils ont été déclenchés auparavant lorsque Ansible a
terminé l'exécution de la liste des tâches.
Ils sont exécutés dans l'ordre où ils sont répertoriés dans la section des gestionnaires
et même si ils sont appelés plusieurs fois dans la section des tâches, elles ne seront
exécutées qu'une seule fois. Ceci est souvent utilisé pour redémarrer les démons
après leur mise à niveau et leur configuration. Le jeu suivant démontre comment
nous allons mettre à niveau un DHCP ISC (Dynamic Host Configuration Protocol) à
la dernière version, le configurer et le configurer pour démarrer au démarrage. Si ce
Playbook est exécuté sur un serveur où le démon DHCP ISC exécute déjà les versions
et les fichiers de configuration ne sont pas modifiés, le gestionnaire ne sera pas
appelé et DHCP ne sera pas redémarré. Considérons le code suivant par exemple:
- - -
- hosts: dhcp
tasks:
- name: update to latest DHCP
yum
name: dhcp

Projet tuteuré
2016-2017 Page 16
state: latest
notify: restart dhcp
- name: copy the DHCP config
copy:
src: dhcp/dhcpd. conf
dest: /etc/dhcp/dhcpd. conf
notify: restart dhcp
- name: start DHCP at boot
service:
name: dhcpd
state: started
enabled: yes
handlers:
- name: restart dhcp
service:
name: dhcpd
state: restarted
IV-Réalisation
IV.1-Installation de Ansible
Actuellement Ansible peut être exécuté à partir de toute machine avec Python 2.6 ou
2.7 installé. Les Windows ne sont pas pris en charge pour la machine de contrôle.
Ubuntu / Debian
$ sudo apt-get install software-properties-common
$ sudo apt-ppa add-référentiel: ansible / ansible
$ sudo apt-get update
$ sudo apt-get install ansible
Fedora / RHEL / CentOS
$ yum install ansible
Intallation à partir de source
$ git clone git: //github.com/ansible/ansible.git
$ cd ansible
$ sudo make install
Une fois qu’Ansible est installé, pour s’assurer qu'il fonctionne correctement en entrant
ansible --version dans la ligne de commande on peut retrouver la version.
$ ansible –version

Projet tuteuré
2016-2017 Page 17
IV.2-Architecture
Pour cette architecture nous allons utiliser quatre machines dont nous allons installer
Ansible sur une qui sera le contrôleur et les autres seront contrôlées à distance.
Dans cette architecture nous disposons de deux serveurs web et un serveur
d’application qui sont gérés à distance par la machine de contrôle.
IV.3-Déploiement
Déploiement I
Installationet configurationd’un serveur ngnix
Pour notre démonstration on va chercher à installer git, zsh, vim, htop et ngnix sur
nos serveurs.
Les rôles
Afin de mieux organiser nos tâches, on va les séparé dans des rôles afin de pouvoir
les réutiliser plus simplement.

Projet tuteuré
2016-2017 Page 18
 Les dossiers tasks vont contenir les tâches, le fichier main.yml sera chargé en
premier par défaut et peut inclure d'autres fichiers de tâches via un include.
 Les dossiers handlers vont contenir des tâches à effectuer lors de la réussite
d'autres tâches (comme le redémarrage de nginx par exemple).
 Les dossiers defaults vont contenir les variables par défaut pour ce role. Ces
variables peuvent être modifiées dans le playbook qui chargera ce role.
Création du fichier d’inventaire
Tout d'abord on va écrire un fichier d’inventaire dans /etc/ansible/hosts qui va contenir
la liste de nos serveurs.

Projet tuteuré
2016-2017 Page 19
[web]
192.168.1.10
Les crochets permettent de définir des groupes. On pourra ainsi appliquer la même
conf à tous les serveurs web. Un serveur peut appartenir à plusieurs groupes
Ici on précise que l'on a un groupe "web" qui contient un seul serveur. On peut
définir plusieurs groupes afin de séparer les serveurs suivant la configuration à y
effectuer (si on a des serveurs pour la base de données et des serveurs pour le
serveur web par exemple).
Création du playbook
Ensuite créons le fichier YAML que nous nommons playbook.yml qui va permettre de
décrire notre tâche :
---
- name: Installation des serveurs web
hosts: web
remote_user: root
var:
user: volibear
domains:
- domain: local.dev
php: no
- domain: demo.fr
php: yes
roles:
-utils
-user
-ngnix
...
Le module APT permet d'utiliser la commande apt afin d'installer différents
packages sur votre serveur. L'avantage est que Ansible n'effectuera pas cette tâche à
chaque fois. La seconde fois que vous lancerez le déploiement, il détectera que Git est
déjà installé et ne fera rien.
Détail des rôles
Rôle pour ngnix

Projet tuteuré
2016-2017 Page 20
Fichier handlers/main.yml
Fichier tasks/main.yml

Projet tuteuré
2016-2017 Page 21
Fichier tasks/php.yml
tasks/site.yml

Projet tuteuré
2016-2017 Page 22
templates/ngnix.j2
Rôle pour user
tasks/main.yml

Projet tuteuré
2016-2017 Page 23
Rôle pour utils
tasks/main.yml
Lancement du déployement
Enfin pour lancer le déploiement :
ansible-playbook -i hosts playbook.yml
Après l’execution de la commande on a ce résultat :

Projet tuteuré
2016-2017 Page 24
Allons vérifier maintenant que git a été bien installé sur la machine distante :
Et que nos sites on été créé
Capture du site local.dev

Projet tuteuré
2016-2017 Page 25
Déploiement II
Configurer Apache Utilisation Ansible sur Ubuntu
Apache est l'un des serveurs Web les plus populaires actuellement utilisés sur
Internet. Il est facile à installer et à configurer sur les distributions Linux comme
Ubuntu et Debian, comme il vient dans les dépôts de paquets et comprend une
configuration par défaut qui fonctionne hors de la boîte.
Étape 1 - Configuration Ansible
Dans cette section, nous allons configurer Ansible pour être en mesure de gérer notre
serveur.
Créons un nouveau répertoire que nous allons utiliser pour cette configuration :
mkdir ansible-apache
Déplaçons-nous dans le nouveau répertoire :
cd ~/ansible-apache/
Créons un nouveau fichier appelé ansible.cfg et éditons le :
nano ansible.cfg
Dans ce fichier, nous voulons ajouter l’option de configuration hostfile avec la
valeur hosts, au sein du groupe [defaults]. Copions le texte suivant dans le fichier
ansible.cfg, puis enregistrons et fermons-le.
[defaults]
hostfile = hosts
Ensuite, le fichier hosts doit être éditeé. Il y a beaucoup d'options disponibles pour
le fichier hosts. Cependant, nous pouvons commencer avec quelque chose de très
simple.
Créons un fichier hosts et éditons-le.
nano hosts
Copions le texte suivant dans le fichier hosts.
[apache]
secondary_server_ip ansible_ssh_user=username

Projet tuteuré
2016-2017 Page 26
Ceci spécifie un groupe d'hôtes appelé apache qui contient un hôte. Nous pouvons
remplacer secondary_server_ip avec le nom d'hôte ou l'adresse IP du serveur
secondaire ou distant qu’on veut configurer, et username avec notre nom
d' utilisateur SSH. Maintenant Ansible devrait être en mesure de se connecter à notre
serveur.
Pour vérifier que Ansible fonctionne et peut communiquer à notre hôte, nous
pouvons exécuter une commande de base ansible.
Utilisation de la commande de base ansible prend le groupe hôte, et le nom du
module: ansible <group> -m <module>. Pour exécuter la commande ping,
entrons la commande suivante :
ansible apache -m ping
La sortie devrait ressembler à ceci:
111.111.111.111 | success >> {
"changed": false,
"ping": "pong"
}
Un autre module Ansible qui est utile pour le test est le module command. Il exécute
des commandes personnalisées sur l'hôte et renvoie les résultats. Pour s’exécuter
la commande command utilise echo, une commande Unix qui fait écho à une chaîne
au terminal, entrons la commande suivante.
ansible apache -m command -a "/bin/echo hello server"
La sortie devrait ressembler à ceci:
111.111.111.111 | success | rc=0 >>
hello server
Étape 2 - Création d'un Playbook
Dans cette section, nous allons créer un playbook Ansible de base pour nous
permettre d'exécuter facilement des modules plus complexes.
Nous allons créer une version basique de playbook de la commande hello server
ci - dessus.
Créons un fichier appelé apache.yml et éditons le.
nano apache.yml
Copions le texte suivant dans le fichier, puis enregistrons et fermons-le.
---
- hosts: apache
tasks:
- name: run echo command
command: /bin/echo hello server

Projet tuteuré
2016-2017 Page 27
La déclaration hosts: apache en haut, qui dit à Ansible que nous utilisons
le groupe d'hôtes apache. Dans cet exemple, nous avons une tâche avec le
nom run echo command. Ceci est simplement une description destinée à
l'utilisateur de comprendre ce que la tâche est en train de faire. Enfin, la
ligne command: /bin/echo hello server exécute le module command avec
les arguments /bin/echo hello server.
La commande ansible-playbook est utilisée pour exécuter les playbooks, et
l'utilisation la plus simple est la suivante : Nous pouvons exécuter le playbook que
nous venons de créer avec la commande suivante :
ansible-playbook apache.yml
La sortie devrait ressembler à ceci.
PLAY [apache]
**************************************************************
***
GATHERING FACTS
**************************************************************
*
ok: [111.111.111.111]
TASK: [run echo command]
******************************************************
changed: [111.111.111.111]
PLAY RECAP
**************************************************************
******
111.111.111.111 : ok=2 changed=1
unreachable=0 failed=0
La chose la plus importante à noter ici est que playbooks ne renvoient pas la sortie
du module, donc contrairement à la commande directe, que nous avons utilisé à
l' étape 1, on ne peut pas voir si hello server a été effectivement imprimé. Cela
signifie que les playbooks sont mieux adaptés pour les tâches où vous n'avez pas
besoin de voir la sortie. Ansible nous dira s'il y avait une erreur lors de l'exécution
d'un module, de sorte que nous avons seulement besoin de cela pour savoir si
quelque chose va mal.
Étape 3 - Installation de Apache
Maintenant que nous avons les introduits playbooks, nous allons écrire les tâches
pour installer le serveur web Apache.
Normalement sur Ubuntu, l’installation d’Apache est un cas simple d'installer
le package apache2 via apt-get. Pour ce faire via Ansible, nous utilisons le
module apt de Ansible . Le module apt contient un certain nombre d'options

Projet tuteuré
2016-2017 Page 28
spécialisés pour la fonctionnalité apt-get. Les options qui nous intéressent
sont les suivantes :
 name : Le nom du package à installer, soit un nom de paquet unique ou une liste de
paquets.
 state : Accepte soit latest, absent ou present. latest assure l’installation de
la dernière version , present vérifie simplement qu'il est installé, et absen il
supprime si elle est installée.
 update_cache : Mise à jour du cache (via apt-get update) si elle est activée,
pour nous assurer qu'il est à jour.
Maintenant , nous allons mettre à jour notre Playbook apache.yml avec le module
apt au lieu du module command. Ouvrez le fichier apache.yml pour l’éditer
à nouveau.
nano apache.yml
Supprimons l’ancien texte et copions le texte suivant dan celui-ci :
---
- hosts: apache
sudo: yes
tasks:
- name: install apache2
apt: name=apache2 update_cache=yes state=latest
La ligne apt installe le package apache2 ( name=apache2) et garantit que nous
avons mis à jour le cache ( update_cache=yes).
Maintenant, exécutons le playbook.
ansible-playbook apache.yml --ask-sudo-pass
Le drapeau --ask-sudo-pass nous demandera le mot de passe sudo sur le
serveur secondaire. Cela est nécessaire parce que l'installation nécessite
des privilèges root .
La sortie devrait ressembler à ceci.
PLAY [apache]
**************************************************************
***
GATHERING FACTS
**************************************************************
*
ok: [111.111.111.111]
TASK: [install apache2]
*******************************************************
changed: [111.111.111.111]

Projet tuteuré
2016-2017 Page 29
PLAY RECAP
**************************************************************
******
111.111.111.111 : ok=2 changed=1
Si nous visitons le nom d'hôte de votre serveur secondaire ou l' adresse IP dans votre
navigateur, nous devrions maintenant obtenir une page par défaut Apache2
Ubuntu pour nous saluer. Cela signifie que nous avons une installation fonctionnelle
d’Apache sur notre serveur, et que nous ne somme pas connecté manuellement
avant d’exécuter une commande.
Un concept important à noter à ce stade est idempotence , qui sous - tend la façon dont
les modules ansible sont censés se comporter. L'idée est que nous pouvons exécuter
la même commande à plusieurs reprises, mais si tout a été configuré sur la première
manche, les essais ultérieurs ne feront aucun changement.
Par exemple, exécutons à nouveau la même commande playbook.
La sortie devrait ressembler à ceci. Notons la section changed=0.
PLAY [apache]
**************************************************************
***
GATHERING FACTS
**************************************************************
*
ok: [111.111.111.111]
*******************************************************
ok: [111.111.111.111]
PLAY RECAP
**************************************************************
******
111.111.111.111 : ok=2 changed=0
Cela nous indique que le paquet apache2 a déjà été installé, donc rien n’a changé.
Étape 4 - Configuration des modules Apache
Maintenant que Apache est installé, il faut activer un module pour être utilisé par
Apache.
Faisons en sorte que le module mod_rewrite soit activé pour Apache. Via SSH,
cela peut se faire facilement en utilisant a2enmod et redémarrer
Apache. Cependant, nous pouvons aussi le faire très facilement avec Ansible

Projet tuteuré
2016-2017 Page 30
en utilisant le module apache2_module et un gestionnaire de tâches pour
redémarrer apache2.
Le module apache2_module prend deux options:
 name - Le nom du module pour permettre, par exemple rewrite.
 state- Soit present ou absent, selon si le module doit être activé ou désactivé.
Ouvrons apache.yml pour l' édition.
nano apache.yml
Mettons à jour le fichier pour inclure cette tâche. Le fichier devrait ressembler à ceci:
---
- hosts: apache
sudo: yes
tasks:
- name: enabled mod_rewrite
apache2_module: name=rewrite state=present
Cependant, nous avons besoin de redémarrer apache2 après que le module est
activé. Une option consiste à ajouter dans une tâche de redémarrer apache2, mais
nous ne voulons pas que pour exécuter chaque fois que nous appliquons notre
Playbook. Pour contourner ce problème, nous avons besoin d'utiliser un gestionnaire
de tâches . Le mode de fonctionnement des gestionnaires est qu'on peut dire à une
tâche de notifier un gestionnaire quand il a changé, et le gestionnaire ne fonctionne
que lorsque la tâche a été modifiée.
Pour ce faire, nous devons ajouter la possibilité notify dans la tâche
apache2_module, puis nous pouvons utiliser le module service pour
redémarrer apache2 dans un gestionnaire.
Cela se traduit par un playbook qui ressemble à ceci:
---
- hosts: apache
sudo: yes
tasks:
notify:
- restart apache2
handlers:
- name: restart apache2

Projet tuteuré
2016-2017 Page 31
service: name=apache2 state=restarted
Maintenant, relançons le playbook.
La sortie devrait ressembler à:
PLAY [apache]
**************************************************************
***
GATHERING FACTS
**************************************************************
*
ok: [111.111.111.111]
*******************************************************
ok: [111.111.111.111]
TASK: [enabled mod_rewrite]
***************************************************
changed: [111.111.111.111]
NOTIFIED: [restart apache2]
***************************************************
changed: [111.111.111.111]
PLAY RECAP
**************************************************************
******
111.111.111.111 : ok=4 changed=2
Étape 5 - Configuration des options Apache
Maintenant que nous avons une installation fonctionnelle d’Apache, avec nos
modules nécessaires activés, nous devons configurer Apache.
Par défaut Apache écoute sur le port 80 pour tout le trafic HTTP. Nous voulons
qu’Apache écoute sur le port 8081 à la place de 80. Avec la configuration par défaut
d'Apache sur Ubuntu , il y a deux fichiers qui doivent être mis à jour:
/etc/apache2/ports.conf
Listen 80
/etc/apache2/sites-available/000-default.conf
<VirtualHost *:80>
Pour ce faire, nous pouvons utiliser le module lineinfile . Ce module est
incroyablement puissant et par l'utilisation de ses nombreuses options de
configuration différentes, il nous permet d'effectuer toutes sortes de modifications

Projet tuteuré
2016-2017 Page 32
apportées à un fichier existant sur l'hôte. Pour cet exemple, nous allons utiliser les
options suivantes:
 dest - Le fichier va être mis à jour dans le cadre de la commande.
 regexp - Expression régulière à utiliser pour correspondre à une ligne existante à
remplacer.
 line - La ligne à insérer dans le fichier, en remplaçant soit la ligne regexp ou une
nouvelle ligne sur la fin.
 state - soit present ou absent.
Ce que nous devons faire pour mettre à jour le port à partir de 80 à 8081 est
de chercher les lignes existantes qui définissent le port 80 et les changer pour
définir le port 8081.
Ouvrons le fichier apache.yml pour le modifier.
nano apache.yml
Modifions les lignes supplémentaires afin que le fichier ressemble à ceci:
---
- hosts: apache
sudo: yes
tasks:
notify:
- restart apache2
- name: apache2 listen on port 8081
lineinfile: dest=/etc/apache2/ports.conf regexp="^Listen
80" line="Listen 8081" state=present
notify:
- restart apache2
- name: apache2 virtualhost on port 8081
lineinfile: dest=/etc/apache2/sites-available/000-
default.conf regexp="^<VirtualHost *:80>" line="<VirtualHost
*:8081>" state=present
notify:
- restart apache2
handlers:
Il est important de noter que nous avons également besoin de redémarrer apache2
dans le cadre de ce processus, et que nous pouvons réutiliser le même gestionnaire

Projet tuteuré
2016-2017 Page 33
, mais le hanlder ne sera déclenchée une fois que malgré les multiples tâches
modifiées.
Maintenant, exécutons le playbook.
Une fois que Ansible a terminée, nous devriez être en mesure de visiter notre hôte
dans notre navigateur et il répondra sur le port 8081, plutôt que le port 80. Dans
la plupart des navigateurs web, ceci peut être facilement obtenue en ajoutant :port
à l'extrémité de l'URL suivante : .http://111.111.111.111:8081/
Étape 6 - Configuration des hôtes virtuels
Ansible dispose d'un couple de modules qui offrent la possibilité de copier un fichier
de modèle local (à Ansible) sur les hôtes. Les deux modules les plus couramment
utilisés à cette fin sont le module copie et le module modèle . Les modules copy
copient un fichier en l' état et ne fait aucune modification, alors que les plus
puissants modules de copies template à travers un modèle et applique
la substitution de variable dans les zones spécifiées à l'aide des crochets doubles
bouclés (c. {{ variable }}).
Dans cette section, nous allons utiliser le module template pour configurer un
nouvel hôte virtuel sur votre serveur
Créons une configuration de l'hôte virtuel
La première étape consiste à créer une nouvelle configuration de l'hôte virtuel. Nous
allons créer le fichier de configuration de l'hôte virtuel sur le serveur maître et le
télécharger sur le serveur secondaire en utilisant Ansible.
<VirtualHost *:8081>
ServerAdmin webmaster@example.com
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example.com
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Créons un nouveau fichier appelé virtualhost.conf.
nano virtualhost.conf
Collons le texte suivant dans virtualhost.conf. Parce que nous utilisons
des templates, il est une bonne idée de changer les valeurs codées dures ci - dessus
pour les variables, pour les rendre faciles à changer dans l'avenir.
<VirtualHost *:{{ http_port }}>
ServerAdmin webmaster@{{ domain }}
ServerName {{ domain }}
ServerAlias www.{{ domain }}

Projet tuteuré
2016-2017 Page 34
DocumentRoot /var/www/{{ domain }}
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Utilisons des variables de template
Ensuite, nous avons besoin de mettre à jour notre Playbook pour faire sortir le
template et utiliser les variables.
La première étape consiste à ajouter dans une section le jeu pour les variables. Il
est appelé vars et va sur le même niveau que hosts, sudo, tasks
et handlers. Nous devons mettre les deux variables utilisées dans le template ci -
dessus, et nous allons changer le port vers 80 dans le processus.
---
- hosts: apache
sudo: yes
vars:
http_port: 80
domain: example.com
tasks:
...
Les variables peuvent être utilisées dans les tâches et les templates, afin que nous
puissions mettre à jour nos existants modules lineinfile à utiliser le http_port
spécifié, plutôt que 8081 nous avons précisé auparavant. La variable doit être
ajoutée dans la ligne, et l'option regexp doit être mis à jour de sorte qu'il ne cherche
pas un port spécifique. Les changements vont ressembler à ceci:
lineinfile: dest=/etc/apache2/ports.conf regexp="^Listen "
line="Listen {{ http_port }}" state=present
lineinfile: dest=/etc/apache2/sites-available/000-default.conf
regexp="^<VirtualHost *:" line="<VirtualHost *:{{ http_port
}}>"
Ajoutons un module Template
L'étape suivante consiste à ajouter dans le module template pour pousser le fichier
de configuration sur l'hôte. Nous allons utiliser ces options pour y arriver:
 dest - Le chemin du fichier de destination pour enregistrer le template mis à jour sur
l'hôte, soit/etc/apache2/sites-available/{{ domain }}.conf.
 src - Le fichier template de la source, à savoir virtualhost.conf.
En appliquant ces derniers à notre Playbook, cela se traduira par une tâche qui
ressemble à ceci:
- name: create virtual host file

Projet tuteuré
2016-2017 Page 35
template: src=virtualhost.conf dest=/etc/apache2/sites-
available/{{ domain }}.conf
Activons l'hôte virtuel
Ce que nous devons faire maintenant est de permettre l'hôte virtuel dans
Apache. Cela peut se faire de deux façons: en exécutant la commande sudo
a2ensite example.com ou un lien symbolique manuellement le fichier de
configuration dans /etc/apache2/sites-enabled/. La première option est plus
sûre, car elle permet à Apache de contrôler le processus. Pour cela, le module
command est utilisé à nouveau.
- name: a2ensite {{ domain }}
command: a2ensite {{ domain }}
notify:
- restart apache2
Empêcher le travail supplémentaire
Enfin, le module command doit savoir quand il doit et ne doit pas fonctionner,
de sorte que le module ne soit pas exécuté inutilement si le playbook est exécuté
plusieurs fois. Dans notre cas, il ne doit être exécuté si le fichier.conf n'a pas
encore été créé sur l'hôte.
Ceci est fait en utilisant l'option creates, qui vous permet de dire au module quel
fichier est créé lors de l'exécution du module. Si le fichier existe, le module ne
fonctionne pas
Les changements vont ressembler à ceci:
args:
creates: /etc/apache2/sites-enabled/{{ domain }}.conf
notify:
- restart apache2
Il est important de noter que l'utilisation de la section args de la tâche. Ceci est un
moyen facultatif de la liste des options du module, et dans ce cas élimine toute
confusion entre ce qui est une option de module et quelle est la commande elle -
même.
Playbook final apache.yml
Maintenant, nous allons appliquer ces changements. Ouvrons apache.yml.

Projet tuteuré
2016-2017 Page 36
nano apache.yml
Avec tous les changements ci - dessus, changeons notre playbook apache.yml
pour ressembler à ceci.
---
- hosts: apache
sudo: yes
vars:
http_port: 80
domain: example.com
tasks:
notify:
- restart apache2
- name: apache2 listen on port {{ http_port }}
" line="Listen {{ http_port }}" state=present
notify:
- restart apache2
- name: apache2 virtualhost on port {{ http_port }}
default.conf regexp="^<VirtualHost *:" line="<VirtualHost
*:{{ http_port }}>"
notify:
- restart apache2
args:
notify:
- restart apache2
handlers:
Enregistrons et fermons le fichier, puis exécutons le playbook.

Projet tuteuré
2016-2017 Page 37
Si nous visitez maintenant le nom d' hôte ou l' adresse IP de notre serveur
secondaire dans notre navigateur, nous verrons qu'il répond sur le port 80 à
nouveau, pas le port 8081. Ensuite, visitons le domaine que nous avons spécifié
pour le nouvel hôte virtuel. Parce que nous n'avons pas ajouté de fichiers encore, il
devrait montrer une page Apache 404 d'erreur plutôt que la page d'accueil Apache.
Étape 7 - Utilisation d'un référentiel Git pour notre site Web
Dans cette section, nous allons utiliser Ansible pour cloner un dépôt Git afin de
mettre en place le contenu de notre site web.
Le module git a beaucoup d'options:
 dest - Le chemin sur l'hôte où le dépôt sera vérifié .
 repo - L'URL du référentiel qui sera cloné. Doit être accessible par l'hôte.
 update- Lorsqu'elle est réglée no, ce qui empêche Ansible de mettre à jour le
référentiel quand il existe déjà.
 accept_hostkey - Indique à SSH d'accepter une clé d'hôte inconnu lors de
la connexion via SSH
La tâche git ressemblera à ceci:
- name: clone basic html template
git: repo=https://github.com/do-community/ansible-apache-
tutorial.git dest=/var/www/example.com update=no
Mis à jour de la tâche apt pour ressembler à ceci:
- name: install packages
apt: name={{ item }} update_cache=yes state=latest
with_items:
- apache2
- git
La liste des articles utilise la itemvariable et exécuter la tâche pour chaque élément
dans la liste.
Ouvrons à apache.ymlnouveau.
nano apache.yml
Mettons à jour le livre de jeux pour correspondre à ce qui suit:
---
- hosts: apache
sudo: yes
vars:
http_port: 80
domain: example.com

Projet tuteuré
2016-2017 Page 38
tasks:
- name: install packages
apt: name={{ item }} update_cache=yes state=latest
with_items:
- apache2
- git
notify:
- restart apache2
- name: apache2 listen on port {{ http_port }}
" line="Listen {{ http_port }}" state=present
notify:
- restart apache2
- name: apache2 virtualhost on port {{ http_port }}
default.conf regexp="^<VirtualHost *:" line="<VirtualHost
*:{{ http_port }}>"
notify:
- restart apache2
args:
notify:
- restart apache2
- name: clone basic html template
git: repo=https://github.com/do-community/ansible-
apache-tutorial.git dest=/var/www/example.com update=no
handlers:
Enregistrons le fichier et lançons le playbook.
Nous devrions maintenant voir autre chose qu'une erreur 404 lorsque nous visitons
l'hôte virtuel à partir de l'étape 6.

Projet tuteuré
2016-2017 Page 39
Conclusion
En somme, ansible est un outil puissant permettant la gestion de plusieurs
machines à distance. A travers ce document nous avons montré quelques tâches
qu’on peut effectuer avec ansible. Ce dernier nous a permis de déployer des
applications, de démarrer les services, de configurer et de déployer les serveurs web
à distance.

Projet tuteuré
2016-2017 Page 40
REFERENCE
[1] Ansible Documentation, 24 Fevrier 2017 [En ligne]. Disponible :
http://docs.ansible.com/ansible. [Consulté le 02 Février 2017].
[2] Automatiser deploiement gestion serveurs ansible, Février 2016. [En ligne]. Disponible :
https://buzut.fr/automatiser-deploiement-gestion-serveurs-ansible/ [Consulté le
02 02 Février 2017].
[3] Documentation, 2017 [En ligne]. Disponible : www.packtpub.com
. [Consulté le 02 Février 2017].

Ansible

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

Similaire à Ansible

Similaire à Ansible (20)

Dernier

Dernier (20)

Ansible