Conception d'une solution de monitoring des conteneurs docker.

I

Septembre 2018

ECOLE SUPERIEURE D'INFORMATIQUE SALAMA
République démocratique Du Congo
Province de Haut-Katanga
Lubumbashi
www.esisalama.org



CONCEPTION D'UNE SOLUTION DE MONITORING DES CONTENEURS DOCKER.

« CAS DE CONGO EQUIPMENT/CAT »

Travail présenté et défendu en vue de l'obtention du grade d'ingénieur technicien en réseaux

Par MUKENDI KABONGO Jonathan

Option Administration systèmes et réseaux

I

Septembre 2018

ECOLE SUPERIEURE D'INFORMATIQUE SALAMA
République démocratique Du Congo
Province de Haut-Katanga
Lubumbashi
www.esisalama.org



" CONCEPTION D'UNE SOLUTION DE MONITORING
DES CONTENEURS DOCKER".

« CAS DE CONGO EQUIPMENT/CAT »

Travail présenté et défendu en vue de l'obtention du grade d'ingénieur technicien en réseaux

Par MUKENDI KABONGO Jonathan Option Administration systèmes et réseaux Directeur Bertin POLOMBWE Co-directeur Herbert KALONJI

I

EPIGRAPHE

« Il y a 10 sortes de gens au monde : ceux qui connaissant le binaire et les autres »

Anonyme

II

DEDICACE

A mes parents Leonard KABEYA et Wivine MUSAU qui n'ont jamais cessés d'être, ceux qui matérialisent mes rêves ; en effet sans leur assistance morale, financière, spirituelle nous ne saurions jamais arrivée là.

Nous vous dédions ce travail

TFE_ESIS_AS 2018

III

REMERCIEMENTS

Ce travail de fin d'études supérieures est le fruit d'un travail assidu, de passion à la recherche, des connaissances acquises, et de preuve de courage manifesté tout au long de notre parcours, mais aussi de l'apport de tout un chacun dans notre entourage.

De ce fait ; jusqu'ici nous exprimons notre profonde gratitude à l'égard de notre Dieu tout puissant, qui n'a pas cessé de nous donner le souffle de vie durant toute la période de notre formation académique jusqu'à ce jour où nous avons le privilège de présenter ce travail.

Nous remercions notre directeur et codirecteur, monsieur Bertin POLOMBWE et monsieur Herbert KALONJI, qui malgré leurs multiples occupations, ont toujours su prendre soin de nous, en nous coachant avec beaucoup d'amour, tout en faisant de ce travail un rêve matérialisé.

Nos remerciements s'adressent une fois de plus à toutes les autorités académiques de l'Ecole Supérieure d' Informatique Salama et plus particulièrement à notre coordonnateur de filière réseau Papa Robert, ainsi que les secrétaires de la filière en la personne de Jonathan BAYONGWA et Papy MUKANDA.

Nous disons merci à nos très adorables parents Leonard KABEYA et Wivine MUSAU ainsi que nos frères et soeurs, nos oncles et tantes, cousines et cousins: Oricia SITITA et Céline NGOIE, Divin KABASELE et Gabriella DIANGU, Olive MUNDI, Marya MOLONGI, Ryan MAYENGE et Israël KABEYA pour la soutenance et la chaleur familiale réconfortante manifestés en notre faveur.

Nos remerciements s'adressent particulièrement à notre curé le révérend Père Barnabé BADJI, et tous les membres de groupes liturgiques au sein de la Paroisse MARIA MAMA WA MITUME, mais aussi à la communauté salésienne de Salama, les prêtres, les frères dont nous citons : Pr. André KAZEMBE, Pr. ALBERT NGOIE, Fr Gaétan.

Nous remercions vivement de tout coeur les ingénieurs : Derick KHON, Israël MUKEYA, Luc KANIKI, YAV GERMAIN Nick, Cédric LUBANZA.

Du reste nous remercions nos camarades avec qui nous avons passé des moments forts d'études. Et pour finir nous adressons nos remerciements à tous ceux, qui de près ou de loin ont contribué d'une manière ou d'une autre à l'élaboration de ce travail et qui n'ont pas vu leurs noms mentionnés ici, nous vous en supplions de ne pas nous en tenir rigueur, nous vous portons à coeur.

TFE_ESIS_AS 2018

IV

IN MEMORIAM

A notre regretté mère que nous aimons tant Julie MUNDI, celle qui nous as donné la vie et qui par elle aujourd'hui le monde peut parler de nous et bénir le nom de Dieu à travers elle, de notre venue au monde. Chère maman durant votre passage sur terre, vous ne cessé de nous répéter que la vie appartient aux courageux, aux hommes débrouillards et autonomes. Vous aurez bien voulu être présente en ce moment, nous assister moralement, mais hélas le bon Dieu a décidé de vous reprendre si tôt au moment où nous avions encore besoin de vous. Chère maman du plus profond de notre coeur, nous vous disons merci, vous trouverez toujours une place dans notre coeur, notre reconnaissance et notre amour envers vous n'aura jamais de fin.

A notre frère Rabbi KAYEMBE, qui aurait rêvé de ce grand jour comme tous nos frères et soeurs également. La passion de devenir ingénieur nous a animé depuis le bas âge et en ce jour où nous rédigeons ce travail de fin d'étude, de l'autre côté où vous vous trouvez dans l'au-delà, vous vous sentez valorisé et vivement représenté.

TFE_ESIS_AS 2018

V

LISTE DES FIGURES

Figure 1.1 Organigramme de l'entreprise Congo Equipment

Figure 1.2 Topologie réseau de l'entreprise

Figure2.1 Architecture générale

Figure2.2 Architecture client serveur

Figure2.3 Architecture de la collecte, du stockage et de la visualisation

Figure 2.4 Diagramme de cas d'utilisation système

Figure 2.5 Diagramme de Prometheus

Figure 2.6 : Diagramme de Grafana

Figure 2.7 Diagramme de CAdvisor

Figure 2.8 Diagramme Datadog

Figure 2.9 Diagramme décisionnel

Figure 3.1 Téléchargement de Package

Figure 3.2 Commande accès téléchargement

Figure 3.3 Téléchargement docker compose

Figure 3.4 Résultat test Proc.int.3.1

Figure 3.5 Résultat test Proc.int.3.2

Figure 3.6 Résultat test Proc.int.3.3

Figure 3.7 Diagramme de Gantt

Figure 3.8 Diagramme de Pert

Figure 4.1 Caractéristique système d'exploitation hôte

Figure 4.2 Vérification environnement docker

Figure 4.3 Vérification docker-compose

Figure 4.4 Résultat téléchargement image conteneur réussi

Figure 4.5 Résultat exécution conteneur

Figure 4.6 Téléchargement Prometheus

Figure 4.7 Téléchargement CAdvisor

Figure 4.8 Installation Prometheus

Figure 4.9 Vérification du lien

Figure 4.10 Lancement Prometheus

Figure 4.11 Installation CAdvisor

Figure 4.12 Lancement CAdvisor

Figure 4.13 Accès fichier Prometheus

Figure 4.15 Configuration fichier Prometheus

Figure 4.16 Configuration fichier Docker-compose

Figure 4.17 Résultat d'exécution Docker-compose

Figure 4.18 Résultat d'execution Prometheus et cAdvisor

Figure 4.19 Image collecte et stockage métriques

Figure 4.20 Conteneurs en exécution

Figure 4.21 Images conteneurs disponible sur le serveur

VI

Figure 4.22 Information sur l'hôte docker

Figure 4.23 Information sur conteneur Ubuntu en exécution Figure 4.24 Utilisation mémoire conteneur Ubuntu Figure 4.25 Utilisation processeur conteneur Ubuntu Figure 4.26 Evaluation des besoins fonctionnels Figure 4.27 Evaluation des besoins non fonctionnels

TFE_ESIS_AS 2018

TFE_ESIS_AS 2018

VII

LISTE DES TABLEAUX

Tableau 1.1 Plan d'adressage

Tableau 1.2 Plan de nommage

Tableau 1.4 Inventaires des équipements

Tableau 1.3 Supports de transmissions utilisées dans le LAN

Tableau 2.1 Logiciel de surveillance Prometheus

Tableau 2.2 Logiciel de surveillance Grafana

Tableau 2.3 Logiciel de surveillance CAdvisor

Tableau 2.4 Logiciel de surveillance Datadog

Tableau 2.5 Tableau décisionnelle

Tableau 4.1 : Besoins fonctionnels

Tableau 4.2 : Besoins non fonctionnels

I VIII

LISTE DES ACRONYMES

DHCP : Dynamic Host Configuration Protocol

VMs : Machines Virtuelles

Os: Operating System

FTP: File Transfer Protocol

VLAN: Virtual Local Area Network

UML: Unified Modeling Language

XOR: Ou exclusif

HTTP: Hyper Test Transfer Protocol

YAML: Yet Another Markup Language

IX

TABLE DES MATIERES

Table of Contents

EPIGRAPHE i

DEDICACE II

REMERCIEMENTS III

IN MEMORIAM IV

LISTE DES FIGURES V

LISTE DES TABLEAUX VII

LISTE DES ACRONYMES VII

TABLE DES MATIERES IX

AVANT-PROPOS XIII

CHAPITRE 0. INTRODUCTION GENERALE 1

0.1 Aperçu générale 1

0.1 Problématique 2

0.2 Hypothèses 2

0.3 Choix et intérêt du sujet 3

0.4 L'état de l'art 4

0.4. Méthodologie 5

0.4.1. Méthodes 5

0.4.2. Techniques 5

0.6. Délimitation du travail 6

0.7. Subdivision du travail 6

0.8. Outils et équipements 6

CHAPITRE 1: SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME 7

1.1. Introduction 7

1.2. Présentation de l'entreprise 7

1.2.1. Historique 7

1.2.2. Situation géographique 8

1.2.3. Structure et fonctionnement 8

1.3. Etude de l'existant 11

1.3.1. Architecture réseaux 12

1.3.1.1. Physique 12

X

TFE_ESIS_AS 2018

XI

1.2 Topologie réseau de l'entreprise 12

1.3.1.2. Logique 13

1.3.1.3. Supports de transmissions 14

1.3.2. Eléments constitutifs 14

1.3.5. Critique du réseau existant 16

1.3.5.1. Points forts 16

1.3.5.2. Points à améliorer 17

1.4. Spécifications des besoins 17

1.4.1. Les besoins fonctionnels 17

1.4.2. Les besoins non fonctionnels 18

1.5. Conclusion Partielle 19

CHAPITRE 2 : CONCEPTION DU SYSTEME 20

2.1. Introduction 20

2.2. Solution par rapport aux besoins 20

2.3. Conception générale 22

2.3.1. Principe de fonctionnement 22

2.4. Conception logique détaillée 22

2.4.1. Du point de vu statique 22

2.4.1.1 Plateforme de surveillance 23

2.4.1.2. Exportateur 24

2.4.1.3. Stockage 26

2.4.1.4. Visualisation 26

2.4.1.5. Alarme d'alerte 26

2.4.2. Du point de vu dynamique 27

2.4.2.1. Scenario 28

2.5. Conception physique 29

2.5.1. Choix d'une solution de surveillance de conteneur 29

2.5.1.1. Analyse et stockage métrique 29

2.5.1.1. A. Prometheus 29

2.5.1.2. Visualisation métriques 30

2.5.1.2. A. Grafana 30

2.5.1.3. Collecte, traitement et visualisation des données 31

2.5.1.3. A. CAdvisor 31

2.5.1.3. B. Datadog 32

TFE_ESIS_AS 2018

2.6. Conclusion partielle 34

CHAPITRE 3 : SURVEILLANCE DE CONTENEUR DOCKER AVEC

PROMETHEUS ET CADVISOR 35

3.1. Définition 35

3.2. Principe de fonctionnement de la solution Prometheus et Cadvisor 35

3.2.1. Architecture Prometheus 36

3.2.2. Détails des différents blocs Prometheus : 37

3.3. Avantages et inconvénients de Prometheus et CAdvisor 37

3.4. Aperçu de la technologie Docker 38

40

3.5. PLAN D'INSTALLATION ET PROCEDURE DE CONFIGURATION 40

3.5.1. Prérequis 40

3.5.1. Proc.inst.3.1. Pour mettre à jour le système et télécharger le package 40

3.5.2. Proc.inst.3.2. Installation de l'environnement docker 40

3.5.3. Proc.inst.3.3.Creation de conteneur 41

3.5.4. Proc.inst.3.4. Pour l'installation de docker compose 41

