1

EPIGRAPHE

« En gestion ce que l’on contrôle à outrance nous contrôle et ce que nous ne gérons nous
gère ».

Sylvain tourangeau
 2

DEDICACE

A notre père POLOMBWE KALENGA qui grâce à ses efforts soutenus nous a offert la
meilleure formation que l’on puisse espérer en tant que passionné de l’informatique

A notre mère NYUNDU MUSAO pour tant d’exonération et dont l’attention soutenue
ainsi que les conseils ont marqués notre itinéraire ainsi que pour tous les moments passés à
nous prodiguer des conseils avisés grâce auxquels nous avons pu atteindre le bout de notre
formation. Vous êtes pour nous le modèle parfait d’une bonne mère.
 3

REMERCIEMENT
La réalisation de ce mémoire a été possible grâce au concours de plusieurs personnes
à qui nous voudrions témoigner toute notre gratitude.
Nous souhaitons avant tout remercier notre Dieu tout puissant pour la force et la grâce
qu’il nous a offerte enfin d’aboutir à la réalisation de ce mémoire.
Nous adressons nos sincères remerciements à Monsieur ZAGABE Yannick Directeur
du mémoire pour son suivi, ses conseils judicieux et ses discussions qui nous ont beaucoup aidé
au cours de nos recherches.
Nous tenons aussi à remercier Mr LWAPULA KULAILA Bob co-directeur du
mémoire, pour son aide dans la réalisation de ce modeste travail.
Nous exprimons nos vives reconnaissances à notre père BERTIN POLOMBWE et à
notre mère NICOLE NYUNDU pour leur soutien constant et leurs encouragements.
Enfin je remercie tous mes amis et compagnons de route, LIONNEL MWAMBA,
JEAN PAUL KABIMBA, ISRAEL MWAMBA, BENJAMIN TAKOBAJIRA, DANIEL
KESONGO, CLEMENT SHABANI, PRUDENCIANE MBAYO, ARISTOTE
KABASUBABU pour les encouragements qu’ils m’ont apportés.

POLOMBWE FIMBO Jacques

 4

AVANT-PROPOS

L’Ecole Supérieure des Technologies de l’Information et de la Communication organise

plusieurs filières parmi lesquelles l’Administration systèmes et réseaux dans laquelle nous
sommes inscrits et au terme de laquelle nous présentons ce travail intitulé « ETUDE D’UNE
SOLUTION D’AUTOMATISATION D’UNE INFRASTRUCTURE RESEAU ET
DATACENTER : CAS PRATIQUE APPLIQUE A UNE SOCIETE MINIERE DU GRAND
KATANGA. »
 5

TABLE DE TABLEAU
Tableau 1: PLAN D'ADRESSAGE LAN .................................................................... 22

Tableau 2: PLAN D'ADRESSAGE WAN ...................................................................23

Tableau 3: PLAN DE NOMMAGE ............................................................................. 23

Tableau 4: EXIGENCES NON FONCTIONNELLES ................................................. 35

Tableau 5: COMPARAISON DES TECHNOLOGIES ................................................ 54

Tableau 6: CRITERES TECHNOLOGIQUE ............................................................... 58

Tableau 7: PARAMETRE MODULE add_host ........................................................... 65

Tableau 8: PARAMETRE MODULE group_by .......................................................... 65

Tableau 9: PARAMETRE MODULE chekpoint .......................................................... 67

Tableau 10: PARAMETRE DU MODULE pymssql ................................................ 68

Tableau 11: PARAMETRE DU MODULE MISC ....................................................... 70

 6

TABLE DES FIGURES

Figure 1:ARCHITECTURE LOGIQUE DE HAUT NIVEAU .....................................24

Figure 2: RESEAU WAN MPLS ................................................................................. 26

Figure 3: LAN DE KOLWEZI .................................................................................... 27

Figure 4: LAN KAMBOVE......................................................................................... 28

Figure 5: LAN JOHANNESBURG ............................................................................. 29

Figure 6:DATACENTER KOLWEZI .......................................................................... 30

Figure 7: DIAGRAMME D'EXIGENCES ...................................................................36

Figure 8: DIAGRAMME DES CAS D'UTILISATION ............................................... 39

Figure 9: FONCTIONNALITES PRINCIPALES DU SYTEME ................................. 40

Figure 10: FONCTIONNALITES SECONDAIRES DU SYSTEME ........................... 41

Figure 11:CONCEPTION LOGIQUE GENERALE .................................................... 43

Figure 12:EXEMPLE D'UN FICHIER D'INVENTAIRE ............................................ 45

Figure 13:EXEMPLE D'UN GROUPE NGINX .......................................................... 45

Figure 14: DIAGRAMME DE SEQUENCE INVENTAIRE .......................................46

Figure 15: EXEMPLE D'UN FICHIER DE CONFIGURATION YAML .................... 48

Figure 16: DIAGRAMME DE SEQUENCE FICHIER DE CONFIGURATION .........49

Figure 17: API SYSTEME .......................................................................................... 50

Figure 18:ARCHITECTURE LOGIQUE DETAILLEE ............................................... 51

Figure 19 DOMINATION DE ANSIBLE SUR UNE REPRESENTATION RADAR . 58

Figure 20:EVOLUTION AU COURS DE 5 ANS DES TECHNOLOGIES ................. 59

Figure 21: ARCHITECTURE PHYSIQUE GENERALE ............................................ 61

Figure 22: ILLUSTRATION DE HOST INVENTORY DE ANSIBLE ....................... 62

Figure 23: PLAYBOOKS ANSIBLE ........................................................................... 63

Figure 24: SSH TRUST ............................................................................................... 63

Figure 25: ARCHITECTURE PHYSIQUE DETAILLEE ............................................ 64

 7

Figure 26: EXEMPLE MODULE DE BASE DES DONNEES. ...................................70

Figure 27: DIAGRAMME DE SEQUENCE SAUVEGARDE DES

CONFIGURATIONS ........................................................................................................... 72

Figure 28: DIAGRAMME DE SEQUENCE RESTAURER UNE SAUVEGARDE SUR

UN PERIPHERIQUE RESEAU ........................................................................................... 74

Figure 29: DIAGRAMME DE SEQUENCE MODULE ios_vlan ................................ 76

Figure 30: DIAGRAMME DE SEQUENCE INSTALLATION D'APACHE SUR UN

SERVEUR LINUX .............................................................................................................. 78

Figure 31: DIAGRAMME DE SEQUENCE DE MISE A JOUR AUTOMATIQUE SUR

WINDOWS .......................................................................................................................... 80

Figure 32: DIAGRAMME PHYSIQUE .......................................................................81

Figure 33:Nexus .......................................................................................................... 85

Figure 34: ARCHITECTURE D'UN SWITCH NEXUS .............................................. 86

Figure 35: Details d’installation des switches Nexus pour la démonstration ................. 87

Figure 36: config module Datacenter ........................................................................... 91

Figure 37:Installation Ansibke ..................................................................................... 96

Figure 38: DEPENDANCE à L'INSTALLATION DE ANSIBLE ............................... 96

Figure 39: . Configuration de base des Provider ........................................................... 97

Figure 40:Configuration des VRFs .............................................................................. 97

Figure 41:. Configuration du routage Eirgp..................................................................98

Figure 42:Verification du Mpls .................................................................................... 98

Figure 43: Vérification de notre table BGP ..................................................................99

Figure 44: Routes Eigrp et BGP................................................................................... 99

Figure 45: Vérification des routes redistribuées ........................................................ 100

Figure 46: Création des groupe slocals ...................................................................... 100

Figure 47:Vérification de vlan disponible dans les switchs se trouvant dans Host
inventory Ansible avec les playbooks ................................................................................. 101
 8

Figure 48: VLANS Vu sur le serveur Ansible ............................................................ 101

Figure 49: Déploiement des VLANS1 ....................................................................... 102

Figure 50: Déploiement des VLANs 2 ....................................................................... 102

Figure 51: Déploiement des VLANs 3 ....................................................................... 103

Figure 52: Vérification du déploiement du VLANs .................................................... 103

Figure 53 : EMULATION DU RESEAU NEXUS AVEC EVE ................................. 104

Figure 54: illustration login Nexus NX9K-01 ........................................................... 104

Figure 55: illustration login Nexus NX9K-02 ........................................................... 105

Figure 56: Le fichier inventaire avec deux nexus enregistré ....................................... 105

Figure 57: Test de connectivité sur les nexus ............................................................. 106

Figure 58:Playbook pour l'activation de l'API nxos_nxapi ......................................... 106

Figure 59: Resultats de l'activation de nxos_nxapi ..................................................... 106

Figure 60: Activation de l'API sur le nexus 01 ........................................................... 107

Figure 61: Activation de l'API sur le nexus 02 ........................................................... 107

Figure 62: PLAYBOOK pour le déploiement des VLANs sur le nexus ..................... 107

Figure 63:Etat initial des VALNS sur les nexus ......................................................... 108

Figure 64: Execution du playbook ............................................................................. 108

Figure 65: RESULTAT OBSERVABLE DANS LE SWITCH NEXUS .................... 108

 9

Table des matières

Chapitre 0. INTRODUCTION GENERALE ............................................................... 13

0.1 Problématique : ............................................................................................ 13

0.2 Hypothèses : ................................................................................................ 13

0.3 Choix et Intérêt du sujet : ............................................................................. 14

1. Intérêt personnelle ....................................................................................... 14

2. Intérêt scientifique ....................................................................................... 14

3. Intérêt Social................................................................................................ 15

0.4 Méthodologie :............................................................................................. 15

0.5 Etat de l’art : ................................................................................................ 15

0.6 Délimitation du travail : ............................................................................... 15

0.7 Subdivision du travail : ................................................................................ 16

Chapitre 1. SPECIFICATION DU FUTUR SYSTEME ............................................... 17

Introduction. ............................................................................................................ 17

1.1 Présentation de l’entreprise. ............................................................................... 17

1.1.1 Situation géographique ................................................................................... 17

1.1.2 Organisation et Organigramme .......................................................................17

1.1.3 Présentation des Opérations de l’usine ............................................................ 18

1.2 Etude de l’existant. ............................................................................................ 18

1.2.1 Contexte. ........................................................................................................18

1.2.1.1 Activités de la société................................................................................... 19

1.2.1.2 Sites Miniers ................................................................................................ 19

1.2.1.3 Description des sites..................................................................................... 20

1.2.1.4 Description détaillée des villes minières. ...................................................... 20

1.2.3 Système informatique ..................................................................................... 21

1.2.3.1 Infrastructure Réseau et Système existante ................................................... 21

 10

1.2.3.2 Plan d’adressage. ...................................................................................... 22

1.2.3.3 Plan de nommage. .................................................................................... 23

1.2.4 Architecture logique de haut niveau de l’infrastructure....................................23

1.2.4.1 Architectures logique détaillée. .................................................................... 25

1.2.4.2 Le réseau WAN avec MPLS. .......................................................................25

1.2.4.3 LAN détaillé par site .................................................................................... 27

1.2.4.5 Architecture système ............................................................................. 30

1.2.4.6 Présentation du système. .............................................................................. 31

1.2.4.7 Organisation du système. ............................................................................. 32

1.2.4.8 Critique du système. ..................................................................................... 32

Points forts .......................................................................................................... 32

Points faibles .......................................................................................................32

1.3 Critique de l’existant. ......................................................................................... 32

1.3.1 Points fort ...................................................................................................32

1.3.2 Point faible ..................................................................................................32

1.4 Spécification des besoins et exigences ......................................................... 33

1.4.1 Besoins .................................................................................................... 33

1.4.2 Exigences fonctionnelles ............................................................................. 33

1.4.3 Exigences non fonctionnelles ......................................................................34

1.4.4 Besoin futur ................................................................................................ 35

1.5. Conclusion partielle ...................................................................................... 37

Chapitre 2 CONCEPTION LOGIQUE DU SYSTEME ............................................... 38

2.1 Introduction .......................................................................................................38

2.2 Conception logique générale .............................................................................. 42

1. Inventaire.....................................................................................................44

2. Fichier de configuration ............................................................................... 44

 11

3. Modules .......................................................................................................44

4. Template......................................................................................................44

5. Hôtes ........................................................................................................... 44

6. Api du système ............................................................................................ 44

7. Operateur .....................................................................................................44

2.3 Conception logique détaillée .............................................................................. 44

2.3.1 Description détaillée de l’architecture ............................................................. 45

1. Le fichier d’Inventaire : ............................................................................... 45

2. Fichier de configuration : ............................................................................. 46

3. Les modules ................................................................................................. 49

4. Api système ................................................................................................. 50

2.4 Conclusion partielle ........................................................................................... 52

Chapitre 3. Conception physique ................................................................................. 53

3.1 Introduction ................................................................................................. 53

3.2 Niveau d’abstraction .................................................................................... 53

3.2.1 Choix des technologies ................................................................................ 53

3.2.1.1 Critères de choix ...................................................................................... 53

