RAPPORT DE PROJET DE FIN D’ETUDES

Filière : Ingénierie Systèmes, Réseaux et Sécurité d’information

Mise en place d’une solution

d’automatisation et gestion de
configuration LAN à l’aide d’ANSIBLE

Effectué à :
Intelcom SA Group Satec

Réalisé par : Encadré par :

Soufiane MEDDOUN Pr. Brahim SABIRI
Mohammed ABDOU-RABIH
Yassine MACHLOUKH

Soutenu le 31/07/2022 Devant le jury :

Pr. :
Pr. :
Pr. :

Année Universitaire 2021-2022

 Remerciements
Avant d’entamer la rédaction de ce rapport et à travers ce modeste travail, nous tenons à
remercier tous ceux qui ont orienté les différentes étapes de ce travail jusqu’à son terme,
par leurs estimables conseils et contributions et particulièrement à :

-Pr. Brahim SABIRI pour son encadrement et son suivi tout au long de notre projet de
fin d’étude, on le remercie aussi pour ses conseils, sa disponibilité et ses critiques.

- Tout le corps administratif de la Faculté des Sciences et Techniques de Settat et tous

nos Formateurs, pour le suivi de notre formation, leurs disponibilités, leur assistance, et pour
les renseignements qu’ils nous ont fournis durant notre année de formation.

Nous tenons finalement à remercier encore une fois les membres du jury et à exprimer
l'expression de nos gratitudes à nos familles et nos respects à tous nos collègues. Nous
remercions également tous ceux, qui ont contribué de près ou de loin à la réalisation de ce
travail.

1
 Résumé
Même que les technologies sous-jacentes ont largement évolué, la gestion des réseaux
continue de stagner depuis des décennies. Les réseaux sont généralement conçus, exploités
et entretenus manuellement. Toutefois, les approches traditionnelles et manuelles adoptées
jusqu'ici pour configurer et mettre à jour les réseaux sont lentes et propices aux erreurs et
cela demande beaucoup d'efforts, ce qui entraîne des coûts opérationnels 2 à 3 fois plus
élevés que le coût du réseau. Elles ne permettent donc pas de satisfaire efficacement les
exigences des charges de travail qui évoluent en permanence. Pour cela, l'automatisation
des réseaux permet aux équipes de Réseaux et Sécurité de configurer, mettre à l'échelle,
protéger et intégrer l'infrastructure réseau et les services d'applications plus rapidement et
flexibilité que si ces tâches quotidiennes étaient effectuées manuellement. Aussi tout en
répondant efficacement aux demandes des entreprises modernes, et de réduire les erreurs
humaines, le temps et de diminuer les frais de recrutement, et aussi de faire plus mieux.
Comme information supplémentaire, le mouvement DevOps appliqué au réseau et connu
sous les noms de NetDevOps est responsable de l’adoption de l’automatisation dans les
réseaux.

Intelcom toujours cherche à améliorer l'efficacité de ses employés, et de satisfaire tous les
besoins de ses clients en assurant de les utiliser les solutions les plus à jour et les meilleures
sur le marché du travail, qui leur permettent à la fois de réduire les coûts et d'augmenter la
productivité, tout en garantissant une bonne qualité de service. C'est la raison qui a poussé
Intelcom à penser de l'utilisation Ansible pour automatiser les réseaux afin qu’il soit
considéré comme l’avenir des réseaux.

Le présent rapport synthétise le travail effectué dans le cadre de ce projet de fin d’études qui
s’est déroulé au sein de la société Intelcom SA Group Satec Témara, en vue de l’obtention du
diplôme d’ingénieure d’Etat en Réseaux et Systèmes de Télécommunications dont le thème
principal est la Mise en place d’une solution d’automatisation et gestion de configuration
Réseau à l’aide d’ANSIBLE (Outil NetDevOps).

L’objectif de ce projet porte sur la mise en place d'une solution Ansible pour automatiser
plusieurs tâches effectuées quotidiennement avec une grande infrastructure réseau qui
constitué d'un ensemble des équipements réseau et sécurité pour justifier le bon
fonctionnement et éclaircir les points forts et l'importance de la solution sur le marché du
travail.

2
Pour y arriver à cet objectif, il était nécessaire de rédiger ce rapport en cinq chapitres
principaux. Le premier chapitre est consacré pour définir et présenter l’entreprise d’accueil
Intelcom et contexte général du projet, le deuxième chapitre est réservé pour une étude
comparative des différentes solutions, puis le troisième chapitre détaille une étude
théorique du ansible, le quatrième chapitre décrit l'état de l'art des technologies utilisés sur
ce projet, enfin le dernier chapitre pour présenter le déploiement et la mise en place de la
solution sur une grande architecture réseau.

3
 Abstract
While the underlying technologies have evolved significantly, network management has
remained stagnant for decades. Networks are typically designed, operated and maintained
manually. However, the traditional, manual approaches taken to date to configure and
update networks are slow and error-prone, resulting in operational costs 2 to 3 times the
cost of the network. This means that they cannot effectively meet the demands of ever-
changing workloads. Network automation enables Network and Security teams to configure,
scale, protect and integrate network infrastructure and application services more quickly
and flexibly than if these daily tasks were performed manually. Also while efficiently meeting
the demands of modern businesses, and reduce human error and recruiting costs. As
additional information, the DevOps movement applied to networking and known as
NetDevOps is responsible for the adoption of automation in networking.

Intelcom has always sought to improve the efficiency of its employees, and to satisfy all the
needs of its customers by ensuring that they use the most up-to-date and best solutions on
the market, which allow them to both reduce costs and increase productivity, while
guaranteeing a good quality of service. This is the reason why Intelcom thought of using
Ansible to automate networks so that it could be considered as the future of networks.

This report summarizes the work done as part of my graduation project which took place
within the company Intelcom SA Group Satec Témara, in order to obtain the diploma of
engineer of State in Networks and Systems of Telecommunications and whose main theme is
the Implementation of a solution of automation and management of Network configuration
using ANSIBLE (NetDevOps tool).

The objective of this project is to implement an Ansible solution to automate several tasks
performed daily with a large network infrastructure that consists of a set of network and
security equipment to justify the proper functioning and clarify the strengths and
importance of the solution on the job market.

To achieve this goal, it was necessary to write my report in five main chapters. The first
chapter is dedicated to define and present the host company Intelcom and general context
of the project, the second chapter is reserved for a comparative study of the different
solutions, then the third chapter details a theoretical study of the ansible, the fourth chapter
describes the state of the art of the technologies used on this project, finally the last chapter
to present the deployment and the implementation of the solution on a large network
architecture.

4
 Liste des Figures
Figure 1.1 : La Présence mondiale de SATEC........................................................................................16
Figure 1.2 : Organigramme D'INTELCOM.............................................................................................18
Figure 1.3 : Diagramme de Gantt.........................................................................................................21
Figure 2.4 : Architecture d’Ansible.......................................................................................................24
Figure 2.5 : Architecture de Chef..........................................................................................................25
Figure 2.6 : Architecture de Puppet......................................................................................................26
Figure 2.7 : Mécanisme Push/Pull........................................................................................................27
Figure 2.8 : Principe de fonctionnement d’Ansible...............................................................................31
Figure 2.9 : Progression de Ansible avec Réseau..................................................................................31
Figure 2.10 : Domaines supportés par Ansible.....................................................................................32
Figure 2.11 : Les équipes qui travaillent sur Ansible.............................................................................32
Figure 2.12 : Produits Cisco supportés par Ansible...............................................................................33
Figure 3.13 : Architecture générale de la solution Ansible...................................................................35
Figure 3.14 : Exemple fichier Ansible Inventory...................................................................................36
Figure 3.15 : Exemple fichier Ansible Playbook....................................................................................38
Figure 3.16 : Variables Ansible Facts....................................................................................................39
Figure 3.17 : Exemple de l'exécution de Facts......................................................................................39
Figure 3.18 : Exemple d’Ansible Rôles..................................................................................................40
Figure 3.19 : Schéma de Modèles Jinja2...............................................................................................41
Figure 3.20 : Exemple d'une partie de fichier ansible.cfg.....................................................................43
Figure 3.21 : Prix d'Ansible Tower........................................................................................................45
Figure 3.22 : Page d'accueil Ansible Galaxy..........................................................................................46
Figure 4.23 : Architecture illustrée pour VLAN.....................................................................................50
Figure 4.24 : Mécanisme de fonctionnement d'OSPF...........................................................................51
Figure 4.25 : Connexions Internet VPN.................................................................................................53
Figure 4.26 : VPN de site à site.............................................................................................................54
Figure 4.27 : VPN d'accès à distance....................................................................................................55
Figure 4.28 : Encapsulation GRE...........................................................................................................56
Figure 5.29 : Interface graphique Ansible tower..................................................................................61
Figure 5.30 : Architecture cible de déploiement.................................................................................63
Figure 5.31 : Fichier d’inventory...........................................................................................................66
Figure 5.32 : Les rôles de ce projet.......................................................................................................68
Figure 5.33 : Playbook d'exécution des Rôles.......................................................................................69
Figure 5.34 : Playbook de configuration du VLAN................................................................................70
Figure 5.35 : Tasks de rôle lié à la configuration OSPF.........................................................................71
Figure 5.36 : Vars de rôle lié à la configuration OSPF...........................................................................72
Figure 5.37 : Tasks de rôle lié à la configuration EIGRP........................................................................72
Figure 5.38 : Tasks de rôle lié à la configuration AAA...........................................................................73
Figure 5.39 : File de rôle lié à la configuration AAA..............................................................................73
Figure 5.40 : Vars de rôle lié à la configuration AAA.............................................................................73
Figure 5.41 : Handlers de rôle lié à la configuration AAA.....................................................................74
Figure 5.42 : Tasks de rôle lié à la configuration GRE...........................................................................74
Figure 5.43 : Tasks de rôle lié à la configuration IPsec..........................................................................75
Figure 5.44 : Tasks de rôle lié à la configuration VPN...........................................................................76

5
Figure 5.45 : File asal1 de rôle lié à la configuration VPN.....................................................................76
Figure 5.46 : File asal2 de rôle lié à la configuration VPN.....................................................................76
Figure 5.47 : Tasks de rôle lié à la configuration NTP...........................................................................78
Figure 5.48 : Vars de rôle lié à la configuration NTP.............................................................................78
Figure 5.49 : Tasks de rôle lié à la configuration DNS...........................................................................79
Figure 5.50 : Playbook de Backup.........................................................................................................80
Figure 5.51 : Playbook de Restore........................................................................................................80
Figure 5.52 : Playbook d'exécution du template Jinja2........................................................................81
Figure 5.53 : Template Jinja2................................................................................................................81
Figure 5.54 : Exemple de Résultat d’exécution de playbook................................................................81
Figure 5.55 : Exemple Playbook de Troubleshooting............................................................................83

Liste des Tableaux

6
Tableau 2.1 : Récapitulatif de comparaison des outils d'automatisation.............................................29
Tableau 5.2 : Les équipements Cisco utilisés........................................................................................64
Tableau 5.3 : Adressage d’Architecture................................................................................................64

Liste des Acronymes

7
 AAA Authentication, Authorization, Accounting
ASA Adaptive Security Appliance
ACL Access Control List
CLI Command Line Interface
DNS Domain Name System
EIGRP Enhanced Interior Gateway Routing Protocol
GRE Generic Routing Encapsulation
IPSEC Internet Protocol Security
IOS Internetwork Operating System
JSON JavaScript Object Notation
LACP Link Aggregation Control Protocol
NTP Network Time Protocol
NAT Network Address Translation
OSPF Open Shortest Path First
PAT Port Address Translation
SSH Secure SHell
VRF Virtual Routing and Forwarding
VLAN Virtual Local Area Network
VPN Virtual Private Network
YAML Yet Another Markdown Language

Les Termes Techniques

DevOps : est un ensemble de pratiques qui met l’accent sur la collaboration et la
communication entre les développeurs de logiciels et les professionnels

8
d’exploitation systèmes, en automatisant le processus de livraison de logiciels et les
changements d’infrastructure. Le terme DevOps est né de l’union du «Development»
et des «Operations» dont l’objectif est favorisé une meilleure communication entre
les deux équipes.

NetDevOps : est l'application des principes et comportements DevOps aux

opérations réseau pour automatiser l'infrastructure du réseau.

JSON : JavaScript Objet Notation est un langage léger d’échange de données

textuelles. Il permet de représenter des données structurées dans un code comme
XML par exemple.

