PFE Master INPTIC Anis Final

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR MINISTERE DE LA POSTE ET DES

ET DE LA RECHERCHE SCIENTIFIQUE TELECOMMUNICATIONS
ECOLE NATIONALE SUPERIEURE DES TECHNOLOGIES DE L’INFORMATION ET

DE LA COMMUNICATION ET DE LA POSTE (ENSTICP)
Domaine : Sciences et Technologies

Filière : Technologies
Mémoire de Projet de Fin d’Etudes pour l’obtention du
Diplôme de Master
Spécialité : TIC et Management
Thème
Monitoring d'une infrastructure

conteneurisée avec Prometheus,
Grafana et Alertmanage
Etudié et réalisé par : Proposé et dirigé par :
HECHAICHI Anis S. FEKIR
OUALI Moustafa A. BARKATI
Soutenu, le : …/…/2022, devant le jury composé de :
Mme. ALLAM MAA ENSTICP Président

M. TALEB Formateur ENSTICP Examinateur
Mme BENNOUR MCB ENSTICP Examinateur
M. FEKIR MAA ENSTICP Encadreur
M. BARKATI MCB ENSTICP Co-encadreur
Année Universitaire : 2021/2022

Dédicaces
“ A la lumière de mes jours, la source de mes efforts, la flamme de

mon cœur, ma vie et mon bonheur, maman que j’adore.
A mon exemple éternel, mon soutien moral et source de joie et de
bonheur, celui qui s’est toujours sacrifié pour me voir réussir, que
Dieu te garde, à toi mon père.
A mes chères sœurs frères Sara, Khaoula, Boshra, Mohamed,
Adem et toute ma famille qui n’ont cessé de m’encourager et me
guider afin d’emprunter le bon chemin.
A mon cher binôme Anis et sa famille.
Comme je le dédie à toute la promo 2017/2018 que j’avais de la
chance d’être Parmi eux. A tous mes amis spécialement Ouail,
Mehdi, Houssam, Oussama, Imad.
A toutes ces personnes que j’ai senties redoutable de leur dédier ce
modeste travail en termes d’amour et de profonde gratitude.
”
- Moustafa
I
“ C’est avec une profonde gratitude et des mots sincères, que je
dédie ce modeste travail de fin de cycle à :
Mes chers parents ; qui ont sacrifié leur vie pour ma réussite. Que
Dieu leur prête bonheur et longue vie.
Mon binôme : Moustafa
Tous mes amis les plus sincères sur tout l’équipe master ; tous ceux
que j’aime et qui m’aiment
”
- Anis
II
Remerciements
M. Abdellah Seddik TAHAR DJEBBAR M. Abdellah BARKATI M. Souhil FEKIR Pour le temps
qu’il nous a consacré et ses conseils avisés ainsi que ses remarques pertinentes et très précieuses.
Nous adressons nos sincères remerciements à mes collegues Anis, Youcef, Dhiya, Hmida, Zaki et
Basset pour leur aide dans le projet. Nos remerciements vont enfin à toute Personne qui a contribué
de près ou de loin à l’élaboration de ce travail.
Nous tenons à remercier en premier lieu DIEU tout puissant qui nous a accordé la
volonté et le courage pour mener à bien ce projet. M. Abdellah Seddik TAHAR
DJEBBAR
M. Abdellah BARKATI
M. Souhil FEKIR
Pour le temps qu’il nous a consacré et ses conseils avisés ainsi que ses remarques
pertinentes et très précieuses.
Nous adressons nos sincères remerciements à mes collegues Anis, Youcef, Dhiya,
Hmida, Zaki et Basset pour leur aide dans le projet.
Nos remerciements vont enfin à toute Personne qui a contribué de près ou de loin à
l’élaboration de ce travail.
Anis Moustafa
III
Table des matières
Dédicaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I
Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III
Liste des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII
Liste des tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX
Liste des abréviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X
Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
I Généralités sur les microservices et la conteneurisation . . . . . . . . . . . . . . . . . 3

I.1 Microservices : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I.1.1 Définition : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I.1.2 Avantages de l’approche microservices . . . . . . . . . . . . . . . . . . . . 4
I.1.3 Inconvénients de l’approche microservices . . . . . . . . . . . . . . . . . . 5
I.2 Virtualisation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
I.3 Conteneurisation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
I.3.1 Définition : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
I.3.2 Avantages des conteneurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
I.3.3 Cycle de vie d’un conteneur . . . . . . . . . . . . . . . . . . . . . . . . . . 8
I.3.4 L’orchestration de conteneurs . . . . . . . . . . . . . . . . . . . . . . . . . 9
I.3.5 Le rôle de l’orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
I.3.6 Conteneur vs VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
II Docker et Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
II.1 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
II.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
II.1.2 Architecture Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
IV
Table des matières
II.1.3 Conteneur Docker : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

II.2 Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
II.2.1 Définition : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
II.2.2 L’architecture du Kubernetes : . . . . . . . . . . . . . . . . . . . . . . . . . 15
II.2.3 Composants du nœud maître . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II.2.4 Composants du nœud travailleur . . . . . . . . . . . . . . . . . . . . . . . . 18
II.2.5 Principales fonctionnalités de Kubernetes . . . . . . . . . . . . . . . . . . . 19
III Monitoring et ces outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

III.1 Le monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
III.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
III.1.2 Monitoring de Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
III.2 Prometheus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
III.2.1 Définition : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
III.2.2 L’architecture de Prometheus . . . . . . . . . . . . . . . . . . . . . . . . . . 23
III.2.3 Base de données de séries chronologiques (TSDB) . . . . . . . . . . . . . . 25
III.2.4 Les métriques de Prometheus . . . . . . . . . . . . . . . . . . . . . . . . . 25
III.2.5 Les exportateurs de Prometheus . . . . . . . . . . . . . . . . . . . . . . . . 25
III.3 Grafana : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
IV Implémentation de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
IV.1 Scénario de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
IV.2 Implémentation de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
IV.2.1 Mise en place du cluster kubernetes . . . . . . . . . . . . . . . . . . . . . . 30
IV.2.2 Versions utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
IV.3 Test de solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
V Partie Manageriale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
V.1 Présentation du l’organisme d’accueille (ENSTICP) . . . . . . . . . . . . . . . . . . 41
V.2 Planification de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
V.3 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
V.4 Impact réel du projet sur le fonctionnement de l’entreprise . . . . . . . . . . . . . . 43
V.5 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
V
Table des matières
Références bibliographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I
Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
VI
Table des figures
I.1 Architecture microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

I.2 L’architecture du virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
I.3 Cycle de vie du conteneur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
II.1 Architecture docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

II.2 Architecture de Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
III.1 L’architecture de Prometheus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

III.2 Tableau de bord Grafana pour l’exportateur Prometheus Node . . . . . . . . . . . . 26
IV.1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

IV.2 Architecture de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
IV.3 L’installation de Minikube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
IV.4 La création de cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
IV.5 Les informations du cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
IV.6 Téléchargement du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
IV.7 La création d’espace de nom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
IV.8 Déploiement pile de monitoring Prometheus . . . . . . . . . . . . . . . . . . . . . . 33
IV.9 L’état des pods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
IV.10 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
IV.11 Redirection de port pour grafana . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
IV.12 L’interface web de Grafana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
IV.13 Redirection de port pour Prometheus . . . . . . . . . . . . . . . . . . . . . . . . . . 34
IV.14 L’interface web de prometheus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
IV.15 Redirection de port pour AlertManager . . . . . . . . . . . . . . . . . . . . . . . . . 35
IV.16 L’interface web d’Alertmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
IV.17 Fichier de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
IV.18 Fichier de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
IV.19 La création du service web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
VII
Table des figures
IV.20 Les informations du déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

IV.21 URL d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
IV.22 La page web de service web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
IV.23 Les informations du cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
IV.24 L’usage de CPU par service webapp . . . . . . . . . . . . . . . . . . . . . . . . . . 38
IV.25 L’usage de RAM par le service webapp . . . . . . . . . . . . . . . . . . . . . . . . 38
IV.26 Ensemble des alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
IV.27 Description d’une alerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
V.1 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
VIII
Liste des tableaux
I.1 Machine virtuel vs Conteneur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
V.1 Structure WBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

V.2 Questionnaire et tendance des avis . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
IX
Liste des abréviations
API Application Programming Interface
CPU Central Processing Unit.
CI Continuous integration
CD Continuous Delivery
CLI Command-Line Interface
CNCF Cloud Native Computing Foundation
DNS Domaine Name System
DevOps Software Development System Administration
HTTPS HyperText Transfer Protocol Security
IOT Internet Of Things
IP Internet Protocol
MAC Media Access Control
PromQL Prometheus Query Language
OS Operator System
RAM Random access memory
X
Liste des tableaux
REST Representational State Transfer
RC Replication Controller
TCP Transmission Control Protocol
TSDB Time Series Data Base
UDP User Datagram Protocol
VLAN Virtual Local Area Network
VM Virtuelle Machine.
XI
Introduction générale
De nos jours, Les entreprises qui ont réussi à jeter les bases d’une innovation continue ont
adopté des architectures informatiques basées sur les microservices pour répondre immédiatement
aux besoins du marché et de ses clients.
Le Cloud Native est un nouveau concept qui veut que cette technologie permette de produire
des applications et de les exécuter dans un environnement moderne comme le Cloud, qu’il soit privé
ou public. Avec la technologie qui ne cesse d’évoluer, les logiciels sont de plus en plus développés à
partir des méthodes employées par les fournisseurs de Cloud.
Les bénéfices d’une approche cloud-native et des technologies de containers comme Kuber-
netes sur laquelle elle repose, ne sont plus à démontrer. Convaincues, les entreprises sont aujourd’hui
nombreuses à investir dans cette voie pour leurs applications legacy ou leurs nouveaux pipelines. Mais
si on reconnait les avantages - portabilité, évolutivité et surtout, réduction drastique des délais de dé-
ploiement - un défi de taille s’impose : comment assurer la fiabilité et la disponibilité des services ?
Le problème majeur de la surveillance des conteneurs est attribué à la nature des conteneurs. Si
le code s’exécute plus rapidement sur les conteneurs, leur fonctionnement interne reste relativement
invisible pour les opérations à cause de la nature de son environnement dynamique. Des problèmes de
sécurité surgissent lorsque les équipes d’opérations essayent d’obtenir des données sur l’infrastructure
conteneurisée.
Il est important de savoir que les systèmes qui nous intéressent sont allumés, mais ce n’est pas
là que réside la véritable valeur. Les gains les plus importants se trouvent dans la compréhension des
performances de ces systèmes.
Un système de monitoring basé sur des métriques peut en fait répondre, et par ailleurs nous
aider à comprendre pourquoi la réponse est ce qu’elle est. Un ensemble complet d’outils de monitoring
pour le débogage et l’analyse comprend non seulement des métriques, mais aussi des journaux, des
traces et des profils. Avec l’avènement des infrastructures Cloud et conteneurisées, les ressources
sont de plus en plus éphémères et dynamiques ce qui rend les solutions de monitoring traditionnelles
1
Liste des tableaux
comme Zabbix et Nagios plus capables de suivre ce dynamisme et superviser les infrastructures Cloud
/ conteneurisées. Par conséquent, des nouvelles solutions de monitoring ont eu lieu, d’ailleurs la stack
Prometheus est la plus connue et la plus utilisée vu son agilité et ses promesses.
La façon dont les projets sont développés a changé radicalement avec l’utilisation des technolo-
gies de conteneurs, et ce projet veut exposer tous les avantages de leur utilisation. L’objectif principal
est la création d’une infrastructure conteneurisée et de supervise cette infrastructure avec les outils
de monitoring ; prometheus, grafana et alertmanager et de comprendre comment elles influencent et
améliorent le développement et la maintenance des projets.
Il est attendu de cette solution l’optimisation des coûts ; en améliorant le fonctionnement du