3.3 Présentation de Ansible. ............................................................................... 59

3.4 ARCHITECTURE PHYSIQUE GENERALE .............................................. 60

3.5 ARCHITECTURE PHYSIQUE DETAILLEE ............................................. 64

1.6 Plan d’installation ........................................................................................ 81

3.6.1 DIAGRAMME PHYSIQUE .................................................................... 81

3.6.2 Blocs ou Modules à Installer. ...................................................................82

b. Installation de La couche cœur .....................................................................83

3.7 Plan de configuration ................................................................................... 89

3.6.1 Blocs ou Modules à Configurer. ............................................................... 89

 12

3.8 Plan d’implémentation ................................................................................. 94

3.9 Conclusion partielle. .......................................................................................... 95

Chapitre 4. IMPLEMENTATION ET TEST................................................................ 96

CONCLUSION GENERALE .................................................................................... 109

Bibliographie ............................................................................................................. 111

 13

Chapitre 0. INTRODUCTION GENERALE

0.1 Problématique :

Dans près de 70% d’entreprises, nous rencontrons des projets de migrations et de gestion
optimal des infrastructures informatiques, de quoi découlent les taches d’administration des
équipements inter-réseaux ainsi que des serveurs, des logiciels selon les besoins des entreprises.

Dans des réseaux évolutifs, les administrateurs ont plusieurs serveurs à gérer et du coup ces
tâches deviennent de plus en plus complexe

Dans cette optique que faire pour effectuer ces taches d’administration de façon efficace,
éliminer les contraintes géographiques, gagner du temps en gérant plusieurs serveurs en même
temps c’est-à-dire de façon parallèle.

Partant de ce fait, quelles technologies peut-on adopter pour subvenir à notre besoin de gagner
du temps dans des taches d’administration dans un réseau en général ?

Dans le même ordre d’idée, que faire pour :

 Coordonner les différents flux de travail et réduire de manière très significative

les délais de traitement,
 Fiabiliser l’ensemble des processus et des opérations à forte occurrence et à faible
valeur ajoutée,
 Superviser les ressources et informer l’utilisateur sur sa consommation, sur le taux
de disponibilité du service, etc.
 Fournir un service à la demande en libre-service en tenant compte d’un « capacity
planning1 »,
 Gérer le cycle de vie des ressources Client (création, suspension, fin d’un
engagement).
 Comment implémenter ces technologies et les adapter à notre réseau ?

0.2 Hypothèses :

1 Capacity planning (La planification de la capacité) est le processus de détermination de la capacité de

production nécessaire à une organisation pour répondre aux demandes changeantes de ses produits.
 14

Pour répondre à toutes ces questions, nous allons utiliser un outil de pilotage systèmes
sans agent faisant partie de la famille des outils DevOps 2, qui nous permettra de simplifier des
opérations d’orchestration complexes, de faire du management de configuration centralisé sur
un grand nombre de machines.

L’orchestration procurera un effet bénéfique immédiat sur les conditions de travail au

sein de toute la chaine de production informatique et permettra de faire de précieuses économies
administratives et financières.

Les résultats de notre automatisation seront une organisation agile, un déploiement rapide
des services, des modifications et des mises hors service sans erreur de configuration. Nous
savons que le niveau élevé des contrats de niveau de service et le temps nécessaire au service
sont essentiels dans toutes les activités.

Pour vérifier l’hypothèse, les concepts de l’automatisation seront implémentés dans un

environnement d’émulation des systèmes et réseaux informatique appelé EVE (Emulated
Virtual Environment) qui permettra de reproduire à une petite échelle toutes les technologies
mises en œuvre dans les réseaux et Datacenters modernes.

0.3 Choix et Intérêt du sujet :

1. Intérêt personnelle : Le présent sujet qui a trait au Software Defined Datacenter

(SDDC) nous passionne du fait qu’il offre une plate-forme unifiée, qui par ailleurs
justifie son choix.
2. Intérêt scientifique : L’automatisation et la « programmabilité » des infrastructures
réseaux et Datacenter permet une stratégie de positionnement unique pour toutes les
problématiques des DSIs3 avec une seule solution, de virtualiser tous les composants
systèmes et réseaux : serveurs, stockage, réseau, sécurité. Avec pour objectif
d’augmenter le niveau d’abstraction à son maximum. Aussi nous pensons qu'il
permettra à nos lecteurs de s'imprégner de quelques notions sur l'orchestration des
serveurs.