SSH : Secure Shell est un protocole de communication sécurisé, il permet la

connexion d'une machine distante via une liaison sécurisée dans le but de transférer
des fichiers ou des commandes en toute sécurité.

DNS : Domain Name System est le service informatique distribué utilisé pour traduire
les noms de domaine Internet en adresse IP.

Table des Matières

Remerciements...................................................................................................................1
Résumé...............................................................................................................................2

9
Abstract..............................................................................................................................4
Liste des Figures..................................................................................................................5
Liste des Tableaux...............................................................................................................7
Liste des Acronymes...........................................................................................................8
Les Termes Techniques.......................................................................................................9
Table des Matières............................................................................................................10
Introduction générale.......................................................................................................14
CHAPITRE 1 : Contexte général du projet..........................................................................15
Introduction......................................................................................................................15
I. Présentation de L’organisme d’accueil..................................................................15
1. Aperçu sur INTELCOM...............................................................................................15
2. Localisation................................................................................................................16
3. Secteur D’activité.......................................................................................................16
4. Organigramme fonctionnel........................................................................................17
II. Présentation du projet..........................................................................................19
1. Contexte du projet.....................................................................................................19
2. Problématique...........................................................................................................19
3. Objectifs du projet.....................................................................................................19
4. Démarche..................................................................................................................20
5. Déroulement et planification du projet.....................................................................20
Conclusion........................................................................................................................22
Chapitre 2 : Etude comparative des différentes solutions................................................23
Introduction......................................................................................................................23
I. Benchmarking des outils disponibles.....................................................................24
1. Ansible.......................................................................................................................24
2. CHEF..........................................................................................................................24
3. PUPPET......................................................................................................................26
4. Choix des critères......................................................................................................27
5. Comparaison et synthèse..........................................................................................28
6. Pourquoi Ansible ?.....................................................................................................29
II. Présentation générale de Ansible..........................................................................30
1. Historique..................................................................................................................30
2. Notions et Concepts..................................................................................................30
3. Progression de Ansible avec Réseau..........................................................................31
III. Les produits supportés..........................................................................................32
1. Tous les produits.......................................................................................................32

10
 2. Produits CISCO...........................................................................................................32
Conclusion........................................................................................................................33
Chapitre 3 : Etude théorique du Ansible...........................................................................34
Introduction......................................................................................................................34
I. Composants principaux de Ansible........................................................................35
1. Architecture de Ansible.............................................................................................35
2. Inventory...................................................................................................................35
3. Playbook....................................................................................................................36
4. Modules.....................................................................................................................38
5. Facts..........................................................................................................................38
6. Roles..........................................................................................................................39
II. Composants supplémentaires...............................................................................40
1. Modèles Jinja2...........................................................................................................40
2. Ansible Vault..............................................................................................................41
3. Mode ad-hoc.............................................................................................................42
4. Langage YAML...........................................................................................................42
III. Les éléments de Configuration..............................................................................42
1. Ansible Configuration file..........................................................................................42
2. Ansible Forks.............................................................................................................44
3. Ansible Strategy.........................................................................................................44
4. Ansible Asynchronous...............................................................................................44
IV. Graphical User Interface........................................................................................45
1. ANSIBLE TOWER........................................................................................................45
2. AWX...........................................................................................................................46
V. Documentation......................................................................................................46
1. Ansible Galaxy...........................................................................................................46
2. Ansible-doc................................................................................................................47
Conclusion........................................................................................................................47
Chapitre 4 : Etat de l'art des technologies.........................................................................48
Introduction......................................................................................................................48
I. Les équipements utilisés sur ce projet...................................................................49
1. IOS.............................................................................................................................49
2. ASA............................................................................................................................49
II. Les technologies utilisées sur ce projet..................................................................49
1. VLAN..........................................................................................................................49
2. OSPF..........................................................................................................................50

11
 3. EIGRP.........................................................................................................................51
4. AAA............................................................................................................................52
5. NTP............................................................................................................................53
6. VPN.……………………………………………………………………………………………………………………….53
7. IPSEC..........................................................................................................................55
8. GRE…..........................................................................................……………………………..56
Conclusion........................................................................................................................56
Chapitre 5 : Le déploiement et la mise en place de la solution..........................................57
Introduction......................................................................................................................57
I. Outils de Simulation..............................................................................................58
1. EVE-NG......................................................................................................................58
2. Distribution Linux : Debian........................................................................................58
3. Git..............................................................................................................................59
II. Installation............................................................................................................59
1. ANSIBLE (CLI).............................................................................................................59
2. GIT.............................................................................................................................60
3. Ansible Tower............................................................................................................60
III. Architecture cible..................................................................................................61
1. Les équipements utilisés............................................................................................64
2. Adressage..................................................................................................................64
IV. Déploiement de la solution...................................................................................65
1. Démarche de déploiement........................................................................................65
2. Automatisation de configuration VLAN.....................................................................69
3. Automatisation de configuration OSPF......................................................................70
4. Automatisation de configuration EIGRP....................................................................72
5. Automatisation de configuration AAA.......................................................................72
6. Automatisation de configuration GRE.......................................................................74
7. Automatisation de configuration IPSEC.....................................................................74
8. Automatisation de configuration VPN Site to Site.....................................................75
9. Automatisation de configuration NTP.......................................................................77
10. Automatisation de configuration DNS.......................................................................78
11. Automatisation de BACKUP / RESTORE.....................................................................79
12. Collecte les informations des périphériques par Template Jinja2.............................80
V. Tests et Vérification...............................................................................................82
Conclusion........................................................................................................................83
Conclusion générale et perspectives.................................................................................84

12
 Webographie....................................................................................................................85

Introduction générale
Aujourd’hui, la diversité des équipements de réseaux est en phase de forte croissance et
impose une plus grande des moyens de configuration. Il ne s’agit plus de la configuration
mais de prendre en compte suivant les souhaits du client. Sans aucun doute, si vous êtes

13
responsable d’un réseau et sécurité sur une entreprise, vous savez que de nombreuses
opérations manuelles sont effectuées via l’interface de ligne de commande (CLI). Il n’est pas
surprenant que le principal défi que rencontrent des équipes en matière de réseau consiste
à améliorer leur agilité. Pour cela, Ansible peut fournir aux entreprises des manières
efficaces que les professionnels non-experts peuvent utiliser afin de répondre au besoin
croissant de la configuration de réseau au sein de l’entreprise.

Alors l’automatisation correspond à l'utilisation de technologies pour automatiser certaines

tâches normalement effectuées par des êtres humains. Elle vise à faire plus, mieux, et plus
vite, avec une intervention humaine minimale, voire nulle. Donc l’automatisation du réseau
est le processus d’automatisation permet de supprimer les étapes manuelles de la
configuration, de la gestion, des tests, du déploiement et du fonctionnement des
périphériques physiques et virtuels au sein d’un réseau. Les tâches et les fonctions
quotidiennes du réseau étant automatisées et les processus répétitifs étant contrôlés et
gérés automatiquement, la disponibilité du service réseau s’améliore.

En d’autres termes, l'automatisation des réseaux s'appuie sur une logique programmable
pour créer des taches reproductibles qui permet de gérer les ressources et les services des
réseaux à l'aide des chaînes de scripts programmées au niveau de l'interface en ligne de
commande d'un système d'exploitation ou d'un logiciel d'automatisation intégré. Avec
l’avènement des réseaux virtualisés et des services Cloud, l’automatisation est une stratégie
indispensable pour aider les équipes de réseaux et sécurité à fournir des services offrant plus
de rapidité, de cohérence et de sécurité, avec une intervention humaine réduite.

En guise de conclusion, on peut dire que la nécessité de gérer une infrastructure avec des
centaines des équipements réseau et sécurité et d’assurer leur bon fonctionnement peut
exercer une pression énorme sur les équipes de Réseaux et Sécurité. Non seulement les
infrastructures ont besoin d'une surveillance constante pour assurer leurs performances,
mais les tâches quotidiennes répétitives qu'ils génèrent, ils peuvent également entraîner une
fatigue. En effet, la gestion automatisée des infrastructures des clients peut réduire du
temps et des efforts aux équipes et le risque d'erreurs. Donc Ansible a justement été créé
pour automatiser ces tâches et vous faire gagner du temps.

14
 CHAPITRE 1 :
Contexte général du
projet
Introduction
Dans ce chapitre, nous éclaircissons le contexte général du projet en projetant la lumière
d’abord sur l’organisme d’accueil et ensuite sur le projet et sa problématique ainsi sur les
objectifs et la démarche que nous avons suivi durant la réalisation, ainsi que la planification
suivie pour atteindre nos objectifs.

1. Présentation de L’organisme d’accueil

2. Aperçu sur INTELCOM
INTELCOM est une société qui appartient au Groupe SATEC, entreprise multinationale
espagnole d’intégration de solutions technologiques, spécialisée dans les services avancés
liés aux nouvelles Technologies de l’Information. Elle a privilégié depuis 1987 la collaboration
avec ses clients à travers l’innovation dans les processus, les ressources et les technologies,
contribuant ainsi au développement, de la productivité et de la compétitivité dans leurs
activités.

Les principes qui régissent leurs actions sont les suivants : une base technologique solide et
une bonne qualification du personnel, en plus d’une gestion experte des fournisseurs, en
veillant constamment à la qualité du produit ou du service. L’entreprise a une grande
expérience dans la mise en place de solutions innovantes avec beaucoup de clients et à une
relation privilégiée avec ses partenaires avec l’engagement ferme d’offrir des solutions et
des services innovateurs adaptés à leurs besoins spécifiques.

3. Localisation

15
La figure 1 présente la répartition du groupe SATEC dans le monde :

Figure 1.1 : La Présence mondiale de SATEC

4. Secteur D’activité
Groupe SATEC est une multinationale espagnole d’intégration de solutions technologiques,
spécialisée dans les services avancés associés aux nouvelles technologies de l’information.
Elle privilégie depuis 1987 la collaboration avec ses clients à travers l’innovation dans les
processus, les moyens et les technologies, contribuant ainsi au changement, à la productivité
et la compétitivité de ses clients dans leur activité.

Groupe SATEC dispose d’une grande gamme de Solutions et de Services TIC qui couvrent les
besoins du Client, recueillent et analysent leurs exigences pour leur développement, leur
mise en place et leur maintenance ultérieures. Cette expérience a également servi à offrir
des solutions et des services spécifiques dans les secteurs d’activité.

 L’administration Publique
 Les télécommunications
 La santé
 L’industrie
 Les banques

16
  Les assurances

5. Organigramme fonctionnel
La figure 1.2 représente les différentes entités auquel opère l’entreprise INTELCOM :

17
6. Présentation du projet
1. Contexte du projet
Les technologies réseaux sont en évolution permanente. C’est dans cette optique que
Intelcom, leader du marché de l’intégration réseau propose des sujets aux stagiaires qui
rentrent dans le cadre d’un projet global de formation de futurs ingénieurs réseaux, sécurité,
système et virtualisation, pour en faire des ingénieurs compétents capables de s’adapter aux
défis du marché.

Au fur et à mesure que les technologies évoluent et la croissance importante de la taille de

l'infrastructure réseau, les difficultés augmentent en conséquence. Dans ce contexte, le
projet ANSIBLE proposé par INTELCOM consiste à s’adapter aux nouveaux enjeux de réseaux
et de sécurité en simplifiant la gestion du réseau à travers l’automatisation, ce qui permet de
supprimer les étapes manuelles de la configuration, de la gestion, des tests, du déploiement
et du fonctionnement des périphériques physiques et virtuels au sein d’un réseau. Elles
visent à faire plus, mieux, et plus vite, avec une intervention humaine minimale, voire même
nulle.

2. Problématique
Lorsque les équipes de Réseaux et Sécurité ont des taches, ils font face à certains problèmes
et les résolvent de manière manuelle. Ainsi, ce processus devient comme une boucle. Donc
cette configuration peut prendre beaucoup de temps et pourra donc causer des contraintes
de temps, et peut surtout être source d'erreurs.

Au total, en fonction des problèmes mentionnés ci-dessus, nous avons besoin d’une solution
évolutive qui puisse s’attaquer à tous ces problèmes. Par conséquent dans ce projet, on a
appuyé sur un outil de NetDevOps Ansible.

3. Objectifs du projet
Le projet que nous avons réalisé au sein d’INTELCOM, a pour objectifs de :

 Mener une étude sur benchmarking des outils possibles (payants et open source)