processus que nous surveillons, révélation les anomalies dans les données pour résoudre les problèmes
de manière proactive et garantir un entretien simple et facile et des performances élevées. Les objectifs
managériaux de notre solution sont :
• Améliorer la QOS
• Garantir la fiabilité et la disponibilité des serveurs
• valoriser l’image de l’entreprise
• pour rester en phase avec l’évolution du marché
Le présent document est structuré en une introduction générale, cinq chapitres et une conclusion gé-
nérale, comme suit :
• Le premier chapitre expose quelques généralités qui permettront de comprendre le concept du

microservice, la virtualisation et l’avènement de la conteneurisation.
• Le deuxième chapitre présentera un aperçu sur les technologies Docker et Kubernetes ainsi que
leurs architectures.
• Le troisième chapitre est consacré à comprendre le monitoring et les outils utilisés dans notre
projet.
• Le quatrième chapitre expliquera Le développement et la mise en place de notre solution.
• Le cinqième chapitre est consacré à l’aspect managérial de notre projet.
• Ce travail sera clôturé par une conclusion générale et des perspectives.
2
Chapitre I
Généralités sur les microservices et la

conteneurisation
Chapitre I. Généralités sur les microservices et la conteneurisation
Introduction :
Avant l’avènement des technologies de conteneurs, le déploiement d’une application prenait
généralement beaucoup de temps, ce qui coûtait à l’entreprise des ressources. Lorsque les technologies
de conteneurs sont devenues plus populaires, l’ensemble du processus a été simplifié et normalisé,
surtout que les conteneurs peuvent être combinés avec une machine virtuelle.
Dans ce chapitre, nous allons aborder l’approche microservices, ses avantages et ses inconvé-
nients et aussi le concept de conteneurisation, ses avantages et le cycle de vie d’un conteneur.
I.1 Microservices :
I.1.1 Définition :
Est un concept architectural permettant de construire une application distribuée à l’aide de
conteneurs. Ils doivent leur nom au fait que chaque fonction de l’application fonctionne comme un
service indépendant. Cette architecture permet à chaque service d’évoluer ou de se mettre à jour sans
perturber les autres services de l’application (Figure I.1). [1]
Un cadre de microservices crée un système massivement évolutif et distribué, qui évite les
goulots d’étranglement d’une base de données centrale et améliore les capacités de l’entreprise, no-
tamment en permettant des applications à livraison/déploiement continu et en modernisant la pile
technologique.[1]
Fig. I.1 : Architecture microservices
I.1.2 Avantages de l’approche microservices

Les microservices offrent une foule d’avantages, notamment :
• Amélioration de la productivité : La décomposition d’une application en fragments auto-

nomes plus petits facilite sa construction et sa maintenance. Chaque service peut être développé,
4
déployé et géré indépendamment, et peut utiliser différents langages de programmation, diffé-

rentes technologies et différents environnements logiciels en fonction des besoins de chacun.
• Une meilleure résilience : La mise en œuvre d’une architecture basée sur des microservices
facilite le processus d’identification et de résolution des problèmes de performance. L’isola-
tion améliorée des pannes offerte par les modules individuels signifie que les applications plus
importantes ne sont pas affectées par une seule panne.
• Évolutivité accrue : Le fait que chaque service puisse être écrit dans un langage ou une techno-
logie différente permet aux équipes DevOps de choisir la pile technologique la plus appropriée
pour chaque module sans se soucier d’incompatibilité
• Intégration continue / délivrance continue (CI/CD) : L’intégration continue et la délivrance

continue sont des concepts clés de la philosophie DevOps et de l’approche agile. L’architec-
ture microservices permet aux équipes interfonctionnelles de développer, tester, résoudre les
problèmes, déployer et mettre à jour les services de manière indépendante, ce qui permet d’ac-
célérer les délais de déploiement et de résolution des problèmes.
• Optimiser les fonctionnalités de l’entreprise : Lorsque la concentration se fait sur un ser-

vice spécifique plutôt que sur l’ensemble de l’application, il est plus facile de personnaliser les
besoins de chaque composant pour améliorer la fonctionnalité de l’entreprise. En travaillant
sur des modules individuels, les équipes peuvent se concentrer sur les capacités de l’entreprise
plutôt que sur les technologies.
I.1.3 Inconvénients de l’approche microservices

L’approche microservices comporte des inconvénients comme :
• Grandes et petites entreprises : : Les microservices sont parfaits pour les grandes entreprises,
mais peuvent être plus lents à mettre en œuvre et trop compliqués pour les petites entreprises qui
doivent créer et itérer rapidement, et ne veulent pas se perdre dans une orchestration complexe.
• La communication entre les services est complexe : puisque tout est désormais un service
indépendant, vous devez gérer avec soin les requêtes qui voyagent entre vos modules. Dans
un tel scénario, les développeurs peuvent être contraints d’écrire du code supplémentaire pour
éviter toute perturbation. Au fil du temps, des complications apparaîtront lorsque les appels à
distance connaîtront une latence.
5
I.2 Virtualisation :
Virtualisation La virtualisation est une technologie qui permet de créer plusieurs environne-
ments simulés ou ressources dédiées à partir d’un seul système physique. Son logiciel, appelé hy-
perviseur, est directement relié au matériel et permet de fragmenter ce système unique en plusieurs
environnements sécurisés distincts. C’est ce que l’on appelle les machines virtuelles. Ces dernières
exploitent la capacité de l’hyperviseur à séparer les ressources du matériel et à les distribuer conve-
nablement. La virtualisation aide à tirer le meilleur parti des anciens investissements.[2]
Le matériel physique doté d’un hyperviseur est appelé « hôte », tandis que toutes les machines
virtuelles qui utilisent ses ressources sont appelées « invités ». Ces invités traitent les ressources de
calcul (processeur, mémoire, stockage) à la manière d’un pool de ressources qui peut être déplacé
sans difficulté. Les opérateurs peuvent contrôler les instances virtuelles du processeur, de la mémoire,
du stockage et des autres ressources, de sorte que les invités reçoivent les ressources dont ils ont
besoin, lorsqu’ils en ont besoin. [2]. Figure I.2 :
Fig. I.2 : L’architecture du virtualisation
Par conséquent, l’installation de plusieurs machines virtuelles sur un seul ordinateur peut exé-
cuter différents systèmes d’exploitation et applications sur un seul serveur physique ou hôte. [2]
6
I.3 Conteneurisation :
I.3.1 Définition :
La création d’un conteneur est de mettre tout ce que l’application a besoin pour fonctionner,
que ce soit des bibliothèques, un système d’exploitation ou toute autre technologie. Ce qui a été créé
peut être copié et utilisé dans n’importe quel environnement. Ce qui permet de gagner du temps et
facilite la poursuite d’autres processus sans réinstaller les mêmes composants du conteneur à chaque
fois qu’il faut tourner une machine virtuelle. Il s’agit d’un type de stratégie de virtualisation qui est
apparu comme une alternative à la virtualisation native ou initiale basée sur un hyperviseur. [3]
La conteneurisation implique la création de conteneurs séparés au niveau du système d’exploi-

tation, ce qui permet de partager des bibliothèques, des systèmes de fichiers et d’autres composants
importants, d’où un gain d’espace considérable par rapport à la virtualisation native, où chaque ma-
chine virtuelle avait ses propres composants de manière isolée. [3]
Il existe quelques technologies de conteneurisation qui offrent des outils de conteneurisation

et des API telles que Docker Engine, Rkt, LXC, OpenVZ, runC et LXD.[3]
Les conteneurs peuvent être classés en deux types :
• Niveau du système d’exploitation : Un système d’exploitation complet s’exécute dans un espace

isolé au sein de la machine hôte, partageant le même noyau que cette dernière.[3]
• Niveau application : Une application ou un service, et les processus minimaux requis par cette
application, s’exécutent dans un espace isolé au sein de la machine hôte. [3]
I.3.2 Avantages des conteneurs