2
Le devops est un mouvement en ingénierie informatique et une pratique technique visant à l'unification
du développement logiciel (dev) et de l'administration des infrastructures informatiques (ops), notamment
l'administration système [14].
3
Le directeur des systèmes d'information (DSI est responsable de l'ensemble des composants matériels
(postes de travail, serveurs, équipements de réseau, systèmes de stockage, de sauvegarde et d'impression, etc.)
 15

3. Intérêt Social : L’automatisation et la « programmabilité » des infrastructures réseaux

et Datacenter va changer la manière dont les entreprises migrent et déploient leurs
applications. Il libère l’application de l’infrastructure physique, qui va permettre aux
entreprises de déployer les applications de manière très flexible.

0.4 Méthodologie :

Dans le but de mieux appréhender les problèmes posés et proposer des solutions
effectives, une approche méthodique du travail est indispensable.

Nous allons donc dans notre travail utiliser le Top Down Design en utilisant le langage
de modélisation « SysML ». SysML est un langage de modélisation faisant la spécification des
systèmes, l’Analyse structurelle, la description et la conception des systèmes modulaires ainsi
que la vérification et la validation de leurs faisabilités avant leurs réalisations.

Nous allons utiliser un logiciel de simulation pour réaliser notre travail.

0.5 Etat de l’art :

La recherche des entreprises à renforcer l’agilité de leurs portefeuilles d’applications et

la continuité de service, amène les infrastructures à accélérer leurs propres transformations. La
stratégie actuelle qui se détache abonde vers l’hébergement hybride (mixe, privé et publique),
en tenant compte des solutions cloud en mode privé ou public. La virtualisation est une
technique bien qu’ancienne mais très efficace pour consolider les ressources offrant une
abstraction qui masque les détails d’un équipement. Dans le cadre des travaux déjà fait ; Le
Software Defined Datacenter a déjà été implémenter dans le cadre
d’automatisation/orchestration des ressources IT globale ou par brique de services réparties
entre un Hébergement IT traditionnels, un cloud privé et/ou un cloud public, dans le
déploiement et la gestion des serveurs. Il a déjà été également implémenter dans le but de créer
une plateforme unifiée. Nous nous sommes principalement inspiré du travail « GESTION DES
CONFIGURATIONS D’UN DATACENTER BASEE SUR PUPPET ET FOREMAN
« Cas de Katanga Networking Academy (KANACAD) »

0.6 Délimitation du travail :

Notre travail s'est étendu de la période allant du mois de janvier 2019 jusqu'à la fin du
mois de juillet 2019. Période pendant laquelle nous avons rédigé notre travail.
 16

Notre travail va se limiter sur la gestion unifiée unique qui permet de surveiller et
d'administrer de manière centralisée toutes les applications sur des zones géographiques
physiques, des infrastructures hétérogènes.

Le sujet est complexe, dans ce travail il sera question d’un « proof of concept » qui va
illustrer la solution a une petite échelle. Dans un projet réel, ce travail pourra être utilisé pour
étendre la solution à toute l’entreprise.

0.7 Subdivision du travail :

Ce travail vise à mettre en place une solution d’automatisation et de gestion unifiée d’un
réseau Datacenter comme l’indique le sujet. De ce fait seront exposées différentes étapes qu’il
nous faudrait franchir afin de présenter nos contributions dans le cadre du dit sujet.

Outre l’introduction générale et la conclusion, ces contributions seront structurées en trois

grands chapitres.

Le chapitre 1 se basera sur la SPECIFICATION FONCTIONNELLE DES

EXIGENCES, de là nous présenterons brièvement notre champ d’application et parlerons de
ses exigences fonctionnelles et non fonctionnelles.

Le chapitre 2 est dédié à la CONCEPTION LOGIQUE de notre système, dans celui-ci

nous décrirons les différents scenarios dans lesquels nous pourrons utiliser notre système.
Chaque scenario représente un cas d'utilisation, nous présenterons ainsi les différents
diagrammes de modélisation.

Nous proposons, dans le chapitre 3, un cadre basé sur la CONCEPTION PHYSIQUE. C’est
dans ce dernier que nous amorceront l’implémentation de notre système.

Le chapitre 4 est dédié à l’IMPLEMENTATION de notre système

 17

Chapitre 1. SPECIFICATION DU FUTUR SYSTEME

Introduction.

Afin de bien poursuivre notre travail et de fournir le système souhaité par l’entreprise, nous
allons d’écrire L’entreprise en général. Et puisque notre solution est informatique, nous
mettrons un accent particulier sur l’infrastructure réseaux.

Nous traiterons aussi de la manière dont les tâches administratives sont gérées
actuellement pour y ressortir les points forts et faibles, lesquels nous permettrons d’établir les
besoins fonctionnels, non fonctionnels, les exigences et les contraintes.

1.1 Présentation de l’entreprise.

Pour des raisons de sécurités nous ne pouvons pas divulguer le nom de la société pour
laquelle on travail, c’est pourquoi certaines informations seront anonymes.

1.1.1 Situation géographique

La société se trouve dans la région minière du grand Katanga.

1.1.2 Organisation et Organigramme

L’entreprise possède une organisation standard et typique des sociétés minière.

A sa tête il y a le Président Directeur Général, suivi des Directeurs généraux qui supervisent les
Directeurs généraux chargés des opérations, les chargés de l’administration et finances, de
l’environnement, de la santé et de la sécurité au travail.

Puis les Managers qui sont gérés par les directeurs généraux, voici quelques
Manager :

 Manager de la mine
 Manager de l’exploitation minière
 18

 Manager des usines de traitement rapporte au directeur général des opérations.

Les Managers chapotent les super intendants généraux, à leurs tours ils chapotent les
super intendants.

 PDG
 Directeurs généraux
 Directeur général chargé des opérations et les Chargés de l’administration et
finance
 Directeur général chargé de l’environnement, de la santé et de la sécurité su
travail
 Manager de la mine
 Manager de l’exploitation minière
 Manager des usines de traitement rapporte au directeur général des opérations.
 Les super intendants
 Les super intendants.

Le département IT dépends des opérations.

1.1.3 Présentation des Opérations de l’usine

Usine Métallurgique (chercher moi-même usine piro-métallurgiques et hydro-

métallurgique) des usines séparées de 90 Km (mesuré distance Kolwezi et kambove) qui
reçoivent les minerais de 7 mines et une mine souterraine.

1.2 Etude de l’existant.

Cette section traite respectivement l’infrastructure système et réseau existante afin de
pouvoir y insérer notre future solution, ainsi que le service d’administration des centaines des
serveurs et son organisation en vue d’en déduire les points forts et les points à améliorer qui
nous permettrons d’établir les exigences auxquelles le futur système devra répondre.

1.2.1 Contexte.

Une société minière en RDC intègre en son sein un département informatique qui gère
son système d’information. Celui-ci est basé sur le produit SAP, mais possède également
plusieurs systèmes informatiques qui gèrent les différents domaines de production minière et la
productivité de l’entreprise.
 19

Nous pouvons citer entre autres :

 Un système de contrôle de processus industriel qui est séparé du réseau business par un
firewall.
 Un ensemble d’applications minières pour gérer les différents aspects de la stabilité du
terrain, de la flotte des engins (Dispatch informatisé), de la planification minière etc.
 Un ensemble d’applications de gestion administrative telle que le pointage automatique,
le contrôle d’accès pour la sécurité physique etc.
 Un ensemble d’applications qui regroupe les communications unifiées, la messagerie,
les services d’infrastructure système et réseaux etc.

Tous ces systèmes (plus de 100 serveurs) sont hébergés sur des serveurs virtuels pour la
plus part. Le Système SAP est géré dans un Datacenter éloigné en dehors du pays alors que le
reste se trouve localisé principalement dans un Datacenter construit sur une infrastructure
VSAN (VMware hyper-convergée).

Un réseau d’entreprise reliant les sites éloignés par MPLS permet de couvrir tous les
bureaux et opérations de la société.

Ces systèmes sont gérés traditionnellement par une équipe IT avec une structure très
minimale. Cette gestion traditionnelle non basée sur la modélisation d’entreprise donne tout de
même des résultats plus ou moins satisfaisants.

A court terme, les choses semblent bien marcher, mais la gouvernance IT n’est pas
optimale. La gestion opérationnelle des systèmes est manuelle et complexe. L’ingénierie et le
développement sont négligés dans le département.

Des problèmes sociaux au sein de l’équipe IT empêchent un meilleur professionnalisme

dans le travail avec d’éventuel conséquences qui peuvent s’en suivre à long terme.

1.2.1.1 Activités de la société

Exploitation minière pour la production du cuivre et du cobalt.

1.2.1.2 Sites Miniers

La société est implantée dans 4 villes de la RDC et dans 3 villes internationales, parmi
lesquels nous nommons :

 Kolwezi
 20

 Kambove
 Lubumbashi
 Kinshasa
 Johannesburg
 Hongkong
 Londres

Il n’y a que deux villes qui comportes des sites miniers, les autres villes ont des bureaux
administratifs.

1.2.1.3 Description des sites

La société est implantée dans les villes suivantes :

a. Kolwezi :

La ville de Kolwezi possède 3 sites miniers, parmi lesquels :

 Un site minier qui comporte une usine hydro métallurgique avec 5 mines à ciel ouvert.
 L’autre site comprend une mine souterraine et deux mines à ciel ouvert.
 Un site se trouve à Kolwezi et un autre site à Kambove.

Le site minier de Kolwezi est divisé en plusieurs zones.

b. Kambove : possède trois sites miniers et un site administratifs

c. Lubumbashi : La société possède un site administratif qui est le siège de la société.
d. Kinshasa : La société possède un site administratif à Kinshasa qui est une
représentation de la société chargée des affaires avec le gouvernement.
e. Johannesburg : Possède un site administratif pour les opérations commerciales.
f. Londres : La société possède une représentation pour les relations internationales.
g. Hongkong : La société est une filiale d’une multinationale basée à Hongkong. C’est
là que se trouve le quartier général de la société mère.

1.2.1.4 Description détaillée des villes minières.

A Kolwezi il y a trois sites administratifs qui supportent les opérations minières et de

traitement. Parmi les trois il y en a un ou se trouve le camp des travailleurs qui sont logés par
la société, un site consacré à la logistique, un site pour l’administration générale.
 21

Le bâtiment administratif de la logistique a deux niveaux, chaque niveau compte 100

utilisateurs. Le bâtiment administratif de l’administration générale possède 3 niveaux.

Il y a 10 bureaux éparpillés à la logistique qui iront sur le core switch de la logistique.

Dans le camp il y a un bâtiment pour le Datacenter, c’est là qu’il y a tous les serveurs de
l’entreprise.

Un Datacenter de backup se trouve à Kambove.

Il y a 20 bureaux éparpillés dans tous le camp.

A la mine (opération de la mine) il y a un bureau administratif de deux niveaux de 50

personnes, bureaux éparpillés 5.

A l’usine (site des opérations métallurgiques) de Kolwezi il y a deux bâtiment à deux

niveaux et ‘un niveau (le ré de chaussé et le premier étage) et a à peu près 100 utilisateur.

Il y a à peu près 15 bureaux éparpillés connecté au distribution switch de l’usine ce sont

des switches à 8 ports chacun.

Un dispatch informatisé gère la flotte des engins miniers, il est situé à une distance de 30
km par rapport au centre-ville, l’usine possède aussi des bureaux techniques pour la gestion des
opérations métallurgiques. Site des bureaux pour les opérations de la mine. Il est éloigné des
bureaux des opérations minières de 1km, c’est un petit bureau avec un access switch de 24 ports
rélié au distribution de ops.

Kambove : Les même sites que ceux de Kolwezi ;

Site administratif, 1 niveau qui sera connecté au site de télécom

Site de mine, 1 niveau

Site de l’usine, deux bâtiments de 1 niveau avec 3 bureaux éparpillés.

Bureau administratifs chargé de l’administration et de la logistique.

1.2.3 Système informatique

A Hongkong, il y a un ERP qui permet la gestion intégrée de toute l’entreprise et cette

partie est inaccessible à la gestion locale.

1.2.3.1 Infrastructure Réseau et Système existante

 22

L’infrastructure réseau de L’Entreprise est composée de plusieurs sites distants (Kolwezi,

Kambove, Kinshasa, Lubumbashi, Hongkong, Londres.), lesquels sont interconnectés par le
fournisseur d’accès internet VODAFONE.

1.2.3.2 Plan d’adressage.

Tableau 1: PLAN D'ADRESSAGE LAN

 23

Tableau 2: PLAN D'ADRESSAGE WAN

1.2.3.3 Plan de nommage.

Tableau 3: PLAN DE NOMMAGE

1.2.4 Architecture logique de haut niveau de l’infrastructure.

L’infrastructure réseau de « Anonymous » est composée de plusieurs sites distants

(Lubumbashi, Kinshasa, Johannesburg. . . ), lesquels sont interconnectés par le fournisseur
d’accès internet VODACOM en utilisant la technologie MPLS.
Cependant les réseaux des différents LAN (Local Area Network) sont implémenter avec le
protocole de routage EIGRP et les différents WAN (Wide Area Network) sont connecté entre
eux par la technologie MPLS.
 24

Figure 1:ARCHITECTURE LOGIQUE DE HAUT NIVEAU

 25

1.2.4.1 Architectures logique détaillée.

Dans cette partie nous illustrerons les différents types de réseaux que possède l’entreprise,
nous allons faire un « proof of concept ». Ainsi nous décrirons le réseau WAN avec MPLS, les
LAN détaillés des quelques sites.

1.2.4.2 Le réseau WAN avec MPLS.

La société interconnecte ses différents sites en passant par un fournisseur MPLS, ce

dernier utilise des protocoles IGP (Interior Gateway Protocol) et EGP (Exterior Gateway
Protocol) pour fournir le service MPLS à la société. Il utilise également les labels dans son
Back-bone, nous approfondirons cela dans la suite du travail
 26

Figure 2: RESEAU WAN MPLS

 27

1.2.4.3 LAN détaillé par site

Comme dit ci haut nous détaillerons quelques LAN de la société.

Le diagramme ci-dessous illustre le Lan de Kolwezi.

Figure 3: LAN DE KOLWEZI

 28

Le diagramme ci-dessous illustre le Lan de Kambove.

Figure 4: LAN KAMBOVE

 29

Le diagramme ci-dessous illustre le Lan de Johannesburg.

Figure 5: LAN JOHANNESBURG

 30

1.2.4.5 Architecture système

Figure 6:DATACENTER KOLWEZI

 31

La Société possède plusieurs Serveurs dans son Datacenter, parmi lesquels nous pouvons
cités :

 Serveur de base des données

 Serveur de messagerie
 Serveur de fichier et d’impression
 Serveur de share point
 Serveur de communication unifié (Voice, vidéoconférence)
 Virtualisation, stockage
 Serveur proxy
 Serveur d’application (application sous Windows et sous linux)
 Contrôleur de Domaine.

1.2.4.6 Présentation du système.

Le côté systèmes de la société s’occupe de :

- D’effectuer les tâches d’administration, telles que :

o Installation des logiciels.
o Arrêt et redémarrage des services.
o Faire des mises à jours.
o Effectuer les configurations.
o Créer des utilisateurs en plus d’autres sur plusieurs serveurs,
qui sont parfois distants.
o Entretenir les serveurs.

L’infrastructure système de l’entreprise est composée de plusieurs branches dans

lesquels nous nommons : Un Datacenter principal sur le site de Kolwezi, un cloud privé à
Johannesburg et un Datacenter de Backup à Kambove, Le diagramme ci-haut illustre une vue
de haut niveau (moins de détails) de ce qu’est le Datacenter de Kolwezi.
 32

1.2.4.7 Organisation du système.

Nous pouvons dire qu’administrer c’est gérer, comme dans toutes entreprises,

Les administrateurs systèmes de la société installent et configurent le matériel, installent les

applications sur un ou plusieurs postes et tout cela ils le font manuellement, ils gèrent les
utilisateurs ce qui comprends l’ajout, la suppression d’un profil, la gestion des droits spécifiques
ou par groupe.

Historiquement, les administrateurs systèmes ont généralement gérer les serveurs,

installer des logiciels, modifier des configurations et administrer des services manuellement, la
société ne fait pas exception pour ces administrateurs.

1.2.4.8 Critique du système.

Points forts

L’entreprise est bien organisée en ce qui concerne la partie infrastructure réseau du fait
qu’elle possède une liaison MPLS pour connecter ses sites WAN et utilise le routage par EIGRP
pour connecter ses sites LAN.

Points faibles

Le système est soumis à plusieurs défaillances humaines, il y a un parc informatique à gérer

mais un faible personnel et plusieurs tâches complexe à orchestrer sans automatisation.

1.3 Critique de l’existant.

1.3.1 Points fort

La société est à jour avec les nouvelles technologies.

1.3.2 Point faible

Le parc informatique se gère manuellement, ainsi cela réduit la productivité car le temps
investis pour la gestion du système est énorme.
 33

1.4 Spécification des besoins et exigences

1.4.1 Besoins

Dans le cadre du sujet ; Ayant eu à mainte reprise l’occasion de discuter avec les
responsables des services (systèmes et réseaux) de « Anonymous », il en résulte les besoins
suivants :

- Standardiser la gestion des serveurs se trouvant sur diverses succursales.

- Gagner du temps et être plus productifs.
- Démarrer ou redémarrer les services d’une multitude de serveurs en un temps record.
- Gérer des switchs et routeurs.
- Eliminer les tâches répétitives. ;
- Surmonter la complexité.
- Centraliser la gestion administrative.
- Déployer de manière efficiente les services.
- Réduire sensiblement le coût de la gestion administrative.

1.4.2 Exigences fonctionnelles

Il s'agit là des fonctionnalités du système. Ce sont les besoins spécifiant un comportement

d'entrée / sortie du Système. Ainsi ils permettent de ressortir une action pouvant être menée sur
l'infrastructure en réponse à la demande.

- Le système doit être capable de supporter l’infrastructure et les équipements du

Datacenter ainsi que des diverses succursales de l’entreprise.
- Le système doit être flexible.
- Le système doit décrire les tâches à accomplir sur les différents serveurs.
- Le système doit Améliorer la collaboration et la satisfaction professionnelle.
- Le système doit optimiser le temps de gestion.
- Le système doit permettre de copier un fichier sur l’ensemble de serveurs.
- Le système doit permettre d’appeler des modules pour exécuter les commandes que
nous voulons.
- Les tâches administratives doivent être déployés sans tenir compte de la distance
géographique (aucune contrainte géographique).
- Le système doit réduire sensiblement les erreurs.
- Le système doit adresser plusieurs serveurs en parallèle.
 34

- Le système doit Regrouper des hôtes et les gérer indépendamment de leurs

emplacements physiques.
- Le système doit permettre bien que plusieurs tâches puissent nécessiter une même
action, l’action en question ne doit être lancée qu’après l’exécution de tous les blocs
tâches.
- Le système doit permettre une vitesse d’exécution des scripts grandement améliorée.
- Le système doit permettre d’installer les paquets dans leur dernière version, dois
également permettre l’installation des dépendances pour le package.
- Le système doit être capable créer des boucles.
- Le système doit gérer à la fois des serveurs, des switchs, des routeurs, etc.
- Le système doit permettre de lancer les tâches sur plus de serveurs en parallèle.
- Le système doit permettre de scinder les tâches en différents fichiers et de les
importer au besoin dans les différents scripts.
- Le système doit être performant.
- Le système doit améliorer la productivité de « Anonymous ».

1.4.3 Exigences non fonctionnelles

Il s'agit des besoins qui caractérisent le système. Ce sont des besoins en matière de
performance, de type de matériel ou le type de conception, contraintes internes et externe
auxquelles le système doit répondre, c'est ainsi ; Afin d’obtenir un système qui convienne le
mieux à l’entreprise ; notre système devra répondre à ces exigences :

Disponibilité

Facilité d'installation

Gestion aisée

Evolutivité

Langage de configuration compréhensible

Interopérabilité
 35

Coût réduit

Tableau 4: EXIGENCES NON FONCTIONNELLES

Il y a une exigence de la part de l’entreprise d’utiliser uniquement certains types

d’équipements comme standards tel que Dell pour les Workstation, Cisco pour les serveurs et
les équipements réseaux en général, Nexus pour les switches du Datacenter.

1.4.4 Besoin futur

L’entreprise « Anonymous » est une entreprise évoluant dans le secteur minier et produit
généralement du cobalt et du cuivre, elle a pour objectif de devenir le premier producteur du
cuivre en Afrique donc au monde par conséquent.

Afin d’y parvenir l’entreprise s’est muni d’un Datacenter (centre des données) pour
améliorer sa productivité en échangeant les informations de ses différentes succursales sur
l’évolution de ses mines ainsi que des transactions faites.

D’où le besoin suivant :

- Le système doit supporter l’augmentation du nombre des serveurs du Datacenter.

Le diagramme ci-dessous répertorie les exigences du système :
 36

Figure 7: DIAGRAMME D'EXIGENCES

 37

1.5. Conclusion partielle

Pour conclure ce chapitre, nous dirons qu’il a été l’occasion pour nous de d’écrire
l’entreprise bénéficiaire de notre future solution en générale. L'étude que nous avons menée
nous a permis de mettre un accent sur les problèmes réels que rencontre « Anonymous » afin
d'y ressortir le maximum d'idées qui nous ont mené à la détermination des objectifs que nous
devrons atteindre dans ce présent travail. C'est pour cela que nous aurons à proposer un système
qui apporte des solutions aux différents problèmes liés à la gestion des configurations de
l'infrastructure.
 38

Chapitre 2
CONCEPTION LOGIQUE DU SYSTEME
2.1 Introduction

Ce chapitre se penchera en premier sur les aspects conceptuels de ce travail. L'étude de

l'existant nous a permis de ressortir les besoins et les fonctionnalités qu'aura le futur système.
A ce stade celui-ci parait comme une boîte noire qui encapsule tous les mécanismes qui pourront
répondre aux fonctionnalités demandées, nous allons le décomposer en modules dans le but de
réduire son niveau d'abstraction.

Nous concevrons l’architecture logique, l’architecture logique détaillée, puis physique.

Ensuite, nous érigerons le plan et la procédure d’installation, le plan et la procédure de
configuration, le plan et procédure de test et le plan d’implémentation.

Pour commencer, faisons un traitement des actions principales qu’entreprendrons les

différents acteurs vis-à-vis du système. Le diagramme de cas d’utilisation que nous utiliserons
d´écrira le scénario global.
 39

Figure 8: DIAGRAMME DES CAS D'UTILISATION

 40

Ensuite, se référant au diagramme ci-haut nous pouvons en tirer les principales fonctionnalités du système que nous approfondirons dans la
conception logique et plus en détail, dans la conception logique détaillée.

Figure 9: FONCTIONNALITES PRINCIPALES DU SYTEME

 41

Le diagramme ci-dessous décrits les fonctionnalités secondaires du système.

Figure 10: FONCTIONNALITES SECONDAIRES DU SYSTEME

Ci-dessous, la liste des différentes fonctionnalités.

 Configuration des serveurs

 Configuration des routeurs
 Configuration des switchs de la couche 3
 Configuration des switchs de la couche 2
 Automatisation serveurs
 Automatisation réseaux
 Faire la sauvegarde des configurations
 Restaurer la configuration
 Mettre à jour les iOS (systèmes d’exploitations)
 Vérifier la conformité des équipements réseau
 42

 Générer dynamiquement la documentation d’un équipement réseau

 Préparer une configuration réseau
 Appliquer une configuration réseau
 Installer un serveur Linux
 Installer un serveur Windows
 Faire une mise à jour serveur.

2.2 Conception logique générale

Dans le but d’intégrer toutes les fonctionnalités principales précitées, l’architecture ci-
dessous nous servira de base de conception du système. Nous décrirons ensuite chacune des
fonctions pour en déduire l’architecture physique.
 43

Figure 11:CONCEPTION LOGIQUE GENERALE

 44

1. Inventaire

Le fichier d’Inventaire est un fichier dans lequel on renseigne les serveurs sur lesquels on
effectue nos actions. Le fichier d'inventaire peut être dans l'un des nombreux formats, en
fonction des plugins d'inventaire que vous avez [1].

Cette fonction a pour objectif de :

 Répertorier les hôtes qu’on veut gérer.

 Grouper les hôtes.

2. Fichier de configuration

Le fichier de configuration permet d’exécuter une tâche spécifique, par exemple

« installer une application » sur les différents groupes répertorier dans l’inventaire [2].

3. Modules

Cette fonction permet l’utilisation facile du système par une tierce personne n’ayant pas
une connaissance avancée dans le domaine en incorporant certains scripts de base permettant
de réaliser des tâches très diverses.

4. Template

Les Template permettent de générer le fichier de configuration pour exécuter des tâches
particulières.

5. Hôtes

Il s’agit des machines (serveurs, routeurs, switches, etc.) à orchestrer.

6. Api du système

Il sert d’interfaçage entre les différents hôtes et le système.

7. Operateur

Il s’agit là d’un ingénieur système ou réseau qui aura la tâche de configurer le système.

2.3 Conception logique détaillée

Dans cette partie nous verrons avec plus de détail chaque module précité ci-haut et nous
décortiquerons les différents comportements de ceux-ci.
 45

2.3.1 Description détaillée de l’architecture

Ici, Il est question du fonctionnement intrinsèque de chaque module ainsi que son
fonctionnement par rapport aux autres modules du système.

1. Le fichier d’Inventaire :

Le fichier d’Inventaire est un fichier dans lequel on renseigne les serveurs sur lesquels on
effectue nos actions. Le fichier d'inventaire peut être dans l'un des nombreux formats, en
fonction des plugins d'inventaire que vous avez [3].

Un exemple de fichier d’inventaire est le suivant :

Figure 12:EXEMPLE D'UN FICHIER D'INVENTAIRE

En général, on travaille sur plusieurs serveurs. On définit ces machines dans notre fichier
d’inventaire et en principe, on regroupe ces hôtes par groupe. Par exemple, imaginons le
scénario où l’on veut installer nginx4 sur la moitié de nos serveurs. On créera alors un groupe
appelé nginx et on y rajoutera tous les serveurs où l’on veut l’installer :

Figure 13:EXEMPLE D'UN GROUPE NGINX

4
NGNIX, prononcé comme « engine-ex » est un logiciel libre de serveur Web (ou HTTP) ainsi qu'un proxy
inverse écrit par Igor Sysoev, dont le développement a débuté en 2002 pour les besoins d'un site russe à très fort
trafic.
 46

 Comportement du bloc inventaire

Ci-dessous un diagramme de séquence pour illustrer le comportement du bloc.

Figure 14: DIAGRAMME DE SEQUENCE INVENTAIRE

2. Fichier de configuration :
 Définition :

Les fichiers de configuration définissent des réglages (affichage, langue, vitesse de

transmission, protocoles de communication, prise en compte de certains périphériques, etc.)
dans les applications, les services d'un serveur informatique ou les systèmes d'exploitation.

La prise en compte de modifications de ces réglages peut être (quasi) immédiate, comme
il est généralement nécessaire pour les systèmes et les services rendus par un serveur ou différée
jusqu'à la prochaine exécution, comme il est généralement suffisant pour une application.
 47

 Structure

La structure des fichiers de configuration est variable : elle peut se conformer aux
conventions mises en place par l'éditeur du système d'exploitation, dépendre des outils de
développement utilisés pour programmer une application ou être entièrement propriétaire, ce
qui la rend souvent difficile à interpréter.

Une grande partie des fichiers de configuration est néanmoins écrite au format ASCII
(sous forme textuelle) et formatée en lignes terminées par des caractères « nouvelle ligne » ou
« CR/LF » (carriage return/line feed)5 selon le système d'exploitation. Leur contenu peut alors
être examiné à l'aide d'un éditeur de texte.

Dans d'autres cas, il faut recourir à des applications spéciales pour créer, modifier et tester
la syntaxe des fichiers de configuration. Pour les services et les systèmes d'exploitation, le code
source est parfois la seule documentation disponible. En général, les pages de manuel ou d'aide
rendent partiellement compte de la syntaxe à utiliser dans ces fichiers.

Les formats XML6 et YAML7 tendent à se généraliser dans l'écriture des fichiers de
configuration. Ils ont l'avantage d'avoir une syntaxe déjà bien définie et de disposer d'outils de
vérification et de validation connus.

Une version de YAML ressemblerait à ceci :

5
CRLF (ou CR+LF), est une séquence de deux octets qui indique une fin de ligne (et surtout une nouvelle
ligne) dans un texte. Le sigle CRLF provient de la juxtaposition du sigle de Carriage Return (retour chariot) et de
Line Feed (saut de ligne).
6
Le XML ou eXtensible Markup Language est un langage informatique de balisage générique. Sa syntaxe
est dite « extensible » car elle permet de définir différents langages avec chacun leur vocabulaire et leur grammaire,
comme XHTML, XSLT, RSS, SVG… Elle est reconnaissable par son usage des chevrons (<, >) encadrant les
noms des balises.
7
Le nom YAML veut dire “YAML Ain’t Markup Language”, soit “YAML n’est pas un langage de balises”.
Si cela met d’emblée des distances avec XML, cela ne nous dit pas ce qu’est YAML. YAML est, d’après sa
spécification, un langage de sérialisation de données conçu pour être lisible par des humains et travaillant bien
avec les langage de programmation modernes pour les tâches de tous les jours.
 48

Figure 15: EXEMPLE D'UN FICHIER DE CONFIGURATION YAML

 Syntaxe

Pour plus de clarté, les fichiers de configuration respectent en général une syntaxe qui
associe des directives (ou mots clés) à des valeurs.

Cette syntaxe peut adopter des formes et des niveaux de complexité différents selon
l'ampleur et la précision des fonctionnalités de l'application.

Les paramètres peuvent être organisés linéairement (par ex. rs_vitesse=9400), en tableau
(comme fstab8) ou encore en « objets », ce qui est le cas avec le XML, délimités par un début
et une fin, et caractérisés par des propriétés et des options propres à chaque type d'objet.

À la manière des langages de programmation, les fichiers de configuration peuvent être

accompagnés de commentaires qui seront ignorés par le programme, mais qui permettront aux
créateurs du logiciel d'insérer des indications, et aux utilisateurs de mieux comprendre le
comportement du programme et de neutraliser momentanément certaines lignes.

 Comportement du fichier de configuration

Ci-dessous un diagramme de séquence pour illustrer le comportement du bloc.

8
Le fichier fstab (file systems table) est la table des différents systèmes de fichiers sur un ordinateur sous
Unix/Linux : il contient une liste des disques utilisés au démarrage et des partitions de ces disques. Pour chaque
partition, il indique comment elle sera utilisée et intégrée à l’arborescence du système de fichiers global (c'est-à-
dire le point de montage). Il se trouve généralement à /etc/fstab.
 49

Figure 16: DIAGRAMME DE SEQUENCE FICHIER DE CONFIGURATION

3. Les modules

Les modules sont généralement autonomes et peuvent être écrits dans un langage de script
standard (tel que Python, Perl, Ruby, Bash, etc.). L'une des propriétés directrices des modules
est l'idempotency, ce qui signifie que même si une opération est répétée plusieurs fois (par
exemple, après une panne), le système sera toujours placé dans le même état.