d’automatisation, afin de s’assurer de notre choix.
 Créer de la facilité en fournissant une solution d’automatisation qui peut suivre le rythme
de la gestion de configuration sans la ralentir.
 Etudier le profil existant en termes de principe de fonctionnement.
 Déployer et mettre en place d’une solution Ansible pour automatiser plusieurs tâches
effectuées quotidiennement à l’aide une grande infrastructure réseau afin de justifier le

18
 bon fonctionnement et éclaircir les points forts et l'importance de la solution sur le
marché du travail.
 Appliquer les bonnes pratiques de sécurité et contrôles dans l’ensemble du cycle de
développement du projet.

4. Démarche
La démarche de réalisation du projet est la suivante :

 Proposition et étude de la solution Ansible.

 Etude des technologies utilisées dans les Pare-feu ASA et IOS (Routeurs et Switches).
 Déploiement et mise en œuvre de la solution adoptée dans un environnement de
simulation EVE-NG :
 Installation d'Ansible sur distribution Linux Debian.
 Automatisation de Configuration des Pare-feu Cisco ASA.
 Automatisation de Configuration des Routeurs.
 Automatisation de Configuration des Switches.
 Tests et vérification.

5. Déroulement et planification du projet

La planification est parmi les phases d’avant-projet les plus importantes. Elle consiste à
déterminer et à ordonnancer les tâches du projet et à estimer leurs charges respectives,
diminuer les risques et rendre compte de l’état d’avancement du projet.

Parmi les outils de planification d’un projet, on trouve le diagramme de GANTT. C’est un outil
qui permet de planifier le projet et de rendre plus simple le suivi de son avancement. Ce
diagramme permet de visualiser l’enchaînement et la durée des différentes tâches durant le
projet comme illustré dans cette figure :

19
Figure 1.3 : Diagramme de Gantt

20
Conclusion
Tout au long de ce premier chapitre nous avons détaillé le cadre général du projet de fin
d’étude en présentant l’organisme d’accueil, le réseau sur lequel nous avons travaillé ainsi
que le contexte général du projet, sa problématique, ses objectifs, le cahier de charge et
finalement sa planification.

21
 Chapitre 2 : Etude
comparative des
différentes solutions
Introduction
Dans ce chapitre, nous allons présenter dans un premier temps l'étude comparative qui est
nécessaire pour choisir le meilleur outil de gestion de configuration et automatisation
répondant aux besoins techniques de ce projet, et aussi l’outil approprié doit contient des
fonctionnalités et des critères adéquats. Cela étant, on montre et on explique les raisons qui
nous ont amené à choisir Ansible face aux autres outils même le plus célèbre dans le marché
tel que Puppet et Chef.
La tâche suivante est consacrée à la présentation générale d’Ansible et à sa progression avec
le réseau.
Nous terminons par montrer les produits d’un grand nombre de fournisseurs utilisant et qui
sont supportés par Ansible.

22
 I. Benchmarking des outils disponibles
Il existe plusieurs outils d'automatisation pour faciliter la gestion de la configuration.
L'objectif de ces outils est de réduire la complexité et le temps de configuration et de
maintenance des réseaux surtout les gros réseaux avec des centaines de périphériques.
Dans la catégorie des outils de gestion de configuration et automatisation, il y'a trois outils
NetDevOps qui sont les plus connus et utilisés par les entreprises : Ansible, Puppet et Chef.

1. Ansible
Ansible est un outil open source qui fournit une automatisation IT simple pour mettre fin aux
tâches répétitives et permettre à l'équipe DevOps de se concentrer sur des tâches plus
stratégiques. Ansible vous permet facilement de gérer la gestion de configuration, le
déploiement applicatif et l’orchestration à partir d'un système unique.

Pour y parvenir, Ansible a été conçu comme un outil simple, fiable, et convivial, contenant
un minimum de dépendances. De plus, son architecture sans agent signifie que les
périphériques gérés ne nécessitent pas l'installation d'un code (agent) sur celui-ci, et utilise
SSH pour partage de configuration par "Push" qui garantit sa sécurité et réduit les frais de
réseau.

Figure 2.4 : Architecture d’Ansible

2. CHEF 
Chef est un outil de gestion de configuration et une plateforme d’automatisation conçu pour
rationaliser les tâches de provisionnement, de configuration et de maintenance des serveurs
d’une entreprise. Il transforme l’infrastructure en code, la rendant souple, visionnable, lisible

23
et testable, quelle que soit la plateforme où il s’exécute ou la taille du réseau. Écrit en Ruby
et Erlang, il peut s’intégrer avec une grande variété de plateformes cloud.

Comme son nom l’indique, Chef requiert l’écriture d’une série de recettes décrivant une
série de ressources qui doivent se trouver dans un état particulier : les packages devant être
installés, les services devant être exécutés, ou les fichiers devant être écrits.

Figure 2.5 : Architecture de Chef

Workstations: il s'agit simplement d'ordinateurs personnels où tout le code de configuration

de développement est créé, testé et modifié avant d'être téléchargé sur le serveur Chef.
Pour chaque poste de travail Chef dispose également d'un outil de ligne de commande
appelé "Knife", qui sera utilisé pour télécharger les modifications de configuration vers le
serveur Chef.

- Recipes : Recipes est une collection de ressources qui décrit une configuration
ou une politique particulière. Elle décrit tout ce qui est nécessaire pour
configurer une partie d'un système et dans quel ordre il faut l'utiliser.
L'utilisateur écrit des Recipes qui décrivent comment Chef gère les applications
et les utilitaires.
- Cookbooks: Plusieurs Recipes peuvent être regroupées pour former un livre de
Recipes. Un livre de Recipes définit un scénario et contient tout ce qui est
nécessaire à la prise en charge de ce scénario. Les livres de Recipes sont créés
en utilisant le langage Ruby.

Chef Server : Le magasin centralisé de la configuration de l’infrastructure. Le serveur Chef

stocke, gère et fournit la configuration à tous les nœuds qui composent l'infrastructure.

Nœuds : ce sont les serveurs sur lesquels le code d’utilisateur doit s'exécuter. Le serveur
Chef gère les nœuds par le client Chef, qui est un logiciel installé sur chaque nœud. Le client
Chef récupère les informations de configuration du serveur Chef.

24
Toute modification apportée au code de l’infrastructure doit passer par le serveur Chef pour
pouvoir être appliquée aux nœuds. Avant d'accepter ou de pousser les changements, le
serveur Chef authentifie toutes les communications via son API REST en utilisant un
chiffrement à clé publique.

3. PUPPET
Puppet est un outil de gestion de configuration qui assure un moyen standard de livrer et
d’exploiter les logiciels, quel que soit l’endroit où ils s’exécutent. Il existe deux éditions de
l’outil : Open Source et professionnelle.
Il est construit sur une architecture serveur-client qui comprend un master (serveur
centralisé) et plusieurs nœuds (clients). Dans chaque nœud, un agent Puppet est installé
pour communiquer avec le master Puppet.
Puppet est basé sur un modèle de déploiement Pull, où les nœuds se connectent
régulièrement au Master pour voir si quelque chose doit être mis à jour dans l'agent. Il
Utilise Ruby pour la configuration des périphériques.
L’objectif de Puppet est de mettre en œuvre une manière flexible et standard d’automatiser
le déploiement et la mise en production des applications.

Figure 2.6 : Architecture de Puppet

Module : Le module est une collection de manifestes et d'autres fichiers de données

connexes organisés d'une manière prédéfinie pour faciliter le partage et la réutilisation Les
modules relient les manifestes, les templates et les fichiers en une seule unité.

Manifests : Le manifeste est simplement le fichier dans lequel sont écrits en Ruby, tous les
scripts Puppet destinés à configurer les clients Puppet.

Templates : Les templates sont généralement utilisés pour configurer les fichiers de
configuration, permettant l'utilisation de variables et d'autres fonctionnalités destinées à
rendre ces fichiers plus polyvalents et réutilisables.

Module : le module est une collection de manifestes et d'autres fichiers de données

connexes organisés d'une manière prédéfinie pour faciliter le partage et la réutilisation. Les
modules relient les manifestes, les templates et les fichiers en une seule unité.

25
Factor : Le facteur collecte les facts, qui sont des informations importantes sur le nœud et
les envoie au Puppet Master. Les facts sont la paire de données key-value qui représente les
états du client Puppet tels que l'adresse IP, le système d'exploitation, l'interface réseau, le
temps de fonctionnement...

4. Choix des critères

Les critères qui vont orienter notre choix d’outil de gestion de configuration et
automatisation sont :

- Disponibilité : en cas de panne du serveur principal, chaque outil a la possibilité d'un

serveur de sauvegarde ou d'un Master alternatif pour rendre le support.
- Langage : Flexibilité et facilité, car joue un rôle principal dans le choix d'outil
d’automatisation.
- Sans Agent (Architecture) : Pouvoir contrôler des machines sans configuration apriori ou
installation d’agent.
- Installation : Complexité de mettre en place l’outil pour un environnement de production.
- Mécanisme : de partage de configuration, push ou pull.

 Pull Configuration : Dans ce type de gestion de la configuration, les nœuds

interrogent périodiquement un serveur centralisé pour obtenir des mises à jour. Ces
nœuds sont configurés de manière dynamique et, en fait, ils tirent les configurations
du serveur centralisé vers les nœuds esclaves sans aucune commande. Ce type de
configuration est utilisé par des outils tels que Chef, Puppet.
 Push Configuration : Dans ce type de gestion de la configuration, le serveur centralisé
pousse les configurations vers les nœuds à l'aide de commandes spécifiques.
Contrairement à Pull Configuration, certaines commandes doivent être exécutées
dans le serveur centralisé afin de configurer les nœuds. La configuration push est
utilisée par des outils comme Ansible.

Figure 2.7 : Mécanisme Push/Pull

26
 - Évolutivité : L'évolutivité des outils d’automatisation est l'un des principaux facteurs pris
en compte par les entreprises avant de choisir un outil.

Chef, Puppet et Ansible sont capables de gérer de grandes infrastructures tout en

supportant la charge de la mise à l'échelle des configurations. Cependant, il existe une légère
différence entre eux en termes d'évolutivité en raison de la complexité de leur langage de
configuration.
- Interopérabilité : En termes d'interopérabilité, les trois outils, Ansible, Chef et Puppet,
présentent des caractéristiques similaires. Dans les trois cas, tous les serveurs fonctionnent
sur des machines Linux ou Unix.
- Dépendance client : les logiciels pré requis pour configurer une machine.
- Contributeur : nombre de contributeur dans le code source de l’outil.
- Prix : Le prix joue un rôle essentiel dans la prise de décision pour l'adoption d'outils
d’automatisation.
- Capacités : Une révision des capacités de chaque outil d’automatisation peut vous
aider à choisir l'outil le mieux adapté à nos besoins. Chaque outil possède son propre
ensemble de capacités qui sont meilleures à leur manière. [1]

5. Comparaison et synthèse
Le tableau synthétise la comparaison des outils de gestionnaire de configuration et
automatisation présentés préalablement, selon les critères établis et exposés
auparavant :

Tableau 2.1 : Récapitulatif de comparaison des outils d'automatisation

Outils
Critères

Disponibilité (en Instance secondaire Serveur de sauvegarde Master alternatif

cas de panne du
serveur)
Langue de Python, YAML Ruby DSL Ruby, Puppet DSL,
configuration Embedded Ruby (ERB), DSL
Architecture Uniquement Master (sans Master-Agent Master-Agent
agent)
Installation et Difficile et complexe en Difficile en raison de la
configuration Facile raison de Chef signature du certificat entre
Workstation le master et l'agent
Mécanisme Push Pull Pull
(Gestion de la

27
 configuration)
Mécanisme de SSH/Netconf
transport
Évolutivité Très haut
Interopérabilité Ansible Server doit être
sous Linux / Unix
Dépendance client Python, sshd, bash
Contributeur 3432
-ansible avec CLI : Gratuit
Prix -ansible avec GUI et sans
support (AWX) : Gratuit
-ansible avec GUI et support
et garantie (Ansible
Tower) : 10000 USD / an
pour jusqu'à 100 nœuds
- Orchestration simple
Capacités - Provisionnement
rationalisé
- Livraison continue avec
flux de travail automatisé
- Déploiement
d'applications
- Intégration de la sécurité
et de la conformité dans les
processus automatisés
Rest
Haut
Chef Server doit être sous
Linux / Unix
Ruby, sshd, bash
522
13700 USD / an pour
jusqu'à 100 nœuds
- Livraison continue avec
flux de travail automatisé
-Gestion de la conformité
et de la sécurité
Rest
Haut
Puppet Master doit être
sous Linux / Unix
Ruby
492
11200-19900 USD / an pour
jusqu'à 100 nœuds
- Orchestration
- Provisionnement
automatisé
- Visualisation et reporting
simples
- Transparence élevée
- Contrôle d'accès basé sur
les rôles