Les principaux avantages des conteneurs sont
• Portabilité : Les conteneurs peuvent s’exécuter n’importe où, à condition que le moteur de
conteneurs prenne en charge le système d’exploitation sous-jacent..
• Efficacité et densité des ressources : Les conteneurs ne nécessitent pas de système d’exploi-
tation distinct et utilisent donc moins de ressources. Les VM ont généralement une taille de
quelques Go, mais les conteneurs ne pèsent généralement que quelques dizaines de mégaoctets,
ce qui permet à un serveur d’exécuter beaucoup plus de conteneurs que de VM. Les conteneurs
nécessitent moins de matériel, ce qui permet d’augmenter la densité des serveurs et de réduire
les coûts des centres de données ou du cloud.
7
• Isolation des conteneurs et partage des ressources : Il permet d’exécuter plusieurs conte-
neurs sur le même serveur, tout en assurant qu’ils soient complètement isolés les uns des autres.
Lorsque les conteneurs se plantent ou que les applications qu’ils contiennent tombent en panne,
les autres conteneurs exécutant la même application peuvent continuer à fonctionner comme
d’habitude.
• Rapidité : démarrer, créer, répliquer ou détruire des conteneurs en quelques secondes. Les
conteneurs sont des paquets légers qui contiennent tout ce dont ils ont besoin pour fonctionner, y
compris leur propre système d’exploitation, leur code, leurs dépendances et leurs bibliothèques.
• Haute évolutivité : Les conteneurs facilitent la mise à l’échelle horizontale des applications
distribuées. Il permet d’ajouter plusieurs conteneurs identiques pour créer plusieurs instances
de la même application. Les orchestrateurs de conteneurs peuvent effectuer une mise à l’échelle
intelligente, en exécutant uniquement le nombre de conteneurs dont on a besoin pour répondre
aux charges applicatives, tout en tenant compte des ressources disponibles dans le cluster de
conteneurs.
• Amélioration de la productivité des développeurs : Les conteneurs permettent aux dévelop-

peurs de créer des environnements d’exécution prévisibles, comprenant toutes les dépendances
logicielles requises par un composant d’application, isolés des autres applications sur la même
machine. Du point de vue du développeur, cela garantit que le composant sur lequel il travaille
peut être déployé de manière cohérente, quel que soit l’endroit où il est déployé.
I.3.3 Cycle de vie d’un conteneur

La Figure I.3 suivante explique le cycle de vie d’un conteneur :
8
Fig. I.3 : Cycle de vie du conteneur
Le cycle de vie complet d’un conteneur Docker s’articule autour de cinq phases :
• Phase de création : un conteneur docker est créé à partir d’une image docker.
• Phase d’exécution : le conteneur docker commence à exécuter les commandes mentionnées

dans l’image. Pour exécuter un conteneur Docker
• Phase de pause : la commande en cours d’exécution dans le conteneur docker est mise en pause.
• Phase de reprise : le conteneur en pause reprend l’exécution des commandes une fois qu’il est
libéré.
• Phase d’arrêt : le processus principal du conteneur est arrêté de manière élégante.
• Phase de destruction : les processus principaux du conteneur sont arrêtés brusquement.
I.3.4 L’orchestration de conteneurs

Les conteneurs prennent en charge la séparation des préoccupations à la manière d’une VM,
mais avec beaucoup moins de frais généraux et beaucoup plus de flexibilité. En conséquence, les
conteneurs ont remodelé la façon dont les gens envisagent le développement, le déploiement et la
maintenance des logiciels.
9
Dans une architecture conteneurisée, les différents services qui constituent une application sont
regroupés dans des conteneurs séparés et déployés sur un cluster de machines physiques ou virtuelles.
Mais cela fait naître le besoin d’orchestration de conteneurs - un outil qui automatise le déploiement,
la gestion, la mise à l’échelle, la mise en réseau et la disponibilité des applications basées sur des
conteneurs.
L’orchestration de conteneurs est donc l’acte de gérer et d’organiser les conteneurs selon un
modèle de comportement spécifié et explicitement défini. Cette définition comprend plusieurs facteurs
nécessaires à l’orchestration des différents conteneurs et varie en fonction des spécifications de chaque
cadre d’orchestration de conteneurs. Tous ont cependant en commun les spécifications des différents
conteneurs à orchestrer (image, nombre de réplications, etc.).
I.3.5 Le rôle de l’orchestration

Le rôle de l’orchestration est de :
• Répartir et déployer les conteneurs sur les machines hôtes selon des besoins spécifiés en termes
de mémoire et CPU.[4]
• Fournir une vue d’ensemble sur les métriques et les health-checks à la fois des conteneurs et
des machines hôtes peut être portée par l’outil d’orchestration.[4]
• Gérer le failover des conteneurs et la scalabilité : en cas d’indisponibilité d’une machine hôte par
exemple, l’orchestrateur permet de redémarrer le conteneur sur une deuxième machine hôte.[4]
• Assurer la mise à jour des conteneurs de manière successive et sans induire d’indisponibilité
applicative. Pendant la phase de mise à jour d’un conteneur, les autres conteneurs disponibles
sont exécutés.[4]
I.3.6 Conteneur vs VM
Le débat entre machine virtuelle et conteneur est au cœur du débat entre l’architecture infor-
matique traditionnelle et les pratiques DevOps contemporaines.
Lorsque l’on compare les technologies de conteneurs aux machines virtuelles normales, il y
a plusieurs avantages. Les conteneurs sont rapides à mettre en place et à configurer, alors que les
machines virtuelles sont plus volumineuses et lentes à mettre en place et à configurer. La nature des
conteneurs étant très agile, ils constituent une bonne base pour les processus de développement et
d’exploitation (DevOps).
10
Pour mettre à jour une nouvelle version de l’application, on peut utiliser un pipeline CI/CD.
De cette façon, l’application est rapidement installée sur l’environnement cible. Cela permet de tes-
ter rapidement les nouvelles versions de l’application et de pousser les nouvelles versions vers les
environnements de production.
On peut regrouper les différences dans un Tableau I.1 :
Machine virtuel Conteneur

Poids lourd Poids léger
Performance limitée Performances natives
Chaque VM fonctionne dans son propre OS Tous les conteneurs partagent le système d’exploitation hôte
Virtualisation au niveau du matériel Virtualisation du système d’exploitation
Temps de démarrage en minutes Temps de démarrage en millisecondes
Allocation de la mémoire nécessaire Nécessite moins d’espace mémoire
Entièrement isolé et donc plus sûr Isolation au niveau du processus, éventuellement moins sûre
Tab. I.1 : Machine virtuel vs Conteneur
Conclusion
Dans ce chapitre, nous avons expliqué ce que sont les microservices. Nous avons présenté
leurs principaux avantages et inconvénients. Nous avons parlé du concept de virtualisation et de son
lien avec les conteneurs, après avoir couvert en détail le concept de conteneurs et complété le chapitre
par une comparaison entre conteneurs et machines virtuelles.
Dans le chapitre suivant, nous présenterons la technologie Docker et Kubernetes, leurs archi-
tectures, leurs composants et leurs rôles.
11
Chapitre II
Docker et Kubernetes
Chapitre II. Docker et Kubernetes
Introduction
La conteneurisation est une technologie populaire qui permet aux développeurs de créer et
de déployer des applications de manière plus rapide. L’une des technologies qui permet la conte-
neurisation est Docker. Pour mieux comprendre cette technologie, nous devons toucher la notion du
Kubernetes.
Dans ce chapitre, nous allons aborder le concept de Docker, son architecture et sa relation avec
les conteneurs. Par la suite, nous allons toucher l’approche kubernetes, son architecture et son rôle.
II.1 Docker
II.1.1 Definition
Docker est une technologie de conteneurs lancée en 2013 par la société Docker Inc. C’est un
projet open-source qui automatise le déploiement d’applications dans des conteneurs logiciels. Ces
conteneurs d’applications s’apparentent à des machines virtuelles légères, car ils peuvent être exécutés
de manière isolée les uns des autres et de l’hôte en fonctionnement. [5]
Docker nécessite des fonctionnalités présentes dans les noyaux Linux récents pour fonctionner
correctement, c’est pourquoi sur Mac OSX et Windows, une machine virtuelle exécutant linux est
nécessaire pour que Docker fonctionne correctement. [5]
Actuellement, la principale méthode d’installation et de configuration de cette machine vir-

tuelle est Docker Toolbox qui utilise VirtualBox en interne, mais il est prévu d’intégrer cette fonc-
tionnalité dans Docker lui-même, en utilisant les fonctionnalités de virtualisation natives du système
d’exploitation. Sur les systèmes Linux, Docker s’exécute nativement sur l’hôte lui-même. [5]
II.1.2 Architecture Docker

Les composants de base de Docker sont les suivants [5] :
13
Fig. II.1 : Architecture docker
• Daemon Docker : Écoute les demandes de l’API Docker et gère ces objets tels que les images,
les conteneurs, les réseaux et les volumes.[5]
• Clients Docker : À l’aide des clients Docker, les utilisateurs peuvent interagir avec Docker. Le
client Docker fournit une interface de ligne-commande (CLI) qui permet aux utilisateurs de
lancer et d’arrêter des commandes d’application à un démon Docker.[5]
• Hôte Docker : Fournit un environnement complet pour exécuter des applications. Il comprend
le démon Docker, les images, les conteneurs, les réseaux et le stockage.[5]
• Registre Docker : Stocke les images Docker. Docker Hub est un registre public que tout le
monde peut utiliser. Docker est configuré pour utiliser les images sur Docker Hub par défaut.
On peut faire exécuter notre propre registre sur ce dernier.[5]
• Images Docker : Sont des modèles en lecture seule qu’on utilise à partir d’un ensemble d’ins-
tructions écrites dans un fichier Docker. Les images définissent à la fois ce à quoi on veut que
notre application packagée et ses dépendances ressemblent et les processus à exécuter lors-
qu’elle est lancée.[5]
II.1.3 Conteneur Docker :