Les modules sont mis en correspondance avec les ressources et leurs états respectifs,
représentés dans des fichiers. Ils permettent de gérer pratiquement tout ce qui contient une API,
une interface de ligne de commande ou un fichier de configuration avec lequel vous pouvez
interagir, y compris les périphériques réseau tels que les équilibreurs de charge, les
commutateurs, les pare-feu, les orchestrateurs de conteneurs, les conteneurs eux-mêmes et
même les instances de machine virtuelle dans un hyperviseur ou une machine virtuelle. Cloud
public (AWS, GCE, Azure) et / ou privé (OpenStack, CloudStack, par exemple), ainsi que
dispositifs de stockage et de sécurité, et configuration système.

 Les modules peuvent être écrits dans n'importe quel langage

 Les configurations déclarées dans les fichiers sont distribuées sur le réseau.
 Les modules sont un moyen d'accroître les capacités des outils Devops.
 50

4. Api système

L'API est une interface de programmation d'application par laquelle un utilitaire ou un

programme utilisateur demande les services d'un système de fichiers. Un système d'exploitation
peut fournir des abstractions permettant d'accéder à différents systèmes de fichiers de manière
transparente.

Certaines API de système de fichiers peuvent également inclure des interfaces pour des
opérations de maintenance, telles que la création ou l'initialisation d'un système de fichiers, la
vérification de l'intégrité du système de fichiers et la défragmentation.

Figure 17: API SYSTEME

Après ce tour d’horizon qui nous a permis d’avoir un aperçu détaillé sur les modules du
système. Un diagramme qui résume de manière succincte et plus ou moins précise toutes les
parties du système s’avère être nécessaire pour sa bonne compréhension en somme.
 51

Figure 18:ARCHITECTURE LOGIQUE DETAILLEE

 52

2.4 Conclusion partielle

Ce chapitre, a traité la question de décrire chaque module de manière générale, nous avons eu
à modéliser notre travail afin qu’il s’adapte à toute sorte de système.
 53

Chapitre 3. Conception physique

3.1 Introduction

Dans ce chapitre, il sera question de faire le choix du matériel et logiciel implémentant

les différentes fonctions logiques écrites ci-haut. La solution ainsi conçue (globalement et
détaillée) peut être alors réalisée dans les technologies disponibles.

3.2 Niveau d’abstraction

A ce niveau du travail, La conception générale et la conception détaillée logique ont déjà

été franchises, arrivés au plus bas niveau d’abstraction de notre conception. Il s’avère important
de faire un choix technologique concernant notre solution [4].

3.2.1 Choix des technologies

3.2.1.1 Critères de choix

Les choix des différentes solutions technologiques ne seront pas faits de façon
arbitraire, nous allons recourir au premier chapitre de notre travail et plus précisément au niveau
des exigences non fonctionnels, ces dernières constitueront nos critères de choix pour
différentes solutions technologiques, chaque critère vaut 5 points, étant donné le nombre
d’exigences non fonctionnelles du système (7), nos critères vaudront au total 35 points. Les
solutions qui seront retenues seront celles qui auront les plus grandes cotes sur 35.