6. Pourquoi Ansible ?
D'après le tableau l’avantage plus important d’Ansible par rapport aux autres outils
d’automatisation est son aspect sans agent, c’est-à-dire, il n’a pas besoin d’une configuration
a priori et ne nécessite l'installation d'aucun logiciel supplémentaire sur les périphériques.
Ainsi qu’en termes de langage de configuration, YAML est considéré comme le plus simple,
car il est lisible par l'humain. Pendant que les langages Puppet DSL et Ruby DSL créent des
inconvénients pour la gestion, et aussi utilisé le mécanisme Push pour la gestion de la
configuration, et sécurité, car utilise le protocole SSH pour gérer les périphériques.
En réalité, Ansible est un outil plus utilisé pour l'automatisation de réseau au marché de
travail. Une fois de plus, c'est le moins cher et aussi il y’a des versions gratuites (Ansible avec
GUI : AWX, Ansible avec CLI). De même, sa communauté est plus grande, et chaque mois de
nouvelles options sont ajoutées.

28
En conclure, Ansible affiche sa domination sur les autres en termes de gestion donc reste le
plus adapté et facile à mettre en œuvre en comparaison avec Chef et Puppet.

7. Présentation générale de Ansible

1. Historique
Ansible a été créé par un ancien employé Red Hat, Michael DeHaan, également auteur de
l’application de serveur de “provisionning” Cobbler et co-auteur du framework Fedora
Unified Network Controller (Func) pour l’administration à distance. La première version
d’Ansible a été publié en 20 février 2012. Le code source du logiciel est sous licence GNU
General Public v3.0. Red Hat a racheté la société Ansible en octobre 2015. Ainsi que Red Hat
a été racheté par IBM en 2018. Donc, Ansible appartient désormais à IBM. [2]
Le nom Ansible a été choisi en référence au terme « Ansible » a été inventé par Ursula K. Le
Guin dans son roman de science-fiction Rocannon's World en 1966 pour désigner un moyen
de communication plus rapide que la lumière.

2. Notions et Concepts
Ansible est un outil NetDevOps d'automatisation informatique écrit en Python. Il fonctionne
sur de nombreuses distributions de type Linux/Unix (Par exemple : Red Hat, CentOS, Debian,
Ubuntu ...). Il est Open Source dans sa version ligne de commande et aussi, Open source
dans sa version web Ansible AWX, mais payant pour sa version web Ansible Tower qui créait
par Red Had Enterprise.
Ansible s’est progressivement imposé comme le principal outil d’automatisation dans le
monde du réseau. Elle combine le déploiement de logiciels multi-nœuds, l'exécution des
tâches ad-hoc, et la gestion de configuration, et l’automatisation des tâches. Elle gère les
différents nœuds à travers SSH et ne nécessite l'installation d'aucun logiciel supplémentaire
sur ceux-ci.
Ansible présente en sortie standard les résultats de ses actions en format JSON.
Mais ansible utilise le format YAML pour exprimer des descriptions réutilisables de systèmes,
appelées "Playbook". Enfin, les variables peuvent se présenter dans Ansible grâce aux
modèles Jinja2.

29
 Figure 2.8 : Principe de fonctionnement d’Ansible

Dans le prochain chapitre, on va essayer de comprendre les composants de base d’

Ansible tels que l’inventory, les modules, les playbooks, les rôles, Langage de configuration
YAML et les modèles Jinja2…

3. Progression de Ansible avec Réseau

Ansible était connu dans les premières versions depuis 2012 comme un outil de DevOps
pour automatiser une infrastructure informatique par exemple la configuration et la gestion
des serveurs. Red Hat a racheté la société Ansible en octobre 2015. Après en 2016 Red Hat a
commencé d'intégration d'Ansible dans le domaine Réseau, et puis ça a commencé à évoluer
progressivement dans l'automatisation de Réseau, pour devenir en 2020 comme l'outil
NetDevOps plus utilisé pour l'automatisation de réseau au marché de travail.

Figure 2.9 : Progression de Ansible avec Réseau

30
4. Les produits supportés
1. Tous les produits
Ansible supporte des matériels, des logiciels ou des solutions d’un grand nombre de
fournisseurs des plusieurs domaines des infrastructures comme :

Figure 2.10 : Domaines supportés par Ansible

Ansible répond aux besoins les admins Système / Cloud, aux DevOps/NetDevOps, aux
admins de Stockage, aux admins Réseaux et Sécurité pour une automation des serveurs, du
réseau et du stockage.

Figure 2.11 : Les équipes qui travaillent sur Ansible

2. Produits CISCO
Ansible prend en charge l'automatisation pour une large gamme de produits et plates-
formes Cisco, notamment :

31
 Figure 2.12 : Produits Cisco supportés par Ansible

Conclusion
Au cours de ce chapitre, nous avons fait une étude comparative des différents outils existent
dans le marché de travail. Dans un premier temps, on a expliqué chaque outil pour sortir
avec notre choix Ansible. Enfin, nous avons fait une étude générale d'Ansible et progression
d'Ansible avec Réseau, ainsi les produits qui supportés par Ansible. Dans le prochain
chapitre, on va montrer une étude théorique détaillé sur Ansible.

32
 Chapitre 3 : Etude
théorique du Ansible

Introduction
Pour bien mener ce projet, il est nécessaire de faire un étude théorique détaillé sur ansible.
Alors dans ce chapitre, il sera composé de cinq parties. La première va porter sur des
Composants principaux d’Ansible, la deuxième sur composants supplémentaires, la
troisième sur les éléments de Configuration d'Ansible, la quatrième sur Graphical User
Interface et puis la dernière partie concerne Documentation d'Ansible.

33
 I. Composants principaux de Ansible
1. Architecture de Ansible
L'architecture Ansible est facile à comprendre :

Figure 3.13 : Architecture générale de la solution Ansible

2. Inventory
Le fichier inventory contient une liste des hôtes (hosts:) (généralement leurs adresses IP ou
DNS) que vous souhaitez configurer ou gérer, il est au format INI par défaut. Les hôtes d'un
inventory peuvent être divisés en groupes plus petits pour faciliter la gestion et la
configuration, il y'a aussi des variables (vars:) attachées à ces hôtes et à ces groupes. Chaque
groupe peut exécuter différentes tâches.

L'option -i suivie du chemin du fichier d'inventory, elle est utilisée avec : ansible-playbook
pour préciser l’emplacement du fichier inventory.

On peut aussi préciser le chemin du fichier d’inventory par défaut dans le fichier de
configuration ansible.cfg avec l’entrée inventory sous la section [defaults].

Voici un exemple de fichier d'inventory :

34
 Figure 3.14 : Exemple fichier Ansible Inventory

- R1, ASA_L1… : Le nom que Ansible utilisera.

- ansible_host : L’adresse IP que Ansible utilisera pour définir un périphérique. Si cette
variable n’est pas définie, on peut utiliser DNS.
- ansible_ssh_user : Le nom d'utilisateur de connexion SSH.
- ansible_ssh_pass : Le mot de passe d'utilisateur de connexion SSH.
- all : groupe par défaut qui contient tous les hôtes.

3. Playbook
Un playbook est un fichier script de configuration d'Ansible qui écrit en langage YAML
pour exécuter l’ensemble des tâches et d’étapes de configuration à effectuer sur les hôtes
de manière séquentielle sur tout ou partie de l’inventory càd un groupe déjà défini dans
l’inventory.
Chaque playbooks est composé d'un ou plusieurs “playbook” exposés sous forme d’une
liste. Un “playbook” organise des tâches (tasks) en play. Mais il est de bonne pratique de

35
l’organiser en “rôles”. Un “rôle” ajoute un niveau d’abstraction dans l’exécution des tâches
d’un playbook. 

Sur le plan fondamental, chaque tâche utilise un module d’Ansible. Donc une “tâche” Ansible
n’est rien de plus qu’un appel à un module Ansible accompagné des paramètres.

Playbook est lancé directement avec la commande : ansible-playbook -i inventory

myplaybook.yml.

Maintenant, on montre un exemple de playbook parmi plusieurs exemples

des playbooks qui déjà utilisés dans ce projet. Le but de ce playbook est la configuration de
Vlan du réseau de ce projet :

36
 Figure 3.15 : Exemple fichier Ansible Playbook

4. Modules
Les modules Ansible sont des programmes utilisés pour exécuter des tâches, ils écrivent
principalement en Python. Aussi, chaque tâche utilise un module qui peut prendre des
paramètres pour être exécuté de manière personnalisée. Ansible exécute ensuite ces
modules (via SSH par défaut) grâce au format JSON sur la sortie standard et les supprime
lorsque l’action est terminée. [3]
Ansible fournit de nombreux modules, mais vous pouvez créer le vôtre, personnalisé. Ainsi
que tous les modules officiels d’Ansible sont téléchargés par défaut sur la machine de
contrôle lors de l’installation d’Ansible. Lorsque vous utilisez un module, Ansible va chercher
le code à exécuter dans le dossier du module sur la machine de contrôle. On peut retrouver
la liste des modules à cette adresse :
/usr/lib/python2.7/distpackages/ansible/modules/network
Aussi Tous les modules officiels sont accessibles sur la documentation d'Ansible :
https://docs.ansible.com/ansible/2.9/modules/list_of_network_modules.html

37
5. Facts
Les Facts sont des informations collectées par Ansible et que l’on peut appeler via des
variables ansible_* et pour les périphériques de Cisco appeler via des variables
ansible_net_*:

Figure 3.16 : Variables Ansible Facts

Par défaut, Ansible collecte les Facts des cibles avant l’exécution des tâches du playbook. Ce
comportement se contrôle sur le playbook avec la directive : gather_facts : une valeur
booléenne. Mais pour les périphériques de Réseau il n’existe pas par défaut, donc quand
vous pouvez travailler par Facts, on doit utiliser toujours le module par exemple : ios_facts,
nxos_facts, fortios_facts, bigip_facts…

38
 Figure 3.17 : Exemple de l'exécution de Facts

6. Roles
Les rôles sont des playbooks génériques, qui peuvent être intégrés dans d’autres playbooks.
Ce concept est essentiel pour créer des tâches complexes. En fait, pour rendre les playbooks
lisibles, il vaut mieux construire des rôles qui peuvent être partagés, distribués et assemblés,
plutôt que créer un playbook qui sera difficile à maintenir et complexe à utiliser et peu
lisible.

Pour chaque élément d’un rôle (tasks, handlers, vars, …) doit mettre nécessairement un
fichier sous le nom : main.yml

Figure 3.18 : Exemple d’Ansible Rôles

Enfin de façon schématique, on peut résumer ce qui précède sont les suivantes :

- Un rôle contient un ou plusieurs fichiers de configuration (playbook).

39
- Un playbook contient une ou plusieurs tâches.

- Une tâche fait appel à un module.

7. Composants supplémentaires
1. Modèles Jinja2
Ansible utilise un module de "Templates" ou modèles, permettant de créer des fichiers
scripts pour la gestion des équipements, et met en forme des données, il s’appuie sur Jinja2
qui permet de gérer des listes ou des variables, des boucles, des tests logiques, et donc
d’étendre la programmabilité dans l’automatisation du réseau. Donc Jinja2 est un langage de
gestionnaire des templates écrit pour Python.

Figure 3.19 : Schéma de Modèles Jinja2

- Les modèles de données sont transformés en configuration de périphériques.