Un conteneur Docker est un logiciel léger qui comprend tout ce qui est nécessaire à son fonc-
tionnement, y compris son propre système d’exploitation minimal, ses ressources d’exécution et ses
dépendances. [3] L’écosystème Docker est au cœur de l’adoption massive et de l’engouement ob-
14
servé dans l’espace conteneur. Pour faire tourner un conteneur Docker spécifique, ils sont développés
à partir d’images conçues pour fournir une capacité spécifique.[3]
Ces images de Docker sont faites à partir de systèmes de fichiers qui sont superposés de ma-
nière à pouvoir partager des fichiers communs. Le partage de fichiers communs présente l’avantage
de réduire l’utilisation de l’espace disque et d’accélérer le téléchargement des images.[3]
Par rapport aux machines virtuelles, les conteneurs sont plus efficaces en termes de ressources
car ils ne nécessitent pas d’hyperviseurs. En outre, les conteneurs ont une empreinte mémoire moindre
et peuvent aider les organisations à éviter les coûts élevés et les tracas liés à la prolifération des
serveurs.[3]
II.2 Kubernetes
II.2.1 Définition :
[6] Kubernetes est un système open-source qui aide les organisations à gérer les applica-
tions conteneurisées basées sur le Cloud. Le système permet d’automatiser le déploiement, la mise à
l’échelle et de gestion des conteneurs qui font partie d’un vaste écosystème distribué d’applications
et de stockage en Cloud.[6]
Kubernetes est une plateforme open-source conçue pour automatiser le déploiement, la mise
à l’échelle et l’exploitation des conteneurs d’applications.[6]
Kubernetes est le principal moteur d’orchestration de conteneurs dans le domaine de la conte-

neurisation. Développé par Google, il utilise les images Docker comme base pour déployer des appli-
cations dans les conteneurs. Avec Kubernetes, les conteneurs sont facilement mis à l’échelle, détruits
et recréés. [6]
Par rapport aux machines virtuelles normales, ils sont déployés plus rapidement, plus efficace-
ment et de manière plus fiable. Docker crée l’image, qui est utilisée dans Kubernetes. Dans le monde
de la virtualisation croissante et de l’internet des objets (IoT), les applications et les services doivent
être déployés rapidement et efficacement.[6]
II.2.2 L’architecture du Kubernetes :

La Figure II.2 présente une architecture de haut niveau de Kubernetes. Comme on peut le voir,
chaque cluster Kubernetes se compose d’un nœud maître et d’un ou plusieurs nœuds travailleurs. Cette
structure permet à Kubernetes d’optimiser la puissance du calcul cluster en distribuant les conteneurs
sur différents nœuds travailleurs, tout en les gérant par le nœud maître. Le nœud maître comprend des
15
composants tels que le serveur API, le gestionnaire de contrôleurs, le planificateur et Etcd. Le nœud
travailleur ne comporte que deux composants, à savoir kubelet et kubeproxy.[7]
Fig. II.2 : Architecture de Kubernetes
Les principaux composants de Kubernetes sont décrits comme suit :
Nœuds maître et travailleur :
Suivant une architecture de type maître-esclave, Kubernetes se compose de nœuds maître et

travailleur. Un nœud, en général, fait référence au dispositif hôte, qui est soit une machine virtuelle, soit
une machine physique. Les nœuds travailleurs exécutent les pods et sont gérés par le nœud maître. Le
nœud maître d’un cluster est responsable de la gestion des conteneurs et se compose de trois processus :
kube APIserver, kube controller manager et kube scheduler.[7]
Pods :
La plus petite unité de calcul déployable dans Kubernetes est appelée pod. Chaque pod est
constitué d’un ou plusieurs conteneurs d’applications, qui sont déployés sur le même hôte physique
et partagent le même ensemble de ressources telles que le stockage et le réseau. Kubernetes applique
ses mécanismes d’ordonnancement et d’orchestration sur des pods et pas sur des conteneurs.[7]
Le contrôleur de réplication :
souvent abrégé en ”RC”, est chargé de s’assurer que le nombre spécifié de pods est toujours
opérationnel, et si ce n’est pas le cas, il répliquera le nombre requis de pods. Il met également fin à
certains pods s’ils sont trop nombreux. Les répliques seront gérées en fonction des règles définies dans
16
le modèle du pod. Un pod créé manuellement peut être expulsé en cas de défaillance, tandis qu’en
utilisant un contrôleur de réplication, nous pouvons définir des pods qui seront remplacés en cas de
défaillance ou de suppression pour une raison quelconque. [7]
Par conséquent, il serait judicieux de définir un contrôleur de réplication plutôt que de créer
manuellement des pods. Cela garantira la santé de l’application, même si elle ne contient qu’un seul
pod.[7]
ReplicaSet :
est un objet API dans Kubernetes, qui gère la mise à l’échelle des pods. Il vérifie l’état des
pods et en maintient le nombre souhaité à tout moment. Selon la documentation de Kubernetes, les
ReplicaSets constituent la prochaine génération de contrôleurs de réplication et offrent davantage de
fonctionnalités.[7]
Le déploiement :
est un concept de plus haut niveau que le replicaSet et le pod. En définissant un déploiement,
nous pouvons déclarer des mises à jour pour les Pods et les ReplicaSets. En d’autres termes, nous
décrivons un état souhaité et le contrôleur de déploiement vérifie l’état réel par rapport à l’état souhaité.
Au lieu d’utiliser directement les pods ou les ReplicaSets, il est recommandé de les définir par des
déploiements.[7]
Un service :
est un moyen abstrait d’exposer aux utilisateurs des applications fonctionnant sur les pods.
Comme mentionné précédemment, une adresse IP unique est attribuée à chaque pod au sein d’un
cluster. Cependant, comme les pods peuvent être créés ou supprimés par le contrôleur de réplication,
leurs adresses IP ne sont pas stables. Chaque pod nouvellement créé recevra une nouvelle adresse IP,
ce ne serait donc pas une approche appropriée pour les utilisateurs de se connecter aux applications via
les adresses IP des pods. C’est là que les services Kubernetes résolvent le problème en offrant une API
de point de terminaison, qui permet aux services d’être accessibles de l’extérieur. De plus, en attribuant
un nom DNS unique à chaque service, Kubernetes fournit un mécanisme interne de découverte des
services et les développeurs n’ont pas besoin d’utiliser une approche externe pour cela.[7]
II.2.3 Composants du nœud maître

Le nœud maître, l’unité de contrôle du cluster Kubernetes, est chargé de maintenir et de gé-
rer l’enregistrement de l’état de tous les objets du système. Pour ce faire, il effectue des boucles de
contrôle continues pour répondre aux changements. Le plan de contrôle est donc l’endroit où les utili-
17
sateurs et les administrateurs système interagissent avec Kubernetes. Il accepte les requêtes des clients
et s’assure de faire évoluer l’état actuel du cluster vers l’état désiré, tel que décrit par les utilisateurs
via le Pod Lifecycle Event Generator (PLEG). Le nœud maître Kubernetes adopte une collection de
processus qui gèrent l’état du cluster. [7]
Ces composants sont décrits comme suit :
• Le serveur API : expose une API REST, qui rend possible la communication de tous les
composants du cluster. Il permet également aux utilisateurs de configurer et de valider tous les
objets du cluster tels que les pods, les contrôleurs de réplication, les services, etc. En outre, le
serveur API gère les communications entre les nœuds maître et travailleur.[7]
• Un gestionnaire de contrôleur : est une boucle de contrôle qui s’exécute sur le maître et qui,
à l’aide du serveur API, vérifie l’état du cluster. Si un changement survient, le gestionnaire de
contrôleur déplace l’état actuel du cluster vers l’état souhaité. Il existe différents contrôleurs
dans Kubernetes, notamment, le contrôleur de réplication, le contrôleur d’espace de noms, le
contrôleur de point de terminaison et le contrôleur de comptes de service.[7]
• Le planificateur : agit comme un contrôleur de ressources et gère la charge de travail d’un

cluster. Plus précisément, il est responsable de l’affectation des pods aux différents nœuds tra-
vailleurs en fonction de plusieurs paramètres tels que les ressources informatiques des nœuds,
les contraintes de politique des pods et les exigences de qualité de service. Dans ce but, le plani-
ficateur garde également une vue d’ensemble des ressources pour savoir lesquelles sont libres
ou occupées.[7]
• Etcd : est un entrepôt de données clé-valeur léger, cohérent, hautement disponible et distribué,
qui est utilisé pour stocker toutes les données du cluster, y compris les configurations et les
informations d’état du cluster. Pour fonctionner en tant que magasin de données, etcd se base
sur l’algorithme de consensus Raft.[7]
II.2.4 Composants du nœud travailleur

Les nœuds travailleurs sont les machines sur lesquelles l’application s’exécute. L’utilisateur
n’a souvent aucune interaction avec ces nœuds et le nœud maître contrôle chacun d’entre eux.[7]
Chaque nœud travailleur est composé de quelques éléments décrits comme suit :
• Moteur de conteneur : comme premier composant, un moteur de conteneur doit être installé sur
chaque nœud travailleur. Le moteur de conteneur est le logiciel responsable de l’exécution des
18
conteneurs. Plusieurs moteurs de conteneurs sont pris en charge par Kubernetes, mais Docker
est le plus populaire.[7]
• Kubelet : Étant responsable de la gestion des pods et de leurs conteneurs dans chaque nœud,
Kubelet est le composant le plus important des nœuds travailleurs. Kubelet reçoit ses instruc-
tions du nœud maître et, en interaction avec etcd, il met à jour les configurations. Sur la base des
informations acquises, il s’assure que les pods sont sains et fonctionnent correctement. Ensuite,
il signale également l’état des nœuds au cluster.
• Kube-Proxy : est un proxy réseau, qui prend en charge les règles réseau sur chaque nœud
travailleur. Ces règles permettent les communications réseau vers les pods depuis l’intérieur ou
l’extérieur du cluster Kubernetes. En d’autres termes, grâce à la mise en correspondance des
conteneurs avec les services et à l’utilisation de mécanismes d’équilibrage des charges, il permet
d’accéder à l’application déployée depuis le monde extérieur. Ces proxies réseau fonctionnent
sur la base de flux TCP et UDP.[7]
II.2.5 Principales fonctionnalités de Kubernetes