3.5.5. Proc.inst.3.5. Installation outils de monitoring Prometheus 42

3.5.6. Proc.inst.3.6. Configuration et intégration CAdvisor 42

43

3.6. Plan et procédure de test 43

3.6.1. Test Proc.inst.3.1 43

3.6.2. Test Proc.inst.3.2 43

44

3.6.3. Test Proc.inst.3.3 44

3.6.4. Test Proc.inst.3.4 44

3.6.5. Test Proc.inst.3.5 44

3.6.6. Test Proc.inst.3.6 44

3.7. Plan d'implémentation 45

3.7.1. Diagramme de Gantt 45

46

3.7.2. Diagramme de Pert 46

3.8. Conclusion partielle 46

CHAPITRE 4 : IMPLEMENTATION DE LA SOLUTION 47

4.1. Introduction 47

XII

TFE_ESIS_AS 2018

48

4.2. Vérification et installation prérequis docker 48

50

4.3. Téléchargement outils de monitoring 50

4.3. Installation outils de monitoring 50

4.5. Configuration et intégration de CAdvisor dans Prometheus (Proc.inst.3.6) 52

4.6. Visualisation résultats de monitoring 55

4.7. Conclusion Partielle 58

4.7.1. Evaluation des besoins 58

4.7.1.1. Besoin fonctionnels 58

CONCLUSION GENERALE 60

BIBLIOGRAPHIE 61

TFE_ESIS_AS 2018

XIII

AVANT-PROPOS

Dans ce travail nous faisons le monitoring ou la surveillance des services conteneurisés dans un conteneur docker. Notons qu'un réseau informatique d'entreprise dont l'administrateur systèmes ne détient pas d'information est un réseau qui est exposé chaque fois à l'indisponibilité des services. De ce fait, en tant qu'administrateur système nous avons pensé à une solution de monitoring de conteneur docker dans le but de palier aux problèmes d'anomalie et d'inactivité des services, de prévention en cas d'échec ou d'exécution de service et d'application, de connaissance en temps réel de l'état actuel, passé de notre système informatique.

1

INTRODUCTION GENERALE

CHAPITRE 0. INTRODUCTION GENERALE

0.1 Aperçu générale

L'informatique est une science évolutive dont l'avancée technologique croit excessivement de nos jours la tendance des entreprises qui jadis utilisaient la virtualisation des services et des applications avec VMs¹ migrent vers la conteneurisation vue les multiples avantages qu'elle offre. La conteneurisation² qui consiste à créer des conteneurs³ dans lesquels seront hébergés les services et applications comme cela se fait avec les VMs, à la différence elle nous offre comme avantage moins d'utilisation d'espace mémoire, moins d'encombrement par apport aux VMs, portable, flexible, en exécution que ce soit sur un serveur local, soit sur un serveur dans le Cloud. Mais cela n'exclut pas la surveillance réseaux, étant donné que la disponibilité de service reste un challenge pour administrateur système, nous nous devons des solutions palliatives pour anticiper tout état d'indisponibilité des services.

Nous sommes sans ignorer que l'indisponibilité des services peut engendrer des conséquences néfastes à l'entreprise. Un bon administrateur est celui qui se doit de mettre sur pieds une infrastructure de surveillance stable en cas de problème pouvant le prévenir de toute activité, anomalie sur le réseau. Voici ce qui justifie le choix du thème de notre travail de fin de cycle « CONCEPTION D'UNE SOLUTION DE MONITORING DES CONTENEURS DOCKER » ayant pour cas d'application l'infrastructure réseau de l'entreprise CONGO EQUIPMENT/CAT, lequel ne possède pas encore un environnement docker, nous nous en sommes servis pour simuler notre solution, pouvant être un problème réel que pourrai éprouver une autre entreprise. Cas cela ne tienne, vous trouverez en annexe les étapes d'installation de l'environnement docker qui ferait l'objet de notre étude.

¹VMs : Machine virtuelle

²Conteneurisation : procédée qui consiste à virtualiser un service mais via conteneur ³Conteneurs : de la même façon que les machines virtuelles, ils hébergent des services et applications

TFE_ESIS_AS 2018

2

INTRODUCTION GENERALE

0.1 Problématique

Les besoins de maintenir le niveau de bon fonctionnement des services réseaux dans un environnement conteneurisé, face à tout indisponibilité des services lié à un état dysfonctionnel des conteneurs, au manque de supervision des conteneurs, a tiré notre attention, surtout que l'adoption de déploiement des conteneurs au sein des infrastructures réseaux des entreprises vient à grande échelle. Les administrateurs systèmes seront butés à une nouvelles méthodologie de surveillance qui est de loin différente à la méthode traditionnelle de surveillance qu'ils utilisés pour la surveillance des entités dans le réseau. La surveillance de conteneurs présente des nouveaux défis, des nouvelles contraintes entre autres...la nature éphémère des conteneurs, la complexité des objets, des services, conteneurisés faisant la base même de notre surveillance. Face à cette problématique; nous nous sommes posés les questions de recherche suivantes:

1. Quelles sont les causes des disfonctionnements des conteneurs, qui
entrainent l'indisponibilité des services ?

2. Quel mécanisme mettre sur pied pour prévenir toute forme de
disfonctionnement de conteneur afin de palier à l'indisponibilité des services ?

3. Quelles solutions concevoir pour surveiller les conteneurs ainsi que
les services qu'ils hébergent ?

0.2 Hypothèses

Dans cette partie nous essayerons de répondre provisoirement aux questions posés dans la problématique:

1. Nous allons identifier, détecter, traiter les causes majeurs qui font en sortes que les conteneurs soit inactif, tel que le manque des ressources mémoires, les nombres de conteneur pouvant supporter un serveur de capacité quelconque face à ses caractéristiques de traitement de données, le cycle de vie de conteneur non surveillé, manque de supervision des conteneurs et tant d'autres...une étude d'ingénierie sera faite pour nous conduire à la solution adéquate.

2. Nous mettrons en place une solution de surveillance adaptée docker temps réel permettant de nous notifier sur l'état passé, actuel, ainsi que l'état de bon fonctionnent de conteneurs. Laquelle serait aussi en mesure de détecter les incidents, les anticiper pour éviter tout arrêt de service.

3. A l'aide d'un Dashboard⁴ logiciel spécialisé pour conteneurs et applications hébergées nous aurons à faire de la suivie statistique, informationnelle et de prise de décision et cela grâce aux graphiques⁵, métriques⁶ et logs⁷, reporting⁸ et capacity planning⁹, généré par un outil de surveillance automatisé.

TFE_ESIS_AS 2018

3

INTRODUCTION GENERALE

0.3 Choix et intérêt du sujet

Le réseau informatique et administration système est une science qui s'assure au sein d'un système informatique d'une entreprise d'offrir aux utilisateurs une meilleur qualité de services, une gestion de services, de la performance et de la sécurité de services. Dans ce dit travail nous proposons des solutions d'administration système liées à la disponibilité de services.

Nous surveillons une infrastructure à conteneur docker du système informatique de Congo Equipment. Nous répartissons l'intérêt à notre sujet comme suit :

? L'intérêt personnel

Par ce sujet nous sommes attirés par l'un de tache dont se doit l'administrateur système celui de se mettre à jour et de mettre son infrastructure réseau à jour ; ainsi nous apportons une nouvelle manière de faire du suivi des infrastructures réseaux modernes.

? L'intérêt scientifique

Ce travail n'est pas seulement réalisé pour l'obtention du diplôme de fin d'études mais c'est une source d'inspiration fiable dont se serviront les chercheurs, la génération estudiantine avenirs qui seront intéressées, passionnées par la surveillance réseau

? L'intérêt social

Ce travail est une solution pour beaucoup d'entreprises qui s'apprêtent à migrer vers la technologie docker pour la conteneurisation des services et applications. Dont trouve déjà son champ d'application au sein de l'infrastructure réseau de CONGO EQUIPMENT.

4 Dashboard : Tableau de bord

⁵Graphique : tracé, dessin représentatif d'une information

⁶Métriques: elles permettent de récupérer une donnée sous forme de chiffres. ⁷Logs:permettent de suivre ce que réalise une application, un système action par action via un fichier

⁸Reporting: permet d'informer sur le système, par la collecte d'information

⁹Capacity planning: élément clé dans le pilotage de la virtualisation. Il permet de prendre les bonnes décisions et d'anticiper les aléas projets.

TFE_ESIS_AS 2018

4

INTRODUCTION GENERALE

0.4 L'état de l'art

Nous ne prétendons pas être le premier, ni le dernier à travailler sur un sujet du genre. Quelques prédécesseurs en ont parlés dont:

Dans la télé-administration des équipements et une solution d'infogérance au sein du parc informatique de la Gécamines :

Par l'ingénieur Derrick KHON au cours de l'année 2010-2011 sous le thème : « Intégration de l'infogérance dans le réseau de la Gécamines ». L'ingénieur proposa une solution de surveillance à distance des services, ainsi que des équipements pouvant lui notifier en temps réel de tous désagréments au sein du réseau et cela grâce à des outils lui permettant de générer de sms, mail, cartographie etc...

Dans la supervision, l'amélioration de performance de l'infra-réseau :

Par l'ingénieur Tracy NTUMBA au cours de l'année 2013-2014 sous le thème : « Etude et mise en place d'une plateforme de supervision hautement disponible ».La dite solution a été déployé au sein du système informatique de Manoah Investment Lubumbashi, laquelle est une solution de supervision tout en un, capable de collecter des informations d'anomalies au sein du réseau et d'y apport une solution préventive de secours qui garantirait la continuité de fonctionnement du réseau, tout en garantissant la disponibilité du serveur de monitoring en implémentant une architecture distribué au sein de l'infra-réseau.

Par l'ingénieur Samuel NUMBI 2015-2016 dans « la mise en place d'un système de déploiement des conteneurs dans une infrastructure IT en vue d'optimiser l'utilisation des applications du monde libre, sur une plateforme Windows ». Le dit travail consiste à la mise en place d'un système de virtualisation des applications légères, qui optimiserait les applications libres et homogénéiserait leur environnement de travail.

Par la suite, l'ingénieur Nick dans « La mise en place d'un système de virtualisation basé sur les conteneurs du monde libre et propriétaire et optimiser les applications homogènes ». Le dit travail consiste à une hétérogénéité des applications du monde libre et propriétaire pouvant être utilisé sur un même hôte.

Ainsi que par l'ingénieur Murphy TSHIAMALA dans « La mise en place d'un système de gestion de configuration de conteneur docker avec Kubernetes » et l'ingénieur Sera MUKASA dans « la mise en place de la solution palliative de conteneur docker pour la sécurité des applications basée sur rocket ».

En ce qui est de notre travail, nous mettrons en place une solution de surveillance des conteneurs qui consisterait à faire de la suivie de nos conteneurs

TFE_ESIS_AS 2018

5

INTRODUCTION GENERALE

lesquels hébergerait des services critiques d'entreprise, dont leur inactivités engendreraient des conséquences néfastes pour le bon fonctionnement du réseau informatique. Notre solution vient palier à cet état d'inactivité des services.

0.4. Méthodologie

0.4.1. Méthodes

? Top down design

Est une méthode permettant de résoudre un problème complexe, tout en les décomposant en des petits problèmes ou modules. Afin de réduire la complexité du problème et avoir une main mise sur chaque petit problème. Cette méthode est basée sur l'identification des besoins et des objectifs du client, elle est structurée en 7 étapes dont nous citons : l'objectif de l'entreprise, les besoins, les contraintes, la détermination de la portée du projet, les objectifs techniques, le cahier des charges et la planification de l'étude. [1].

? Traitement des résultats

Est une méthode qui consiste à tester, interpréter, corriger, les résultats après une solution donné à un problème, ainsi elle nous permettra de voir si les résultats obtenus correspondent aux besoins. Au cas contraire nous continuons nos recherches, afin d'améliorer les résultats.

? Méthode de comparaison

Elle va nous permettre de faire une étude comparative face aux logiciels ou solutions mieux adapté par rapport aux autres pour une

meilleure présentation de notre solution.

0.4.2. Techniques

? La documentation

Cette technique nous a lancé sur le chemin de lecture, sans lequel ce dit travail ne serait appelé travail de fin d'étude. Plusieurs livres, ouvrages, des sites internet, des rapports et revues nous ont permis de réaliser un bon travail.

? Interview

Cette technique dite de feedback ou d'échange nous a permis de nous entretenir avec nos ainés scientifiques, nos collègues administrateurs systèmes et réseaux, afin de poser des questions à nos encadreurs de stage IT Congo Equipment, sur la solution qui fait notre sujet de fin d'étude.

