WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception d'une solution de monitoring des conteneurs docker.


par Jonathan Mukendi
Ecole Supérieure d'Informatique Salama - Diplôme d’ingénieur technicien en réseaux 2018
  

Disponible en mode multipage

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

    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 VMs1 migrent vers la conteneurisation vue les multiples avantages qu'elle offre. La conteneurisation2 qui consiste à créer des conteneurs3 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.

    1VMs : Machine virtuelle

    2Conteneurisation : procédée qui consiste à virtualiser un service mais via conteneur 3Conteneurs : 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 Dashboard4 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 graphiques5, métriques6 et logs7, reporting8 et capacity planning9, 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

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

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

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

    9Capacity 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 VPN10 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

    10VPN : 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 Vsat11 à une autre. Les liaisons WAN12 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 UTP13 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.

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

    13UTP : 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 DHCP14

    -Le serveur active directory -Le contrôleur de domaine -Le serveur de température -Le serveur FTP15

    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

     

    14DHCP : Dynamic host configuration Protocol 15FTP : 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 virtualisation16 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 VLAN17

    · Présence d'un serveur de backup

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

    · Présence des UPS18 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 MAC19 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.

    16Virtualisation : 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

    17VLAN : Virtual local area network

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

    19Adresse 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-serveur22 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 proc21.

    · 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 UML22 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 Soundcloud22. 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

    22Soundcloud : 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 Go22 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 service2 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 XOR23 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étaire2 ou du monde libre2, 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/dockercompo

    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.yml2 afin d'y placer la configuration suivante :

    scrape_configs:

    - job_name: cadvisor scrape_interval: 5s static_configs:

    - targets:

    - cadvisor: 8080

    24YML: 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/. »






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Je ne pense pas qu'un écrivain puisse avoir de profondes assises s'il n'a pas ressenti avec amertume les injustices de la société ou il vit"   Thomas Lanier dit Tennessie Williams