• Extensibilité : Il s’agit de la capacité d’un outil à permettre une extension de sa ou de ses
capacités sans modification notable de l’infrastructure.
• Portabilité : Dans son sens le plus large, cela signifie la capacité d’une application à être dé-
placée d’une machine à l’autre. Cela signifie que le paquet peut être exécuté n’importe où.[7]
• Auto-réparation : Kubernetes assure la résilience des applications grâce aux opérations qu’il
lance, comme le démarrage automatique, utile en cas de panne d’une application, la réplication
automatique des conteneurs et la mise à l’échelle automatique en fonction du trafic. La propriété
de guérison de Kubernetes lui permet de réagir efficacement. [7]
• Équilibreur de la charge : Kubernetes optimise les tâches à la demande en les rendant dis-
ponibles et évite de solliciter indûment les ressources. Dans le contexte de Kubernetes, nous
avons deux types d’équilibreurs de charge - l’équilibreur de charge interne et externe.
• Déploiement automatisé et même réplication des conteneurs.[7]
Conclusion
Après qu’on a expliqué le concept de Docker et son architecture de base, on a défini les conte-
neurs et Docker. Ensuite, nous avons abordé l’orchestrateur Kubernetes et nous avons expliqué son
19
architecture et on a appris le rôle de cette notion.
Dans le prochain chapitre, Nous allons présenter le Monitoring d’une infrastructure conteneu-
risée et les outils utilisés.
20
Chapitre III
Monitoring et ces outils

Chapitre III. Monitoring et ces outils
Introduction
L’exécution de tous vos services dans des conteneurs permet d’obtenir des caractéristiques ap-
profondies des ressources et des performances, puisque chaque conteneur fonctionne dans son propre
CGroup et que le noyau Linux nous fournit toutes sortes de mesures utiles.
Bien qu’il existe quelques autres outils de monitoring, nous allons vous montrer c’est quoi le
monitoring, c’est quoi Prometheus, Grafana et Alertmanager et pourquoi on pense qu’ils sont parfai-
tement adaptés au monitoring des infrastructures basées sur des conteneurs.
III.1 Le monitoring
III.1.1 Définition
D’un point de vue technologique, le monitoring est l’ensemble des outils et des processus par
lesquels vous mesurez et gérez votre système technologique.[8]
elle fournit également la vision et la capacité de diagnostiquer, détecter et alerter sur la base
des données recueillies. Ces données sont une représentation de l’expérience vécue par les clients
lors de l’utilisation de votre produit. On pense souvent, à tort, que seules les équipes technologiques
peuvent bénéficier du monitoring. Les départements commerciaux peuvent également prendre des
décisions sur la base des rapports qui permettent de mesurer l’état du produit et des investissements
technologiques.[8]
Pour disposer d’un ensemble de monitoring solide pour le développement d’applications, il

faut le considérer comme un composant central plutôt que comme un composant supplémentaire. Il
est préférable de prendre en compte les métriques et le suivi dès la phase de planification.[8]
III.1.2 Monitoring de Kubernetes

Il y a plusieurs outils de monitoring dans le marché comme Zabbix. Le monitoring de Ku-
bernetes a été initialement testé à l’aide de Zabbix. Il s’agit d’une plateforme de surveillance d’hôte
conçue pour la collecte de métrique système en temps réel à l’aide de leurs agents propriétaires, qui
collectent l’utilisation des ressources par le biais de ces agents. Initialement, la configuration a été
faite pour l’un des clusters des environnements de test afin que les agents enregistrent chaque pod
Kubernetes comme un seul hôte. [9]]
Le problème avec Zabbix est qu’il n’est pas conçu pour les environnements dynamiques où
les hôtes à surveiller disparaissent et apparaissent. Après la phase de test, il était clair qu’il fallait
une autre plateforme plus dynamique pour surveiller les services fonctionnant dans Kubernetes. La
22
plateforme suivante qui a été prise en considération est Prometheus. [9]
Prometheus était beaucoup plus prometteur que Zabbix puisqu’il n’avait aucune relation avec
les ressources de Kubernetes. L’un des avantages de Prometheus par rapport à Zabbix est qu’il existe
des points d’extrémité de surveillance Kubernetes qui produisent déjà les données dans un format
accepté par Prometheus.[9]
III.2 Prometheus
III.2.1 Définition :
Prometheus est un outil de monitoring et d’alerte open-source créé chez SoundCloud en 2012
pour remplacer leurs outils de monitoring existants, Graphite et StatsD, qui ne répondaient plus à leurs
besoins. Prometheus a rejoint la CNCF (Cloud Native Computing Foundation) en 2016 en tant que
deuxième projet hébergé, après Kubernetes. [10]
Au départ, ils voulaient que Prometheus réponde à quatre exigences :
• un modèle de données multidimensionnel
• une simplicité opérationnelle
• une collecte de données évolutive
• un langage de requête puissant
Prometheus prend en charge la collecte des données, le stockage (temporaire) des données et les phases
d’alerte.[10]
Prometheus est basé sur la méthode de collecte des données de monitoring dite ”pull”. Afin
d’extraire les métriques d’un service l’exportateur Prometheus doit être installé sur un serveur.[10]
III.2.2 L’architecture de Prometheus