TFE_ESIS_AS 2018

6

INTRODUCTION GENERALE

0.6. Délimitation du travail

Dans le temps et dans l'espace notre travail s'étend d'une période allant du mois d'octobre 2017 au mois de septembre 2018 et a pour cas d'application l'infrastructure réseau de Congo Equipment.

En ce qui concerne notre travail, nous nous sommes limité à concevoir une solution des surveillances des conteneurs dans un environnement docker afin d'optimiser la disponibilité et la performance des services dans un réseau LAN d'entreprise.

Notons que notre solution a été mise au point à 90 % car la partie notification par alerte n'a pas été réalisée suite au manque de certaines ressources logicielles.

0.7. Subdivision du travail

Voici comment notre travail sera subdivisé à part l'introduction générale et la conclusion générale, nous aurons quatre chapitres dans lesquels va s'articuler notre travail qui sont :

Le premier intitulé : « Spécification fonctionnelle du futur système ». Dans ce chapitre, il sera question de faire une étude de l'infrastructure réseau existante de l'entreprise Congo Equipment, choisi dans ce travail pour nous servir de cas d'application. Nous allons, nous en servir pour prélever les besoins fonctionnels et non fonctionnels, lesquels nous allons, nous baser pour concevoir la solution adéquate à mettre sur pieds.

Le deuxième intitulé : « Conception logique du futur système ». Dans cette deuxième partie, nous allons, nous servir des besoins non fonctionnels, et fonctionnels récoltés au chapitre précèdent afin de concevoir une solution logique du futur système de manière générale et détaillée, lesquels nous permettra d'opter pour la meilleure solution logique du problème.

0.8. Outils et équipements

Voici les quelques outils matériels et logiciel que nous avions utilisé pour implémenter la solution :

· Granttproject

· Zoterro

· Microsoft vision pro 2013

· Ordinateur portable

· Moniteur

· Ubuntu 18 LTS

· cAdvisor

· Prometheus

· VMware workstation

TFE_ESIS_AS 2018

7

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

CHAPITRE 1: SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

1.1. Introduction

Dans cette partie de notre travail, nous allons présenter l'entreprise Congo Equipment ainsi que son infrastructure IT, nous mènerons une étude de l'existant, une critique de l'infrastructure réseaux de Congo Equipment, afin de prélever les points forts et faibles de l'infrastructure réseau, et ainsi détecter les besoins qui nous permettrons de bien concevoir notre solution.

Les méthodes et techniques cités ci-haut nous ont permis de détenir des informations fiables et de maitriser la complexité des besoins identifiés au sein du département IT, tout en le groupant en besoins fonctionnels et besoins non fonctionnels. Sans plus tarder passons à la présentation de l'entreprise ainsi que son infrastructure réseau.

1.2. Présentation de l'entreprise

1.2.1. Historique

Congo Equipment sprl est une société de droit congolais constituée suivant l'acte constitutif du 7 mars 2007.

Elle est une joint-venture entre deux grands dealers de Caterpillar en Afrique. Il s'agit de BARLOWORLD Equipment, société sud-africaine qui occupe l'Afrique Australe et TRACTAFRIC Equipment, société française qui a la juridiction de l'Afrique Centrale et toute la R.D.C.

La société Congo Equipment est le représentant officiel de Caterpillar sur toute l'étendue de l'ex province du Katanga. Elle représente aussi les équipements industriels Manitou, Hyster, Perkins, Olympian, Bucyrus (ex O&K Terex).Congo Equipment et une entreprise bilingue car certains dirigeants sont anglophone et autre francophones, Ainsi il est demandé à tout le personnel de savoir parler anglais et français. Mais grâce à une bonne organisation de Congo Equipment l'entreprise offre à son personnel des cours d'anglais financés par l'entreprise elle-même.

? Mission de l'entreprise

Congo Equipment a pour mission la réalisation de toutes opérations commerciales, techniques (vente et services après-vente) des engins industriels, miniers ou de génie civil.

? Slogan ou promesse de l'entreprise

« Vos projets, nos services »

? Objectif de l'entreprise

Congo Equipment a pour objectif de mettre à la disposition de ses clients non seulement des produits ou services les plus modernes ou performant mais surtout de gagner la confiance de manière à les fidéliser.

TFE_ESIS_AS 2018

8

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

La qualité et la perfection de ses produits et services font de Congo Equipment une entreprise fiable et compétente.

· OEuvre sociale de l'entreprise

L'entreprise a eu à faire des oeuvres social dans le cadre de sponsoring entre autre Congo Equipment est, chaque fois l'un des sponsors du tournois d'équitation organisé chaque année au cercle hypique à Lubumbashi. Mais aussi, Congo Equipment s'est lancé dans la formation de la jeunesse congolaise. La société a de ce fait construit pour l'Institut Technique Salama un atelier, centre de formation au standard Caterpillar pour un investissement de près de 400.000$. Ce centre a été inauguré en février 2016.Il sera géré par Congo Equipment pendant deux ans pour être remis à l'Institut Technique Salama.

1.2.2. Situation géographique

Les bureaux administratifs de la société sont situés au n° 675 de l'avenue de la Métallurgie, plus précisément dans l'enceinte des installations de Fondaf.

Elle a deux agences à Kolwezi et Fungurume où elle met à disposition des grandes sociétés minières du Katanga son matériel et sa technicité.

En dehors de Kolwezi et Fungurume qui sont les grands sites miniers, Congo Equipment a offert aussi ses services dans les sites miniers de Luswishi, Kipoi et Mabende sur la route Likasi, à Dikulushi dans le territoire de Pweto, à Mutanda dans le Lualaba. Congo Equipment était aussi à Sakania dans le Haut-Katanga.Suite à la baisse des cours des métaux et la réduction des activités minières, Congo Equipment s'est vu perdre certains clients comme MCK et KCC. D'où son retrait progressif des sites de Dikulushi, Kipoi, Mabende, Sakania, etc.

1.2.3. Structure et fonctionnement

Pour la réalisation de ses objectifs, la société Congo Equipment Sprl organise en son sein plusieurs départements ayant chacun une mission spécifique, nous citons :

· Le département commercial : dirigé par un directeur commercial.

· Le département financier : dirigé par un directeur financier.

· Le département technique : dirigé par un directeur technique.

· Les départements de pièces et rechanges : dirigé par un directeur de départements pièces et rechanges.

· Le département de ressources humaines : dirigé par un directeur de ressources humaines.

· Le département de location : dirigé par un directeur de location.

· Le département de formation : dirigé par un directeur de formation

9

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

Voici comment se présente l'organigramme, sur la page suivante :



Figure 1.1 Organigramme de l'entreprise Congo Equipment

10

TFE_ESIS_AS 2018

10

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

? Subdivision du département IT en service

Le département IT est dirigé par l'IT Manager en la personne de Monsieur Kedrick MUSHAYUMA qui coordonne l'ensemble de service, c'est lui qui possède le pouvoir décisionnel au sein du département. Il est secondé par Madame Patricia KALIATA Assistante IT Manager, elle s'occupe du bon déroulement de taches attribuées à chaque service et fait rapport à l'IT Manager.

Le département IT est subdivisé en plusieurs services dont nous citons :

BUSINESS APPLICATION, SERVICE NETWORK, BUSINESS TECHNOLOGY ET HELP DESK

? BUSINESS APPLICATION

Ce service a pour responsable principal Monsieur Christian KYAMUSALU ayant pour mission première d'assurer la maintenance, l'administration technique et l'évolution des applications métiers utilisées par les différents départements dont nous pouvons citer SAP, CITRIX...Ce service est également en charge de développer des applications lorsque la mise en place d'un progiciel ne s'avère pas nécessaire.

? SERVICE NETWORK

Ce service a pour responsable principal Monsieur Vincent TSHIBANGU et secondé par Monsieur Ruddy TSHILUMBA ce service a pour mission de gérer la globalité du réseau de l'entreprise LAN, WAN et INTERNET mais aussi d'administrer, contrôler et gérer les accès au réseau des utilisateurs. Il s'occupe aussi de la configuration et de la surveillance réseau : switch, antenne cambium, routeur, pare feu, proxy...

? BUSINESS TECHNOLOGY

Ce service a pour responsable Monsieur Trésor BODIKA chargé de la supervision et des achats des équipements mais aussi la préparation des ordinateurs selon les besoins des utilisateurs, le déploiement et maintenance des imprimantes, le déploiement et maintenance des IPhones, les scanneurs et toute autres forme d'installation de logiciel et antivirus sur les ordinateurs des utilisateurs.

? HELP DESK

Ce service est chapeauté par Monsieur Luc ILUNGA, c'est l'un des services le plus actif qui travail en synergie avec les autres services épinglés ci-haut. En effet de par sa cellule d'intervention d'assistance utilisateurs, ses différents membres sont constamment en action sur le terrain afin d'assurer le support aux utilisateurs présents dans différents

11

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

départements. Cette équipe d'intervention est repartie selon des secteurs et sites à Lubumbashi, à TFM, à MUTANDA, à SOCOCOT, KOLWEZI...Evaluer les besoins des utilisateurs, préparer des postes pour les utilisateurs, faire du dépannage logiciel et matériel, toutes ces tâches rythment le quotidien du service help desk.

1.3. Etude de l'existant

Le département IT de Congo Equipment gère une infrastructure réseau à liaison étendue, qui relie Lubumbashi avec les autres sites qui sont MUTANDA, KOLWEZI, SOCOCOT, TFM où sont installés les succursales Congo Equipment. Les différents succursales communiquent avec la base, le point centrale qui est Lubumbashi via lignes louées attribué par les fournisseurs d'accès internet suivants Airtel, Vodacom, Intersys... ; sur lesquels des VPN¹⁰ on était créé.

Voici comment se présente la topologie réseau composée de 5 sites distants :

? Lubumbashi

Est le siège, la base du réseau possédant une forte densité de trafic réseau mais aussi le centre des différentes connexions, dont le département sont relié entre elles via des antennes sectorielles se trouvant sur le bâtiment administratif et le signal est relayé via Access point dans chaque département dont nous citons : le département service, training, parts, rentals et sales, et enfin le département technique. Ceci est dit pour une connexion en sans-fil mais aussi une liaison par fibre optique interconnecte les différents départements cités ci-haut.

? Kolwezi

Site relié à d'autres sites via des liaisons WAN reliant aussi le département administratif de Lubumbashi à celui de Kolwezi. ? MUTANDA

Site relié à d'autres sites via des liaisons WAN reliant ainsi le département administratif de Lubumbashi aux différents départements se trouvant au sein de MUMI.

? SOCOCOT

Site relié à d'autres sites via des liaisons WAN reliant ainsi le département administratif de Lubumbashi aux différents départements se trouvant au sein de Sococot.

TFE_ESIS_AS 2018

¹⁰VPN : Réseau virtuel privé

12

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

1.3.1. Architecture réseaux

1.3.1.1. Physique

Voici comment se présente l'architecture réseau physique de Congo Equipment :



Dép. technique

1.2 Topologie réseau de l'entreprise

TFE_ESIS_AS 2018

13

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

1.3.1.2. Logique

Voici comment se présente l'architecture logique de l'infra-réseau Congo Equipment :

	? Plan d'adressage Tableau 1.1 Plan d'adressage				Sites
Adresses réseaux	Plages		Masques	Lubumbashi
10.15.15.0	10.15.15.1-10.15.15.254		255.255.255.0	Mutanda
10.15.16.0	10.15.16.1-10.15.16.254		255.255.255.0	Kolwezi
10.15.17.0	10.15.17.1-10.15.17.254		255.255.255.0	TFM
10.15.18.0	10.15.18.1-10.15.18.254		255.255.255.0	Sococot
10.15.19.0	10.15.19.1-10.15.19.254		255.255.255.0

Voici comment se présente le plan d'adressage interconnectant les différents sites de notre réseau. Le plan d'adressage a pour but de définir pour chaque réseau physique, une adresse de réseau IP. Pour chaque machine de chacun de ce réseau, une adresse machine relative [2].

? Plan de nommage

C'est un ensemble des règles communes pour nommer les différents équipements enregistrés dans un système d'information. Il permet à un agent IT d'identifier aisément tous les équipements dans son parc informatique [3].

	Tableau 1.2 Plan de nommage					Succursales