Voici donc nos critères de choix :

Critère 1 (C1) : Disponibilité, Elle représente la capacité du système à être en état de

fonctionner dans des conditions données et à tourner avec un temps d’arrêt très réduit ;

Critère 2 (C2) : Facilité d'installation, Elle représente la qualité du système à être facile à
implémenter ;

Critère 3 (C3) : Gestion aisée, représente la capacité pour un utilisateur d’exécuter une
tâche dans un temps donné après une formation d’une durée déterminée ;

Critère 4 (C4) : Evolutivité, désigne la capacité d'un produit à s'adapter à un changement

d'ordre de grandeur de la demande (montée en charge), en particulier sa capacité à maintenir
ses fonctionnalités et ses performances en cas de forte demande ;
 54

Critère 5 (C5) : Langage de configuration compréhensible, Ce dernier doit être facilement

configurable ;

Critère 6 (C6) : L’interopérabilité est la capacité que possède un produit ou un système,

dont les interfaces sont intégralement connues, à fonctionner avec d'autres produits ou systèmes
existants ou futurs et ce sans restriction d'accès ou de mise en œuvre ;

Critère 7 (C7) : Coût réduit, Solution efficace pouvant être implémentée avec un budget
minimum ;

Chef vs Puppet vs Ansible vs Saltstack [5]

Métriques Chef Puppet Ansible Saltstack

Disponibilité ✔ ✔ ✔ ✔

Facilité Pas Pas vraiment Pas vraiment

Facile
d'installation vraiment facile facile facile

Pas Pas vraiment

Gestion aisée Facile Facile
vraiment facile facile

hautement hautement hautement hautement

Evolutivité
évolutif évolutif évolutif évolutif

Langage de DSL(PuppetD YAML(Py YAML(Pytho

DSL(Ruby)
configuration SL) thon) n)

Interopérabilit
Haute Haute Haute Haute
é

Prix (jusqu'à $11200- $15,000(appro

$13700 $10,000
100 nœuds) $19900 x.)

Tableau 5: COMPARAISON DES TECHNOLOGIES

 55

 Disponibilité

Il est question de comparer Chef, Puppet, Ansible et Saltstack sur la base des
disponibilités. Tous ces outils sont hautement disponibles, ce qui signifie qu'il existe plusieurs
serveurs ou plusieurs instances. Disons que si votre maître principal ou votre serveur tombe en
panne, il y a toujours un serveur de sauvegarde ou un autre maître pour le remplacer.

Parcourons chacun des outils individuellement :

Chef - En cas de défaillance du serveur principal, c’est-à-dire du serveur Chef, un serveur

de sauvegarde remplace le serveur principal.

Puppet - Il a une architecture multi-maîtres, si le maître actif tombe en panne, l’autre maître
prend la place du maître actif.

Ansible - Il s'exécute avec un seul nœud actif, appelé instance principale. Si primaire tombe
en panne, une instance secondaire doit prendre sa place.

Saltstack - Plusieurs maîtres peuvent être configurés. Si un maître est en panne, les agents se
connectent à l'autre maître de la liste. Par conséquent, il a plusieurs maîtres pour configurer les
serviteurs [6].
 Facilité d'installation

Par facilité d’installation, concentrons-nous sur chaque outil un par un :

Chef - Chef a une architecture d'agent maître. Le serveur Chef s'exécute sur l'ordinateur
maître et le client Chef s'exécute en tant qu'agent sur chaque ordinateur client. En outre, il existe
un composant supplémentaire appelé poste de travail, qui contient toutes les configurations qui
sont testées puis transférées vers le serveur chef central. Par conséquent, ce n'est pas si facile.

Puppet - Puppet a également une architecture d’agent principal. Le serveur Puppet

s'exécute sur l'ordinateur maître et les clients Puppet s'exécutent en tant qu'agent sur chaque
ordinateur client. Après cela, il y a également une signature de certificat entre l'agent et le
maître. Par conséquent, ce n’est pas aussi facile.

Ansible - Seul le maître s'exécute sur la machine serveur, mais aucun agent ne s'exécute
sur la machine cliente. Il utilise la connexion ssh pour se connecter aux systèmes clients ou aux
nœuds que vous souhaitez configurer. La machine virtuelle cliente ne nécessite aucune
configuration particulière, elle est donc plus rapide à configurer !
 56

Saltstack - Ici, le serveur est appelé maître du sel et les clients sont appelés minions du
sel, lesquels s'exécutent en tant qu'agents sur la machine cliente.
 La gestion aisée

Pour entamer cette partie, il sied important de dire que Puppet et Chefs suivent les
configurations par tirage & Ansible et Saltstack suivent les réglages push.

Dans la configuration push, toutes les configurations présentes dans le serveur central
seront poussées vers les nœuds, tandis que dans la configuration par extraction, les nœuds
esclaves extrairont automatiquement toutes les configurations du serveur central sans aucune
commande.

Chef - Vous devez être un programmeur pour gérer les configurations car il offre des
configurations dans Ruby DSL. Le client extrait les configurations du serveur.

Puppet - Il est difficile de gérer les configurations car il utilise son propre langage appelé
Puppet DSL (Domain Specific Language). Le client extrait les configurations du serveur. Il est
plutôt orienté administrateur système et l'exécution à distance n'est pas immédiate.

Ansible - Facile à apprendre à gérer les configurations car il utilise YAML, c’est-à-dire
un autre langage de balisage qui ressemble beaucoup à l’anglais. Le serveur envoie les
configurations à tous les nœuds. Bon pour les applications en temps réel et il y a une exécution
à distance immédiate.

Saltstack - Facile à apprendre à gérer les configurations car il utilise également YAML.
Le serveur envoie les configurations à tous les clients. Exécution à distance immédiate.

 L'évolutivité

Les quatre outils sont hautement évolutifs. Supposons que si vous avez besoin de
configurer environ 70 nœuds aujourd'hui et demain 500, cela ne pose aucun problème. Ce n'est
pas un problème avec ces outils. Ils peuvent gérer une infrastructure importante, il vous suffit
de spécifier l'adresse IP et le nom d'hôte des nœuds que vous souhaitez configurer. Le reste de
la tâche sera géré par ces outils. Par conséquent, tous ces outils sont hautement évolutifs.

 Langue de configuration

Chef - Chef utilise le langage Ruby Domain Specific Language (Ruby DSL). Il a une
courbe d'apprentissage abrupte et orientée développeur.
 57

Puppet - Puppet utilise son propre langage spécifique au domaine de la marionnette

(Puppet DSL). Ce n'est pas très facile à apprendre et son administrateur système orienté.

Ansible - Ansible utilise YAML, c’est-à-dire un autre langage de balisage (Python). Il est
assez facile à apprendre et orienté administrateur. De nos jours, Python est intégré à la plupart
des déploiements Unix et Linux. Par conséquent, la configuration et l’utilisation de l’outil sont
plus rapides.

Saltstack - Saltstack utilise également YAML (Python). Il est encore facile à apprendre
et orienté administrateur.

 L'interopérabilité

Dans ces outils, maître ou serveur principal ou vous pouvez aussi dire machine de
contrôle, doit être sous Linux / Unix mais leurs esclaves ou les nœuds qu’ils doivent configurer
peuvent être sous Windows. Décortiquons chaque outil un à un :

Chef - Chef Server ne fonctionne que sous Linux / Unix, mais Chef Client et Workstation
peuvent également fonctionner sous Windows.

Puppet - Puppet Master ne fonctionne que sous Linux / Unix, mais Puppet Agent
fonctionne également sous Windows.

Ansible - Ansible prend également en charge les machines Windows, mais le serveur
Ansible doit être installé sur une machine Linux / Unix.

Saltstack - Salt Master ne fonctionne que sous Linux / Unix, mais les sbires de sel peuvent
aussi fonctionner sous Windows.

 Coût réduit

Les coûts d’entreprise pour les outils de configuration sont les suivants :

Chef - Chef Automate vous donne tout ce dont vous avez besoin pour construire, déployer
en 137$ par nœud / annuel.

Puppet - Les prix de Puppet vont de 112 USD par nœud / an avec un plan de support
standard à 199 USD par nœud / an avec le plan premium.

Ansible - Le prix pour Ansible Tower pour les opérations informatiques standard jusqu'à
100 nœuds est de 10 000 USD / an. Cela inclut une assistance 8 * 5, tandis que premium offre
une assistance 24 * 7 pour 14 000 USD / an.
 58

Saltstack - Le coût pour Saltstack Enterprise par nœuds est de 150 $ / an (environ). Vous
pouvez contacter le support pour le prix actuel de l'abonnement annuel.

Voici un tableau qui illustre les critères remplis de chaque technologie.

Critères C1 C2 C3 C4 C5 C6 C7 Total
Chef 4 1.5 1 3.5 2 4 2.5 18.5/35
Puppet 4 1.5 1 4 1.5 4 1 17/35
Ansible 4 4 4 4 4 4 3 27/35
Saltstack 4 2 4 4 4 4 2 24/35
Tableau 6: CRITERES TECHNOLOGIQUE

Figure 19 DOMINATION DE ANSIBLE SUR UNE REPRESENTATION RADAR

La figure ci-dessus montre la domination de Ansible (au vu de sa surface qui est la plus
grande) sur une représentation radar.
 59

L’image donnée ci-dessous, montre comment ces outils ont dominé le secteur
informatique au cours des 5 dernières années.

Figure 20:EVOLUTION AU COURS DE 5 ANS DES TECHNOLOGIES

Comme vous pouvez le voir ci-dessus, Puppet et Chefs sont les anciens dans ce domaine,
tandis qu'Ansible et le Saltstack en sont de nouveaux. Et Ansible semble très prometteur avec
la tendance croissante.

Partant de cette étude et vu le total des critères rempli, Il serait judicieux d’opté pour la
solution Ansible.

3.3 Présentation de Ansible.

Une ansible est un dispositif théorique permettant de réaliser des communications à une
vitesse supraluminique. Elle peut envoyer et recevoir des messages en provenance et en
direction du périphérique correspondant sur n’importe quelle distance sans aucun délai. Les
ansibles sont une composante emblématique de la littérature de science-fiction [7].

Ansible se démarque de la plupart des outils de ce type, car il ne fonctionne pas en mode
client-serveur ou maître-esclave. Il utilise les technologies SSH (Secure Socket sHell) et JSON
(JavaScript Object Notation) pour distribuer les modules sur les nœuds distants, et utilise donc
les ressources uniquement pour des tâches utiles. Tant que le nœud n’est pas modifié, aucun
agent ni daemon ne fonctionne en arrière-plan. Cette configuration tient compte des contextes
des différents systèmes d’un environnement IT multiniveau [8].

Ansible est :

Simple :

 Automatisation facile
 Pas besoin d’être programmeur
 Les tâches sont exécutées en ordre
 60

 Utilisable par tous

 Devenez productif rapidement

Puissant :

Déploiement d’application

Gestion de configuration
Orchestration de workflow
Automatisation des réseaux
Orchestrer le cycle de vie complet

Sans agents :

Sans agent
Utilise OpenSSH & WinRM
Pas d’agent à exploiter ou
maintenir
Démarrer immédiatement
Plus efficace, plus sécure

Dans les prochains paragraphes, nous allons découvrir l’architecture d’Ansible et son
fonctionnement. Puis nous montrons la gestion de configuration des environnements et le
déploiement des hôtes.

3.4 ARCHITECTURE PHYSIQUE GENERALE

Ansible est un moteur d’automatisation simple qui automatise le Cloud, le

provisionnement, la gestion de la configuration, le déploiement d’applications, l’orchestration
de services ainsi que beaucoup d’autres fonctionnalités.
Dans cette section, nous allons vous donner un aperçu de la façon dont Ansible fonctionne.
 61

[9]

Figure 21: ARCHITECTURE PHYSIQUE GENERALE

1. Host Inventory

Ansible permet à l’heure actuelle de manipuler des inventaires statiques et des inventaires
dynamiques. Le modèle statique fonctionne bien avec des environnements figés, n’évoluant pas
souvent. Par contre il devient vite limitant dans le cadre d’environnements en cours de
développement sujets à des reconstructions ou en évolutions permanentes.

Au travers des inventaires dynamiques, Ansible est capable de générer automatiquement

son inventaire à partir des APIs d’un cloud provider ou de services tiers, pour pouvoir ensuite
l’utiliser.

Les inventaires Ansible peuvent contenir des variables relatives aux instances mais pour
gagner en clarté, les variables sont placées dans des group_vars et des host_vars

L’inventaire fournit la liste des hôtes (routeurs managés, switchs managés serveurs
managés) sur lesquels Ansible exécutera les tâches. Il peut également être utilisé pour regrouper
les hôtes et configurer les variables pour les hôtes et les groupes.
 62