L’écosystème Prometheus se compose d’un serveur, d’un alertmanager, d’un Pushgateway et
d’une interface utilisateur Figure III.1
23
Fig. III.1 : L’architecture de Prometheus.
• Le serveur : se compose d’une base de données de séries chronologiques (TSDB) pour le sto-
ckage des données et d’un serveur Hypertext Transfer Protocol Secure (HTTPS) pour la récupé-
ration ou l’envoi des données. Prometheus définit ses charges de travail en utilisant le scraping.
Le scraping est une tâche de configuration de Prometheus, qui définit les points de terminaison,
où les données doivent être récupérées. Il permet également de manipuler les données avant
de les stocker dans une TSDB. Par défaut, Prometheus collecte des données toutes les trente
secondes auprès de ses cibles. Ce rythme de collecte des données peut également être modifié
dans la configuration d’un scrape. Prometheus possède un langage de requête propriétaire ap-
pelé Prometheus Query Language (PromQL) qui permet d’interroger et d’agréger les données
stockées dans TSDB.
• L’Alertmanager : permet de créer des alertes sur la métrique et ses valeurs. ingérées dans
Prometheus. Sa configuration est stockée à l’intérieur de Prometheus. des intégrations à d’autres
plateformes d’alerte et la possibilité d’envoyer des alertes via des webhooks. [11]
• La pushgateway : permet aux services externes qui n’exposent pas de métriques d’envoyer
constamment des données à Prometheus. L’un des avantages de cette solution est qu’elle per-
met aux services d’envoyer à Prometheus des métriques qui pourraient ne pas être présentes
lors de la collecte des données. Cette solution est idéale pour les services basés sur des tra-
vaux par lots. Pushgateway ne modifie ni n’agrège les données qui lui sont fournies. (Github,
promtheus/pushgateway [10]
24
• Interface utilisateur : Le serveur Prometheus dispose également d’une interface utilisateur

permettant d’interroger et de visualiser les métriques à l’aide de PromQL. Malheureusement,
il lui manque la possibilité de créer des tableaux de bord. Chaque fois qu’un utilisateur veut
voir certaines données, il doit les réinterroger. Ainsi, Prometheus est surtout utilisé comme un
stockage de données. La visualisation et les tableaux de bord pour les services sont généralement
envoyés à un autre service tel que Grafana. [10]
III.2.3 Base de données de séries chronologiques (TSDB)

Une base de données de séries chronologiques (TSDB) est un système informatique conçu
pour stocker et récupérer des enregistrements de données faisant partie d’une ”série chronologique”,
c’est-à-dire un ensemble de points de données associés à des horodatages. Les horodatages fournissent
un contexte critique pour chacun des points de données dans la façon dont ils sont liés aux autres. Les
données de séries chronologiques sont souvent un flux continu de données, comme les mesures des
capteurs et les cours boursiers intrajournaliers. Une base de données de séries chronologiques vous
permet de stocker de grands volumes de données horodatées dans un format qui permet une insertion
et une récupération rapides pour prendre en charge une analyse complexe de ces données. [12]
III.2.4 Les métriques de Prometheus

Prometheus stocke toutes les données sous forme de séries chronologiques. Une métrique est
une série chronologique définie par son nom unique et des paires clé-valeur optionnelles appelées
étiquettes. (Prometheus, Data model)
Prometheus est adapté aux séries chronologiques numériques, ce qui signifie que les valeurs
de chaque métrique doivent être numériques. (Prometheus, Overview )
Comme les métriques Prometheus sont numériques, il est possible d’appliquer des fonctions
mathématiques telles que la somme ou le taux aux métriques.
III.2.5 Les exportateurs de Prometheus

Prometheus dispose d’un vaste écosystème d’exportateurs, qui sont tous préconstruits par la
communauté open-source, comme CouchDB ou l’exportateur Elasticsearch. Cela permet une col-
lecte plus rapide des métriques pour les utilisateurs et la création de systèmes de surveillance plus
complexes dès le départ. Prometheus dispose de bibliothèques d’instrumentation officielles pour les
langages Go, Java ou Scala, Python et Ruby. Il existe d’autres bibliothèques clientes tierces non of-
ficielles pour Node.js, C et PHP. Les exportateurs écrits sur mesure ont la possibilité de créer des
mesures personnalisées liées à la logique métier qui peuvent être surveillées, comme les demandes
25
faites à un point de terminaison spécifique au cours des cinq dernières minutes ou la durée moyenne
d’une requête de base de données spécifique. (Prometheus, Client libraries. [10]
III.3 Grafana :
Le projet Grafana a été lancé en 2014. Grafana est un logiciel de visualisation et d’analyse
open source. Il nous permet d’interroger, de visualiser, d’alerter et d’explorer nos métriques, journaux
et traces, quel que soit l’endroit où ils sont stockés. Il nous fournit des outils pour transformer les
données de notre base de données de séries chronologiques (TSDB) en des magnifiques graphes et
visualisations.
Grafana est généralement utilisé comme un outil de visualisation pour Prometheus, car les
méthodes de visualisation de Prometheus sont trop primitives pour les exigences actuelles.
Grafana dispose d’une communauté active qui développe grafana et ses composants. La créa-
tion de tableaux de bord dans Grafana est rendue très simple. L’utilisateur peut télécharger des tableaux
de bord prêts à l’emploi pour les exportateurs Prometheus à partir du site Grafana. Par exemple pour
les métriques fournies par le Node Exporter, le tableau de bord présenté dans la Figure III.2 peut être
téléchargé. Ces tableaux de bord prêts à l’emploi peuvent ensuite être personnalisés pour répondre
aux besoins de l’utilisateur.[13]
Fig. III.2 : Tableau de bord Grafana pour l’exportateur Prometheus Node
26
Conclusion
Dans ce chapitre nous avons choisi de commencer par une définition sur le monitoring pour
bien comprendre ce champ d’étude, après on a touché sa relation avec kubernetes et la probléma-
tique avec les anciens outils de monitoring, ensuite nous avons défini les outils utilisés dans ce projet
(Prometheus) et décrit son architecture et ces fonction, puis nous avons abordé tout sur grafana et ces
fonctionnalités.
Dans le chapitre suivant, nous présenterons l’implémentation de notre solution proposée ainsi
que les résultats de notre travail.
27
Chapitre IV
Implémentation de la solution
Chapitre IV. Implémentation de la solution
Introduction
Après avoir présenté un aperçu sur les fondements théoriques de notre solution. Ces derniers
seront interprétés par la présentation d’un cas de solution pratique.
Dans ce chapitre, nous allons présenter un cas pratique adapté pour monitorer un cluster kuber-
netes via l’intégration de Prometheus avec Grafana, et Alertmanager. La partie applicative comprend
le scénario de déploiement, les principales configurations, et des tests.
IV.1 Scénario de déploiement

Pour la mise en place de la solution proposée, qui consiste à appliquer une solution de moni-
toring sur une infrastructure conteneurisée avec Prometheus, Grafana et Alertmanager au niveau de
l’ENSTICP. Pour la bonne réalisation de notre application, nous avons utilisé des logiciels, tels que :
• Prometheus : Ceci définit un déploiement Prometheus souhaité sur Kubernete
• Alertmanager : Ceci définit un déploiement Alertmanager souhaité sur le cluster Kubernetes.
• Grafana : Ceci surveiller et analyser des données Web .
• ThanosRul : Cela définit le déploiement de la règle souhaitée par Thanos.
• ServiceMonitor : Spécifie comment les groupes de services Kubernetes doivent être surveillés.
• PodMonitor : Spécifie de manière déclarative comment le groupe de pods doit être surveillé.
• Sonde : Spécifie comment les groupes d’entrées ou les cibles statiques doivent être surveillés.
• PrometheusRule :Fournit la spécification de l’ensemble d’alertes Prometheus souhaité. L’opé-

rateur génère un fichier de règles, qui peut être utilisé par les instances Prometheus.
• AlertmanagerConfig :Spécifie de manière déclarative les sous-sections de la configuration d’Alert-

manager, permettant le routage des alertes vers des récepteurs personnalisés et la définition de
règles d’inhibition.
La figure IV.1 représente notre architecture de notre solution qui contient les principaux élé-
ments de notre travail :
29
Fig. IV.1 : Architecture de la solution
IV.2 Implémentation de l’application
IV.2.1 Mise en place du cluster kubernetes

Après avoir installé Ubuntu 20.04, en tant que machine vertuel, sur un hyperviseur (virtualbox),
sur cette machine, nous avons installé Minikube pour que nous puissent déployer automatiquement
cluster kubernetes, ce derniers est géré et contrôlé à travers Kubectl.
La figure IV.2 représente l’environnement crée.
30
Fig. IV.2 : Architecture de travail
Afin de pouvoir se connecter aux différents serveurs, la configuration IP est indiquée dans la
section suivante.
IV.2.2 Versions utilisées

Nous avons utilisé les versions suivantes :
• Minikube : 2.0.4
• Docker : 20.10.12
• Kubectl :1.24.2
Nous commençons par l’installation de Minikube, voir la figure :
31
Fig. IV.3 : L’installation de Minikube
Minikube crée par default un cluster et un namespace, et sur lesquels nous allons appliquer
notre solution, voir la figure IV.4 Une fois l’installation terminée, une fenêtre s’affiche marquant la
Fig. IV.4 : La création de cluster
fin de la création du cluster, comme illustrée sur la figure IV.5, où apparait l’IP de control plane.
Fig. IV.5 : Les informations du cluster
Pour obtenir une pile de monitoring complète, nous utiliserons le kube-prometheus qui inclut
Prometheus Operator parmi ses composants. La pile kube-prometheus est destinée au monitoring des
clusters et est préconfigurée pour collecter les métriques de tous les composants Kubernetes, avec un
ensemble par défaut de tableaux de bord et de règles d’alerte.
Après avoir installé le cluster, on commence par le dépècement de prometheus, nous avons
besoin de cloner le kube-prometheus sur notre système local :
Fig. IV.6 : Téléchargement du projet
32
Ensuite, nous créons l’espace de nom ’monitoring’, le pod opérateur et les CustomResource-
Definitions nécessaires. Les informations sont illustrées dans les figures ci-dessous :
Fig. IV.7 : La création d’espace de nom
Une fois que nous avons confirmé que les ressources sont définies, nous déployons la pile de
monitoring Prometheus.
Fig. IV.8 : Déploiement pile de monitoring Prometheus
Nous utilisons les commandes ci-dessous pour vérifier l’état des pods :
Fig. IV.9 : L’état des pods
Egalement, Pour lister tous les services créés, nous allons lancer la commande suivante : Apres avoir
33
Fig. IV.10 : Services
déployé la pile de monitoring, nous pouvons accéder aux tableaux de bord de Grafana, Prometheus
et Alertmanager, on utilisant kubectl port-forward, voir la figure Ensuite, nous accédons au tableau
Fig. IV.11 : Redirection de port pour grafana
de bord Grafana sur votre navigateur local sur l’URL. Voir la figure IV.12 : Pour le transfert de port
Fig. IV.12 : L’interface web de Grafana
de Prometheus, nous exécutons les commandes ci-dessous : La console web de Prometheus est ac-
Fig. IV.13 : Redirection de port pour Prometheus
cessible par l’URL, voir la figure IV.14 Pour le transfert de port d’Alertmanager, nous exécutons les
Fig. IV.14 : L’interface web de prometheus
commandes ci-dessous : La console web d’Alertmanager est accessible par l’URL, voir la figure :
34
Fig. IV.15 : Redirection de port pour AlertManager
Fig. IV.16 : L’interface web d’Alertmanager
Une fois que la solution est bien déployée, nous avons effectué un ensemble des tests pour
assurer de leur bon fonctionnement.
IV.3 Test de solution

Pour le test de l’application, nous déployons une application web dans notre cluster.
Nous avons créé un fichier YAML de type déploiement dans lequel nous avons défini notre
état souhaité pour le cluster, y compris l’image docker de l’application « richardchesterwood/k8s-
fleetman-webapp-angular :release0». Notre fichier de déploiement YAML est le suivant : Donc pour
Fig. IV.17 : Fichier de déploiement
permettre aux clients d’échanger de manière plus fiable avec les conteneurs s’exécutant dans le Pod à
35
l’aide d’une adresse IP virtuelle statique grâce au travail du composant kube-proxy, nous avons créé
un service de type ”Nodeport” à travers un fichier YAML. Ce fichier s’exécute de la même manière
que le déploiement. Notre fichier de service YAML est le suivant : Pour exécuter ce déploiement dans
Fig. IV.18 : Fichier de service
le cluster, nous avons transmis le fichier YAML comme une spécification d’objet en utilisant l’option
-f avec la commande kubectl create : La figure ci-dessus montre que notre déploiement « webapp »
Fig. IV.19 : La création du service web
a été bien crée. Pour accéder à ce service, nous avons exécuté la commande suivante : La figure ci-
Fig. IV.20 : Les informations du déploiement
Fig. IV.21 : URL d’accès
dessus montre l’interface web du service webapp qui consiste à une catre du monde : Le tableau de
bord complet de l’exportateur de nœuds sera importé. On peut voir que toutes les mesures telles que
la charge du système, la RAM utilisée, l’occupation du processeur, etc. sont surveillées avec succès
36
Fig. IV.22 : La page web de service web
Fig. IV.23 : Les informations du cluster
sur Grafana. Nous filtrons les resultats. On peut voir que Grafana est capable de visualiser de nom-
breuses métriques de notre déploiement “webapp” qu’il est en cours d’exécution. Après, sur l’onglet
“Alertes” de Prometheus. On peut voire des alertes concernant le fonctionnement de notre cluster.
On peut ensuite faire défiler le rapport et voir les règles qui ont été évaluées. Dans cet exemple, nous
avons exploré l’élément ”kubeSchdularDown”. On peut voir le niveau de sévérité, et la description du
problème. Plus de détails sur cette règle sont affichés sur la figure IV.27. A partir du dernier résultat,
nous avons réussi à trouver un service de monitoring proactif avec une détection rapide des problèmes
et l’identification des activités et qui donne à l’entreprise le niveau de protection approprié à la valeur
de l’information et aux exigences de l’entreprise.
37
Fig. IV.24 : L’usage de CPU par service webapp
Fig. IV.25 : L’usage de RAM par le service webapp
Fig. IV.26 : Ensemble des alertes
38
Fig. IV.27 : Description d’une alerte
Conclusion
Nous avons abordé dans ce chapitre la partie de préparation de l’environnent, suivi par l’ins-
tallation et la config de la solution, et conclu par des scenarios et testes qui confirment que la mise en
place est terminée avec succès.
Dans le suivant chapitre, nous allons aborder l’aspect managérial de notre solution.
39
Chapitre V
Partie Manageriale
Chapitre V. Partie Manageriale
Introduction
La surveillance des conteneurs à l’échelle de l’entreprise nécessite une transformation du sys-
tème, et Uniquement le management peut conduire ce changement d’état d’esprit. Comme l’a dit
William Edwards Deming, ”Un système est utilisé par les employés, mais il est créé par la direction”.
Nous avons choisi une étude de managériale pour notre PFE afin de bien définir nos priorités
et de bien gérer notre temps.
V.1 Présentation du l’organisme d’accueille (ENSTICP)

L’ENSTICP est une institution universitaire spécialisée dans les domaines des télécommunica-
tions, de l’ingénierie des réseaux, des technologies de l’information et de l’administration des affaires.
En plus de cette formation supérieure, l’institut dispose d’autres formations parallèles aux certificats
Cisco et d’Oracle et du permis de conduire informatique européen.
V.2 Planification de travail

La planification consiste à découper le projet en tâches. D’abord une liste exhaustive des tâches
doit être établie, ensuite, elles vont devoir être ordonnancées de façon à déterminer les interdépen-
dances et l’ordre dans lequel elles devront être réalisées.
Un WBS (Work Breakdown Structure) qui aide à la répartition structurée des activités est un
outil de planification qui permet d’identifier et de définir toutes les taches à considérer pour pouvoir
d’abord organiser le projet et pouvoir ensuite évaluer régulièrement leur avancement.
La division temporelle de notre projet nous permet de définir trois phases, chacune contenant
plusieurs tâches. Comme indiqué dans le tableau ci-dessous.
41
WBS Nom de la tâche Durée Début Fin

1 Avant-Projet 3 jours 15/04/2022 18/04/2021
1.1 Etude de faisabilité et analyse des risques 1 jour 18/04/2022 19/04/2022
1.2 Définition des objectifs 1 jour 19/04/2022 20/04/2022
1.3 Etablissement du plan de travail 1 jour 20/04/2022 21/05/2022
2 Etude théorique 39 jour 21/04/2022 30/05/2022
2.1 Étude théorique sur l’approche micro-service 1 jour 21/04/2022 22/04/2022
2.2 Étude théorique sur la virtualisation 1 jour 22/04/2022 23/04/2022
2.3 Étude théorique sur les conteneurs 3 jours 23/04/2022 26/04/2022
2.4 Recherche sur la relation entre les machines virtuelles et les conteneurs 1 jour 26/04/2022 27/04/2022
2.5 Rédaction du chapitre 1 6 jours 27/04/2022 23/05/2022
2.6 Étude théorique sur la kubernetes 3 jours 03/05/2022 06/05/2022
2.8 Étude théorique sur le monitoring 4 jours 09/05/2022 13/05/2022
2.9 Étude théorique sur le monitoring et kubernetes 1 jour 13/05/2022 14/05/2022
2.10 Étude théorique sur prometheus et alerte-manager 2 jours 14/05/2022 16/05/2022
2.11 Étude théorique sur grafana 7 jours 16/05/2022 23/05/2022
3 Mise en œuvre de la solution proposée 30 jours 30/05/2022 29/06/2022
3.1 Etude et maîtrise de l’environnement linux Ubuntu 6 jours 30/05/2022 05/06/2022
3.2 Préparation de l’environnement de travail 2 jours 05/06/2022 07/06/2022
3.3 Installation du Docker, Minikube et Kubernetes 1 jours 07/06/2022 18/06/2022
3.4 Installation Prometheus, Alertmanager et Grafana 10 jours 18/06/2022 20/06/2022
3.5 Configurer Grafana avec Prometheus 2 jours 20/06/2022 21/06/2022
3.6 Configurer Grafana avec Prometheus 1 jours 21/06/2022 29/06/2022
3.7 Teste l’efficacité du la solution 8 jours 21/04/2022 29/04/2022
4 Partie manageriale 1 jours 21/04/2022 21/04/2022
4.1 La rédaction de l’introduction du PFE 1 jours 21/04/2022 21/04/2022
4.2 Préparation du questionnaire et le transmettre en direction des parties prenantes 1 jours 21/04/2022 21/04/2022
4.2 Etablir une synthèse globale des résultats 1 jours 21/04/2022 21/04/2022
5 Phase finale 13 jours 21/04/2022 21/04/2022
5.1 Vérification totale du mémoire 6 jours 21/04/2022 21/04/2022
5.2 Préparation de la soutenance 7 jours 21/04/2022 21/04/2022
Tab. V.1 : Structure WBS
V.3 Diagramme de GANTT

Afin de Modélisez la planification des taches requise pour notre projet nous avons utilisé le
diagramme de Gantt où chaque tâche est représentée par une barre horizontale de longueur propor-
tionnelle à sa durée. Qui procure une lecture simple.
42
Fig. V.1 : Diagramme de GANTT
V.4 Impact réel du projet sur le fonctionnement de l’entreprise

Après la mise en place de telle solution, nous devons mener une analyse d’impact afin d’iden-
tifier toutes les conséquences d’un changement sur les collaborateurs, processus, métiers, moyens
matériels et moyens humains, Néanmoins nous ne pouvons pas observe l’impact pour une organisa-
tion possédant aussi peu de serveur tel que l’ENSTICP.
Afin de bien savoir l’apport de notre projet, nous avons effectué une enquête auprès de diffé-
rentes grandes entreprises ou nous camarade de promos ont effectué leur stage, nous avons envoyé
le questionnaire a une quinzaine de développeurs, administrateurs et managers à travers LinkedIn et
onze personnes ont répondu aux questionne que nous avons distribués, nous avons ensuite calculé les
tendances (Voir tableau V.2).
Pour calculer les tendances, nous avons utilisé la grille de pondération d’échelle à quatre (04)
niveaux de consentement, présentée ci-dessous, qui met en évidence l’impact de notre solution : • Pas
du tout d’accord (1) • Plutôt en désaccord (2) • D’accord (3) • Tout à fait d’accord (4) Et nous avons
calculé les tendances selon la règle : ((a1x1) + (a2x2) + (a3x3) + (a4x4)) /(x1+x2+x3+x4).
Dans cette partie nous allons analyser les différents résultats obtenus :
43
Réponses
Questions Tendance
1 2 3 4
1-Organisation du travail
1. Je vois un grand intérêt à mettre en place cette proposition 0 2 6 3 3.09
2. De nouveaux procédés de travail ont été développés par cette solution technique 0 2 7 2 3
3. Je peux utiliser cette solution sans être dérangé (pas d’interférence, pas de conflit de priorité avec d’autres dispositifs) 3 4 1 3 2.36
4. Je vois des inconvénients si je ne mets pas en place cette proposition 3 2 2 4 2.63
5. Cette solution technique nous a permis d’améliorer notre mode de fonctionnement 2 1 6 2 2.72
2- Moyens mis à la disposition pour réussir la mise en place de la solution
6. J’ai à ma disposition tous les outils de travail nécessaires à la mise en place de cette solution technique 1 2 4 4 3
7. J’ai toute la documentation nécessaire pour concrétiser cette solution technique 2 5 3 2 2.63
8. L’aménagement de mon environnement de travail est favorable pour accomplir cette solution 3 2 2 5 3
9. La procédure de travail s’accommode avec cette solution 2 1 5 3 2.81
3- Moyens humains (collègues, support en compétences)
10. J’ai le support nécessaire pour accomplir cette solution 0 0 4 7 3.63
11. Cette solution me permet d’améliorer mes compétences techniques 0 3 5 3 3.27
12. De nouvelles compétences sont développées au sein de notre structure suite à la mise en place de cette solution 2 1 4 4 2.9
4- Gestion (encadrement et hiérarchie)
13. Mes comportements et mes résultats au travail se sont améliorés 0 0 5 6 3.54
14. Mes tâches et responsabilités sont mieux définies par mes responsables dans le cadre de cette solution technique 0 0 7 4 3.36
15. Les performances de ma structure sont améliorées 0 2 7 4 3.36
16. Notre travail est de meilleures qualités 0 0 7 4 3.36
5- Gestion du changement
17. On m’a expliqué pourquoi ils ont mis en place cette solution 1 2 6 2 2.81
18. Après la mise en place de la solution technique, j’ai accepté d’acquérir et/ou modifier mes habitudes 1 2 5 3 3.90
19. Nous accueillons favorablement cette solution 0 4 6 1 3.72
Tab. V.2 : Questionnaire et tendance des avis
1. Les résultats de la première catégorie montrent que notre solution suscite l’intérêt pas mal d’em-
ployés. Car elle permet de gagne un temps considérable ainsi qu’une qualité de travail meilleur
Néanmoins Cette solution peu cause des pertes en premier lieu en raison de manque de compé-
tences et expériences suffisante.
2. les outils et logiciels sont accessible open source mais elle peut exiger un personnel possédant
des compétences spécifique qui est l’unique prix de cette solution.
3. Pour cette catégorie nous devons la diviser en deux parties : Pour la première catégorie elle
concerne les développeurs, ils pensent majoritairement que la solution est bénéfique pour leur
travail néanmoins il existe une partie important qui s’oppose à cause des compétences requises.
Pour cette catégorie nous devons la diviser en deux parties :
• Pour la première catégorie elle concerne les développeurs, ils pensent majoritairement
que la solution est bénéfique pour leur travail néanmoins il existe une partie important qui
s’oppose à cause des compétences requises.
• La deuxième partie quant à elle, concerne les administrateurs réseaux qui disent que leur
solution leur convient parfaitement car elle permet de gagner du temps et de mieux orga-
nise leur travail sans exige un travail ou une formation supplémentaire
La première partie concerne les administrateurs réseau qui disent que l’implémentation
de cette solution permet d’améliorer et organiser leur travail, bien que cette solution ne
44
nécessite ni formation ni travail supplémentaire.
La première partie concerne les administrateurs réseau qui disent que l’implémentation
de cette solution permet d’améliorer et organiser leur travail, bien que cette solution ne
nécessite ni formation ni travail supplémentaire.
4. La mise en place de cette solution permet une meilleur organisation du travail, la division des
équipes et leur rôle et responsabilité est similaire aux conceptions des microservices le type
d’arrangement des équipes est similaire à la manière dont les microservices ont été conçu ce
qui permet une communication plus fluide de cérémonies agiles plus fructueuses et d’itérations
plus rapides sur des fonctionnalités ciblées.
5. La majorités des personnes interrogée adhèrent complétement à cette solution et sont prêts à
prendre des initiatives pour adapter leur habitues et acquérir les compétences techniques re-
quises mais il existe une catégorie de personnes qui ne sont pas d’accord ou pas prêt à entre-
prendre ce changement et qui voit que la solution contient plus inconvénient que de bénéfices.
6. La mise en place de cette solution permet une meilleur organisation du travail, la division des
équipes et leur rôle et responsabilité est similaire aux conceptions des microservices le type
d’arrangement des équipes est similaire à la manière dont les microservices ont été conçu ce
qui permet une communication plus fluide de cérémonies agiles plus fructueuses et d’itérations
plus rapides sur des fonctionnalités ciblées
7. La majorités des personnes interrogée adhèrent complétement à cette solution et sont prêts à
prendre des initiatives pour adapter leur habitues et acquérir les compétences techniques re-
quises mais il existe une catégorie de personnes qui ne sont pas d’accord ou pas prêt à entre-
prendre ce changement et qui voit que la solution contient plus inconvénient que de bénéfices.
V.5 Synthèse
Après l’analyse des résultats obtenus du questionnaire diffusé sur LinkedIn a différent per-
sonnes travaillant dans le domaine de la technologie d’information, nous déduisant que les équipes
réseaux sont en faveur du changement, car elle permet des un travail plus simple ainsi une économie
en termes de cout et de travail.
Par contre les équipes de développement réclame une formation pour accepter ce passage vers
la nouvelle solution car elle nécessite quelque compétence afin de pouvoir bénéficier pleinement des
avantages de la nouvelle solution. . Mais une autre refuse catégoriquement ce passage-là. C’est pour
45
cela, des compagnes de sensibilisation doivent être faites dans les directions concernées tout en mettant
l’accent sur l’avantage et le grand apport de la solution.
Conclusion
Après avoir fait une étude managériale sur notre projet et avoir traversé le processus projet en,
on peut dire que notre solution est très intéressante pour l’entreprise car elle a un Retours positifs des
ingénieurs Cloud.
46
Conclusion générale
Aujourd’hui, dans de nombreux environnements des microservices, La fiabilité des systèmes

est l’une des principales priorités. L’objectif principal d’un administrateur système et réseau sera de
maintenir et résoudre le plus rapidement possible tout problème. Ces incidents peuvent avoir un impact
significatif sur les entreprises et leurs clients. Ces clients recherchent fréquemment des outils qu’ils
peuvent utiliser pour évaluer et sécuriser leurs environnements.
Le but de notre projet était d’établir une solution de monitoring centralisée avec Prometheus,
Grafana et Alertmanager afin de gérer les alertes dans un cluster. Nous avons mené à bien cette tâche
en proposant une solution basée sur Docker dans une infrastructure Prometheus/Alertmanager.
Pour bien mener notre projet et répondre aux préoccupations d’ENSTICP, nous nous sommes
basés sur plusieurs étapes. Nous avons d’abord dû comprendre le principe de fonctionnement et l’ar-
chitecture des microservices. Ensuite, nous nous sommes tournés vers la conteneurisation, Docker et
l’orchestrateur Kubernetes et les solutions Grafana, Prometheus et Alertmanager en termes d’adminis-
tration. En suit nous avons fais une étude managériale. Pendant cette expérience nous avons enrichir
nos connaissances théoriques et pratique dans le domaine de la conteneurisation. Donc nous servira
certainement dans le monde de travail.
Au cours du développement de ce travail, certaines difficultés ont été rencontrées, en raison

d’un problème lier les spécifications du Kubernetes.
A l’issu de ce projet, nous avons réussi à maintenir deux critères qui sont la performance et la
Haute disponibilité. Il est attendu de cette solution, une amélioration de la surveillance, analyse simple
de la performance système, prédiction des risques, identification proactive, résolution des problèmes
et protection des données contre les pannes.
Les résultats obtenus sont réalistes et raisonnables par rapport à les circonstances de tests, le
temps entre la notification de détection des alertes et données et la visualisation de ces derniers.
Cette solution permettra à l’entreprise le monitoring du n’importe quel infrastructure conte-
47
neurisé ainsi qu’une gestion de conformité avec flexibilité.
Avant de conclure, nous proposerons comme perspectives, d’intégrer des systèmes d’automa-
tisation comme Ansible pour créer des réactions efficiences et rapides.
48
Références bibliographiques
[1] Redhat . Les microservices, qu’est-ce que c’est ? ? https://www.redhat.com/fr/topics/

microservices/what-are-microservices.
[2] Redhat . Virtualization. https://www.redhat.com/fr/topics/virtualization.
[3] IBM Cloud Education . What is Docker ? https://www.ibm.com/cloud/learn/docker.
[4] MAZOUZ Omar Abdelhak BENHAGOUGA Nour Ouadjdi . “Développement d’une applica-
tion de supervision du réseau informatique de Nokia en suivant l’approche microservices.”
Mém. de mast. INPTIC, oct. 2020.
[5] Docker . Docker overview. https://docs.docker.com/get-started/overview/.
[6] Kubernetes . What is Kubernetes ? https://kubernetes.io/docs/concepts/overview/

what-is-kubernetes/.
[7] Kubernetes . Cluster Architecture. https://kubernetes.io/docs/concepts/architecture/.
[8] J. Turnbull . in Monitoring with Prometheus. Turnbull Press, 2018.
[9] Zabbix . Zabbix Agent. https://www.zabbix.com/zabbix_agent.
[10] prometheus . What is Prometheus ? https : / / prometheus . io / docs / introduction /

overview/.
[11] Prometheus . Alertmanager. https://prometheus.io/docs/alerting/latest/alertmanager/

#alertmanager.
[12] hazelcast . Time Series Database. https : / / hazelcast . com / glossary / time - series -
database/.
[13] prometheus . FUNCTIONS. https://prometheus.io/docs/prometheus/latest/querying/

functions/.
I
Résumé :
Depuis le début de l’industrie du logiciel. La quantité de logiciels à maintenir a augmenté. Le moni-

toring est sans aucun doute l’un des outils les plus efficaces pour la maintenance des logiciels. La motivation
de cette mémoire est l’introduction de la plateforme docker-container, Kubernetes, prometheus et grafana. En
raison de cela, un nouvel outil de surveillance était nécessaire pour obtenir une visibilité sur l’utilisation des
ressources des services fonctionnant sur la nouvelle plate-forme.
Mots clés : Montoring, Micro services, Docker, Kubernetes, conteneurisation, orchestration, prome-
theuse, grafana.
: ‫ملخص‬
‫ المراقبة هي بلا شك واحدة من أكثر الأدوات فعالية‬.‫ زادت كمية البرامج المراد صيانتها‬.‫منذ بداية صناعة البرمجيات‬
. Grafana‫ و‬Prometheus Kubernetes، Docker، ‫ الدافع من هذه الأطروحة هو تقديم منصة حاويات‬.‫لصيانة البرامج‬
‫ كانت هناك حاجة إلى أداة مراقبة جديدة للحصول على رؤية لاستخدام الموارد للخدمات التي تعمل على النظام‬،‫لهذا السبب‬
.‫الأساسي الجديد‬
prometheuse, ،‫ التنظيم‬،‫ الحاوية‬Kubernetes، Docker، ،‫ نهج الخدمات المصغرة‬،‫أ المراقبة‬: ‫كلمات مفتاحية‬
grafana.
Abstract :
Since the beginning of the software industry. The amount of softwares to maintain has increased. Mo-
nitoring is undoubtedly one of the most effective tools for software maintenance. The motivation for this dis-
sertation is the introduction of the docker-container platform, Kubernetes, prometheus and grafana. Because
of this, a new monitoring tool was needed to gain visibility into the resource usage of services running on the
new platform.
Keywords : Monitoring, Microservices, Docker, Kubernetes, containerization, orchestration, prome-

theus, Grafana

PFE Master INPTIC Anis Final

Transféré par

Droits d'auteur :

Formats disponibles

PFE Master INPTIC Anis Final

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PFE Master INPTIC Anis Final

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR MINISTERE DE LA POSTE ET DES

ECOLE NATIONALE SUPERIEURE DES TECHNOLOGIES DE L’INFORMATION ET

Domaine : Sciences et Technologies

Monitoring d'une infrastructure

Soutenu, le : …/…/2022, devant le jury composé de :

Mme. ALLAM MAA ENSTICP Président

Année Universitaire : 2021/2022

“ A la lumière de mes jours, la source de mes efforts, la flamme de

Liste des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII

Liste des tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX

Liste des abréviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X

I Généralités sur les microservices et la conteneurisation . . . . . . . . . . . . . . . . . 3

II.1.3 Conteneur Docker : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

III Monitoring et ces outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

I.1 Architecture microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

II.1 Architecture docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

III.1 L’architecture de Prometheus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

IV.1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

IV.20 Les informations du déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

V.1 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

I.1 Machine virtuel vs Conteneur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

V.1 Structure WBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

API Application Programming Interface

CPU Central Processing Unit.

CLI Command-Line Interface

CNCF Cloud Native Computing Foundation

DNS Domaine Name System

DevOps Software Development System Administration

HTTPS HyperText Transfer Protocol Security

IOT Internet Of Things

MAC Media Access Control

PromQL Prometheus Query Language

RAM Random access memory

REST Representational State Transfer

TCP Transmission Control Protocol

TSDB Time Series Data Base

UDP User Datagram Protocol

VLAN Virtual Local Area Network

Il est attendu de cette solution l’optimisation des coûts ; en améliorant le fonctionnement du

• Garantir la fiabilité et la disponibilité des serveurs

• valoriser l’image de l’entreprise

• pour rester en phase avec l’évolution du marché

• Le premier chapitre expose quelques généralités qui permettront de comprendre le concept du

• Le quatrième chapitre expliquera Le développement et la mise en place de notre solution.

• Le cinqième chapitre est consacré à l’aspect managérial de notre projet.

• Ce travail sera clôturé par une conclusion générale et des perspectives.

Généralités sur les microservices et la

Fig. I.1 : Architecture microservices

I.1.2 Avantages de l’approche microservices

• Amélioration de la productivité : La décomposition d’une application en fragments auto-

déployé et géré indépendamment, et peut utiliser différents langages de programmation, diffé-

• Intégration continue / délivrance continue (CI/CD) : L’intégration continue et la délivrance

• Optimiser les fonctionnalités de l’entreprise : Lorsque la concentration se fait sur un ser-

I.1.3 Inconvénients de l’approche microservices

Fig. I.2 : L’architecture du virtualisation

La conteneurisation implique la création de conteneurs séparés au niveau du système d’exploi-

Il existe quelques technologies de conteneurisation qui offrent des outils de conteneurisation