Access Points	Switchs	Routeurs	Serveurs		Lubumbashi ce_ap_lub01
ce_sw_lub01		ce_rt_lub01	ce_srv_lub01		Mutanda
ce_ap_mu01	ce_sw_mu01	ce_rt_mu01	ce_srv_mu01		Kolwezi
ce_ap_klz01	ce_sw_klz01	ce_rt_klz01	ce_srv_klz01		TFM
ce_ap_tfm01	ce_sw_tfm01	ce_rt_tfm01	ce_srv_tfm01		Sococot
ce_ap_soc01	ce_sw_soc01	ce_rt_soc01	ce_srv_soc01

N.B : Le plan de nommage est tel que la première partie identifie l'entreprise Congo Equipment, la deuxième partie identifie l'Equipment réseau et la troisième partie identifie l'emplacement ou le site, suivie du numéro de l'équipement. Signalons aussi que dans les différents sites, il y a des départements et les équipements sont nommés comme suit: ce_ap_lub_adm01, ce_sw_klw_srve01, etc.

TFE_ESIS_AS 2018

14

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

1.3.1.3. Supports de transmissions

· WAN

Les ondes électromagnétiques pour l'interconnexion des différentes succursales distantes à grande échelle géographique. Le choix porté sur les ondes électromagnétiques d'une antenne Vsat¹¹ à une autre. Les liaisons WAN¹² repose sur la technique de la liaison point à point qui consiste à établir une connexion entre un opérateur et un client via ligne louée [4]. Dans notre cas, il s'agit de Vodacom, Intersys, Airtel.

· LAN

Tableau 1.3 Supports de transmissions utilisées dans le LAN

Filaire Sans fil

Les câbles UTP^13 catégorie 5 et catégorie 6 utilisés pour l'interconnexion des équipements réseaux. La fibre optique est utilisée pour interconnecter le bâtiment administratif et celui de training.

Le WIFI est la technologie sans fil utilisé qui émet de signaux radio fréquence via des équipements radio tel que les Access points en raison de leur distance qui est qu'à même considérable. De ce fait, le choix porté pour la fibre à bien son pesant d'or.

1.3.2. Eléments constitutifs

· Les switchs

Equipement utilisé pour relier ou interconnecter les équipements dans le réseau.

· Le pare-feu

Pour la politique de sécurité, un pare-feu est installé pour définir les types de communication autorisées et limités. Pour notre cas, il s'agit du Sonic Wall.

· Les Access Points

De modèle cambium Uapro et Uae wifi, qui permet d'arroser de fournir un bon niveau de signal réseau wifi dans différents départements.

¹¹Vsat : Very Small Aperture ou Terminal à très petite ouverture ¹²Wan : Réseau étendu

¹³UTP : Unshielded twisted pair soit paire torsadée

TFE_ESIS_AS 2018

15

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

? Les serveurs

Sont des modèles HP ProLiant GEN8 64 Gb. Sur lequel est installé un système Windows server 2018. Sur lesquelles plusieurs applications et services y tournent. Beaucoup de services sont virtualisés à l'aide de l'hyperviseur VMware ESXI entre autres :

-Le serveur d'impression -Le serveur Citrix

-Le serveur d'application -Le serveur web

-Le serveur de messagerie -Le serveur de management -Le serveur DHCP¹⁴

-Le serveur active directory -Le contrôleur de domaine -Le serveur de température -Le serveur FTP¹⁵

N.B : Sur chaque site, il y a un serveur physique sur lequel sont installés plusieurs serveurs logiques et services.

Tableau 1.4 Inventaires des équipements					Equipements
modèles Types de machine	Nombres	Etats		Ordinateur laptop
Dell et HP Physique	70	Bon		Ordinateur desktop
Dell et HP Physique	130	Bon		Serveur
HP ProlianG8 Physique	5	Bon		Access Point
Cambium Uapro -	15	Bon		Access Point
Cambium UAE -	15	Bon		Routeur
Cisco physique	15	Bon		Antenne sectorielle
- physique	6	Bon		Serveur
- virtuel	10	Bon		Modem
- Physique	10	Bon

¹⁴DHCP : Dynamic host configuration Protocol ¹⁵FTP : File transfert protocole

TFE_ESIS_AS 2018

16

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

1.3.5. Critique du réseau existant

Tout travail de recherche est sujet d'une critique. Pendant trois mois passé au sein de l'entreprise Congo Equipment, nous avons pu énumérer les points forts ainsi que les points faibles de l'infrastructure réseau.

1.3.5.1. Points forts

· L'infrastructure réseau est bien équipée en matériel informatique et présente un très bon cadre pour l'apprentissage des débutants.

· Gain en terme de coût, car un seul serveur physique répond aux besoins des 10 serveurs physiques. Une virtualisation¹⁶ des serveurs reposant sur VMware ESXI est déployé pour la création des serveurs et applications critiques de l'infrastructure réseau.

· La présence d'un serveur physique sur chaque site sur lequel est virtualisé les services et applications.

· Très bonne couverture du signal wifi dans diffèrent département assuré par la présence des Access points offrant une couverture totale de la zone.

· Présence de VPN dans l'interconnexion intersites.

· Présence de VLAN¹⁷

· Présence d'un serveur de backup

· Audit de sécurité faite tout le six mois. Bref, bonne sécurité informatique.

· Présence des UPS¹⁸ pour le desktop en cas de coupure brusque d'électricité.

· Bonne sécurité d'accès réseau. Peut avoir une connexion internet wifi que l'équipement réseau dont l'adresse MAC¹⁹ est répertoriée dans les systèmes

· Adresses réseaux évolutives.

· Présence des applications des surveillances et des gestions.

· Présence d'une application client-serveur de mis à jour automatique.

¹⁶Virtualisation : Elle consiste à travers une couche logicielle appelée hyperviseur de créer sur un serveur physique des machines virtuelles qui utiliseront les ressources physiques du serveur avec leur propre OS

¹⁷VLAN : Virtual local area network

¹⁸UPS : Onduleur pour la sauvegarde d'électricité en cas de coupure

¹⁹Adresse MAC : Adresse physique d'un équipement pouvant être connecté sur le réseau

TFE_ESIS_AS 2018

17

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

1.3.5.2. Points à améliorer

· La virtualisation des services et applications occupe un grand espace mémoire du serveur physique et engendre des causes de lourdeur du système. Le mieux serait d'implémenter un système de virtualisation moins gourmand en ressource léger et facile à exécuter. Vu la multiplicité des services, applications virtualisés, il serait mieux de concevoir une solution de surveillance afin de palier à tout indisponibilité des services.

· La répétition des mêmes tâches par les administrateurs

· Vu la complexité du réseau manque d'autorisation d'installation de logiciel sur les terminaux

· Qualité de service moindre car internet dispose d'un taux de disponibilité inferieure. D'où augmentation de la bande passante, vu les besoins élevés des nombres des équipements connectés.

1.4. Spécifications des besoins

· La mise en place d'un système de virtualisation léger et moins gourmand en ressources qui est la conteneurisation [5]. Les multiples avantages qu'elle offre par rapport à la virtualisation traditionnelle n'exclus pas la surveillance de ce nouvel environnement au sein de parc informatique d'entreprise.

· La mise en place d'un système de suivi automatisé des conteneurs qui optimiserait la disponibilité et la performance afin de garantir un niveau de service maximal.

· Avoir un temps record d'installation et configuration permettant ainsi aux administrateurs systèmes de gagner en temps.

1.4.1. Les besoins fonctionnels

Les besoins fonctionnels expriment une action qui doit être mené

sur l'infrastructure à définir en réponse à une demande [6]

C'est les besoins exprimés par l'entreprise Congo Equipment et

voici les fonctionnalités qui en découlent numérotés pour une bonne

traçabilité :

f.1.1 L'environnement de sauvegarde des informations

f.1.2 Dispositif de prévention ou de signalisation

f.1.3 mécanisme d'identification des services

f.1.4 Mécanisme de collecte d'information

Pour plus, nous allons expliciter les fonctionnalités ci-haut :

TFE_ESIS_AS 2018

18

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

F.1.1 L'environnement de sauvegarde des informations :

Une bonne solution de surveillance et celle qui est dotée de fonctionnalité de sauvegarde. La sauvegarde qui consiste à conserver, enregistrer, les données, les évènements, les états de bon et de mauvais fonctionnement de nos conteneurs.

F.1.2 Dispositif de prévention ou de signalisation

Il serait mieux que notre solution, nous notifie de toutes activités sur l'environnement conteneurisé. La prévention consiste à prendre de disposition pour prévenir toute anomalie sur l'environnement à conteneur.

F.1.3 mécanisme d'identification des services

Identifier qui consiste à déterminer la nature sur l'état de conteneur, répertorier, faire une sorte d'inventaire de tous les conteneurs ainsi que les services qui y sont hébergés et cela sous forme représentatif avec graphique et métrique ou logs, pour avoir une vue générale de ce que nous surveillons.

F.1.4 mécanisme de collecte d'information

La détention de l'information globale, de l'infrastructure réseau reste un cheval de batail pour administrateurs systèmes. La collecte des informations consiste à récolter des informations via des agents installés sur le serveur ou l'environnement à conteneur qui poussent les données vers l'outil de monitoring.

1.4.2. Les besoins non fonctionnels

Etant donné que les besoins non fonctionnels font parties des

contraintes auxquelles les systèmes doit répondre. Nous signalons que

pour une solution parfaite, cela nécessiterait de tenir compte de critères

suivants :

? La simplicité d'utilisation

? La fiabilité

? La rapidité d'installation

? La performance

? Le coût

19

SPECIFICATION FONCTIONNELLE DU FUTUR SYSTEME

1.5. Conclusion Partielle

En résumé, il était question dans ce chapitre de faire une étude de l'existant de l'infrastructure réseau de l'entreprise Congo Equipment, laquelle nous a permis de critiquer, mais aussi d'identifier les points forts et points faibles de l'infra-réseau. Nous nous en sommes servi pour détecter les besoins cruciaux auxquelles sera exposée l'entreprise afin d'y apporter une solution, celle de surveiller des conteneurs dans un environnement conteneurisé.

Ainsi, pour une suite logique de notre travail après prélèvement, des besoins fonctionnels et non fonctionnels, place maintenant à la partie suivante qui consiste à la conception logique du futur système.

TFE_ESIS_AS 2018

TFE_ESIS_AS 2018

20

CONCEPTION DU SYSTEME

CHAPITRE 2 : CONCEPTION DU SYSTEME

2.1. Introduction

Après avoir identifié les besoins, après avoir fait une analyse de l'existant, lesquels nous a permis d'identifier les besoins fonctionnels et non fonctionnels ; place maintenant à la conception logique de notre système qui consiste à la mise en place d'un model répondant aux exigences faisant notre problématique sur lequel va s'appuyer notre solution physique.

Une étude comparative des outils sera faite afin de nous permettre de faire un choix logiciel relatif aux besoins et la méthodologie top down design choisie pour ce travail va nous permettre de bien saisir la complexité du problème et ainsi apporter une solution globale et satisfaisante.

2.2. Solution par rapport aux besoins

Dans ce point nous allons répondre aux exigences techniques, auxquelles se rapportent les fonctionnalités épinglées et numérotées ci-haut :

? Pour la fonctionnalité F.1.1 voici l'exigence technique y relatif nommé S.1.1 Base de données :

La sauvegarde des informations reste objective dans le choix d'un outil de monitoring car elle va nous permettre de stocker dans une base de données certains paramètres liés au fonctionnement du logiciel, mais aussi des informations venant de data sources diverses qui s'associent aux bases de données et dont ils y accèdent par des langages des requêtes. Ainsi, permettre de combiner les data sources au sein d'un unique tableau de bord, et proposer des graphiques à l'aide des données récupérées [7].

La base de données de série chronologique est une solution potentielle pour le stockage car elle a pour objectif de stocker de données des relevés de diverses sources, mais aussi des natures diverses et y produire des graphiques en utilisant ces données et présente de gros stockage de données [8].

? Pour la fonctionnalité F.1.2 voici l'exigence technique y relatif nommé S.1.2 l'alarme d'alerte :

La remontée d'alerte reste un point important que doit nécessairement avoir un outil de surveillance. L'alarme se définit comme étant une émission de message d'alerte sous forme sonore, visuelle ou encore par mail permettant à

21

TFE_ESIS_AS 2018

CONCEPTION LOGIQUE DU SYSTEME

L'administrateur Systèmes et réseaux d'être notifié des erreurs, des dysfonctionnements sur l'état d'objet, de service qu'il monitore au sein de son parc informatique [9]. Les alertes sont créées via des règles. Ces règles permettent en fonction d'une condition de lancer une alerte. Cette alerte est ensuite gérée par un service tiers, que possède l'outils de monitoring, Qui peut récupère l'alerte lancée puis en fonction des informations contenues dans l'alerte, notifier les bonnes personnes via différents moyens de notification pouvant être par mail, mais aussi par le biais d'outils de management [10].