Figure 22: ILLUSTRATION DE HOST INVENTORY DE ANSIBLE

2.Playbooks

Les Playbooks sont une manière complètement différente d’utiliser Ansible que dans le
mode d’exécution de tâches ad hoc, et sont particulièrement puissants.

En un mot, les playbooks sont la base d’un système de gestion de configuration et de

déploiement multi-machines très simple, unique en son genre et parfaitement adapté au
déploiement d’applications complexes.

Les Playbooks peuvent déclarer des configurations, mais ils peuvent également orchestrer les
étapes de tout processus de commande manuelle, même si différentes étapes doivent rebondir
entre des ensembles de machines dans des ordres particuliers. Ils peuvent lancer des tâches de
manière synchrone ou asynchrone.

Le Playbook est le langage de configuration d’Ansible utilisé pour effectuer l’ensemble des
tâches et d’étapes de configuration ou pour faire appliquer une politique sur les nœuds distants.
Les modules Ansible sont utilisés dans le Playbook pour exécuter une opération.

Le Playbook est écrit en YAML qui est un langage simple, lisible par l’homme et
développé dans un anglais de base comme la langue du texte. Les Playbooks sont plus
susceptibles d’être conservés dans le système de contrôle de version et utilisés pour assurer les
configurations des systèmes distants.
 63

Figure 23: PLAYBOOKS ANSIBLE

3. Ssh trust

Par défaut, Ansible essaiera d'utiliser OpenSSH en natif pour les communications à
distance lorsque cela est possible. Cela active ControlPersist (une fonctionnalité performante),
Kerberos et des options dans ~ / .ssh / config, telles que la configuration de l'hôte sauté.

Quand nous parlons avec des machines distantes, Ansible suppose par défaut que nous
utilisons des clés SSH.

Figure 24: SSH TRUST

 64

3.5 ARCHITECTURE PHYSIQUE DETAILLEE

Après cette description qui nous a permis de voir chaque bloc du système en détail,
un diagramme qui résume de manière succincte toutes les parties du système s’avère être
nécessaire pour sa bonne compréhension en globalité.

Figure 25: ARCHITECTURE PHYSIQUE DETAILLEE

1.Modules

Ansible fonctionne en se connectant aux nœuds et en poussant de petits programmes,

appelés « Ansible Modules ». Ces programmes sont écrits pour être des modèles de ressources
de l’état souhaité du système. Ansible exécute ensuite ces modules (sur SSH par défaut) et les
supprime une fois terminé. La bibliothèque de modules peut résider sur n’importe quel
ordinateur et aucun serveur, démon ou base de données n’est requis.

Ansible est livré avec un certain nombre de modules (appelés "bibliothèque de modules")
qui peuvent être exécutés directement sur des hôtes distants ou via Playbooks.

Les utilisateurs peuvent également écrire leurs propres modules. Ces modules peuvent
contrôler des ressources système, telles que des services, des packages ou des fichiers (quelque
chose de vraiment), ou gérer l'exécution de commandes système.

Les modules Ansible sont tous écrit en Python et PowerShell, mais les modules
peuvent être écrits en n’importe quel langage.

Parmi les modules Ansible nous citerons les principaux :

 Inventory Modules

Comme son nom l’indique, le module « Inventory Modules » s’occupe de

l’inventaire. Il regorge en lui plusieurs modules qu’on peut se permettre d’appeler sous-
modules [10] :
 65

add_host - Ajoute un hôte (et un groupe) à l'inventaire en mémoire de ansible-

playbook.

Paramètre Choix / Défauts Commentaires

groups Les groupes auxquels ajouter le nom d'hôte.

list

aliases: group, groupname

name Le nom d’hôte / ip de l’hôte à ajouter à

l’inventaire peut inclure un signe deux-points et un
string / required
numéro de port.

aliases: host, hostname

Tableau 7: PARAMETRE MODULE add_host

group_by - Crée des groupes Ansible basés sur des faits.

Paramètre Choix / Défauts Commentaires

key Les variables dont les valeurs seront utilisées en

tant que groupes.
string / required

parents La liste des groupes de parents.

list

added in 2.4

Default:

"all"

Tableau 8: PARAMETRE MODULE group_by

 Network Modules :

Les modules Ansible Network étendent les avantages d'une automatisation simple,
puissante et sans agent aux administrateurs et aux équipes réseau. Les modules réseau
Ansible peuvent configurer votre pile réseau, tester et valider l'état du réseau existant, et
détecter et corriger la dérive de la configuration réseau [11].

Parmi les modules réseau Ansible, nous citerons :

 66

ACI :

L'infrastructure ACI (Cisco Application Centric Infrastructure) permet aux applications

de définir le réseau. Cette architecture simplifie, optimise et accélère l'ensemble du cycle de vie
du déploiement de l'application.

Les modules Ansible ACI fournissent une interface conviviale pour la gestion d’un
environnement ACI à l'aide de playbooks Ansible.

Par exemple, s’assurer qu’une instance spécifique existe, à l’aide de la tâche Ansible suivante
utilisant le module aci_tenant.

CHEKPOINT :

Gère les objets hôtes sur les périphériques Checkpoint, notamment la création, la mise à
jour et la suppression des objets de règles d'accès. Toutes les opérations sont effectuées sur
l'API de services Web.

Paramètre Choix / Défauts Commentaires

auto_install_policy Choices: Installez la stratégie de package si des

modifications ont été apportées une fois la
boolean
 no tâche terminée.
 yes ←

auto_publish_session Choices: Publiez la session en cours si des

modifications ont été apportées une fois la
boolean
 no tâche terminée.
 yes ←

ip_address Adresse IP de l'objet hôte.

string

name Nom de la règle d'accès.

string / required
 67

policy_package Default: Nom de la politique de package à

installer.
string "standard"

state Default: Etat de la règle d'accès (présent ou

absent). Défauts à présenter.
string "standard"

targets Cibles sur lesquelles installer la

politique de package.
list

Tableau 9: PARAMETRE MODULE chekpoint

 Database Modules :

Ce module gère et déploie les bases des données, sans trop tarder là-dessus, passons à
quelques exemples :

mysql_db - Ajoute ou supprime des bases de données MySQL d'un hôte distant.

Exigences

Les exigences ci-dessous sont nécessaires sur l'hôte qui exécute ce module.

python> = 2,7

pymssql

Paramètre Choix / Défauts Commentaires

autocommit Choices: Validez automatiquement la

modification uniquement si l'importation
boolean
 no ←
réussit. Parfois, il est nécessaire d'utiliser
 yes
autocommit = true, car certains contenus ne
peuvent pas être modifiés dans une
transaction.

login_host Hôte exécutant la base de données

-
 68

login_password Le mot de passe utilisé pour

s'authentifier avec
-

login_port Default: Port du serveur MSSQL. Requiert

que login_host soit défini comme autre que
- 1433
localhost si login_port est utilisé

login_user Le nom d'utilisateur utilisé pour

s'authentifier avec
-

name nom de la base de données à ajouter

ou à supprimer
- / required

alias: dbauthenticate with

state Choices: L'état de la base de données

-
 present ←
 absent
 import

target

- Emplacement, sur l'hôte distant, du

fichier de vidage à lire ou à écrire. Les
fichiers SQL non compressés (.sql) sont
pris en charge.

Tableau 10: PARAMETRE DU MODULE pymssql

MISC :

Gère les plugins de recherche Elastic.

Paramètre Choix / Défauts Commentaires

 69

force Choices: Forcer le mode batch lors de l'installation

de plugins. Cela n'est nécessaire que si un plug-in
boolean
 no ← nécessite des autorisations supplémentaires et que
added in 2.7  yes la détection de la console échoue.

name Forcer le mode batch lors de l'installation

de plugins. Cela n'est pas nécessaire si un plug-in
- / required
est nécessaire.

plugin_bin Emplacement du binaire du plugin. Si ce

fichier n'est pas trouvé, les fichiers binaires du
-
plugin par défaut seront utilisés.

La valeur par défaut modifiée dans Ansible

2.4 a été définie sur Aucune.

plugin_dir Default: Votre répertoire de plugins configuré

spécifié dans Elasticsearch
"/usr/share/elasticse
arch/plugins/"

proxy_host Hôte proxy à utiliser lors de l'installation du

plug-in
-added in 2.1

proxy_port Port proxy à utiliser lors de l'installation du

plugin
added in 2.1

src Définissez éventuellement l'emplacement

source à partir duquel vous souhaitez extraire le
- added in 2.7
plug-in. Cela peut être un fichier : // URL à
installer à partir d'un fichier local ou une URL
distante. Si ce n'est pas défini, l'emplacement du
plugin est juste basé sur le nom.

state Choices: Etat souhaité d'un plugin.

-
 present
 absent

timeout Default: Réglage du délai d'attente: 30s, 1m, 1h ...

 70

- "1m"
Valable uniquement pour Elasticsearch
<5.0. Cette option est ignorée pour Elasticsearch>
5.0.

url Définir l'URL exacte à partir de laquelle

télécharger le plug-in (Fonctionne uniquement
-
pour ES 1.x).

Pour ES 2.x et versions ultérieures, utilisez

src.

version Version du plugin à installer. Si le plugin

existe avec la version précédente, il ne sera PAS
-
mis à jour

Tableau 11: PARAMETRE DU MODULE MISC

Exemple :

Figure 26: EXEMPLE MODULE DE BASE DES DONNEES.

 71

Comportement dynamique d’un système d’automatisation avec Ansible

Implémenter une solution complète basée sur Ansible est un travail de grande envergure
qui ne saurait être contenu dans le cadre limite du présent travail. C’est pourquoi il sera ici
question de vérifier seulement quelques scenarios afin de vérifier l’hypothèse qui peut être
confirmé par extension a un plus grand projet relatif a tout un datacenter et a un réseau
d’entreprise a grande échelle.

La « programmabilité » réseau et la gestion automatique et la définition logicielle des

infrastructures IT forment aujourd’hui un grand domaine de spécialité qui nécessite plusieurs
années d’apprentissage et d’expérience.

Ci-dessous retrouvez quelques diagrammes des séquences illustrant le comportement des

certains modules Ansible pour un nombre très limite de scenario.

Sauvegarde de la configuration du core switch

Le paramètre backup du module ios_config déclenche la sauvegarde et stocke

automatiquement les sauvegardes de configuration de périphérique dans un répertoire de
sauvegarde.

Dans ce scénario réaliste, vous allez créer un livre de lecture pour sauvegarder les
configurations de routeur Cisco. Dans les laboratoires suivants, nous utiliserons cette
configuration sauvegardée pour restaurer les périphériques dans leur état correct connu.
 72

Figure 27: DIAGRAMME DE SEQUENCE SAUVEGARDE DES CONFIGURATIONS

 73

Restaurer la configuration avec Ansible.

Si des modifications hors bande ont été apportées à l'appareil et qu'il doit être restauré à
la dernière configuration correcte connue, nous pourrions adopter l'approche suivante :

Copier la configuration nettoyée sur les périphériques

Utiliser les commandes fournies par le fournisseur pour restaurer la configuration du

périphérique

Voici ci-dessous un diagramme de séquence illustrant le comportement de la

fonctionnalité.
 74

Figure 28: DIAGRAMME DE SEQUENCE RESTAURER UNE SAUVEGARDE SUR UN PERIPHERIQUE RESEAU
 75

Le module Ansible ios_vlan.

L'objectif est de fournir un module déclaratif pour la gestion des VLAN sur les
périphériques IOS. En cela, il serait judicieux d’utiliser des images IOSv-L2 [12].

Le module a plusieurs paramètres mais les plus importants sont les suivants :

 agrégat : liste des définitions de VLAN

 related_interfaces : Vérifie l'état de fonctionnement de l'interface

 delay: 10 secondes par défaut, combien de temps attendre pour voir l'état
déclaratif.

 interfaces: liste d'interfaces auxquelles le VLAN doit être affecté

 name: nom du VLAN

 purge: purger les VLAN non définis dans le paramètre d'agrégat

 état: présent / absent / actif / suspendre - l'état dans lequel il devrait être

 vlan_id: ID du VLAN
 76

Figure 29: DIAGRAMME DE SEQUENCE MODULE ios_vlan

 77

Installation d’apache sur des serveurs linux.

Le diagramme ci-après illustre les séquences des configurations des serveurs linux en
serveurs web.
 78

Figure 30: DIAGRAMME DE SEQUENCE INSTALLATION D'APACHE SUR UN SERVEUR LINUX

 79

Installation des mises a jours sur des serveurs Windows.

Le diagramme ci-après illustre les séquences des mises à jours automatiques sur des
serveurs Windows.
 80

Figure 31: DIAGRAMME DE SEQUENCE DE MISE A JOUR AUTOMATIQUE SUR WINDOWS

 81

1.6 Plan d’installation

3.6.1 DIAGRAMME PHYSIQUE

Figure 32: DIAGRAMME PHYSIQUE