- Les sorties des périphériques peuvent être transformées en documentation (dynamique).
- On doit mettre l’extension «. j2 » qui désigne ce fichier comme étant au format « Jinja2 ».
Les fichiers de type jinja2 sont assez souples au niveau de la syntaxe, cependant il faut noter
quelques particularités :
- Une variable se déclare grâce à la syntaxe suivante {{ variable }}.
- Toutes les instructions (Statement) commencent et se terminent par {% … %}.
- Tous les commentaires Jinja2 commencent et se terminent par {# … #}, Ils ne sont pas
affichés en sortie de fichier.

40
2. Ansible Vault
Ansible-vault est une fonctionnalité d’Ansible qui nous permet de crypter les fichiers qui
contiennent des données sensibles telles que les mots de passe ou les clés, plutôt que de les
laisser en clair dans les Playbooks ou les rôles.
#ansible-vault {encrypt/decrypt} main.yml : crypter par un password
Pour exécuter un Playbook avec des fichiers de données cryptés par Vault, nous devons
fournir le mot de passe Vault, on peut stocker dans un fichier (dans ce exemple :
pass_vault.txt). Alors il y'a deux méthodes pour l'exécution ce playbook :
#ansible-playbook -i inventory myplay.yml --vault-password-file pass_vault.txt
#ansible-playbook -i inventory myplay.yml --ask-vault-pass

3. Mode ad-hoc
Mode Ad-Hoc est la commande ansible en une ligne qui exécute une tâche sur l'hôte cible.
Elle vous permet d'exécuter une tâche simple en une ligne sur un hôte ou un groupe d'hôtes
définis dans la configuration du fichier d'inventory. Une commande Ad-Hoc n'aura que deux
paramètres, le groupe d'hôtes sur lequel vous souhaitez effectuer la tâche et le module
Ansible à exécuter.
La commande Ad-Hoc vous donne plus d'avantages pour l'exploration d'Ansible. Vous
pouvez d'effectuer de tâche à manière rapide sans créer un playbook.
Dans cette partie, je vais montrer l'utilisation de base du mode Ad-Hoc, je vais l'utiliser pour
effectuer une tâche simple : 
ansible -i inventorycisco -c local -m ios_command -a "commands='show running-config' "

4. Langage YAML
YAML (Yet Another Markup Language) a été proposé pour la première fois par Clark Evans en
2001, qui l'a conçu avec Ingy döt Net et Oren Ben-Kiki. Il est un langage de sérialisation de
données lisible par l'homme qui est souvent utilisé pour les fichiers de configuration et dans
les applications où des données sont stockées ou transmises. [4]

Il vise un grand nombre des mêmes applications de communication que le langage de

balisage extensible (XML) mais possède une syntaxe minimale. C'est un sur-ensemble strict
de JSON, un autre langage de sérialisation des données. Mais comme il s'agit d'un sur
l'ensemble strict, il peut faire tout ce que JSON peut faire et plus encore. L'une des
principales différences est que les nouvelles lignes et l'indentation ont une signification
réelle dans YAML, contrairement à JSON, qui utilise des crochets et des accolades.

41
5. Les éléments de Configuration
1. Ansible Configuration file
Ansible fournit un fichier de configuration de base situé dans /etc/ansible/ansible.cfg. Si le
fichier ansible.cfg existe dans le répertoire dans lequel le playbook est exécutée, il est utilisé
à la place du fichier global /etc/ansible/ansible.cfg.

En résumé, on peut changer ces variables de configuration en renseignant un fichier de

configuration. Ansible cherchera dans l’ordre que le premier trouvé sera utilisé et les autres
seront ignorés :

1-Le contenu de la variable d’environnement ANSIBLE_CONFIG (si la variable

d’environnement est valorisée).
2- L’emplacement ./ansible.cfg (dans le dossier courant, le répertoire de travail).
3- L’emplacement ~/.ansible.cfg (à la racine du dossier utilisateur comme fichier caché).
4- L’emplacement /etc/ansible/ansible.cfg (dans le dossier de configuration du logiciel).
5- Ansible contient des valeurs par défaut qu'il utilise (Si le fichier de configuration global
/etc/ansible/ansible.cfg n'est pas présent).

Le fichier de configuration Ansible se compose de plusieurs sections, chaque section

contenant des paramètres définis sous forme de paires clé-valeur. Les titres des sections
sont placés entre crochets. Il y a plusieurs par exemple :

- [defaults] définit les paramètres par défaut pour le fonctionnement d'Ansible.

- [privilege_escalation] configure la manière dont Ansible effectue l'escalade de privilèges
sur les hôtes gérés.
- [ssh_connection]

Ansible doit savoir comment communiquer avec ses hôtes gérés. L'une des raisons les plus
courantes de modifier le fichier de configuration est de contrôler les méthodes et les
utilisateurs qu'Ansible utilise pour administrer les hôtes gérés. Parmi les informations
nécessaires figurent :

- L'emplacement de l'inventory qui répertorie les hôtes et les groupes d'hôtes gérés.
- Le protocole de connexion à utiliser pour communiquer avec les hôtes gérés (par défaut,
SSH), et si oui ou non un port réseau non standard est nécessaire pour se connecter au
serveur.
- L'utilisateur distant à utiliser sur les hôtes gérés, il peut s'agir de root ou d'un utilisateur
non privilégié.
- Si l'utilisateur distant n'est pas privilégié, Ansible doit savoir s'il doit essayer d'élever les
privilèges jusqu'à root et comment le faire (par exemple, en utilisant sudo).

42
- S'il doit ou non demander un mot de passe SSH ou un mot de passe sudo pour se connecter
ou obtenir des privilèges.

Par exemple, ce qui suit est une partie de fichier ansible.cfg :

Figure 3.20 : Exemple d'une partie de fichier ansible.cfg

2. Ansible Forks
Lorsque nous exécutons un playbook, il traite généralement chaque tâche dans tout
l'inventory par un comportement qui existe par défaut avant de passer à une autre
tâche. Mais on peut modifier ce comportement par défaut dans le fichier ansible.cfg.
Forks : Il s'agit du nombre de processus parallèles à lancer lors de la communication avec des
hôtes distants qui effectuées par Ansible sur chaque tâche. Le nombre de Fork est
automatiquement limité au nombre d'hôtes possibles au moment de l'exécution de chaque
tâche de playbook, donc c'est vraiment une limite de la charge réseau et CPU que vous
pensez pouvoir gérer. Selon que le serveur Ansible avoir des caractéristiques techniques plus
élevées ensuite vous avez la possibilité qui permettront d'exécuter plus rapidement les
playbooks sur des grands nombres des hôtes à la fois. La valeur par défaut de forks sur
Ansible est : 5, signifie qu'Ansible n'exécutera une tâche de playbooks que sur 5
périphériques à la fois. Mais on peut Définir forks=[nombre] dans le fichier de configuration
d'Ansible (ansible.cfg) pour définir une nouvelle valeur de forks par défaut pour toutes les
exécutions des playbooks.

3. Ansible Strategy
Ansible propose principalement deux stratégies d’exécution :
- Linear : C'est la stratégie que Ansible utilise par défaut, le fonctionnement d'elle est que
chaque tâche devait être exécutée et terminée sur chaque périphérique avant que Ansible

43
lance une nouvelle tâche vers tous les périphériques. Cela signifiait que si vous exécutez des
tâches sur des plusieurs périphériques et que l'un d'entre eux est moins performant, tous les
périphériques iront à la vitesse du périphérique moins performant.
- Free : Cette stratégie permet de lancer une nouvelle tâche à chaque périphérique dès que
celui-ci a terminé la tâche précédente. Cela permettra aux périphériques les plus rapides de
terminer le playbook avant les autres les plus lents. Si vous choisissez cette stratégie
d'exécution, vous devez vous rappeler que certaines tâches peuvent nécessiter l'exécution
d'une tâche précédente sur tous les périphériques et dans ce cas, il y a la possibilité d'échec.

4. Ansible Asynchronous
Désigne une tâche qui est configurée pour être exécutée en arrière-plan plutôt que
d’attendre l’achèvement. Si vous avez un long processus qui durerait plus longtemps que le
délai d’attente SSH, il serait logique de lancer cette tâche en mode asynchrone. Les modes
Asynchrones peuvent être interrogés toutes les secondes ou peuvent être configurés pour
“tirer et oublier”, auquel cas Ansible ne vérifiera même pas à nouveau la tâche, il la
déclenchera simplement et passera aux étapes suivantes.

Ce qui est particulièrement génial à propos de la fonctionnalité de tâche asynchrone est

qu'elle est vraiment facile à utiliser. Il n'y a que deux drapeaux associés à cette fonction. Le
drapeau -B est utilisé pour définir la valeur du délai d'attente de la tâche. Nous passons un
nombre de secondes avec le drapeau. Par exemple : ansible -m command -a ". /running-
command" -B 600. Cette commande exécutera. /running-command et permettra un délai de
600 secondes.

5. Graphical User Interface

Il devient très difficile de gérer une grande infrastructure. Il existe différents utilisateurs et
groupes qui ont besoin de différents niveaux d'accès pour utiliser Ansible. De plus, nous
devons intégrer ces outils avec d'autres outils tiers pour faire fonctionner l'infrastructure
réseau selon des normes définies, comme d'avertir l'utilisateur par courrier électronique ou
en utilisant des applications de messagerie en cas d'échec. Nous avons également besoin
d'une piste d'audit pour suivre correctement qui a exécuté quelle tâche et quand. Et une
autre chose importante est le support produit. Ces fonctionnalités ne sont pas disponibles
dans Ansible CLI et ne peuvent être réalisées que par Interface Graphique Ansible Tower ou
Ansible AWX.

1. ANSIBLE TOWER
Ansible Tower est Ansible au niveau de l’entreprise, une offre commerciale par Red Hat. Il
s’agit d’une solution Web permettant des entreprises de gérer facilement les
environnements avec une interface utilisateur, qui aide les équipes à gérer des déploiements
complexes et surveille toutes les configurations à plusieurs niveaux par ajoutant un tableau

44
de bord avec des résumés de l’état de tous les hôtes, l'accès basé sur les rôles, la
planification des travaux, des notifications intégrées. Et d'autres fonctionnalités
intéressantes qui permettent aux entreprises de gérer facilement les environnements avec
Ansible. Une fois qu'une entreprise exploite Ansible à une échelle particulière, il peut
devenir difficile de gérer son environnement d'automatisation Ansible lors de l'utilisation des
simples outils de ligne de commande Ansible. Ansible Tower est la solution à ce problème,
car il fournit les fonctionnalités plus "entreprise" à la solution en permettant une approche
plus échelonnée pour plusieurs utilisateurs/accès d'automatisation et en fournissant les
intégrations que la plupart attendent d'une plate-forme d'automatisation. Voici quelques
caractéristiques qui distinguent َAnsible Tower :

- Service de support 24h/7j : Formation, Documentation, des conseils, développement

de leur pratique d'automatisation, donnent des aides pour résoudre des problèmes.
- Licence Red Hat.
- Mises à jour avec la stabilité et la sécurité.
- Les clients peuvent compter sur les correctifs de sécurité et les corrections de
bogues fournis pendant toute la durée de vie du produit.
- Haute disponibilité prise en charge.

Figure 3.21 : Prix d'Ansible Tower

2. AWX
AWX est un projet de communauté open source, sponsorisé par Red Hat, qui permet aux
utilisateurs de mieux contrôler l’utilisation de leurs projets Ansible dans des
environnements. AWX est le projet en amont à partir duquel l’offre Red Hat Ansible Tower
est finalement dérivée. Ceci est similaire au projet Fedora qui stimule l'innovation et qui est
immature ou naissante en termes de stabilité et de vitesse du projet. AWX est une branche
de développement. Des changements fréquents sont introduits et peuvent être publiés avec
un minimum de tests. Cela peut limiter l'adoption dans une entreprise. Voici quelques
caractéristiques qui distinguent :

45
 - Aucun service de support et formation ou de conseil n'est disponible auprès de Red
Hat sur AWX.
- Open Source (Utilisation gratuite).
- Mises à jour publiés avec un minimum de tests, donc il peut être ne fournit pas de
correctifs de sécurité pour les versions précédentes. 
- Uniquement disponible au format conteneur (Docker).

3. Documentation
1. Ansible Galaxy
Ansible Galaxy est un site gratuit à partir duquel vous pouvez télécharger des rôles Ansible
développés par la communauté. Vous pouvez contribuer nos propres rôles pour que d'autres
personnes puissent les utiliser, et aussi évaluer les rôles des autres. Pour commencer à
utiliser Ansible Galaxy, vous devez inscrire simplement à l'aide de créer un compte sur le site
Web : https://galaxy.ansible.com/ et pour télécharger un rôle depuis Ansible Galaxy, utilisez
la commande suivante :
ansible-galaxy install username.rolename

Figure 3.22 : Page d'accueil Ansible Galaxy

2. Ansible-doc
Ansible-doc est un outil fourni par le paquetage de base Ansible qui contient toute la
documentation relative aux modules et plugins installés dans les bibliothèques Ansible. Il
fonctionne comme une commande à l'invite de la ligne de commande. Cet outil/commande
peut vous guider en fournissant de la documentation sur les plugins et les modules, leur
utilisation, une courte description, les paramètres disponibles et les options associées. En
outre, Ansible-doc fournit des exemples pour la plupart des modules et plugins disponibles,
qui peuvent être utilisés directement dans les playbooks. En outre, pour les modules
personnalisés ou créés par nous-mêmes, lorsque nous devons fournir des informations

46
connexes via la documentation, Ansible-doc est configuré pour être utilisé pour lire cette
documentation à partir de bibliothèques.
Ansible-doc fonctionne comme une commande sous Linux. Lorsque nous créons un playbook
et que nous ne sommes pas sûrs d'un module, nous utilisons ansible-doc pour lire la
documentation du module concerné. Cela nous permet de comprendre les idées d'un
module et les possibilités connexes pour utiliser la même chose. [5]
Si vous ne savez pas comment d’utiliser ansible-doc ou si vous l'oubliez à un moment donné,
n'oubliez pas d'exécuter la commande ci-dessous pour obtenir des détails sur cet outil de
ligne de commande :

Conclusion
Dans ce chapitre théorique, nous avons mis en lumière sur la solution Ansible en
décortiquant ses différents composants et son fonctionnement. Le but de cette étude était
l’apprentissage de la solution Ansible proposée par Red Hat afin de préparer à
l’implémentation la solution qui fait l’objet de la prochaine étape, que nous allons rapporter
dans le chapitre 5.

Chapitre 4 : Etat de
l'art des technologies

Introduction
Avant de parler de mise en place de ce projet, il est jugé nécessaire de faire une étude des
technologies utilisée au niveau de l’infrastructure de l'architecture réseau de ce projet. Il
porte sur deux parties : une première partie dans laquelle nous allons définir les
équipements utilisés et une deuxième partie où nous allons faire un aperçu général sur les
technologies automatisées.

47
 I. Les équipements utilisés sur ce projet
1. IOS
Cisco IOS (Internetwork Operating System) est une famille de logiciels utilisée sur la plupart
des routeurs et switches Cisco Sytems. Il dispose d’un ensemble de fonctions de routage
(routing), de commutation (switching), d’interconnexion de réseaux (internetworking) et de
télécommunications dans un système d’exploitation multitâche.

2. ASA
ASA (Adaptive Security Appliance) est un périphérique de pare-feu multifonction de Cisco.
Elle protège les réseaux des entreprises et les centres de données de toutes tailles. Elle offre
aux utilisateurs un accès hautement sécurisé aux données et aux ressources du réseau, à
tout moment, en tout lieu et sur tout type de périphérique. Les dispositifs Cisco ASA
représentent plus de 15 ans d'ingénierie et de leadership éprouvés en matière de pare-feu
et de sécurité réseau.
ASA est généralement utilisé pour filtrer les paquets, mais il prend en charge de nombreuses
fonctionnalités supplémentaires, telles que le filtrage dynamique, l'inspection des
applications, le NAT, le DHCP, le routage, le VPN, etc… Le système d'exploitation Cisco ASA
est le logiciel Cisco ASA.

48
3. Les technologies utilisées sur ce projet
1. VLAN
Vlan (Virtual local area network) est un sous-réseau qui peut regrouper des ensembles
d'appareils sur des réseaux locaux physiques (LAN) distincts. Il s’agit, sur un même switch de
créer plusieurs réseaux indépendants ne pouvant pas de communiquer entre eux. Par
analogie, on peut considérer qu’un VLAN correspond à un domaine de diffusion (Broadcast)
dans lequel on déploie un adressage IP cohérent comme un LAN.
Chaque port de switch doit devenir soit Access port, soit un Trunk Port :
- Access Port : chaque port de switch qui connecté avec end device.
- Trunk Port : chaque port de switch qui connecté avec un autre switch et doit transfert plus
de TAG.

Figure 4.23 : Architecture illustrée pour VLAN

1.1. Types de VLAN

Les VLANs sont utilisés pour différentes raisons dans les réseaux modernes. Certains types
de VLAN sont définis par des classes de trafic. D'autres types de VLAN sont définis par la
fonction spécifique qu'ils remplissent :

- VLAN par défaut : tous les ports du switch font partie de ce VLAN en premier utilisation par
défaut jusqu'à ce que le switch soit configuré.
- VLAN de données : sont des VLAN configurés pour séparer le trafic généré par l'utilisateur.
- VLAN de gestion : est un VLAN de données configuré spécifiquement pour le trafic de
gestion du réseau, notamment SSH, Telnet, HTTPS, HHTP et SNMP.

49
- VLAN natif : Le trafic utilisateur d'un VLAN doit être marqué avec son ID VLAN lorsqu'il est
envoyé à un autre switch.
- VLAN Voice : Un VLAN distinct est nécessaire pour prendre en charge la voix sur IP (VoIP).

2. OSPF
Le protocole OSPF (Open Shortest Path First) est le protocole de routage dynamique
intérieur TCP/IP crée la première version en 1988 par l’IETF. C’est à l’heure actuelle
l’IGP (Interior Gateway Protocol) le plus répandu, il est un protocole open source. Il
fonctionne selon le principe des protocoles à état de lien qui utilisent
l’algorithme Dijkstra. Contrairement à un protocole de routage à vecteur de
distance, OSPF collecte l’état de toutes les liaisons au sein d’une zone (area) et calcule de
son point de vue toutes les routes pour les destinations de la zone. Pour bien expliquer, les
routeurs collectent l’ensemble des coûts des liens et construisent de leur point de vue
l’arbre de tous les chemins possibles. Les meilleures routes sont alors intégrées à la table de
routage. Le protocole fonctionne en connectant les zones entre elles, mais il reste
néanmoins un protocole de routage intérieur. La version actuelle d’OSPFv2 est décrite dans
le RFC 2328 (1998) pour IPv4. Une version 3 est définie dans le RFC 5340 qui permet
l’utilisation de OSPF principalement pour IPv6 (2008). 

Figure 4.24 : Mécanisme de fonctionnement d'OSPF

50
3. EIGRP
EIGRP (Enhanced Interior Gateway Routing Protocol) est un protocole de routage dynamique
intérieur avancé à vecteur de distance développé par Cisco en 1992 comme un protocole
propriétaire disponible uniquement sur les périphérique Cisco, En 2013, Cisco a publié une
fonctionnalité de base d'EIGRP en tant que norme ouverte à l'IETF sous la forme d'un RFC
informatif. Comme son nom l'indique, EIGRP est une amélioration d'un autre protocole de
routage Cisco, IGRP (Interior Gateway Routing Protocol). Concurrent immédiat du protocole
de routage à états de lien OSPF, EIGRP est le protocole préféré dans les infrastructures
homogènes Cisco. EIGRP s’oppose aussi à OSPF au moins à deux égards : c’est un protocole
de routage à vecteur de distance ultra-performant d’une part, et d’autre part, il supporte
nativement les deux protocoles IPv4 et IPv6 de manière plus mieux. Du point de vue de la
performance, il tout aussi performant voir plus performant qu’OSPF. Enfin, il est simple à
configurer et à maintenir. [6]

L'EIGRP est un protocole de routage à vecteur de distance qui inclut des fonctions trouvées
dans les protocoles de routage état de lien. Il peut évoluer pour inclure plusieurs topologies
et fournir des temps de convergence extrêmement rapides avec un trafic réseau minimal.
Pour bien expliquer, il permet de contrôler finement la métrique de manière à influencer les
entrées de la table de routage. EIGRP est alors capable de répartir la charge de trafic sur des
liaisons à coûts inégaux.

4. AAA
AAA (Authentication, Authorization, Accounting) assure la sécurité avec un degré
d'évolutivité supérieur à l'authentification EXEC de niveau ligne et privilégiée. L'accès non
autorisé, les accès commutés et les environnements Internet sont des possibilités pour les
intrus du réseau d'accéder à un réseau, des services et des équipements sensibles. AAA
assure un système de sécurité systématique et évolutif. Le concept entier est basé sur
l'architecture modulaire, c'est-à-dire Authentication, Authorization, Accounting. Les
composants fonctionnels que AAA a l'intention de fournir :

- Authentication : Ceci est utilisé pour identifier les utilisateurs par identification de
connexion et mot de passe. Ce composant répond à la question « qui vous êtes ? Il a
également pour but de déterminer si l'utilisateur est la personne qu'il prétend être. L'entité
qui cherche l'accès est le client et celui qui vérifie les informations d'identification est le
serveur. Cela met l'utilisateur au défi de répondre avant de permettre à l'utilisateur
d'accéder au réseau. Il peut également être configuré pour prendre en charge le chiffrement
en fonction des options de sécurité sélectionnées. Les informations d'identification sont
vérifiées à l'aide de mots de passe et de certificats numériques.

- Authorization : Une fois l'authentification terminée, il est temps d'autoriser. Ce à quoi tout
utilisateur est déterminé à accéder sur le réseau est déterminé par autorisation. C'est le

51
processus d'octroi ou de refus d'accès aux services fournis sur le réseau. Le critère de
détermination est la politique d'accès spécifiée pour des entités spécifiques. A ce stade, des
adresses IP peuvent également être émises comme dans le cas de l'utilisation de VPN. Dans
Cisco IOS, l'autorisation AAA peut être effectuée avec une méthode d'autorisation de liste de
noms. Les privilèges d'accès concernent généralement l'utilisation de services tels que le
filtrage d'adresses IP, l'attribution d'adresses, la qualité de service, le tunneling obligatoire,
etc.

- Accounting : C'est le dernier « A » et cela signifie comptabilité. Les informations de sécurité

sont collectées en vertu de cela et peuvent à leur tour être utilisées pour la facturation, le
reporting et même l'audit. C'est un moyen de vérifier ce que l'utilisateur fait une fois qu'il est
autorisé à avoir accès au réseau. Il conserve un enregistrement complet de ce que
l'utilisateur a fait pendant qu'il était connecté au système. Il maintient une trace des
ressources consommées par les différents utilisateurs. Généralement, la comptabilité
concerne les informations sur l'utilisateur, la nature du service utilisé, le début du service et
la fin de celui-ci.

5. NTP
NTP (Network Time Protocol) est un protocole qui permet de synchroniser à travers le
réseau l’horloge locale des périphériques du réseau sur une date et une heure de référence.
Chaque périphérique réseau (routeur, serveur…) peut être soit un serveur, soit un client. Il
utilise un algorithme d’intersection (une version modifiée de l’algorithme de Marzullo) pour
choisir les meilleures sources de temps et pour la prise en charge de délais supplémentaires
sur le réseau à partir d'une strate (Stratum) commence de 0 à 15 qui nécessaire pour savoir
dans quelle mesure cette source (NTP server) est préférée et précise de façon à la strate plus
petite est le mieux, par défaut : strate de routeur Cisco = 8.

6. VPN
Les entreprises ont besoin de moyens à la fois sécurisés, fiables et économiques permettant
d'interconnecter plusieurs réseaux, par exemple pour que les filiales et les fournisseurs
puissent se connecter au réseau du siège de l'entreprise. De plus, avec l'augmentation du
nombre de télétravailleurs, les entreprises ont un besoin croissant de moyens sécurisés,
fiables et économiques de connecter aux ressources présentes sur les sites de l'entreprise
les employés travaillant dans de petites structures ou des bureaux à domicile, ainsi qu'à
d'autres emplacements distants.

La sécurité est un problème lorsque les entreprises utilisent le réseau Internet public pour
mener à bien leurs activités. Les réseaux privés virtuels (VPN) sont utilisés pour garantir la
sécurité des données sur Internet. Un VPN sert à créer un tunnel privé sur un réseau public.
Les données peuvent être sécurisées à l'aide du chiffrement dans ce tunnel via Internet et en

52
utilisant une méthode d'authentification destinée à protéger les données de tout accès non
autorisé.

Le tunnel supprime la barrière de distance et permet aux utilisateurs distants d'accéder aux
ressources réseau du site central. Un VPN est un réseau privé créé par tunneling sur un
réseau public, généralement Internet. Un VPN est un environnement de communication
dans lequel l'accès est strictement contrôlé de manière à autoriser les connexions
homologues au sein d'une communauté définie d'intérêt.

Une passerelle VPN est requise pour l'implémentation de VPN. La passerelle VPN peut être
un routeur, ou un pare-feu par exemple Cisco ASA.

Figure 4.25 : Connexions Internet VPN

Comme le montre la figure, un VPN utilise des connexions virtuelles qui sont routées via
Internet depuis le réseau privé de l'entreprise jusqu'au site ou à l'hôte distant. Les
informations issues d'un réseau privé sont transportées de manière sécurisée sur le réseau
public afin de constituer un réseau virtuel.

Il existe deux types de réseaux privés virtuels :

- VPN de site à site : Un VPN de site à site est créé lorsque les périphériques situés des deux
côtés de la connexion VPN connaissent par avance la configuration VPN, comme le montre la
figure. Le VPN reste statique et les hôtes internes ne savent pas qu'un VPN existe. Dans un
VPN de site à site, les hôtes finaux envoient et reçoivent le trafic TCP/IP normal par
l'intermédiaire d'une « passerelle » VPN. La passerelle VPN est responsable de
l'encapsulation et du chiffrement de la totalité du trafic sortant issu d'un site spécifique.

53
 Figure 4.26 : VPN de site à site

- VPN d'accès à distance : VPN d'accès à distance sont utilisés pour la connexion d'hôtes
individuels devant accéder en toute sécurité au réseau de leur entreprise via Internet. La
connectivité Internet utilisée par les télétravailleurs.

Figure 4.27 : VPN d'accès à distance

7. IPSEC
IPsec (Internet Protocol Security) est un ensemble de protocoles permettant le transport de
données IP sécurisées. Il comprend des mécanismes de chiffrement et d’authentification.
L’IETF standardise ce protocole et son architecture depuis 1995, et publie des RFCs dont la
plus important aujourd’hui est IPsecv2. Il a été décidé que IPsec serait obligatoire dans IPv6
et facultatif dans IPv4, mais avec un mécanisme identique.
Les protocoles d’IPsec agissent au niveau de la couche de réseau (niveau 3 du modèle OSI).
L’utilisation d’IPsec permet de protéger d’avantage les données dès la couche 3. Son grand
succès est qu’il sécurise toutes les applications et leurs communications au-dessus d’IP de
façon transparente, évitant ainsi les vulnérabilités des couches supérieures.

54
Comme information supplémentaire pour montrer l'importance d'IPsec. Avec IP sans IPsec,
les données IP sont transportées sont contenues en clair dans les paquets. Il est donc
possible, en écoutant le trafic réseau, de lire et de modifier les paquets soit le contenu
(données) soit l'entête (adresse source, adresse destination...). IP étant utilisé aussi bien
pour les communications d’Internet qu’au sein des réseaux privés, ces faiblesses peuvent
avoir de larges répercussions.
IPsec regroupe les trois mécanismes ou services de sécurité au niveau réseau :
- AH (Authentication Header) qui sert à valider l’intégrité des messages.
- ESP (Encapsulation Security Payload) qui sert à assurer la confidentialité des messages.
- IPcomp (IP compression) qui compresse les données qui transitent.
Il existe deux modes (Transport et Tunnel) dans IPsec qui diffèrent par la méthode de
construction des paquets IP des messages. Dans le mode transport seules les données sont
protégées. Par contre, dans le mode tunnel l’en-tête est aussi protégé.

8. GRE
Le protocole GRE (Generic Routing Encapsulation) est considéré comme étant un VPN de site
à site de base, car il s'agit d'un réseau privé créé par tunneling sur un réseau public, non
sécurisé comme VPN. Il est un protocole développé par Cisco, capable d'encapsuler une
large variété de types de paquets de protocoles au sein de tunnels IP. Il crée une liaison
point à point vers des routeurs Cisco au niveau de points distants sur un inter réseau IP.
Le protocole GRE est conçu pour gérer le transport du trafic multi protocole et multidiffusion
IP entre deux ou plusieurs sites, qui peuvent ne posséder que de la connectivité IP. Il peut
également encapsuler plusieurs types de paquets de protocoles au sein d'un tunnel IP. Il
prend également en charge le tunneling de multidiffusion IP. Cela signifie que des protocoles
de routage peuvent être utilisés dans le tunnel, ce qui permet l'échange dynamique des
informations de routage dans le réseau virtuel.

La fonctionnalité GRE n'offre toutefois aucun chiffrement ni autre mécanisme de sécurité.

Par conséquent, les données qui sont envoyées sur un tunnel GRE ne sont pas sécurisées. Si
des communications de données sécurisées sont nécessaires, des VPN IPsec doivent être
configurés.

55
 Figure 4.28 : Encapsulation GRE

Conclusion
Dans ce chapitre, nous avons montré l’état de l’art de ce projet, nous avons cité toutes les
technologies utilisées dans l’infrastructure. Cela nous a permis de bâtir une base qui va nous
permettre de bien comprendre le chapitre suivant qui sera purement technique en utilisant
des terminologies, des solutions et des méthodes expliquées durant ce chapitre et le
chapitre 3.

56
 Chapitre 5 : Le
déploiement et la
mise en place de la
solution
Introduction
Dans ce chapitre, on va aborder l’étape finale de ce projet qu’elle s’agit de l’automatisation
des configurations des périphériques par Ansible. Ceci sera effectué en étudiant
l’architecture qu’on veut implémenter. En d’autres termes, ce chapitre permet de traiter en
détails toutes les étapes de la réalisation et la mise en place de la solution avec
l’infrastructure, il explique le travail effectué en termes de développement, de configuration
et Installation.

57
 I. Outils de Simulation
1. EVE-NG
EVE-NG est une plateforme de simulation très adaptée qui répond aux exigences
informatiques actuelles. Il permet aux entreprises, aux fournisseurs / centres
d'apprentissage en ligne, aux individus et aux collaborateurs d’avoir un moyen virtuel
robuste par lequel ils peuvent simuler et prouver leurs concepts théoriques informatiques. Il
comporte les fonctionnalités et les améliorations suivantes :

 Consoles multi-utilisateurs.
 Multi-configuration sur le même LAB.
 Supporte jusqu’ à 1024 dispositifs par LAB.
 Supporte les conteneurs Docker.
 Exécution de plusieurs LAB simultanément.
 Import/Export des configurations EVE du / vers le PC local.
 Plusieurs utilisateurs par le même LAB, chaque utilisateur maintient un compte
utilisateur.
 NAT intégré avec DHCP.
 Wireshark.

2. Distribution Linux : Debian

Debian est l'un du plus ancien et populaire système d'exploitation basée sur le noyau Linux
pour les ordinateurs personnels et les serveurs, il est gratuit et open source, développé par
le projet Debian, soutenu par la communauté, qui a été créé par Ian Murdock le 16 août
1993. Les nouvelles distributions sont mises à jour continuellement et stable. Et sa
communauté est mature et grande. Debian est également la base de nombreuses autres
distributions, notamment Ubuntu. 

3. Git
Le système de contrôle de version moderne le plus utilisé dans le monde, aujourd'hui, est
Git. Il est un projet open source mature et gratuite, développé à l'origine en 2005 par Linus
Torvalds.
Git est un logiciel permettant de suivre les modifications de n'importe quel ensemble de
fichiers, généralement utilisé pour coordonner le travail des développeurs en collaboration
le code source lors du développement de logiciels à l'aide de GitHub. Et aussi travailler sur
propre projet façon à de faire un Backup de projet par manière périodiquement et
synchroniser avec le site GitHub et il y a possibilité de revenir des versions précédentes de ce

58
Backup. Ses objectifs sont notamment la rapidité, l'intégrité des données et le support des
flux de travail distribués et non linéaires.

4. Installation
1. ANSIBLE (CLI)
Ansible s'installe facilement et uniquement sur serveur de gestion, alors pour
installer Ansible sur Debian 10, vous devez effectuer les trois étapes simples suivantes :
Étape 1 : Mettre à jour le système Debian 10
Avant d'installer Ansible sur Debian 10, vous devez le mettre à jour avec la commande
indiquée ci-dessous :

Étape 2 : Installer Ansible sur le système Debian 10

Une fois que la mise à jour du système est terminée, vous pouvez installer Ansible sur
Debian 10 avec la commande indiquée ci-dessous :

Pendant l'exécution de cette commande, vous verrez un message vous demandant si vous
voulez continuer l'installation ou non sur le terminal. Vous devez taper "Y" pour que le
processus d'installation continue à se dérouler sans problème.
Étape 3 : Confirmer l'installation d'Ansible sur le système Debian 10 :
L'installation d'Ansible sur un système Debian 10 est si simple qu'elle s'effectue en deux
étapes. Cependant, vous pouvez toujours vérifier s'il a été installé avec succès sur le système
Debian 10 ou non. Ceci peut être fait en vérifiant sa version avec la commande suivante :

Alors pour chaque distribution de Linux il y'a une méthode d'installation. Voici le lien qui
contient la méthode d'installation de chaque distribution Linux :
https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html

2. GIT
Si vous souhaitez installer les outils Git de base sur Linux via un installateur binaire, vous
pouvez généralement le faire par le biais de l'outil de gestion des paquets fourni avec la
distribution. Les dépôts par défaut de Debian vous offrent une méthode rapide pour installer
Git à partir d’utiliser apt :

59
Vous pouvez confirmer que vous avez correctement installé Git en exécutant la commande
suivante :

3. Ansible Tower
Il devient très difficile de gérer une grande infrastructure. Il existe différents utilisateurs et
groupes qui ont besoin de différents niveaux d'accès pour utiliser Ansible. De plus, nous
devons intégrer ces outils avec d'autres outils tiers pour faire fonctionner l'infrastructure
réseau selon des normes définies, comme d'avertir l'utilisateur par courrier électronique ou
en utilisant des applications de messagerie en cas d'échec. Nous avons également besoin
d'une piste d'audit pour suivre correctement qui a exécuté quelle tâche et quand. Et une
autre chose importante est le support produit. Ces fonctionnalités ne sont pas disponibles
dans Ansible CLI et ne peuvent être réalisées que par Interface Graphique Ansible Tower ou
Ansible AWX.

Figure 5.29 : Interface graphique Ansible tower

Maintenant, je vais expliquer comment installer Ansible Tower sur le système Linux :
Étape 1 : vous devez exécuter ces commandes

60
Étape 2 : Téléchargez-le package Ansible Tower via le lien
https://releases.ansible.com/ansible-tower/setup/
Étape 3 : Ajouter des mots de passe dans le fichier d’inventaire qui existe dans le package.
Étape 4 : Lancer le script ./setup.sh pour commencer l'installation.

4. Architecture cible
La figure 5.30 illustre l’architecture adoptée pour la réalisation de projet. Elle est composée
des 6 routeurs Cisco qui représentent un fournisseur de services qui interconnecte quatre
sites distants : Bureau Principal qui contient Firewall ASA et trois switches, Bureau Régional
qui contient aussi la même chose comme bureau précédent, Client site A, et Client Site B
chacun contient un routeur et un switch.

61
Figure 5.30 : Architecture cible de déploiement

62
1. Les équipements utilisés
Tout le travail de projet sera inscrit dans le cadre d'un périmètre bien défini qui concerne un
parc constitué d'un ensemble d'équipements réseau et sécurité :

Tableau 5.2 : Les équipements Cisco utilisés

Firewall Cisco ASA Cisco IOS

ASA_L1 Routeurs Switches

ASA_L2 R1, R2, R3, R4, R5, R6, MLS_L1, SW1_L1, SW2_L1,
RC1, RC2 MLS_L2, SW1_L2, SW2_L2,
SW1, SW2

2. Adressage
LOOPBACK 1 : 10.10.numéro_routeur.10/32

Tableau 5.3 : Adressage d’Architecture

Sites Equipements Interface Adresse

Mgmt0/0 192.168.1.6/24
ASA_L1
GI0/0 192.168.10.2/24
Bureau
MLS_L1 Vlan1 192.168.1.30/24
Principal
SW1_L1 Vlan1 192.168.1.31/24

SW2_L1 Vlan1 192.168.1.32/24

GI0/0 172.17.1.2/24
ASA_L2
GI0/1 172.20.1.1/24
Bureau
MLS_L2 Vlan1 172.20.1.10/24
Régional
SW1_L2 Vlan1 172.20.1.11/24

SW2_L2 Vlan1 172.20.1.12/24

Ethernet0/0 192.168.2.1/24

R1 Ethernet0/1 192.168.3.1/24

Ethernet0/2 192.168.10.1/24

Ethernet0/3 172.16.1.1/24

Ethernet0/0 192.168.2.2/24

63
 Fournisseur
R2 Ethernet0/1 192.168.6.2/24
de Services
Ethernet0/2 192.168.4.2/24

R3 Ethernet0/0 192.168.3.3/24

Ethernet0/1 192.168.5.3/24

Ethernet0/2 192.168.4.3/24

Ethernet0/0 192.168.7.4/24

R4 Ethernet0/1 192.168.8.4/24

Ethernet0/2 192.168.5.4/24

Ethernet0/3 192.168.6.4/24

Ethernet0/0 192.168.9.5/24

R5 Ethernet0/1 192.168.7.5/24

Ethernet0/2 172.17.1.1/24

Ethernet0/0 192.168.8.6/24

R6 Ethernet0/1 192.168.9.6/24

Ethernet0/2 172.18.1.6/24

Client - Site A RC1 Ethernet0/0 172.16.1.7/24

Ethernet0/1 192.168.100.1/24

Client - Site B RC2 Ethernet0/0 172.18.1.8/24

Ethernet0/1 172.30.1.1/24

3. Déploiement de la solution
1. Démarche de déploiement
Je vais travailler avec un fichier d’inventaire sous nom « inventorycisco » écrit en format INI
qui contient les groupes des hôtes (hosts:) qu'on souhaite de configurer.

64
 Figure 5.31 : Fichier d’inventory

Remarquez ci-dessus, l'adresse IP de ansible_host, c'est l'adresse IP de l'interface de gestion

de chacun des périphériques.

65
Dans ce fichier, les termes entre les crochets [ ] définissent un groupe. Par exemple,
[routeurs] est un groupe qui contient les routeurs, [asa] est un groupe qui contient les
firewalls asa, ...
Ensuite, je vais définir les informations de SSH de chaque groupe dans [nom_groupe:vars]
qui seront utilisées pour se connecter aux périphériques. Ces variables sont signifiées que le
nom d'utilisateur (ansible_ssh_user) et le mot de passe (ansible_ssh_pass) sont ceux que
nous avons défini lors de la configuration initiale de SSH des périphériques.
Notes aussi qu’un groupe all existe toujours et reprend tous les groupes et tous les hôtes
définis dans l’inventory.
Il y a deux méthodes d’automatiser les configurations, La première méthode est d’écrire
les playbooks de la manière normale et la seconde méthode est d’utiliser les rôles.
Je vais d’abord essayer d’écrire le playbook de Vlan par la première méthode normale juste
pour montrer la méthode.
Mais pour le reste des playbooks, j’utiliserai la méthode des Rôles, car cette méthode est
plus pratique pour gérer et exécuter plusieurs playbooks en même temps. En d’autres
termes, les rôles sont des playbooks génériques, qui peuvent être intégrés dans
d’autres playbooks. Ce concept est essentiel pour créer des tâches complexes. En fait, pour
rendre les playbooks lisibles, il vaut mieux construire des rôles qui peuvent être partagés,
distribués et assemblés, plutôt que créer un playbook qui sera difficile à maintenir et
complexe à utiliser et peu lisible.
La figure ci-dessous montre les rôles que j'utiliserai dans le projet :

66
 Figure 5.32 : Les rôles de ce projet

Maintenant, je vais créer un playbook « run_roles.yml » pour lancer les Rôles, voici un

exemple :

67
 Figure 5.33 : Playbook d'exécution des Rôles

Ce Playbook va permettre d’exécuter les Rôles (ospf, vrf, acl_asa, aaa) sur l’ensemble des
hosts contenus dans le groupe [routeurs_asa]. Ce groupe comprend à la fois les firewall Asa
et les routeurs Cisco.
Ansible utilise SSH pour pousser les configurations vers les périphériques cibles, donc dans
ce cas, nous avons besoin de configuration SSH et création un utilisateur avec privilège 15 et
password sur chacun des périphériques Cisco IOS et ASA avant de pouvoir automatiser.
Je voudrais terminer cette partie par un résumé de toutes les étapes nécessaires pour établir
la communication et le droit de lancer des playbooks :
1- Vérifier que Python est installé sur le serveur Linux.
2- installer ansible sur la distribution Linux.
3- Configurer SSH sur tous les périphériques de l’infrastructure.
4- Créer un utilisateur avec privilège 15 et password sécurisé sur tous les périphériques.
5- Vérifier le ping entre le serveur ansible et les périphériques.
6- Vérifier la connexion SSH entre le server ansible et les périphériques.
7- Définir un inventory des périphériques.
8- Vous devez écrire les playbooks.
9- Finalement, vous pouvez lancer le Playbook avec la commande suivante :

Ou à l'aide d'Interface graphique Ansible Tower/AWX.

2. Automatisation de configuration VLAN

Ce playbook est utilisé pour configurer le Vlan en trois étapes : la première tâche est de
créer des vlans dans tous les switches par une boucle sur le variable "name_id_vlan" en
même temps par un module "ios_vlan", et le deuxième tache "access port" permet de la
configuration Access port par affectation des interfaces à des VLANs, et le troisième tâches
"trunk" permet de configurer l'agrégation entre les switches pour transporter le trafic de
plusieurs VLANs.

68
 Figure 5.34 : Playbook de configuration du VLAN

3. Automatisation de configuration OSPF

Ce rôle permet de configurer OSPF avec deux zones dans le groupe [routeurs asa] qui
contient des routeurs de fournisseur de services et des Firewalls ASA :
Tasks :

69
Figure 5.35 : Tasks de rôle lié à la configuration OSPF

Vars :

70
 Figure 5.36 : Vars de rôle lié à la configuration OSPF

4. Automatisation de configuration EIGRP

Ce rôle aussi permet de configurer EIGRP dans le groupe [routeurs asa] qui contient des
routeurs de fournisseur de services et des Firewalls ASA :
Tasks :

Figure 5.37 : Tasks de rôle lié à la configuration EIGRP

Vars :

5. Automatisation de configuration AAA

Ce rôle est visé de configurer AAA et supprimer l'ancienne configuration si elle existe dans le
groupe [ios] qui contient des routeurs de fournisseur de services, des switches de bureau
principal, des switches de bureau régional :

71
Tasks :

Figure 5.38 : Tasks de rôle lié à la configuration AAA

File :

Figure 5.39 : File de rôle lié à la configuration AAA

Vars :

Figure 5.40 : Vars de rôle lié à la configuration AAA

Handlers :

72
 Figure 5.41 : Handlers de rôle lié à la configuration AAA

6. Automatisation de configuration GRE

Ce rôle permet de créer un tunnel entre le site A et le site B d'un client à l'aide de configurer
GRE dans le groupe [RC] qui contient les deux routeurs de client dans le site A et le site B :
Tasks :

Figure 5.42 : Tasks de rôle lié à la configuration GRE

7. Automatisation de configuration IPSEC

Tasks :
Le but de ce rôle est de sécuriser le tunnel GRE à l'aide de configurer IPsec dans le groupe
[RC] qui contient les deux routeurs de client dans le site A et le site B :

73
 Figure 5.43 : Tasks de rôle lié à la configuration IPsec

8. Automatisation de configuration VPN Site to Site

L'objectif de ce rôle est la configuration de VPN IPsec site to site entre le bureau principal et
le bureau régional, alors ce rôle visé le groupe [asa] qui contient les firewalls ASA_L1,
ASA_L2 :
Tasks :

74
 Figure 5.44 : Tasks de rôle lié à la configuration VPN

config_vpn_asa_l1.cfg :

Figure 5.45 : File asal1 de rôle lié à la configuration VPN

config_vpn_asa_l2.cfg :

Figure 5.46 : File asal2 de rôle lié à la configuration VPN

75
9. Automatisation de configuration NTP
Ce rôle permet de synchroniser l’horloge locale en tous les périphériques du réseau sur une
date et une heure de référence par la configuration de protocole NTP dans le groupe [all] qui
contient tous les périphériques. Aussi supprimer l'ancienne configuration NTP si elle existe.
Tasks :

76
 Figure 5.47 : Tasks de rôle lié à la configuration NTP

Vars :

Figure 5.48 : Vars de rôle lié à la configuration NTP

10. Automatisation de configuration DNS

Le but de ce rôle est de configurer DNS dans le groupe [all] qui contient tous les
périphériques du réseau :
Tasks :

77
 Figure 5.49 : Tasks de rôle lié à la configuration DNS

Vars :

11. Automatisation de BACKUP / RESTORE

Backup :
Le but de ce playbook est de faire un Backup périodique de tous les périphériques du réseau
et de stocker le Backup de chaque périphérique dans un fichier portant son nom :

78
 Figure 5.50: Playbook de Backup

Restore :
Ce playbook vous permet de restaurer la configuration de chaque périphérique à partir le
backup en cas de panne :

Figure 5.47 : Playbook de Restore

12. Collecte les informations des périphériques par Template Jinja2 

L'objectif de ce rôle est de collecter des informations sur tous les périphériques du réseau,
ces informations sont stockées dans des variables prédéfinies par Ansible facts à l'aide du
modèle Jinja2, qui permet de stocker ces informations de chaque périphérique dans un
fichier portant son nom :

79
 Figure 5.48 : Playbook d'exécution du template Jinja2

Jinja2 : info.j2

Figure 5.53 : Template Jinja2

Exemple parmi les résultats : R1.md

Figure 5.54 : Exemple de Résultat d’exécution de playbook

80
13. Tests et Vérification
Ce playbook permet de faire Troubleshooting à manière automatisé de l’infrastructure
réseau. Le mécanisme de fonctionnement se le fait en gardant les résultats des commandes
de Troubleshooting dans les fichiers portant le nom du périphérique, technologie et l'heure
d’exécution par une manière automatisée.
Dans ce playbook ci-dessous, je vais montrer une partie de Troubleshooting des technologies
qui sont : table routage, Vlan, VPN, NTP. De même manière, j'ai déjà fait des
Troubleshooting pour d’autres technologies.

81
82
 Figure 5.55 : Exemple Playbook de Troubleshooting

Conclusion
Ce dernier chapitre porte sur l’atteinte des objectifs de ce travail, j’ai pu réaliser une
automatisation de la configuration d’environnement qui concerne les périphériques de
l’infrastructure réseau en se basant sur la solution Ansible. Et j’ai définis les différentes
fonctionnalités, aussi j’ai présenté les fichiers qui représentent l'automatisation de
l’infrastructure, enfin j’ai vérifié l'automatisation de l’infrastructure.

83
 Conclusion générale et perspectives
En guise de conclusion pour ce rapport de mémoire de projet fin d’études, dans lequel ils
m’ont confié la mission de développer l'automatisation des équipements réseau et sécurité
de Cisco en intégrant l’outil de gestion de configuration et d’automatisation Ansible. En
effet, la thématique que j'ai traité au cours de ce stage a été très bien choisie et constitue un
sujet d’actualité. J'ai essayé dans ce stage de réaliser les objectifs que j'ai posés au début de
développement de rapport.
Alors je peux affirmer avec conviction, que le travail effectué au sein de l’entreprise
accueillante Intelcom, il a été très bénéfique pour ma carrière et il a ouvert un bon ensemble
d’issues et de portails à explorer par la suite. D’autre part, ce projet de fin d’études m’a
permis de consolider mon aptitude à comprendre et à analyser les besoins des entreprises
au niveau de réseaux et sécurité. Aussi, il m’a permis de bien comprendre le monde de
réseaux et sécurité, l’évolution de ce domaine m’a donné l’envie de bien m’approfondir
dedans, il m’a permis également de me familiariser avec le processus de réalisation de projet
dans un cadre professionnel.
De plus, j'encourage l’utilisation de ce rapport pour convaincre les clients de l'importance
d'utiliser cette solution Ansible.
En perspective, mon travail ne s'arrête pas dans cette phase, en effet, j'envisagerai
d'automatiser par Ansible des autres équipements au niveau de réseau et sécurité par
exemples : firewall Fortigate, firewall Palo Alto, Cisco ISE, Cisco Nexus...

84
 Webographie

[1]  https://www.veritis.com/blog/chef-vs-puppet-vs-ansible-comparison-of-devops-management-tools/

[2] https://linux.goffinet.org/ansible/presentation-produit-ansible/

[3] https://openclassrooms.com/fr/courses/2035796-utilisez-ansible-pour-automatiser-vos-
taches-de-configuration?status=published

[4] https://docs.ansible.com/ansible/latest/index.html

[5] https://docs.ansible.com/ansible/latest/network/index.html

[6] https://cisco.goffinet.org/ccna/

85