? Pour la fonctionnalité F.1.3 voici l'exigence technique y relatif nommé S.1.3 les agents ou les crochets d'accès à distance, les logs ou les métriques :

Nous ne pouvons pas parler d'une solution de surveillance sans faire allusion à la récolte d'information. En ce qui concerne le monitoring des conteneurs deux méthodes se pointent à l'horizon dont le push et le pull:

? Push

Le système de push permet à l'administrateur d'envoyer de lui-même l'information au serveur, qui lui est en écoute et ne fait qu'attendre passivement les connexions.

? Pull

Le système de pull quant à lui fonctionne dans le sens inverse, c'est le serveur qui va récupérer l'information directement sur le client via un port ouvert. Le système de pull permet de mieux savoir si une cible est stoppée ou a cessé de fonctionner, car le pull tente une connexion avec la cible et peut donc savoir si la machine, l'objet est toujours en marche, ou que le service est arrêté [11].

? Pour la fonctionnalité F.1.4 voici l'exigence technique y relatif nommé S.1.4 le Dashboard :

Ceci est indispensable, car la surveillance nous permet de prendre de décision, d'avoir les informations d'état d'un service. Ainsi le Dashboard va aider l'administrateur systèmes et réseaux à afficher les données collecter sous forme de graphe. Notre choix se portera sur un Dashboard intégrant le capacity planning et le reporting.

TFE_ESIS_AS 2018

22

CONCEPTION DU SYSTEME

2.3. Conception générale





Figure 2.1 Architecture générale

2.3.1. Principe de fonctionnement

Le monitoring actuel est un monitoring basé sur la collecte des logs et des métriques. Cette collecte est réalisée grâce à des exportateurs qui sont des mécanismes de collette d'information sur chaque hôte et renvoie les informations collectés à un mécanisme de stockage d'information qui va les traiter et en suite les envoyer à un mécanisme de visualisation de graphique et à un mécanisme pouvant générer les alertes.

3.4. Conception logique détaillée

2.4.1. Du point de vu statique

La conception détaillée permet une étude approfondie de chaque sous système, au fur et à mesure que les détails augmentent, le niveau d'abstraction diminue et l'on voit que le système devient de plus en plus concret, c'est l'objet d'une étude détaillée [13].

TFE_ESIS_AS 2018

23

CONCEPTION DU SYSTEME

Concrètement, nous allons expliciter le cas d'utilisation pour la surveillance, ce qui devrait nous aider à comprendre les problèmes qui peuvent être résolus avec la surveillance. Nous allons découvrir les deux différentes manières d'utiliser des événements: les métriques, les journaux. En décomposant les métriques nous allons comprendre comment les données sont collectées, ingérées, stockées, traitées, alertées et visualisées.

2.4.1.1 Plateforme de surveillance

Place maintenant à la description de module de base de la

plateforme :

? Suivi conteneur :

Est un sous module du bloc plateforme de surveillance permettant de collecter les informations au niveau de chaque conteneur, les stocker et ainsi générer des graphiques et des alertes. Ce sous module est constitué essentiellement d'un serveur central de monitoring. En effet, la surveillance de conteneur est basée sur une architecture client-serveur²² permettant ainsi d'accéder aux informations du serveur sur n'importe quel hôte du réseau via page web.

? Conception architecture client serveur

Notons que l'application doit fonctionner dans un réseau. Certes l'accès doit donc être possible à partir de n'importe quel poste par le biais d'un navigateur web, d'où l'importance d'avoir un système de stockage de donnée épinglé parmi les besoins fonctionnels et de gestion de logs nous oblige de faire un choix logiciel ayant une base des données permettant de stocker les différents évènements.

Ainsi l'architecture à trois niveaux s'avère la mieux à adopter (aussi appelée architecture 3- tiers) caractérise les systèmes clients/serveurs dans lesquels le client demande une ressource et le serveur la lui fournit directement [14].



Figure 2.2 Architecture client-serveur [14]

20 Client-serveur : Architecture réseau dans laquelle les traitements sont repartis entre les clients qui demande les informations dont ils ont besoin au serveur

TFE_ESIS_AS 2018

24

CONCEPTION DU SYSTEME

· Serveur

Un serveur est une machine qui fournit de service à d'autre machine dans le réseau.

· Client

Est une machine qui envoie de demande de requête au serveur dans notre cas il s'agit de conteneur qui est un environnement permettant de virtualiser les services et applications.

· Le protocole de communication

Pour qu'il y ait échange d'information du serveur au client considéré ici comme étant les conteneurs. Il faut des règles de communications. Ainsi, nous allons expliciter quelque protocole de communication faisant partie intégrante de notre solution :

· HTTP :

HyperText Transfert Protocol. Grâce à ce protocole de communication les exportateurs vont s'en servir pour collecter les logs et les métriques et ainsi permettre via une page web d'accéder aux informations collectées.

· UDP :

User Datagramm Protocol. Grâce à ce Protocol de communication qui permet la transmission de donnée entre les serveurs de monitoring et le conteneur et cela via une adresse IP et un numéro de port.

· Adresse IP :

L'adresse IP est un identifiant d'hôte dans le réseau.

· Numéro de port

Est un identifiant de service ou de logiciel dans un réseau informatique.

2.4.1.2. Exportateur

Il s'agit d'un mécanisme de récolte d'information. Qui est basé

essentiellement de :

· Les métriques

Les métriques concernent des événements agrégées dans le temps. Ils comptent combien de fois chaque type d'événement arrive, combien de temps chaque type d'événement prend et combien de données était traité par le type d'événement. Les métriques se soucient peu du contexte de l'événement. Il permet de suivre des dizaines de



TFE_ESIS_AS 2018

25

CONCEPTION DU SYSTEME

milliers de types d'événements dans un seul service. Cela signifie que vous pouvez avoir un aperçu de la performance du code

Tout au long de votre application et cela grâce aux métriques [9].

· Les logs

Les journaux, parfois appelés journaux d'événements, sont tous liés au contexte des événements. Les journaux font le compromis opposé aux métriques. Ils ne font pas agrégation dans le temps. Cela les limites à suivre une cinquantaine à une centaine d'information par évènement.

· Conception de l'architecture de la collecte, du stockage et de la visualisation

Figure2.3 Architecture de la collecte, du stockage et de la visualisation [9] Nous explicitons :

· Collection

La collecte est le processus de conversion de l'état du système et des événements en métriques, qui peuvent ensuite être recueilli par le système de surveillance. La collection peut se produire de plusieurs manières:

· Complètement à l'intérieur d'un processus.

· En convertissant les données d'un autre processus dans un format utilisable, en extrayant des données du système de fichiers proc²¹.

· Par deux processus travaillant en synergie l'un pour capturer les événements et l'autre pour les convertir en métriques [9].

· Ingestion

L'ingestion prend les mesures de la collecte et les alimente dans la surveillance système. Cela peut être un processus en plusieurs étapes impliquant un système de file d'attente ou un simple transfert de données directement à partir de la collection. Ses à ce stade, il faut mentionner le débat «push vers pull». Tous les deux approches ont des avantages et des inconvénients. Nous ne pouvons pas couvrir l'étendue

TFE_ESIS_AS 2018

26

CONCEPTION DU SYSTEME

de ce débat dans ces pages, mais la version courte est que les deux approches peuvent être mises à l'échelle et les deux peuvent fonctionner dans un environnement conteneurisé [9].

2.4.1.3. Stockage

Le stockage est un module indispensable dans une solution de monitoring. Les bases de données de série chronologique seront d'une grande utilité car elles vont nous permettre de stocker des données provenant de plusieurs sources différentes mais aussi de nature diverse que devra utiliser la plateforme de surveillance pour générer des graphiques.

Une fois les données ingérées, elles sont généralement stockées. Il peut s'agir d'un stockage à court terme de seulement les derniers résultats, mais cela peut être n'importe quelle quantité de minutes, d'heures ou de jours de stockage de données. Une fois les données stockées vont au-delà de ce qui rentre facilement dans la mémoire machine, il y a des compromis opérationnels et de fiabilité à faire, et encore une fois, il y a des avantages et des inconvénients basés sur ce que l'organisation exige à partir de leurs données de surveillance [9].

2.4.1.4. Visualisation

La visualisation permet d'afficher les résultats collectés sous forme représentatif ou graphique, à ce niveau nous rencontrons les fonctionnalités suivantes de surveillance :

? Reporting :

Comme le nom l'indique, il s'agit d'un rapport d'état qui est un sous module dans la visualisation permettant de tenir des historiques de surveillance et pouvant représenter cela sous forme d'un tableau ou d'un histogramme [16].

? Capacity planning

Est un module qui nous permettra de planifier les taches mais aussi de prendre de décision sur nos conteneurs afin d'anticiper tout anomalie des services.

? Dashboard

Tableau de bord ou le tableau qui nous permettra de visualiser sous forme graphique les résultats.

2.4.1.5. Alarme d'alerte

Les données ne sont pas d'une grande utilité si nous ne faisons rien avec celà. La plupart des métriques collectées par le système offrent un moyen de faire des calculs sur les données ingérées, et généralement aussi, offrir un moyen d'alerter les humains de conditions anormales [9].

TFE_ESIS_AS 2018

27

CONCEPTION DU SYSTEME

· Règle d'alerte

Les règles d'alerte sont des critères conçus par l'administrateur système afin de déclencher une alerte, une fois que les conditions ou critères de préventions sont respectés.

· Type d'alerte :

· Alerte sonore : est une alerte émettant un son sous forme de bip.

· Outils de management : outils logiciel nous permettant de déclencher les alertes.

· Sms : Short Message System que pourrai recevoir l'administrateur.

Dans cette partie nous allons modéliser notre solution de surveillance et le langage utilisé pour la modélisation et bel est bien UML²² qui est un langage de modélisation d'objet. Il permet :

· De visualiser le système comme il est ou comme il devrait l'être.

· De valider le modèle vis-à-vis des clients

· De fournir un guide pour le choix du système [12]

2.4.2. Du point de vu dynamique

Le langage UML possède 9 diagrammes qui sont le diagramme de cas d'utilisation, le diagramme de classes, le diagramme d'état-transitions, diagramme d'activité, le diagramme de déploiement, le diagramme d'objet, le diagramme de séquence, le diagramme de collaboration et enfin le diagramme de composant. Pour modéliser notre solution, nous avons porté notre choix sur le diagramme de cas d'utilisation, représenté sur la figure ci-dessous :



Surveillance Conteneur

Figure 2.4 Diagramme de cas d'utilisation système

28

CONCEPTION DU SYSTEME

2.4.2.1. Scenario

? Authentication

L'administrateur s'authentifie sur la plateforme de

surveillance via son login et son mot de passe.

? Surveillance de conteneur

Une fois connecté sur la plateforme, l'administrateur peut maintenant surveiller les conteneurs.

? Alerte d'alarme

En cas de disfonctionnement ou d'activité anormale sur le système, une alarme est déclenchée afin de prévenir l'administrateur du réseau, l'alerte peut être des sms, ou un bip sonore.

? Visualisation graphique

Cette partie permettra à l'administrateur de visualiser aisément les graphiques décrivant l'état de chaque conteneur.

? Prendre décision

Enfin l'administrateur peut exercer une tâche palliative sur base de contenu des graphiques qu'il a visualisé.

Maintenant que nous avons une meilleure idée des types des systèmes de surveillance et les problèmes qu'ils seront en mesure de résoudre, Nous aurons certainement besoin de combiner les outils pour créer une solution complète de surveillance de conteneurs. C'est l'étude qui sera faite dans la partie suivante.

TFE_ESIS_AS 2018

29

CONCEPTION DU SYSTEME

2.5. Conception physique

2.5.1. Choix d'une solution de surveillance de conteneur

A part les besoins fonctionnels qui nous ont permis d'aboutir au choix d'une bonne solution, d'autre besoin s'ajoute qui sont des besoins non fonctionnels relatifs aux exigences du client ou du système qui sont :

· La disponibilité

· La fiabilité

· La rapidité

· La performance

· Le coût

L'ensemble de ce besoins nous permettra de faire une étude comparative des outils afin de choisir les meilleurs outils qui répondront mieux aux critères :

o PROMETHEUS

o CADVISOR

o GRAFANA

o DATADOG

2.5.1.1. Analyse et stockage métrique

2.5.1.1. A. Prometheus