Ce diagramme physique est une capture du système implémenté dans EVE pour une émulation de la solution Ansible
 82

3.6.2 Blocs ou Modules à Installer.

Dans notre travail nous installerons les modules suivant :

 Le réseau WAN Mpls

 La couche cœur
 La couche distribution
 La couche accès
 La couche Datacenter
 Ansible Tower

a. Installation du réseau WAN MPLS.

Nous avons relié nos différents LAN par une liaison WAN Mpls VPN, nous nous sommes
basés sur les trois principales villes de la société.

Voici les exigences requises pour notre réseau WAN :

 4 routeurs du côté fournisseur dont 2 se trouvant dans le backbone Mpls et 2 autres pour
se connecter à nos LAN.
 Câbles Ethernet.

Procédure d’installation du WAN :

 PE_1 (Provider Edge 1) :

 Relié au Provider (P_1) par son interface Ethernet0/0.
 Relié au LAN Kolwezi par son interface Ethernet0/1.
 Relié au LAN Kambove par son interface Ethernet0/2.
 P_1 (Provider 1) :
 Relié au Provider (P_2) par son interface Ethernet0/0.
 Relié au Provider Edge 1 (PE_1) par son interface Ethernet0/1.
 P_2 (Provider 2) :
 Relié au Provider (P_1) par son interface Ethernet0/1.
 Relié au Provider Edge 1 (PE_3) par son interface Ethernet0/0.
 PE_3 (Provider Edge 3) :
 Relié au Provider (P_2) par son interface Ethernet0/0.
 Relié au LAN Johannesburg par son interface Ethernet0/1.
 83

b. Installation de La couche cœur.

Voici les exigences requises pour la couche cœur :

 4 switchs de couche 3, dont 2 à Kolwezi, 1 à Kambove et 1 à Johannesburg.

 4 switchs de couche 3 pour la liaison vers les routeurs.
 Câbles Ethernet.

Procédure d’installation : Se référé au diagramme physique.

c. La couche distribution.

En fonction de notre topologie ; Voici les exigences requises pour la couche distribution :

 8 switchs de couche 3, dont 4 à Kolwezi, 2 à Kambove et 2 à Johannesburg.

 Câbles Ethernet.

Procédure d’installation : Se référé au Diagramme Physique

d. Installation de La couche Datacenter

Le composant Datacenter est ici représenté par deux switches Nexus 9000. Le choix de la
technologie Cisco Nexus n’a pas été fait parce que ces switches sont déjà sur la liste des
équipements standards de la société (Contrainte politique).

Cisco NX-OS est le système d'exploitation réseau (OS) qui alimente les commutateurs Cisco
Nexus dans des milliers d'environnements clients. Il s'agit du premier système d'exploitation de
réseau de centre de données à être construit avec Linux. Le logiciel Cisco NX-OS est le système
d’exploitation réseau le plus extensible, ouvert et programmable, appelé Open NX-OS. La suite
logicielle riche Open NX-OS construite sur une fondation Linux expose les API, les modèles
de données et les constructions programmatiques

Grâce aux interfaces de programmation d'application (API) et aux agents de

configuration, les opérateurs peuvent modifier les modifications de configuration de manière
plus programmatique et adopter la culture de changement NetDevOps. Cisco fournit divers
outils et infrastructures pour permettre aux ingénieurs / développeurs de réseau d'automatiser
et de programmer les périphériques Nexus. NX-API REST amène la programmation par modèle
(MDP) aux commutateurs Nexus autonomes (N3k / N9k) héritant de la puissance des modèles,
facilitant ainsi la configuration des périphériques réseau. Les clients peuvent approvisionner et
gérer leurs commutateurs à l'aide d'outils d'intégration habituels (dans ce laboratoire, nous
utilisons Ansible) et avoir accès à une API robuste et à un support communautaire.
 84

Pour réduire les coûts associés à l'infrastructure informatique, de nombreuses entreprises

ont hérité d'un modèle à la demande utilisant l'automatisation et la virtualisation. Tout
périphérique offrant des fonctionnalités de programmabilité et d'automatisation permet aux
services informatiques de créer des applications pour déployer et configurer les environnements
souhaités pour les besoins de l'entreprise. Dans les centres de données, les serveurs et les
applications ont été virtualisés et automatisés pendant près de deux décennies, mais l'élément
le plus important, le réseau physique, a été laissé pour une configuration manuelle. Il y a environ
une décennie, le concept de réseau défini par logiciel (SDN) a gagné du terrain parmi les
principaux fournisseurs d'équipements de réseau. Les entreprises ont commencé à créer ou à
intégrer des fonctionnalités dans leurs périphériques réseau pour une configuration facile et un
fonctionnement programmable. Les commutateurs de centre de données de la série Nexus de
Cisco sont un de ces dispositifs. Les ingénieurs et les administrateurs réseau peuvent créer des
réseaux de centres de données en quelques heures.
Le tableau suivant récapitule les domaines les plus importants et les technologies respectives
disponibles sur les commutateurs Cisco Nexus.

Concepts du « Boot and Provisioning with POAP and PXE »

Avant l’automatisation :

Supposons qu'une équipe d'ingénieurs ait besoin de construire un nouveau centre de

données à partir de zéro. Auparavant, pour permettre la gestion à distance, les ingénieurs réseau
devaient se connecter à chaque périphérique via un câble de console et télécharger un fichier
de configuration ou entrer des commandes manuellement.

Pour déployer plusieurs équipements, cette approche était réalisable. Toutefois, pour un
centre de données avec des centaines de périphériques, cette approche n’aurait pas bien évolué.

Automatisation avec POAP et PXE

Lors de leur démarrage initial, ces périphériques téléchargent leurs images de disque et
leurs fichiers de configuration à partir d’un serveur préconfiguré.

Les commutateurs Cisco Nexus disposent de deux technologies pour ce faire : le POAP
(Power-On Auto Provisioning) et l'environnement PXE (Preboot Execution Environment).

Power-On Auto Provisioning (POAP)

POAP permet à un commutateur de mettre à niveau son image au démarrage sans

intervention d'un administrateur. Cela aide à éliminer les erreurs pouvant survenir lors d'un
processus de configuration manuelle.
 85

Le POAP se produit lorsque, lors du démarrage, le commutateur ne trouve pas son fichier
de configuration de démarrage. À ce stade, le périphérique recherche un service DHCP
(Domain Host Configuration Protocol) sur le réseau. DHCP attribue au périphérique l'adresse
IP, la passerelle par défaut et l'adresse IP suivies par le serveur DNS (Domain Name System).

Ensuite, POAP obtient l'adresse IP d'un serveur de script, télécharge le script approprié
pour le commutateur et l'exécute sur le périphérique.

Le script indique généralement au système de télécharger et d'installer la bonne image et

le fichier running-config.
Vous pouvez également déployer des agents Puppet ou Chef avec POAP. Pendant que le
routeur télécharge les images et le fichier running-config, il exécute également le fichier
exécutable de l'agent Puppet ou de l'agent Chef.

Lorsque le commutateur apparaît, l'agent approprié s'exécutera dans un conteneur Linux.

Ensuite, l'agent établit une connexion avec le serveur Puppet Master ou Chef.

Figure 33:Nexus

Preboot Execution Environment (PXE)

Un autre chargeur d'amorçage avancé disponible sur les commutateurs de la gamme Cisco
Nexus est l'outil de démarrage PXE (Preboot Execution Environment). PXE est un framework
commun bien compris par les administrateurs systèmes. Il récupère également une image du
réseau et permet une installation et un démarrage automatisés.

Architecture d’un switch Nexus

 86

Figure 34: ARCHITECTURE D'UN SWITCH NEXUS

Gestion des packages et des applications

Les commutateurs Cisco Nexus n'exécutent plus de système d'exploitation propriétaire.
Ils utilisent un noyau Linux Wind River 64 bits basé sur Yocto. Cela permet à toute
équipe ayant des compétences Linux d'accéder à l'environnement bash d'un périphérique
et de gérer un commutateur de la même manière que ses serveurs Linux.
Le Cisco NX-OS, plus récent et plus ouvert, permet le chargement d'autres packages
logiciels à l'aide de RPM (Red-Hat Package Managers). À l'aide de Yellowdog Updater,
Modifier (YUM), un administrateur peut mettre à jour ou mettre à niveau le logiciel du
commutateur de la série Nexus comme il le ferait avec un serveur Linux. Par exemple,
pour mettre à jour le protocole BGP sur le commutateur, l'administrateur utilise la
commande yum update bgp.

Outils de gestion de la configuration

Puppet, Chef et Ansible, les outils d’orchestration tiers les plus populaires
d’aujourd’hui, peuvent être utilisés pour interagir avec les commutteurs de la gamme
Cisco Nexus. Sur les anciennes versions du commutateur Nexus, Puppet n'était
disponible que dans un conteneur et ses capacités étaient limitées. Dans les versions
plus récentes, Puppet et Chef ont davantage de fonctionnalités. Ils sont disponibles
nativement, pour s'exécuter en tant que RPM, sur le noyau. Celles-ci

Details d’installation des switches Nexus pour la démonstration

 87

Figure 35: Details d’installation des switches Nexus pour la démonstration

Un diagramme simple a été choisi en tenant aussi compte des ressources limitées à la
disposition de ce travail. Nexus exige beaucoup de mémoire RAM. Il est recommandé de
travailler avec 8GB de RAM par switch Nexus pour simuler son comportement. A cause de
cette exigence, le Datacenter a été simulé à part.

e. Installation de Ansible Tower

Une fois installé, Ansible n’ajoutera aucune base de données et il n’y aura plus de
démons pour démarrer ou continuer à fonctionner. Vous n'avez besoin de l'installer que sur une
seule machine (qui pourrait facilement être un ordinateur portable) et il peut gérer un parc entier
de machines distantes à partir de ce point central. Lorsque Ansible gère des ordinateurs distants,
les logiciels ne sont ni installés ni exécutés. Il n’y a donc pas de vraie question sur la mise à
niveau d’Ansible lors du passage à une nouvelle version.