Logiciel open source de monitoring de systèmes et d'alerte mis au point dans le laboratoire de Soundcloud²². La force de Prometheus réside dans sa capacité à ingérer les données provenant de très nombreuses sources, dont les conteneurs, y compris les informations provenant des autres logiciels de surveillance [15].

· Avantage:

· Le serveur Prometheus est simple à installer

· Le serveur est accessible via un navigateur

· Permet d'effectuer rapidement des statistiques et graphiques

· Langage de requête puissant

· Présence des fonctionnalités de notification

TFE_ESIS_AS 2018

²²Soundcloud : Entreprise de conception de logiciel

TFE_ESIS_AS 2018

30

CONCEPTION DU SYSTEME

Tableau 2.1 : Logiciel de surveillance Prometheus

Critères Pourcentages

La simplicité d'utilisation 100%

La fiabilité 80%

La rapidité d'installation 80%

La performance 80%

Le coût 10%

LA MOYENNE TROUVEE POUR PROMETHEUS EST DE 70%

Logiciel de surveillance Prometheus



La simplicité d'utilisation La fiabilité

La rapidité d'installation La performance

Le coût

Figure 2.5 Diagramme de Prometheus

2.5.1.2. Visualisation métriques

2.5.1.2. A. Grafana

Est une application open source dont le socle de base est écrit en langage Go²² ce qui permet de la rendre très performante s'appuie sur une base Mysql qui lui permet de stocker certains paramètres liés à son propre fonctionnement; embarque son propre serveur web, et utilise le format JSON pour présenter et formater l'intégralité des informations liées à un tableau de bord. L'affichage graphique des données est réalisé dynamiquement. Pour résumer, Grafana fournit l'intégralité des outils pour agréger,

organiser et analyser les données issues
de bases hétérogènes ou d'applicatifs différents avec une souplesse assez déconcertante [10].

GO : langage de programmation compilé développé par Google

TFE_ESIS_AS 2018

31

CONCEPTION DU SYSTEME

Tableau 2.2 : Logiciel de surveillance Grafana

Critères Pourcentages

La simplicité d'utilisation 80%

La fiabilité 50%

La rapidité d'installation 80%

La performance 80%

Le coût 10%

LA MOYENNE TROUVEE POUR GRAFANA EST DE 60%



La simplicité d'utilisation La fiabilité La rapidité d'installation La performance Le cout

Logiciel de surveillance Grafana

Figure 2.6 : Diagramme de Grafana

2.5.1.3. Collecte, traitement et visualisation des données

2.5.1.3. A. CAdvisor

Outil open source très récent développé par Google en go et basé sur lmfctfy (let me container that for you). CAdvisor lui-même est placé dans un conteneur Docker et délivre rapidement des informations utiles sur le comportement de base des conteneurs en exploitation supporte nativement Docker et permet de collecter, agréger, traiter et exporter des données quant à l'utilisation des ressources de chaque conteneur. Il garde ces données par conteneur et par machine et crée des diagrammes d'utilisation des ressources à l'aide de celles-ci.

? Avantage :

? simple à déployer et à utiliser

TFE_ESIS_AS 2018

32

CONCEPTION DU SYSTEME

? Inconvénient :

? Borné à suivre les conteneurs qui tournent sur le même hôte que lui.

? Ne convient pas à des déploiements multi-noeuds, ni pour suivre ou agréger les statistiques dans la durée.

Tableau 2.3 : Logiciel de surveillance CAdvisor

Critères Pourcentages

La simplicité d'utilisation 100%

La fiabilité 80%

La rapidité d'installation 80%

La performance 80%

Le coût 70%

LA MOYENNE TROUVEE POUR Cadvisor EST DE 82%



La simplicité d'utilisation La fiabilité La rapidité d'installation La performance Le coût

Logiciel de surveillance CAdvisor

Figure 2.7 Diagramme de CAdvisor

2.5.1.3. B. Datadog

Datadog est un service de monitoring. Puisqu'il agrège les données venant de différents hôtes et il dispose d'une architecture plug-in qui permet différentes intégrations. Mais il a un coût : 10 dollars par hôte. Mais ses fonctionnalités de reporting sont plus détaillées et plus flexibles. Ces informations, recueillies en temps réel, sont consolidées au sein de tableau de bord. Datadog permet aussi de partager et commenter des alertes et des événements via un module de collaboration de type chat [14].

TFE_ESIS_AS 2018

33

CONCEPTION DU SYSTEME

Tableau 2.4 Logiciel de surveillance Datadog

Critères Pourcentages

La simplicité d'utilisation 90%

La fiabilité 80%

La rapidité d'installation 80%

La performance 80%

Le coût 20%

LA MOYENNE TROUVEE POUR DATADOG EST DE 70%



La simplicité d'utilisation La fiabilité La rapidité d'installation La performance Le coût

Logiciel de surveillance Datadog

Figure 2.8 Diagramme de Datadog Tableau 2.5 Tableau décisionnelle

Outils		Pourcentages	Prometheus
70%		Grafana
60%		Datadog
70%		CAdvisor
82%

34

TFE_ESIS_AS 2018

CONCEPTION DU SYSTEME



Prometheus Grafana Datadog Cadvisor

Diagramme décisionnel

Figure 2.9 Diagramme décisionnel

Maintenant que nous avons fait une étude pour choisir les meilleurs outils de surveillance. Nous aurons à intégrer à la base Prometheus à Cadvisor pour créer une solution complète de surveillance des conteneurs.

2.6. Conclusion partielle

En définitif, dans ce chapitre, il était question de concevoir une solution logique qui répondrait aux exigences du système et du client. Trois grandes parties ont faits le point dans ce chapitre, il s'agit de la conception générale qui s'est penché sur l'étude fonctionnelle du système, la conception détaillé du système qui s'est penché sur l'étude approfondie de chaque sous système et enfin la conception physique qui a permis d'élire les meilleurs outils répondant à la problématique faisant notre solution.

A présent, l'heure est venu de détailler de donner, le plan d'installation de configuration de test ainsi que d'implémentation de l'outil élu. Prière de retrouver tout cela dans la partie suivante nommée conception du système.

TFE_ESIS_AS 2018

35

CHAPITRE 3 : SURVEILLANCE DE CONTENEUR DOCKER AVEC PROMETHEUS ET CADVISOR

3.1. Définition

Prometheus est une base des données de surveillance et de série chronologique développé par Sound cloud dans le cadre d'une évolution vers une architecture de micro service² pour réaliser de la surveillance Prometheus ne fonctionne pas seul, il est composé de quelques modules configurés séparément dont nous citons :

? Serveur Prometheus : C'est le serveur central, il contient la base de donnée de série chronologique et traite les informations collectées par les exportateurs et génère ainsi des graphes, et des alertes.

? Grafana : Est le visage de Prometheus c.à.d. lorsque Prometheus, rassemble, stock, et traite les informations, il le délègue à Grafana qui a la lourde tâche d'afficher les graphiques et les tableaux de bord, mais pour notre solution nous utiliserons Cadvisor car, il permet déjà de bien représenter les graphiques.

? Alertmanager : Grace à ce sous composant, il va permet à Prometheus de gérer les alertes et le faire passer à de différents canaux tel que le slack...

? Node-Exporter : Pour que Prometheus puisse analyser les données, il lui faut les exportateurs qui sont des outils crées par l''équipe de Prometheus ou la communauté afin de permettre à Prometheus de récupérer les données des cibles qu'il observe, en lieu et place de Node-exporter, nous allons utiliser cAdvisor qui intègre déjà la fonctionnalité des exportations des données pour la collecte de métrique des conteneurs [10].

3.2. Principe de fonctionnement de la solution Prometheus et Cadvisor

Prometheus pour son fonctionnement stock certains paramètres et les métriques collectées dans une base des données de série chronologique par le fait que les informations viennent de plusieurs sources de données. Le serveur Prometheus stock les informations sur 16 octets au total ; pour stocker une métrique, il fait appel à l'opération XOR²³ qui consiste à comparer l'ancienne et la nouvelle valeur, en fonction du résultat trouvé, le moteur stockera une représentation compressée de la différence constatée, en suite il pourra être interrogé au travers de son API pour la restitution de ces informations qui seront soit utilisées pour la définition d'alerte, soit pour générer des graphiques. Notons que les métriques et logs sont collectées via le job-exporter tel que cAdvisor ou Node-exporter. cAdvisor va analyser et exposer les informations recueillies telles que l'utilisation des ressources du processeur ou de la mémoire des conteneurs en exécution, plus précisément dans chaque conteneur, il conserve les paramètres d'isolation des ressources, l'utilisation des ressources historiques et les histogrammes d'utilisation complète des ressources.

23 XOR : Technique du OU exclusif

TFE_ESIS_AS 2018

36

SURVEILLANCE DE CONTENEUR DOCKER AVEC PROMETHEUS

Ces données sont exportées par conteneur et à l'échelle de la machine, mais elle ne fournit pas d'interface pour explorer les métriques de conteneur. Raison pour laquelle nous lui associons Prometheus [14].



Figure2.4 Principe de fonctionnement Prometheus et cAdvisor [14]

3.2.1. Architecture Prometheus



Figure2.5 Architecture Prometheus [10]

TFE_ESIS_AS 2018

37

SURVEILLANCE DE CONTENEUR DOCKER AVEC PROMETHEUS ET CADVISOR

3.2.2. Détails des différents blocs Prometheus :

· Prometheus serveur :

C'est le moteur permettant de stocker les métriques collectées.

· Jobs-exporter :

Il s'agit des agents dont se servira Prometheus pour collecter les différentes métriques.

· API-web UI :

Interface qui permettra de restituer des métriques à l'administrateur, ainsi pour notre solution nous associerons Grafana pour la visualisation des graphiques.

· Pushgateway :

Permet de créer un pont entre les services que l'on doit collecter et le serveur de monitoring Prometheus au cas où un service est à courte durée et que le serveur Prometheus n'a pas eu assez de temps pour récupérer les informations ce service, ainsi Pushgateway va nous permettre d'anticiper ce genre de cas.

· PromQL :

Est le langage de requête utilisé par Prometheus pour récupérer les données métriques et réaliser ainsi de traitement dessus [10].

· Les librairies :

Permettent au serveur Prometheus de monitorer directement les applications, en générant leur propre métrique au sein du code de l'application codée en GO, Java, python ou Ruby, ainsi les librairies peuvent monitorer n'importe quel données des services mis en place [10].

3.3. Avantages et inconvénients de Prometheus et CAdvisor

Prometheus est une base des données, ainsi sa façon d'afficher les graphiques n'est pas conviviale, de ce fait il faudra lui ajouter Grafana outil spécialisé offrant une bonne analyse et visualisation de graphique, mais pour notre solution nous allons nous contenter uniquement de graphique générer par cAdvisor.

La base des données Prometheus peut supporter des données de séries chronologique, il permet d'effectuer rapidement des statistiques et graphiques, il possède un langage de requête très flexible et très puissant ayant beaucoup de fonctionnalité.

TFE_ESIS_AS 2018

38

SURVEILLANCE DE CONTENEUR DOCKER AVEC PROMETHEUS

Pour accéder à la plateforme Prometheus il y a aucun système d'authentification mais avec Grafana, il existe une authentification ; compte tenue à cette remarque, cela lui réduit du point de vu sécuritaire, mais aussi Prometheus à lui seul a du mal à récolter les informations venant des conteneurs.

Notons que Prometheus nous accorde plus d'avantage que d'inconvénient, voici une liste de ses quelques avantages :

- La collection de séries chronologiques de Prometheus utilise un modèle tiré sur http

- Il a la découverte de service automatique des cibles et les fichiers de configuration peuvent être utilisés pour la même chose.

- Les séries temporelles sont supportées via une passerelle intermédiaire - Prometheus prend en charge plusieurs modes de graphique et de tableau de bord [17].

CAdvisor fournit aux administrateurs systèmes une compréhension de l'utilisation des ressources et des caractéristiques, des performances des conteneurs en cours d'exécution tournant dans leur environnement réseau. Mais cAdvisor ne peut collecter que les métriques conteneurs tournant sur la même machine que lui raison pour laquelle nous lui avoir associé Prometheus qui a la possibilité d'aller collecter même les conteneurs crée à distance sur un autre serveur hébergeant docker.

3.4. Aperçu de la technologie Docker

? C'est quoi docker :

Docker est un projet open source qui automatise le déploiement d'application dans des conteneurs logiciels virtuels, il peut être comparé à l'hyperviseur dans la virtualisation.

? C'est quoi une image conteneur docker :

Comparable à une image de machine virtuelle, elle est la base référentielle sur laquelle tourne le conteneur, c'est comme une image système sur laquelle est installé un service ou une application.

? C'est quoi conteneur :

Très simplement nous pouvons dire qu'un conteneur est une image conteneur en exécution, nous pouvons comparer ça à une application qui tourne sur une image système virtualisé, mais à la différence le conteneur partageant les ressources de la machine

TFE_ESIS_AS 2018

39

SURVEILLANCE DE CONTENEUR DOCKER AVEC PROMETHEUS

hôte et économise en terme d'installation des images systèmes sur le système d'exploitation hôte.

· C'est quoi un orchestrateur docker :

Est un processus qui consiste à gérer de manière intelligente et automne un système complexe ainsi plusieurs conteneurs qui y tournent.

· C'est quoi docker client :

Il s'agit de l'utilitaire grâce auquel on transmet les commandes de gestion des conteneurs, c'est grâce à lui que nous pouvons saisir de commande pour par exemple télécharger une image conteneur sur docker hub.

· C'est quoi docker daemon :

Il s'agit d'un élément capital qui permet de créer l'environnement docker sur un système d'exploitation propriétaire² ou du monde libre², et s'occupe de paramétrer et d'instancier le conteneur. Tant qu'il ne sera pas opérationnel, aucune commande de type docker, pourra être exécuté.

· C'est quoi docker compose :

Dans un environnement ou il y a divers conteneurs, docker compose va nous aider à faire communiquer, les conteneurs c.à.d. créer une liaison de communication inter conteneur pour un but bien spécifique.

· C'est quoi Docker Hub :

Il s'agit du site officiel de téléchargement de conteneur.

· C'est quoi Docker Registry :

Il s'agit tout simplement d'un dépôt d'images sur lequel nous nous qui serviront à instancier des conteneurs.

Après avoir eu un aperçu sur l'environnement docker, place maintenant à comment nous pensons procéder, planifier pour le déploiement de notre solution, bien avant cela, veuillez poursuivre la lecture pour vous imprégner sur la dite solution.

TFE_ESIS_AS 2018

40

SURVEILLANCE DE CONTENEUR DOCKER AVEC PROMETHEUS ET CADVISOR

3.5. PLAN D'INSTALLATION ET PROCEDURE DE CONFIGURATION

3.5.1. Prérequis

? Hyperviseur

? Vmware workstation ou Vmware Esxi

? Système d'exploitation Ubuntu 18.04 LTS (Bionic)

? Un compte utilisateur sur Docker Hub

? Un compte utilisateur sur Ubuntu non root

A présent, voici comment nous présentons le plan sommaire :

1. Mettre à jour le système et télécharger le package d'installation sur Ubuntu 18.04

2. Procédure d'installation de l'environnement docker

3. Création de conteneur

4. Installation docker compose

5. Installation outil de monitoring Prometheus

6. Configuration et intégration CAdvisor

3.5.1. Proc.inst.3.1. Pour mettre à jour le système et télécharger le package

Sur linux la mise à jour et l'installation de package est primordial sans lequel rien de ce que nous voulons faire sera d'exécution :

Toujours dans le terminal, en mode non privilégié nous saisissons :

Figure 3.1 Téléchargement Package

Une fois fini, nous pouvons maintenant passer à la 2^ème procédure d'installation nommée proc.inst.3.2.

3.5.2. Proc.inst.3.2. Installation de l'environnement docker

Ici nous installerons le serveur docker version 18.06.1-ce contenant le docker daemon, lequel après installation apportera les fonctionnalités docker sur le système. Notons que le client docker s'installe directement sur le noyau du système d'exploitation sur linux, il permet d'interroger le docker daemon, en ce qui concerne la création de conteneur et tout activité que nous pourrons faire sur le conteneur, en bref nous pourrons dire que c'est la partie qui donne des instructions au conteneur.

Voici comment nous allons procéder:

Nous devons nous rassurer que nous sommes en mesure de télécharger sur la plateforme en ligne de docker. De ce fait ; nous allons lancer le terminal en mode non privilégié nous allons saisir la commande suivante :

41

TFE_ESIS_AS 2018

SURVEILLANCE DE CONTENEUR DOCKER AVEC PROMETHEUS ET CADVISOR

Et pour finir, pour voir si le service docker fonctionne, nous saisirons dans le terminal la commande :

? sudo systemctl status docker

Une fois fini et bien exécuté, nous pouvons passer à la 3^ème procédure d'installation nommée proc.inst.3.3.

3.5.3. Proc.inst.3.3.Creation de conteneur

Pour créer le conteneur nous allons nous servir du fichier dockerfile dans lequel nous allons saisir un script de création de conteneur. Mais en ce qui concerne notre solution nous allons télécharger les images conteneurs directement sur la plateforme officielle de téléchargement d'image docker nommé Docker Hub pour télécharger les images docker nécessaire pouvant faire usage de notre solution de monitoring. Toujours dans le terminal en mode privilégié, nous allons saisir la commande de recherche de conteneur:

? docker search nom_image

Par exemple : #docker search ubuntu pour une image de système d'exploitation Ubuntu. Une fois l'image trouvé, nous pouvons maintenant l'installer en faisant :

$docker pull ubuntu

Et une fois fini, nous pouvons exécuter l'image en saisissant sur le terminal : $docker run -i -t ubuntu

Voilà, à présent nous passons à la 4^ème procédure nommée proc.inst.3.4.

3.5.4. Proc.inst.3.4. Pour l'installation de docker compose

Docker compose va nous permettre de créer une relation de communication entre divers conteneurs. Dans le cas où nous aimerons que des conteneurs ayant divers services communiquent pour un but donné.

Nous sommes toujours sur le terminal, nous allons saisir la commande suivante pour le téléchargement à jour de docker compose:



Figure 3.3 Téléchargement docker compose

Maintenant nous allons donner à docker compose de privilège nécessaire en saisissant la commande:

42

TFE_ESIS_AS 2018

SURVEILLANCE DE CONTENEUR DOCKER AVEC PROMETHEUS ET CADVISOR

_$sudo chmod +x _/usr_/local_/bin_/dockercom_po

Après que l'installation ait pris fin et bien passé, nous allons vérifier la version avec la commande :

? $docker-compose -version

Tout est enfin réunit pour que nous installions notre solution de monitoring. Passons maintenant à la procédure nommée proc.inst.3.5.

3.5.5. Proc.inst.3.5. Installation outils de monitoring Prometheus

Toujours dans le terminal en mode non privilègé, nous allons commencer par télécharger et installer Prometheus, en saisissant la commande :

$ docker run --name prometheus -d -p 127.0.0.1:9090:9090 quay.io/prometheus/prometheus

Une fois finie nous allons démarrer et activer Prometheus : $ docker start ID_conteneur ou nom de conteneur

Maintenant nous pouvons accéder à Prometheus via le navigateur web, en saisissant le lien suivant:

? http://localhost:9090/Status

3.5.6. Proc.inst.3.6. Configuration et intégration CAdvisor

Pour intégrer CAdvisor dans Prometheus, nous nous devons d'accéder au fichier prometheus.yml² afin d'y placer la configuration suivante :

scrape_configs:

- job_name: cadvisor scrape_interval: 5s static_configs:

- targets:

- cadvisor: 8080

²⁴YML: Yet another markup language

43

TFE_ESIS_AS 2018

SURVEILLANCE DE CONTENEUR DOCKER AVEC PROMETHEUS ET CADVISOR

3.6. Plan et procédure de test

3.6.1. Test Proc.inst.3.1

Voici le test relatif à la procédure proc.inst.3.1 et les résultats relatifs, nous saisirons la commande suivante pour accéder aux résultats :

? $ubuntu-support-status Voici le résultat :



Figure 3.4 Résultat test Proc.inst.3.1

3.6.2. Test Proc.inst.3.2

Nous allons saisir la commande de test suivante : ? $docker

Voici le résultat :



44

TFE_ESIS_AS 2018

SURVEILLANCE DE CONTENEUR DOCKER AVEC PROMETHEUS ET CADVISOR Figure 3.5 Résultat test Procinst32

3.6.3. Test Proc.inst.3.3

Pour voir si une image docker a été bien téléchargée ou bien créée nous allons

saisir la commande suivante, pour voir le dernier conteneur téléchargé:

? $docker ps -l

Voici la sortie relative :



Figure 3.6 Résultat test Proc.inst.3.3

3.6.4. Test Proc.inst.3.4

Si l'installation de docker compose s'est bien déroulée, voici la commande de

test :

? $docker-compose -version Sortie résultat relatif :

Output

docker-compose version 1.21.2, build a133471

3.6.5. Test Proc.inst.3.5

Ce test consiste à vérifier, si l'outil de monitoring Prometheus est bel et bien fonctionnel. Nous allons saisir sur le navigateur le lien suivant : http://localhost:9090/Status

3.6.6. Test Proc.inst.3.6

Ce test consistera, à voir si Cadvisor est bel et bien fonctionnel. Nous allons saisir sur le navigateur le lien suivant : http://localhost:8080/

45

SURVEILLANCE DE CONTENEUR DOCKER AVEC PROMETHEUS ET CADVISOR

3.7. Plan d'implémentation

1. Installation de prérequis

2. Mise à jour du système et téléchargement package

3. Installation et configuration environnement docker

4. Installation et configuration docker compose

5. Installation outil de monitoring Prometheus

6. Configuration et intégration CAdvisor dans Prometheus

3.7.1. Diagramme de Gantt



Figure 3.7 Diagramme de Gantt

TFE_ESIS_AS 2018

TFE_ESIS_AS 2018

46

SURVEILLANCE DE CONTENEUR DOCKER AVEC PROMETHEUS ET CADVISOR

3.7.2. Diagramme de Pert



Figure 3.8 Diagramme de Pert

N.B : Notre solution parle sur le monitoring de conteneur docker. Ainsi, pour implémenter notre solution, cela nécessiterai la présence d'un environnement docker et des conteneurs en exécution raison pour laquelle nous montrons d'une manière simplifié les différentes étapes d'installation et de configuration de l'environnement docker. Notre implémentation sera consacrée uniquement à la solution de monitoring Prometheus intégrant, Alertmanager, et CAdvisor pour répondre aux besoins épinglé dans la problématique.

3.8. Conclusion partielle

Dans ce chapitre, il a été question de présenter la solution monitoring avec l'outil Prometheus pouvant être déployé pour la surveillance de conteneur tournant dans un environnement docker. De ce fait ; une étude a été faite sur l'outil Prometheus afin d'appréhender son fonctionnement basique. Mais aussi, un aperçu sur la technologie docker a été d'usage dans ce chapitre afin de nous permettre de bien implémenter notre solution, ceci sera d'application dans le chapitre suivant nommé implémentation.

TFE_ESIS_AS 2018

47

CHAPITRE 4 : IMPLEMENTATION DE LA SOLUTION

4.1. Introduction

Dans cette partie nous allons concevoir la solution de monitoring des conteneurs docker. Car l'une des tâches que se doit l'administrateur système est celle d'être informé en temps réel de tout ce qui se passe dans son parc informatique afin de palier à l'indisponibilité des services. Ici, vous trouverez une solution de monitoring ayant fait preuve d'une étude pouvant aider tout administrateur qui aurait à la longue besoin de la surveillance des conteneurs dans son parc informatique. Sans plus tarder, voici comment nous présentons le plan de sommaire :

Plan de sommaire :

1. Vérification et installation prérequis docker

· Vérification type système d'exploitation du serveur hôte

· Vérification de l'environnement docker

· Vérification de docker-compose

· Création et téléchargement image conteneur

2. Téléchargement outil de monitoring

· Téléchargement Prometheus

· Téléchargement CAdvisor

3. Installation outil de monitoring

· Installation Prometheus

· Installation cAdvisor

4. Configuration et intégration cAdvisor dans Prometheus

· Intégration CAdvisor

5. Visualisation résultats de monitoring

· Représentation de la collecte et stockage métriques des conteneurs via Prometheus

· Visualisation proprement dite des résultats de monitoring

TFE_ESIS_AS 2018

48

IMPLEMENTATION DE LA SOLUTION

4.2. Vérification et installation prérequis docker

? Vérification type système d'exploitation du serveur hôte

Notre solution tourne sur un système d'exploitation linux. Nous avons porté notre choix sur Ubuntu 18.04 LTS Bionic ayant comme caractéristique ce qui suit sur la figure suivante :



Figure 4.1 Caractéristique système d'exploitation hôte

? Vérification de l'environnement docker

Nous devons premièrement nous rassurer que l'environnement docker est belle est bien existant sur notre système hôte, comme nous pouvons le voir sur la capture suivante :