Voici les exigences requises pour l’installation de Ansible Tower :

 Go de RAM minimum (4 Go + RAM recommandés)

 Go de RAM (minimum et recommandé pour les installations à l'essai Vagrant)
 Go de RAM sont recommandés pour 100 fourches
 20 Go d'espace disque dédié
 L’ordinateur doit posséder une adresse IP.

 Configuration requise pour le nœud

 88

 Sur les nœuds gérés, nous aurons besoin d’un moyen de communication, qui est
normalement ssh. Par défaut, cela utilise sftp. Si cela n’est pas disponible, nous
pouvons passer à scp dans ansible.cfg. Nous aurons également besoin de Python
2 (version 2.6 ou ultérieure) ou de Python 3 (version 3.5 ou ultérieure).

Procédure d’installation :

Systèmes d'exploitation pris en charge :

 Red Hat Enterprise Linux 6 64 bits

 Red Hat Enterprise Linux 7 64 bits
 CentOS 6 64 bits
 CentOS 7 64 bits
 Ubuntu 12.04 LTS 64 bits
 Ubuntu 14.04 LTS 64 bits

Installation du nœud de contrôle

Sur Fedora :

$ sudo dnf install ansible

Sur RHEL et CentOS :

$ sudo yum install ansible

Sur Ubuntu :

$ sudo apt update

$ sudo apt install software-properties-common

$ sudo apt-add-repository --yes --update ppa:ansible/ansible

$ sudo apt install ansible

Sur Debian :

Ajouter la ligne suivante à /etc/apt/sources.list :

deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main

Puis lancez ces commandes :

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367

$ sudo apt update

 89

$ sudo apt install ansible

Sur Gentoo :

$ emerge -av app-admin/ansible

$ echo 'app-admin/ansible' >> /etc/portage/package.accept_keywords

Sur FreeBSD :

Bien qu'Ansible fonctionne avec les versions Python 2 et 3, FreeBSD propose différents
packages pour chaque version Python. Donc, pour installer, nous pouvons utiliser :

$ sudo pkg install py27-ansible

Où :

$ sudo pkg install py36-ansible

3.7 Plan de configuration

3.6.1 Blocs ou Modules à Configurer.

Nous configurerons les modules suivants :

 Le réseau WAN Mpls

 La couche cœur
 La couche distribution
 La couche accès
 La couche Datacenter
 Ansible Tower

a. Configuration du réseau WAN MPLS.

Il s’agira ici des grandes étapes pour l’élaboration du réseau WAN MPLS qui
interconnectera les différentes villes.

Procédure de configuration :

 Mise en place du protocole de routage intra-nuage (OSPF)

 Mise en place du protocole de découverte des voisins MPLS (LDP)
 Configuration de l’authentification des voisins (MD5)
 Mise en place des VRFs et des interfaces
 90

 Mise en place du protocole de routage CE-PE (EIGRP)

 Mise en place du protocole MP-BGP
 Gestion de la redistribution des préfixes ou routes

b. Configuration de la couche cœur.

Procédure de configuration :

 Adressage ip sur les interfaces.

 Mise en place du protocole de routage EIGRP

c. Configuration de la couche distribution.

Procédure de configuration :

 Adressage ip sur les interfaces.

 Mise en place du protocole de routage EIGRP.
 Création des VLANs.
 Routage Inter-Vlan.

d. Configuration de la couche accès.

Procédure de configuration :

 Attribution des ports aux VLANs.

 Définition des ports Trunk

e. Configuration du module Datacenter

Exigences :
 Configurer au minimum les 2 switches pour qu’ils soient joignable via leurs
interfaces de management
 Configurer le switch de distribution qui les alimentent en connexion pour
qu’Ansible puisse les contacter
 91

Figure 36: config module Datacenter

Procédures de configuration

Seul le provisionning des VLAN sera illustré dans la démonstration par manque
d’espace et de temps.

A part la configuration minimale et l’authentification, Ansible peut tout automatiser

sur le Nexus.

Les 2 switches doivent être ajoutés à l’inventaire de Ansible.

Un playbook pour ces switch contiendra les informations suivantes

/etc/ansible/hosts:

[all:vars]
ansible_network_os=nxos
ansible_connection=network_cli
ansible_user=cisco
ansible_ssh_pass=cisco

[N9000v-Leaf]
10.10.80.3 ansible_host=nx-9k-01.anonymous.com
10.10.80.4 ansible_host=nx-9k-02.anonymous.com
Activer le module ‘nxos_nxapi’dans Nexus pour pouvoir déclarer des taches dont les
détails seront masqués par cette abstraction.
 92

---
- name: Enable NX-API
hosts: N9000v-All
gather_facts: no
tasks:
- name: Module to enable NX-API on switch is "nxos_nxapi"
nxos_nxapi:
state: present
http: yes
https: yes

Configurer les VLANs

name: Vlan Provisioning

hosts: N9000v-All
gather_facts: no
tasks:
- name: CREATE VLANS AND ASSIGN A NAME USING VLAN_ID
nxos_vlan:
vlan_id: "{{ item.FIXIT }}"
name: "{{ item.name }}"
state: present
loop:
- vlan_id: 90
name: Applications
- vlan_id: 100
name: Messagerie
- vlan_id: 110
name: Systemes

-
f. Ansible TOWER.

Procédures de configuration :

 Vérification de la configuration des VLANs sur les distributions switch de

Kolwezi :
 Nous allons créer un fichier inventaire qui va répertorier nos distributions
switch de Kolwezi.
[switch]
10.10.5.1 ansible_network_os=ios
10.10.6.1 ansible_network_os=ios

NB : Le crochet définit un groupe.

 Nous allons ensuite créer un playbook en respectant les indemptations pour la

vérification des VLANs.
---
 93

- hosts : switch
connection: local
tasks:
- name: Show VLAN
ios_command:
commands: show vlan brief
register: show_vlan

- debug: var=show_vlan.stdout_lines
 Déploiement de la configuration des VLANs 20, 21, 22 et 23 sur les distributions
switch de Kambove afin de faire le routage inter-VLANs :
 Nous allons créer un groupe inventaire qui va répertorier les distributions
switch de Kambove.
[kambove_distributions_switch]
10.20.5.1 ansible_network_os=ios
10.20.6.1 ansible_network_os=ios
 Nous allons ensuite créer un playbook en respectant les indemptations
pour la création des VLANs.
---
- hosts: kambove_distributions_switch
connection: network_cli
gather_facts: no
become_method: enable
become: yes

tasks:
- name: Create vlan 20
ios_vlan:
vlan_id: 20
name: Grand_kam_1
state: present
- name: Create vlan 21
ios_vlan:
 94

vlan_id: 21
name: Grand_kam_2
state: present
- name: Create vlan 22
ios_vlan:
vlan_id: 22
name: Petit_kam_1
state: present
- name: Create vlan 23
ios_vlan:
vlan_id: 23
name: Petit_kam_2
state: present
- name: Add interfaces to VLAN
ios_vlan:
vlan_id: 20
interfaces:
- Ethernet0/0
- Ethernet0/1
 Nous allons ensuite créer un playbook en respectant les indemptations pour la
vérification des VLANs 20, 21, 22 et 23.
---
- hosts: kambove_distributions_switch
connection: local

tasks:
- name: Show VLAN
ios_command:
commands: show vlan brief
register: show_vlan

- debug: var=show_vlan.stdout_lines

3.8 Plan d’implémentation

 95

Le plan d’implémentation a pour but d’ordonnancer les taches dont l’objectif de réaliser
le projet dans un temps optimal. Dans ce cadre, on distingue trois méthodes pouvant nous servir
parfaitement : il s’agit des plus connus comme GANTT, PERT et parmi les moins connus le
diagramme MPM. PERTT et MPM sont les plus expressif visuellement.
Dans la méthode MPM que nous utiliserons les taches représentées par des sommets,
chaque tâche est renseignée par la date au plus tôt et la date au plus tard, à chaque arc
est associé une valeur numérique qui représente la durée de la tâche.

3.9 Conclusion partielle.

Durant ce chapitre nous avons choisi les différents modules ansible qui implémentent les
fonctions logiques. Nous avons aussi décrit l’architecture physique. Enfin nous avons élaborer
un des diagrammes de séquences illustrant le comportement des différents modules puis nous
avons décrit le plan d’installation, de configuration et d’implémentation.
 96

Chapitre 4. IMPLEMENTATION ET TEST

4.1 Installation.

Figure 37:Installation Ansibke

Figure 38: DEPENDANCE à L'INSTALLATION DE ANSIBLE

Installer le fichier Ansible

 97

4.2 Etape 2. Configuration de base des Provider (Juste les grandes lignes).

Figure 39: . Configuration de base des Provider

4.3 Etape 3. Configuration des VRFs sur les Provider (Juste les grandes lignes).

Figure 40:Configuration des VRFs

 98

4.4 Etape 4. Configuration du routage Eirgp

Figure 41:. Configuration du routage Eirgp

4.5 Vérifications du Mpls

Figure 42:Verification du Mpls

 99

Figure 43: Vérification de notre table BGP

Figure 44: Routes Eigrp et BGP

 100

Figure 45: Vérification des routes redistribuées

4.6 Etape 5. Host inventory Ansible (Juste les grandes lignes).

Figure 46: Création des groupe slocals

 101

4.7 Etape 6. Vérification de vlan disponible dans les switchs se trouvant dans
Host inventory Ansible avec les playbooks (Juste les grandes lignes).

Figure 47:Vérification de vlan disponible dans les switchs se trouvant dans Host inventory Ansible avec les playbooks

4.7 Etape 7. Résultats de la vérification. Avec la commande « ansible-

playbook -i inventory.txt test_vlan_dist.yml -u admin –k »

Figure 48: VLANS Vu sur le serveur Ansible

 102

Comme vous pouvez le voir, ce résultat se trouve sur Ansible.

4.8 Etape 8. Déploiement des VLANS

Figure 49: Déploiement des VLANS1

Figure 50: Déploiement des VLANs 2

 103

Figure 51: Déploiement des VLANs 3

4.9 Etape 9. Vérifications

Figure 52: Vérification du déploiement du VLANs

Etapes des switches Nexus

Diagramme physique réalisé dans EVE

 104

Figure 53 : EMULATION DU RESEAU NEXUS AVEC EVE

4.10 Etape9 : Installation et configuration minimale finie du Nexus 01

Figure 54: illustration login Nexus NX9K-01

 105

Installation et configuration minimale finie du Nexus 02

Figure 55: illustration login Nexus NX9K-02

Bon fichier inventaire prenant en charge les 2 switches Nexus. Celui qui a été planifié
dans la conception physique n’a pas marché.

Figure 56: Le fichier inventaire avec deux nexus enregistré

La commande : « ansible N9000-All -m ping permet de tester la connectivite de Ansible sur les
switches Nexus : L’ecran ci-dessous confirme que tout passe.
 106

Figure 57: Test de connectivité sur les nexus

Le respect de l’identation dans les fichier .yml est tres importante sous peine d’avoir des erreurs.

Le fichier planifieee n’a pas marchee, le suivant est celui qu’il fallait pour activer l’API NX-
API.

Figure 58:Playbook pour l'activation de l'API nxos_nxapi

Résultats de l’activation de l’API :

Figure 59: Resultats de l'activation de nxos_nxapi

 107

Les captures ci-apres montre que les 2 switches du datacenter ont été modifiees a distance par
Ansible.

Figure 60: Activation de l'API sur le nexus 01

Figure 61: Activation de l'API sur le nexus 02

La configuration distante des VLAN sur les Nexus s’est faite par le fichier suivant (celui de la
planification a été légèrement modifié.

Figure 62: PLAYBOOK pour le déploiement des VLANs sur le nexus

Voici l’etat des VLANs d’un Nexus avant execution du playbook

 108

Figure 63:Etat initial des VALNS sur les nexus

Résultats de l’exécution du playbook :

Figure 64: Execution du playbook

Le résultat observable dans le switch Nexus :

Figure 65: RESULTAT OBSERVABLE DANS LE SWITCH NEXUS

 109

CONCLUSION GENERALE
Ce travail a traité sur la gestion des configurations d’un Datacenter basée
sur un gestionnaire des configurations (Ansible), il s’agissait de concevoir et implémenter une
simulation d’un système centralisant toutes les configurations du parc des serveurs du centre de
données de Notre entreprise.
L’objectif poursuivi était celui de permettre aux administrateurs systèmes de s’affranchir
des commandes propres à chaque système d’exploitation utilisé dans le réseau cible.

Pour y arriver, nous avons utilisé les grands principes de l’ingénierie des systèmes qui
consistaient à diviser les tâches, a employer l’abstraction afin de partir du général au particulier.
Voilà pourquoi notre travail a été structuré en quatre parties.

Dans un premier temps, nous avons décrit l’infrastructure système existante dont il était
question dans notre travail et critiquer l’existant dans le but de ressortir les spécifications
fonctionnelles du futur système.
Sur base des spécifications fonctionnelles recueillies dans la première partie, nous
nous sommes appuyés dessus dans le but de concevoir logiquement le système qui devait
répondre aux différents besoins exprimés par L’entreprise; cette conception consistait en la mise
en place d’une architecture générale du dit système et une
conception détaillée logique qui montrait les détails sur la façon dont les différents modules
constituant l’architecture générale interagissaient entre eux.

Après avoir ainsi conçu une solution logique répondant aux besoins, nous avons
réalisé cette dernière dans les technologies disponibles en opérant des choix technologiques des
composants pouvant réaliser les fonctionnalités de chaque module ce qui a
conduit à la mise en place de l’architecture du système sur le plan physique. Du reste,
nous avons également planifié l’implémentation du système en partant des procédures
d’installation, des configurations ainsi que des tests unitaires et ceux globaux du système.

La simulation (ou plutôt l’émulation) du système a en fait mis un terme à ce travail, c’est-
à-dire concrétiser tout ce qui a été développé dans l’abstraction. En d’autres termes réaliser tout
ce qui a été planifié en appliquant les procédures d’installation données auparavant pour la
mise en place du système ainsi que leurs tests unitaires et globaux.
 110

Il était aussi question d’appliquer les configurations prévues pour les différents nœuds et
enfin procéder aux tests des objectifs fixés dans ce travail afin de prouver l’hypothèse de
ce travail.

Il serait prétentieux de dire que l’on a épuisé le sujet car beaucoup reste encore à faire. Il
y a certainement des choses à améliorer à l’issue de ce travail. Celui-ci ouvre néanmoins
d’autres perspectives qui pourront être élucidés par d’autres travaux.

Il y a lieu ainsi d’approfondir par exemple l’implémentation des VXLAN et d’autres

concepts avancés du datacenter. Ansible reste un potentiel énorme pour bien travailler dans le
domaine du SDDC.
 111

Bibliographie

[1] L. B. Marc Cyprien, ANSIBLE INVENTORY – Du Statique au Dynamique,

Posté le 21/12/2018.

[2] Wikipedia, fichier de configuration.

[3] LeMAgiT, LeMAGit, 2019/01.

[4] I. Mukeya, GESTION DES CONFIGURATIONS D’UN DATACENTER,

Lubumbashi, 2017.

[5] J. zilk, Puppet vs. Chef vs. Ansible vs. SaltStack, 2018.

[6] intigua, Puppet vs. Chef vs. Ansible vs. SaltStack, 2019/05.

[7] R. Hat, AnsibleWindowsVF, 2017.

[8] Ansible, User Guide, 2019/04.

[9] G. images, ARCHITECTURE ANSIBLE, 2019/06.

[10] Ansible, Network modules, 2019/06.

[11] Ansible : Automatiser la gestion de serveurs, 2019/02.

[12] sweetohm, sweetohm, 2019.

[13] Mr bertin, sysml, l'shi: dr, 109.

[14] Wikipedia, Devops, 2019.