Figure 4.2 Vérification environnement docker

? Vérification de docker-compose

Nous devons nous rassurer que docker compose est belle est bien fonctionnel, sans cela la solution monitoring ne serait mis au point, cette étape est liée à la procédure Proc.test.3.2:



Figure 4.3 Vérification docker-compose

TFE_ESIS_AS 2018

49

IMPLEMENTATION DE LA SOLUTION

? Création et téléchargement image conteneur

Nous allons télécharger les images conteneurs sur lesquels s'exécutent les conteneurs. (Proc.test.3.3)

Premièrement, nous allons faire une recherche des images conteneurs, dans le site officiel docker hub ou les membres de la communauté docker upload des images des conteneurs. Nous saisirons la commande suivante de recherche d'une image conteneur : $docker search nom_application par exemple : $docker search hello-world

Deuxièmement, nous allons télécharger l'image conteneur docker. Nous saisirons la commande suivante de téléchargement : $docker pull nom_application par exemple : $docker pull hello-world

Troisièmement, nous allons lancer les conteneurs. Nous saisirons la commande : $docker run -i -t nom_application par exemple : $docker run -i -t hello-world

A présent voici comment, nous présentons les résultats de téléchargement des images conteneurs :



Figure 4.4 Résultat téléchargement image conteneur réussi



Figure 4.5 Résultat exécution conteneur

TFE_ESIS_AS 2018

50

IMPLEMENTATION DE LA SOLUTION

4.3. Téléchargement outils de monitoring

Notons que nos outils de monitoring sont tous des applications conteneurisées dans un conteneur docker. Voici comment nous avons pu télécharger les images conteneurs :

? Téléchargement Prometheus



Figure 4.6 Téléchargement Prometheus

? Téléchargement CAdvisor



Figure 4.7 Téléchargement CAdvisor

4.3. Installation outils de monitoring

Après avoir téléchargé nos images conteneurs de monitoring, place maintenant à l'installation de nos outils :

? Installation Prometheus(Proc.inst.3.5)

Voici la commande relative à l'installation de Prometheus, représenté sur la figure ci-dessous :



Figure 4.8 Installation Prometheus

TFE_ESIS_AS 2018

51

IMPLEMENTATION DE LA SOLUTION

Une fois Prometheus installé, nous pouvons maintenant vérifier sur quelle adresse IP et quel numéro de port pouvons-nous lancer Prometheus sur un navigateur web. La figure ci-après nous le démontre d'avantage :



Figure 4.9 Vérification du lien

Une fois fait, nous pouvons maintenant lancer Prometheus sur le navigateur en saisissant le lien http://localhost:9090



Figure 4.10 Lancement Prometheus

? Installation CAdvisor

Voici la commande relative à l'installation de CAdvisor, représenté sur la figure ci-dessous :



Figure 4.11 Installation CAdvisor

Une fois CAdvisor installé, nous pouvons maintenant vérifier sur quelle adresse IP et quel numéro de port pouvons-nous lancer CAdvisor sur un navigateur web. Nous saisirons la commande suivante : $nestat -pltn qui va nous lister l'adresse ainsi que le port d'accès à CAdvisor, dans notre cas il s'agit de 172.0.0.1 :8080/

TFE_ESIS_AS 2018

52

IMPLEMENTATION DE LA SOLUTION

Une fois fait, nous pouvons maintenant lancer CAdvisor sur le navigateur en saisissant le lien http://localhost:8080



Figure 4.12 Lancement CAdvisor

4.5. Configuration et intégration de CAdvisor dans Prometheus (Proc.inst.3.6)

Cette étape a pour prérequis docker-compose. De ce fait ; nous allons accéder au fichier prometheus.yml situé à l'emplacement suivant :



Figure 4.13 Accès fichier Prometheus

Nous y accédons en saisissant :$nano Prometheus.yml une fois à l'intérieur du fichier

nous allons ajouter les configurations suivantes qui vont signifier à Prometheus que

désormais, tu travailleras en synchronisation avec CAdvisor. Voici les configurations qui

seront saisies dans le fichier Prometheus.yml:

scrape_configs:

- job_name: cadvisor

scrape_interval: 5s

static_configs:

- targets:

- cadvisor: 8080

Une fois fait, nous allons créer dans le même dossier, un fichier que nous allons nommer

docker compose.yml dans lequel nous saisirons les configurations suivantes :

services:

prometheus:

image: prom/prometheus:latest

container_name: prometheus

ports:

- 9090:9090

command:

- --config.file=/etc/prometheus/prometheus.yml

volumes:

- ./prometheus.yml:/etc/prometheus/prometheus.yml:ro

depends_on:

TFE_ESIS_AS 2018

53

IMPLEMENTATION DE LA SOLUTION

- cadvisor cadvisor: image: google/cadvisor:latest container_name: cadvisor ports:

- 8080:8080

volumes:

- /:/rootfs:ro

- /var/run:/var/run:rw

- /sys:/sys:ro

- /var/lib/docker/:/var/lib/docker:ro

depends_on:

- redis

redis:

image: redis:latest

container_name: redis

ports:

- 6379:6379

Voici à présent les captures relatives :



Figure 4.15 Configuration fichier Prometheus

54

IMPLEMENTATION DE LA SOLUTION



Figure 4.16 Configuration fichier Docker-compose

Une fois fait, nous allons activer docker compose avec la commande suivante : $docker-compose up

Voici la capture relative aux résultats :

TFE_ESIS_AS 2018

Figure 4.17 Résultat d'exécution Docker-compose

55

IMPLEMENTATION DE LA SOLUTION

Puis nous allons tester pour voir si Prometheus et cAdvisor sont up, en saisissant la commande suivante : $docker ps

Voici la capture relative aux résultats :



Figure 4.18 Résultat d'exécution Prometheus et cAdvisor

4.6. Visualisation résultats de monitoring

? Représentation de la collecte et stockage métriques via Prometheus



Figure 4.19 Image collecte et stockage métriques

TFE_ESIS_AS 2018

56

IMPLEMENTATION DE LA SOLUTION

? Visualisation proprement dite des résultats de monitoring

Dans cette étape, nous allons présenter quelques captures des informations de monitoring que met à notre disposition CAdvisor, relatif aux conteneurs tournant sur notre serveur :





Figure 4.20 Conteneurs en exécution



Figure 4.21 Images conteneurs disponible sur le serveur



TFE_ESIS_AS 2018

Figure 4.22 Information sur l'hôte docker



Figure 4.23 Information sur conteneur Ubuntu en exécution



Figure 4.24 Utilisation mémoire conteneur Ubuntu

57

IMPLEMENTATION DE LA SOLUTION



Figure 4.24 Processus en exécution conteneur Ubuntu



Figure 4.25 Utilisation processeur conteneur Ubuntu

TFE_ESIS_AS 2018

TFE_ESIS_AS 2018

58

IMPLEMENTATION DE LA SOLUTION

4.7. Conclusion Partielle

4.7.1. Evaluation des besoins

4.7.1.1. Besoin fonctionnels

Après un cycle de conception, il est normal de se poser la question de savoir ; est-ce que le problème est-il résolu ? Raison pour laquelle nous avons pensé à évaluer les besoins fonctionnels ainsi que les besoins non fonctionnels pour vérifier, si la solution a bel et bien répondu à nos critères d'exigence.

Tableau 4.1 : Besoins fonctionnels

Besoins fonctionnels	Identifiant	Évaluation en %
Environnement sauvegarde informations	F.1.1	100 %
Dispositif de prévention ou signalisation	F.1.2	0%
Mécanisme de visualisation des services	F.1.3	100%
Mécanisme de collecte d'information	F.1.4	1000%



120

100

40

80

60

20

0

F.1.1 F.1.2 F.1.3 F.1.4

Evaluation besoins fonctionnels

Evaluation en %

Figure 4.26 Evaluation des besoins fonctionnels
Tableau 4.2 : Besoins non fonctionnels

Besoins fonctionnels Identifiant Evaluation en %

La simplicité d'utilisation C.1.1 100%

La fiabilité C.1.2 95%

La rapidité d'installation C.1.3 97%

La performance C.1.4 90%

TFE_ESIS_AS 2018

59

IMPLEMENTATION DE LA SOLUTION

Le coût C.1.5 90%



102

100

98

96

94

92

90

88

86

84

C.1.1 C.1.2 C.1.3 C.1.4 C.1.5

Evaluation besoins non fonctionnels

Evaluation en %

Figure 4.27 Evaluation des besoins non fonctionnels

En définitif, nous avons dans ce chapitre conçu notre solution de monitoring d'un environnement conteneurisé docker tout en respectant les exigences citées ci-haut dont a

fait notre étude, afin de présenter une solution qui répondrait aux attentes du client.

TFE_ESIS_AS 2018

60

CONCLUSION GENERALE

Somme toute ; il s'avère important de noter que ce dit travail intitulé : « Conception d'une solution de monitoring des conteneurs docker » marque les multiples compétences et connaissances acquises tout au long de notre parcours académique à l'Ecole Supérieure d'Informatique Salama, dont le domaine faisant objet de notre recherche est l'administration systèmes et réseaux. En tant qu'ingénieur technicien dans ce domaine nous nous devons de donner solution aux différents problèmes que nous pourrons rencontrer au sein de notre société relative à ce cas d'application.

En ce qui concerne notre sujet, il a été question de concevoir une solution de surveillance des conteneurs docker, laquelle hébergerait des services critiques d'un système informatique, de ce fait , l'une de tache d'un administrateur système est celui de veiller à la disponibilité des services ; ainsi notre solution de surveillance, de récolte d'information en temps réel, de notification par rapport à l'utilisation des ressources dans un environnement à conteneur vient palier à la dite problématique.

A présent, veuillons faire les points sur les quatre chapitres ayant faits notre étude d'ingénierie système qui consistait à saisir la complexité du problème en le décomposant en de sous problème modulaire, afin de réduire le problème de son niveau d'abstraction le plus élevé au niveau d'abstraction le plus base tout en utilisant le cheminement proposé par la méthode top down design.

Dans le premier chapitre, il a été question de prélever les spécifications fonctionnelles du système tout en épinglant les besoins fonctionnels, les besoins non fonctionnels ainsi que les points forts et les points faibles du système. En bref, il s'agissait de faire une critique de l'existant et de prélèvement d'information. Le second chapitre fut caractérisé par une étude de conception système, lequel nous a permis de bien élire la technologie qui ferait notre solution, ceci a ouvert directement une entrée au troisième chapitre dans lequel nous avons parlé en long et en large sur la dite solution. Cela, nous a permis de chuter avec le quatrième chapitre relatif à l'implémentation de la solution.

Puisqu'un travail scientifique est une oeuvre humaine ayant des imperfections, nous admettons toutes remarques et suggestions pouvant améliorer notre solution ayant faite le point dans ce travail.

TFE_ESIS_AS 2018

61

BIBLIOGRAPHIE

[1] « www.memoireonline.com/01/14/8531/mise-au-point-d'une-strategie-de-qualité-

service/. » [En ligne]

[2] « www.gatoux.com/.../leplan-dadressage/. » [En ligne]

[3] D. de la Drôme, Plan de nommage des documents et plan de classement, octobre 2012

[4] I. Mukeya, Gestion des configurations d'un Datacenter basée sur puppet et foreman, septembre 2016

[5] S. Numbi, la mise en place d'un système de déploiement des conteneurs dans une infrastructure IT en vue d'optimiser l'utilisation des applications du monde libre, sur une plateforme Windows, septembre 2016

[6] S. Numbi, la mise en place d'un système de déploiement des conteneurs dans une infrastructure IT en vue d'optimiser l'utilisation des applications du monde libre, sur une plateforme Windows, septembre 2016

[7] J. Camoin, Optimiser et communiquer grace à la supervision, Aix-Marseille université DOSI-Pôle Système

[8] « www.gurau-audibert.hd.free.fr/josdblog/2015/01/bases-de-données-de-series-
chronologique./ »

[9] Alex Williams, Benjamin Ball, Monitoring and management with docker and containers

[10] C. Thomas, Supervision dans des infrastructures élastiques de production, 27 mars 2017

[11] « www.enst-bretagne.fr/. »

[13] H. Kalonji, Cours de maintenance réseaux, ESIS 2015

[14] « www.docker.io/. »

[15] M. Cros, 6 outils de suivi des conteneurs concurrent à docker, Septembre 2015

[16] T. Ntumba, Etude et mise en place d'une plateforme de supervision hautement disponible, Esis 2014

[17] « www.prometheus.io/. »