République de Côte d’Ivoire

Union-Discipline-Travail

Ministère de la Communication et de
l’Economie Numérique

Ecole Supérieure Africaine des Technologies

Année académique : 2021-2022
de l’Information et de la Communication

MEMOIRE DE FIN DE CYCLE POUR L’OBTENTION DU DIPLÔME DE MASTER

ETUDE ET MISE EN PLACE D’UN

ORCHESTRATEUR DE CONTENEURS DANS UN
ENVIRONNEMENT DEVOPS
M-22.KOU.152
Présenté par :
KOUAME Kouabenan Désiré Daniel
Mémoire soutenu publiquement le 17 septembre 2022

Encadrants académiques Maitre de stage

Professeur SORO Etienne M. DIABY Cheick Oumar
(Maître de conférences à l’ESATIC) (Ingénieur support et
Dr KONE Kigninman Désiré maintenance à NGSER)

(Maître assistant à l’ESATIC)

Membre du jury :
Président : Professeur KONATE ADAMA, enseignant chercheur à l’INPHB
Rapporteur : Dr BAMBA Aliou, Maitre-assistant à l’ESATIC
Assesseur : M DEALOUE Dodo Alexis, consultant senior télécom à TEXXIUM
Membre : M COULIBALY Bamba Mamadou, enseignant à l’ESATIC
 République de Côte d’Ivoire

Union-Discipline-Travail
Ministère de l’Economie Numérique
et de la Poste

Ecole Supérieure Africaine des Technologies

de l’Information et de la Communication Année académique : 2021-2022

MEMOIRE DE FIN DE CYCLE POUR L’OBTENTION DU DIPLÔME DE MASTER

ETUDE ET MISE EN PLACE D’UN

ORCHESTRATEUR DE CONTENEURS DANS UN
ENVIRONNEMENT DEVOPS
M-22.KOU.152
Présenté par :
KOUAME Kouabenan Désiré Daniel
Mémoire soutenu publiquement le 17 septembre 2022

Encadrants académiques Maitre de stage

Professeur SORO Etienne M. DIABY Cheick Oumar
(Maître de conférences à (Ingénieur support et
l’ESATIC) maintenance à NGSER)
Dr KONE Kigninman Désiré
(Maître assistant à l’ESATIC)
Membre du jury :
Président : Professeur KONATE ADAMA, enseignant chercheur à l’INPHB
Rapporteur : Dr BAMBA Aliou, Maitre-assistant à l’ESATIC
Assesseur : M DEALOUE Dodo Alexis, consultant senior télécom à TEXXIUM
Membre : M COULIBALY Bamba Mamadou, enseignant à l’ESATIC
DEDICACE
Je dédie ce mémoire à mes parents pour leur amour inestimable, leur confiance, leur aide, leurs
sacrifices et pour toutes les valeurs qu’ils ont su m’inculquer.

I
REMERCIEMENTS
Ce travail que nous avons l’honneur de présenter est le fruit de l’implication et l’aide de façon
directe ou indirecte de plusieurs personnes. Nos chaleureux remerciements vont à l’endroit de :

Professeur KONATE Adama, Directeur général de l’ESATIC, pour la mise en place

de cet environnement de formation dans lequel nous avons beaucoup appris ;
Docteur SORO Etienne, Directeur de la pédagogie de l’ESATIC, pour la création d’un
environnement pédagogique de qualité ;
Professeur ASSEU Olivier, Directeur des Recherches et de l’Innovation
Technologique (DRIT) de l’ESATIC, pour la facilitation des travaux de recherches ;
M ELLEPO Sébastien, Directeur général et M KASSI Michel, Directeur général
adjoint de la Nouvelle Génération de Service (NGSER), pour avoir bien voulu de nous
comme stagiaire ;
M DJOUBATE Djakaridja (Senior manager du département projet), M
MAGASSOUBA Cheik Oumar et M TENEMAGA Coulibaly tout deux chef projet
a NGSER, pour le partage de connaissances ;
M DIABY Cheick Oumar, notre maître de stage, pour les conseils et consignes qu’il
nous a apporté ;
A toute l’équipe de NGSER, pour fraternité ;
Dr KONE Kigninman Désiré, notre encadrant académique pour la qualité de la
supervision ;
Tout le personnel de l’ESATIC notamment le personnel administratif, pour l’éducation
moral ;
Corps enseignant, pour l’enseignement donné tout au long de notre formation ;
Membres du jury qui donneront de leurs temps pour venir noter notre travail ;
M KOUASSI Kouamé Jean-Baptiste, mon père pour la confiance et le soutien moral ;
A toute ma famille pour la confiance qu’il me témoigne chaque jour ;
Nos amis de classe pour les explications de certaines notions essentielles à la
compréhension du sujet.

II
SOMMAIRE
INTRODUCTION

PARTIE I : ETUDE GENERALE

CHAPITRE I : ETUDE DE L’EXIXTANT

I. PRESENTATION DE L’ENTREPRISE
II. PRESENTATION DU PROJET D’ETUDE
III. ETUDE DU SYSTEME DE PRODUCTION LOGICIEL DE
NGSER

CHAPITRE II : ETAT DE L’ART SUR

L’ENVIRONNEMENT ET LES OUTILS
D’ORCHESTRATIONS DevOps

I. ETAT DE L’ART SUR L’ENVIRONNEMENT DevOps

II. ETUDES DES OUTILS D’ORCHESTRATION DevOps
III. CHOIX DE LA SOLUTION

PARTIE II : REALISATION DE LA SOLUTION,

PRESENTATION DES RESULTATS ET DISCUSSIONS

CHAPITRE III : REALISATION DE LA SOLUTION

I. ARCHITECTURE
II. MISE PLACE DE LA SOLUTION

CHAPITRE IV : PRESENTATION DES RESULTATS ET

DISCUSSIONS

I. PRESENTATION DES RESULTATS

II. DISCUSSIONS

CONCLUSION

III
LISTE DES TABLEAUX
Tableau II. 1: Tableau comparatif virtualisation et conteneurisation ....................................... 20

Tableau II. 2 : Tableau comparatif des conteneurs .................................................................. 28

Tableau II. 3 : Tableau comparatif des orchestrateurs ............................................................. 45

Tableau IV. 1 : Tableau du planning du projet......................................................................... 62

Tableau IV. 2: Tableau de l'estimation financière du projet .................................................... 63

IV
LISTE DES FIGURES
Figure I. 1 : Organigramme de NGSER ..................................................................................... 5

Figure I. 2 : Système de production logiciel de NGSER ........................................................... 9

Figure II. 1: Principes de la méthodologie DevOps [1] ........................................................... 15

Figure II. 2: Architecture machine virtuel ................................................................................ 18

Figure II. 3: Hyperviseur type 1 et 2 ........................................................................................ 18

Figure II. 4: Architecture conteneur [2] ................................................................................... 19

Figure II. 5: Différence entre Virtualisation et Conteneurisation [3] ....................................... 22

Figure II. 6: Fonctionnement de Docker .................................................................................. 25

Figure II. 7: Fonctionnement de CRI-o .................................................................................... 28

Figure II. 8 : Architecture Docker Swarm ................................................................................ 30

Figure II. 9 : Fonctionnement de Docker Swarm ..................................................................... 32

Figure II. 10 : Architecture de sécurité de Docker Swarm ....................................................... 33

Figure II. 11: Architecture global de Docker Swarm ............................................................... 34

Figure II. 12: Architecture de Kubernetes ................................................................................ 35

Figure II. 13 : Architecture de Rancher .................................................................................... 43

Figure III. 1: Architecture semi-automatique avec Rancher .................................................... 52

Figure III. 2: Architecture semi-automatique avec Rancher .................................................... 53

Figure III. 3: Fenêtre de connexion de Rancher ....................................................................... 57

Figure IV. 1: Page d'accueil de Rancher .................................................................................. 58

Figure IV. 2 : Terminal du serveur Rancher ............................................................................ 59

Figure IV. 3 : Page de gestion de cluster.................................................................................. 59
Figure IV. 4: Tableau de bord Rancher .................................................................................... 60
Figure IV. 5 : page de déploiement .......................................................................................... 60
Figure IV. 6 : Page de création d'un déploiement .................................................................... 61
Figure IV. 7 : Page du déploiement éffectif ............................................................................. 61

V
LISTE DES ABREVIATIONS
CI/CD : Intégration Continue/Déploiement Continu) ;

VM : Machine virtuelle ;

NGSER : Nouvelle génération de service ;

CAMS : Culture, Automatisation, Mesure, Partage ;

KPIs : Indicateurs Clés de Performances ;

Etcd : Serveur de stockage ;

API : Interface de Programmation ;

SAN : Réseau de serveur ;

TU : Test Unitaire ;

CPU : Unité centrale de traitement ;

ROM : Mémoire morte ;

RAM : Mémoire vive ;

IP : Protocol Internet ;

AWS : Service Web d’Amazon ;

CNI : Interface réseau de conteneurs ;

CRI : Interface exécution de conteneur ;

CSO : Opérateur de sécurité des conteneurs ;

DevOps : Développement Opérations ;

EBS : Elastic Block Store ;

ECS : Elastic Container Service ;

ELB : Equilibrage de charge élastique;

ESATIC : Ecole Supérieure Africaine des Technologies de l’Information et de

Communication ;

IAM : Identification et gestion des accès ;

OCI : Initiative pour les conteneurs ouverts ;

VI
PSP : Politique de sécurité des pods ;

QOS : Qualité de Service ;

RHEL : Red Hat Enterprise Linux ;

SMB : Serveur Message en Block ;

STS : Service d’émission de jeton de sécurité ;

TLS : Sécurité de la couche de transport ;

VPC : Cloud Privé Virtuel ;

WSL : Sous-système Windows de Linux.

VII
INTRODUCTION
Le génie logiciel est une discipline qui consiste à concevoir des applications et à les mettre à
disposition des clients. Cette mise à disposition, appelée déploiement est très souvent faite
manuellement. Cela occasionne des délais énormes, de la lenteur et provoque parfois des pertes
de données. Les mises à jour se font périodiquement car les déploiements sont fastidieux. Et il
se pose un réel problème de sécurité dû aux faits de l’intervention omniprésente de l’homme
dans le système. Tous ces problèmes sont à la base de forte dépense pour les entreprises. Le
génie logiciel connait aujourd’hui une avancée considérable au niveau de ces entreprises à
travers des nouvelles méthodologies innovatrices telle que le DevOps. Le DevOps, considéré
comme une méthodologie émergente capable d’automatiser tout le processus de production
d’un logiciel prend en charge des technologies qui répondent aux besoins et enjeux de demain.
Parmi ces technologies on peut citer les conteneurs qui sont des micro-services packagés avec
leurs dépendances et leurs configurations, utilisés pour construire des applications modernes.
Cela permet aux applications de fonctionner de manière identique quel que soit l’environnement
dans lequel elles sont déployées. Un orchestrateur est un logiciel open-source ou payant qui
permet de déployer et de gérer ces conteneurs, même en cas de besoins d’extension de ces
derniers. Il permet de faire migrer les applications de l’environnement de développement vers
d’autres environnements sans générer de problèmes au cours de l’opération et assure la
disponibilité de l’application. Cette technologie est actuellement en vogue auprès des
entreprises. C’est pour ne pas être en marge de cette évolution technologique que le thème
suivant nous a été donné : « ETUDE ET MISE EN PLACE D’UN ORCHESTRATEUR DE
CONTENEUR DANS UN ENVIRONNEMENT DEVOPS ». Ce sujet est d’une grande
utilité pour nous en tant qu’étudiant en réseaux et télécommunications car il nous permettra de
mettre en pratique nos connaissances apprises au cours de notre cursus académique. Afin de
mener à bien cette étude il serait plus judicieux de répondre aux questions suivantes :

➢ Comment mettre en place un orchestrateur de conteneur dans un environnement

DevOps ?
➢ Qu’est-ce qu’un orchestrateur de conteneurs en environnement DevOps ?

➢ Quels sont les diffèrent orchestrateurs de conteneurs dans ce type d’environnement ?

➢ Quelles sont les fonctionnalités et les outils ou encore les technologies nécessaires pour
réaliser une telle solution ?

1
Pour une analyse rigoureuse de ce sujet nous suivrons un plan qui est le suivant. La première
partie portera sur la généralité autour du sujet. C’est le lieu de présenter l’entreprise, le projet
d’étude et de faire un état de l’art sur le DevOps puis une étude comparative des outils
d’orchestration DevOps. Dans la seconde partie, il sera question de faire dans un premier temps,
la mise en place de la solution avant de passer à la phase de discussion ou nous poserons toutes
les difficultés dû à notre projet. Nous finirons ce mémoire par une conclusion.

2
PARTIE I : ETUDE GENERALE

3
CHAPITRE I : PRESENTATION DU SYSTÈME DE
PRODUCTION LOGICIEL DE NDSER

I. LA STRUCTURE D’ACCEUIL
La société NGSER (Nouvelle Génération de Services) est une Société à Responsabilité
Limitée (SARL) à capitaux ivoiriens Créée en 2008. Elle fournit des services dans le domaine
des télécommunications, des banques, des systèmes d’informations et dans les nouvelles
technologies de l’information et de la communication. Notamment, dans la conception
d’application mobile et web. L’entreprise se situe dans la ville d’Abidjan précisément dans la
commune de Plateau à l’avenue Lamblin, au sein de l’immeuble MATCA, et occupe les
troisièmes et quatrièmes étages de cet immeuble.
1. Activités
NGSER s’attèle à offrir à sa clientèle une large palette de services dans divers domaines dont :
➢ Les Télécommunications : L’entreprise est spécialisée dans l’exploitation,
l’administration, le développement des réseaux de télécommunications et dans les
systèmes de transmission numériques et la gestion des systèmes fixes et mobiles ;
➢ Internet of Things (IOT) : Ce sont les services associés aux objets connectés ;
➢ Le Développement d’applications web et mobiles : NGSER offre la possibilité à ses
clients d’obtenir des applications répondant à leurs exigences vis-à-vis des activités
qu’ils mènent. NGSER développe alors des compétences dans la maîtrise de l’utilisation
des outils de conceptions lui permettent de suivre tout type de projets web quel que soit
ses contraintes technologiques ;
➢ E-payement : Le système monétique de NGSER offre un large éventail de choix aux
clients finaux dans leur processus de paiement en ligne. L’entreprise met en œuvre un
système interopérable et entièrement sécurisé pour garantir fiabilité, irréversibilité et
totale contrôle ;
➢ La Cyber sécurité : Avec ses partenaires technologiques, NGSER travaille à la
sécurisation des systèmes d’informations critiques dans différents secteurs d’activité
tels que la loterie, l’électricité, le transport, la banque, le secteur publique, etc ;
➢ La Blockhain : NGSER offre une technologie qui permet un stockage infaillible, une
transparence entière et une sécurité maximale des informations ;

4
 ➢ L’ERP (Enterprise Ressource Planning) : est un progiciel qui permet de gérer
l’ensemble des processus d’une entreprise intégrant l’ensemble de ses fonctions comme
la gestion des ressources humaines, la gestion financière et comptable, l’aide à la
décision, la vente, la distribution, l’approvisionnement, la production ou encore du e-
commerce.

Il faut noter que l’entreprise NGSER intervient aussi dans la gestion électronique de documents
(GDE), le E-Archives, Customer Relationship Management (CRM), le Big Data, Business
Intelligence. Dans la réalisation de ses activités, NGSER a plusieurs clients tels que : Orange,
MTN, MOOV, NOKIA, HUAWEI, MYRIAD, NSIA BANQUE, CNAM, LONACI.
2. Organigramme de NGSER
Comme la majorité des entreprises, NGSER suit une division hiérarchique des différentes
entités qui la constituent. L’organigramme de l’entreprise de l’entreprise se trouve dans la
figure I.1.

Figure I. 1 : Organigramme de NGSER

La direction générale se trouve en tête de structure. Il s’agit de l’organe de décision de

l’entreprise. Elle donne les directives à suivre et oriente l’entreprise. Elle est dirigée par M
ELLOPO SEBASTIEN en qualité de gérant. Le département projet est dirigé par M
DJOUBATE DJAKARIDJA (Senior Manager).

5
C’est au sein de ce département que nous avons effectué notre stage. Ce département est chargé
de faire la planification de tous les projets et d’en faire le suivi pour que ceci soit bien conçut
et rendu dans les délais.

II. PRESENTATION DU PROJET

1. Contexte

Avant les années 2007 les entreprises de digitalisation, pour la conception et le déploiement de
leurs applications avaient un système constitué de deux équipes travaillant de façons séparées.
D’une part, nous avions l’équipe des développeurs chargé de la conception des applications et
d’autre part l’équipe d’exploitation responsable de la mise en production de ces applications.
Ces deux équipes étaient confrontées à des problèmes à cause de la différence entre
l’environnement de développement et de déploiement des logiciels. En effet, L’équipe de
production était accusée par l’équipe de développement de provoquer des retards dans les
livraisons et l’équipe de développement était tenue responsable des incidents en production par
l’équipe d’exploitation. Afin de palier à ce souci majeur, entre les années 2007 et 2008 est
apparu le terme DevOps, qui va concilier ces deux métiers en intégrant des outils adaptés à cet
effet. L’approche DevOps vient pour l’automatisation de toutes la chaine de déploiement d’un
logiciel. Ceux qui permet aux deux équipes de travailler en collaboration en partageant le même
objectif. Celui d’apporter à l’entreprise du profit et des services répondant aux exigences
clients. En outre, NGSER applique d’ores et déjà cette méthodologie. Mais, elle n’intègre pas
un système contenant des outils permettant d’automatiser tout le processus de monitoring des
applications. Ce qui rend le système complexe à maintenir. En effet, les outils utilisés par
l’équipe support de NGSER ne permettent pas d’assurer la continuité de service (indisponibilité
partielle des applications), le monitoring continu des applications et n’informe pas sur l’état des
applications dans le système. Le monitoring ou intégration et déploiement continu des
applications est le fait d’automatiser toute la chaine de production d’un logiciel depuis le code
jusqu’au déploiement. C’est en cela que, pour pallier ces insuffisances, nous avons décidés de
compléter l’architecture utilisée en implémentant un outil pour orchestrer non seulement le
système. Mais, aussi qui intègre des fonctionnalités de supervision. Dans le chapitre suivant,
nous ferons une étude détaillée de l’architecture de production logiciel de NGSER afin d’en
déceler les limites.

6
 2. Cahier des charges du projet
2.1. Travail à faire

L’automatisation de toutes la chaine de déploiement d’un logiciel dans les entreprises pour les
clients exige une bonne méthodologie avec des outils adaptés. Les outils DevOps semblent
constituer le meilleur moyen de réussir à mettre en place et de façon optimale ces exigences
qui, de nos jours sont indispensables dans le processus de productions logiciel au niveau des
entreprises informatiques. De ce fait, trois principales tâches sont à accomplir dans ce projet.
Ce sont :

❖ Faire un état de l’art sur le DevOps et ses outils

L'élaboration d’un déploiement continue des applications nécessitent des études poussées pour
obtenir un résultat qui répond aux exigences de l’environnement dans lequel l’on souhaite les
utiliser. Dans le cadre de ce projet, il convient de faire une étude méticuleuse des outils DevOps
existants.

❖ Faire une étude comparative des différents outils

Afin de mettre en place un outil adapté à notre environnement, il est judicieux de faire l’étude
minutieuse des outils d’automatisation DevOps déjà existant afin d’en déceler leurs principales
caractéristiques. Nous nous baserons sur ses résultats afin de proposer un outil adapté à notre
réalité.

❖ Intégrer et déployer la solution retenue

Une plateforme en tant que service (PaaS) sera implémentée pour faciliter l’intégration et le
déploiement des applications.

2.2. Objectifs

L’objectif dans ce projet est de mettre en place un outil capable d’assurer l’automatisation
complet de toute la chaine de production des applications pour les entreprises de digitalisation
tout en orchestrant les conteneurs sur lesquels ces applications tournent. Plus spécifiquement, il
sera question de mettre en place un outil capable :

• De permettre l’intégration et le déploiement continu des applications a NGSER ;

• Faire des mises à jour des applications de façon automatique ;
• De permettre la disponibilité des applications à tout moment pour les clients ;
• D’avoir une visibilité sur les applications déployer ;

7
 • De donner des notifications sur l’état de chaque application en cas d’incident ;
• De raccourci le time to marcket (temps mis entre l’idée d’un projet et sa réalisation) : Gain
de temps ;
• D’accroître la sécurité des applications hébergées sur les serveurs ;
• De s’adapter aux besoins des utilisateurs ;
• Avoir une vue globale sur toute l’architecture à travers une interface graphique.

III. ETUDE DE L’EXISTANT

Nous ne pouvions commencer ce projet sans avoir une idée claire et précise sur l’existant quel
qu’il soit. La première tâche a été de rencontrer différentes personnes qui entretiennent
directement ou indirectement une relation avec le service informatique de NGSER. Après quoi,
nous avons menés différentes recherches avant de débuter le travail. Cette méthodologie de
travail nous a permis d’avoir une connaissance large de l’existant. Dans cette partie, nous
procèderons à une présentation générale du fonctionnement du système de production avant
d’entrer dans les détails avec le principe de fonctionnent même du système. Nous terminerons
en donnant les limites de ce fonctionnement et nous proposerons une solution.

1. Présentation du système de production logiciel actuel de NGSER

1.1. Architecture

Pour le monitoring (toutes les étapes d’intégration et déploiement d’une application) des
applications, NGSER a en sa possession le département technique informatique (DTI) constitué
de deux équipes. D’une part les développeurs et d’autres part l’équipe de DevOps qui
fonctionne avec la méthodologie DevOps dont le fonctionnement sera présenté dans la figure
I.2, ci-dessous.

8
 Figure I. 2 : Système de production logiciel de NGSER

Ce département, pour la production des applications a un fonctionnement qui vous sera présenté
dans la suite des travaux à travers cette architecture dont le principe de fonctionnement sera
explicité dans le point suivant.

1.2. Principe de fonctionnement

Afin d’avoir un time to market (le temps mis entre l’idée d’un projet et sa mise en place) réduit,
le département technique informatique opte pour l’approche DevOps dont le fonctionnement
en son sein est décrit comme suit :

➢ Equipe de développement, Chargée de la production du code des applications

informatiques, utilisent l’outil Git pour versionner leurs codes sur leurs propres
machines. Ces codes, une fois terminées sont poussées par le développeur sur un dépôt
distant de code source appelé GitLab (1) ;
➢ Ensuite, ces codes sont bulder et déployer sur le serveur de recette par les développeurs
eux même pour des tests (2) ;
➢ Par la suite, si les tests s’avèrent satisfaisant, les développeurs font un merge sur la
branche de pré-production de GitLab (3) ;
➢ Et informent l’équipe DevOps de la disponibilité du code sur cette branche (4) ;

C’est en ce moment qu’intervient l’équipe DevOps charger du déploiement des applications

sur les différents serveurs.

9
 ➢ Dans un premier temps, ils récupèrent les applications déposées par les développeurs
sur la branche de pré-production du dépôt distant GitLab (5) ;
➢ Puis les déploient sur le server de pré-production dans des conteneurs pour des tests par
l’équipe projet (6) ;
➢ Et font un mail de notification à l’équipe projet (7) ;
➢ L’équipe projet fait les tests (8) ;
➢ Puis, fait un retour aux développeurs si les tests sont mauvais, ou aux DevOps si les
tests sont OK (9) ;
➢ Si tests sont OK le DevOps fait un merge sur la branche production sinon les
développeurs reprennent le processus avec des corrections (10) ;
➢ Si et seulement si les tests sont OK, le DevOps fait le déploiement en production pour
les clients (11).

Ce fonctionnement a priori s’accommode avec les objectifs actuels de l’entreprise. Cependant,

quand sera-t-il des objectifs futurs quant au fait que l’entreprise devra déployer des centaines
de millier d’application sur diffèrent conteneur dans différents nœuds (servers) ?

2. Limites
Comme évoqué un peu plus haut, le fonctionnent actuel pour la production de logiciel de
NGSER sera très vite obsolète quand il sera question du déploiement en masse des applications.
Comme limite, on peut citer entre autres :

➢ Difficile de surveiller les différents nœuds : une fois les applications déployées sur les
environnements, il est impératif pour le DevOps de se connecter à chaque server
manuellement à chaque fois qu’il veut voir leurs états de fonctionnement ;
➢ Pas d’extensibilité du système : le système n’est pas capable de s’adapter
automatiquement aux besoins des clients ;
➢ Aucune notification : il serait plus intéressant pour l’équipe DevOps lors du merge de
l’application sur la branche de pré-production par les développeurs d’avoir une
notification soit par mail, slack, télégramme, etc ;
➢ Aucune alerte : en cas d’incident sur un cluster ; il n’y a aucun moyen de savoir l’état
du système ;
➢ Pas d’orchestration : le système n’est pas capable de coordonner, gérer les conteneurs
des nœuds ;

10
 ➢ Lenteur dans les déploiements : quand le code source d’une application est disponible
sur la branche de pré-production, le DevOps est dans l’obligation d’aller le chercher
avant de le déployer sur les différents servers. Or, le simple fait de déclencher tous se
processus après le merge du code sur la branche de production serait plus judicieux ;
➢ Pas de visibilité globale sur l’architecture : avoir une interface graphique sur laquelle
l’on pourrait observer l’architecture mise en place serais un plus ;
➢ Un système vulnérable au niveau sécurité : le système actuel utilise un outil de
conteneurisation pour le déploiement des applications qui apport une certaine sécurité
et autres avantages. En effet, les conteneurs sont conçus pour isoler les applications les
unes des autres, mais n'oublions pas que les applications conteneurisées exécutées sur
un nœud utilisent le même système d'exploitation. Dans cette situation, le système
d'exploitation (ou le moteur de conteneurisation) peut devenir une vulnérabilité. Que se
passerait-il, par exemple, si un pirate lançait une attaque par déni de service contre le
système d'exploitation du serveur ? Cette attaque pourrait se solder par une panne
touchant plusieurs applications. De même, que se passerait-il si le système d'exploitation
plantait en raison d'une défaillance au niveau du noyau ?

3. Solutions envisagées
Pour pallier à ces inconvénients après l’étude ci-dessus menée, nous sommes arrivés à la
conclusion qui consiste à compléter le système de fonctionnement actuel avec un outil qui aurait
la capacité d’absorber les limites citées un peu plus haut. En d’autres termes, il sera question de
mettre en place un outil d’orchestration offrant une interface nous permettant dans un premier
temps de voir l’historique de tous les évènements qui surviennent sur les servers dans lesquels
nos applications seront déployées. Et dans un second temps, nous permettre de déclencher
automatiquement l’intégration et le déploiement continue de nos applications à partir d’un
niveau bien précis (lorsque le développeur effectue un merge sur la branche de production de
GitLab).

Dans la suite de nos travaux nous procèderons à une étude de l’existant qui consistera à faire
un état de l’art de l’environnement DevOps sur lequel nous nous appuierons pour mener une
étude sur les différents outils d’orchestration qui y sont utilisés afin d’en ressortir celui le mieux
adapté à nos besoins.

11
CHAPITRE II : ETAT DE L’ART SUR L’ENRIRONNEMENT
ET LES OUTILS D’ORCHESTRATION DevOps

I. ETAT DE L’ART SUR L’ENRIRONNEMENT DevOps

Régulièrement évoqué dans le chapitre précèdent, le termes DevOps requiert à présent toutes
notre attention. Il sera question dans ce chapitre de faire une étude plus ou moins détaillée de
l’environnement DevOps. Plus précisément, nous verrons un bref historique accompagner
d’une définition claire de l’environnement DevOps. Suivi des principes et des pratiques qui
l’incombe. Et enfin nous nous attèlerons à donner les outils nécessaires pour sa bonne mise en
œuvre avant d’en donner les avantages et les limites.

1. Historique

Le terme DevOps vient de la concaténation des mots « développement » et « opérations ».

Autrefois, le développement et les opérations étaient séparés dans le domaine du logiciel dans
les entreprises. Les équipes de développement écrivaient le code, et les administrateurs système
étaient responsables de son déploiement et de son intégration. La communication entre ces deux
silos était limitée, et les spécialistes de chaque domaine travaillaient séparément sur un même
projet. Ce mode opératoire était satisfaisant lorsque la méthode de développement était
prédominante. Toutefois, avec l’essor de la méthode Agile et du flux de travail continu, un
changement s’est imposé. Les fréquents remous, survenant entre ses deux équipes, imposaient
une nouvelle approche et de nouveaux rôles. C’est ainsi que l’approche DevOps a vu le jour.
Aujourd’hui, cette approche de développement logiciel est de plus en plus populaire. Elle est
utilisée par Facebook, Netflix, Amazon, etc… et d’autres entreprises mondialement connues.
L’origine du DevOps est liée aux besoins d’innovation en matière de développement logiciel.
Les concepts DevOps se sont popularisés à la fin des années 2000. C’est toutefois en 2009 que
ce terme a été réellement inventé par Patrick Debois et Andrew Clay Shafer.

2. Définition

La méthode DevOps est un ensemble de pratique (une philosophie) et d’outils ayant pour but
d’automatiser les processus entre les équipes de développement et de production. En d’autres
termes, Le DevOps est une approche conciliant le développement et les opérations.
Couramment utilisée dans le domaine du développement logiciel, elle est aussi adoptée pour la
Data Science et le Machine Learning.

12
Pour profiter des avantages du DevOps, il est important de comprendre qu’il ne s’agit pas d’un
ensemble d’actions, mais plutôt d’une philosophie. L’idée n’est pas d’apporter des changements
techniques, mais de modifier la manière dont les équipes travaillent.

3. Principes du DevOps

Le DevOps repose avant tout sur un ensemble de principes. En 2010, Damon Edwards et John
Willis ont résumé ces principes à travers l’acronyme « CAMS » : Culture, Automation,
Measurement, Sharing (culture, automatisation, mesure, partage en français).

3.1. Culture

La méthode DevOps repose avant tout sur une culture, un état d’esprit de collaboration entre
les équipes de développement et d’opérations. Cette culture repose sur la collaboration et la
communication constante, les changements graduels, le partage de responsabilité et la
résolution précoce et hâtive des problèmes.

3.2. Automatisation

Il consiste en l’automatisation systématique des procédures de développement, de test, de

configuration et de déploiement. Dès lors que l’automatisation est possible, il faut saisir
l’opportunité pour éliminer les tâches répétitives et chronophages et pouvoir se focaliser sur les
activités importantes qui ne peuvent être automatisées.

3.3. Mesure des KPIs

La mesure des KPIs (Indicateurs Clés de Performances) permet de suivre en permanence le

progrès des activités composant le flux DevOps. Ceci permet de prendre des décisions basées
sur des informations factuelles, de comprendre ce qui fonctionne et ce qui ne fonctionne pas, et
donc d’optimiser les performances.

3.4. Partage

Le partage est essentiel. Les équipes doivent partager le feedback, les meilleures pratiques et le
savoir afin de favoriser la transparence, de créer une intelligence collective et d’éliminer les
contraintes.

4. Les pratiques DevOps

La philosophie et les principes DevOps s’appliquent à travers un modèle de cycle de livraison

comprenant la planification, le développement continu, le test continu, le déploiement continu,

13
la release et la surveillance. Les pratiques DevOps améliorent en continu et automatisent les
processus. Bon nombre d'entre elles portent sur une ou plusieurs phases du cycle de
développement :

➢ La planification doit être agile. Le travail s’organise autour de courtes itérations

appelées ” sprints “. Ceci permet d’augmenter le nombre de relaxes et d’intensifier leur
rythme. Concrètement, seuls les objectifs de haut niveau sont fixés. En parallèle, les
équipes planifient à l’avance et de façon détaillée une ou deux itérations. Ce mode
opératoire offre une flexibilité.
➢ Le concept de développement continu repose, lui aussi, sur une approche itérative.
Tout le travail de développement est décomposé en petites portions, pour une production
plus rapide et de meilleure qualité. Les ingénieurs apportent des contributions au code
sous forme de petits morceaux plusieurs fois par jour, afin de faciliter les tests.
➢ Les tests sont eux aussi continus et automatisés. Une équipe en charge de l’assurance
qualité teste le code à l’aide d’outils automatisés comme Selenium et Ranorex. Si des
bugs ou des vulnérabilités sont découverts, les extraits de code sont renvoyés aux
ingénieurs. Le contrôle de version permet aussi de détecter les problèmes d’intégration
à l’avance. Si le code passe les tests, il est intégré à un dépôt unique et partagé sur un
serveur. Ceci permet d’éviter les différences entre le code principal et ses branches afin
d’éviter les problèmes d’intégration. Il s’agit du concept d’intégration continue. De son
côté, la livraison continue consiste à automatiser le développement, le test et le
déploiement du code.
➢ Le déploiement continu : ici, le code est déployé pour être exécuté en production sur
un serveur public, de façon à ne pas affecter les fonctionnalités existantes tout en étant
accessible à un large panel d’utilisateur. Le déploiement fréquent permet de tester les
nouvelles fonctionnalités de façon précoce. On utilise différents outils comme Chef,
Puppet, Azure Resource Manager ou Google Cloud Deployment Manager.
➢ Le monitoring continu : Il s’agit de surveiller en permanence le projet pour détecter
les éventuels problèmes d’un processus et d’analyser le feedback de l’équipe et des
utilisateurs pour pouvoir améliorer le fonctionnement du produit.
➢ Le déploiement continu à l'instar de la livraison continue est une pratique qui
automatise la publication d'un code nouveau ou modifié dans l'environnement de
production. Les entreprises peuvent être amenées à publier plusieurs fois par jour des
modifications du code ou des fonctionnalités.

14
 ➢ La surveillance continue : Cette pratique prévoit une surveillance continue du code
exécuté et de l'infrastructure sous-jacente. Les développeurs reçoivent des retours sur
les bogues ou sur les problèmes. La figure ci-dessous résume bien tous les termes
développés. La figure II.1 donne plus de détails sur ces propos.

Figure II. 1: Principes de la méthodologie DevOps [1]

5. Outils utilisés

Pour implémenter les pratiques DevOps, il est nécessaire d’utiliser différents outils pour couvrir
toutes les étapes du processus de livraison continue. Si certains processus sont automatisés à
l’aide de scripts, la plupart des ingénieurs DevOps utilisent divers produits dédiés. A savoir :

➢ Puppet, pour la configuration et la gestion de serveurs ;

➢ Chef est utilisé pour la gestion de l’infrastructure en tant que code ;
➢ Ansible automatise la gestion de configuration, l’approvisionnement de Cloud et le
déploiement d’application ;
➢ Pour les étapes d’intégration et de livraison continue (CI/CD), on utilise Jenkins et ses
plugins.
➢ La plateforme GitLab est l’outil DevOps utilisé pour le stockage des codes sources des
développeurs ;
➢ Docker, pour la conteneurisation des applications ;
➢ OpenShif, Docker Swarm et Kubernetes ou encore Rancher sont exploités pour
l’orchestration de conteneurs ;
➢ Pour le monitoring en DevOps, nous avons des outils comme Nagios et ses rapports
visuels ou la solution open source Prometheus.

Toutes ces plateformes constituent un arsenal complet permettant d’implémenter la

méthodologie DevOps.

15
 6. Avantages et inconvénients

Pour les entreprises qui suivent les pratiques DevOps, les avantages commerciaux et techniques
sont évidents et la plupart contribuent à améliorer la satisfaction des clients. Comme avantage
on peut citer entre autres :

➢ Accélération et amélioration de la fourniture des produits ;

➢ Résolution plus rapide des problèmes et complexité réduite ;
➢ Plus grande évolutivité et disponibilité inégalée ;
➢ Stabilité accrue des environnements d'exploitation ;
➢ Meilleure utilisation des ressources ;
➢ Automatisation accrue ;
➢ Meilleure visibilité sur les résultats du système ;
➢ Innovation renforcée ;
➢ Un développement plus rapide ;
➢ La mise au point plus rapide des mises à jour et des versions de développement ;
➢ La sécurité augmentée grâce aux contrôles continus ;
➢ Plus de nouveautés grâce à l’accélération des étapes de production ;
➢ Une fiabilité renforcée grâce aux tests menés en parallèle du développement ;
➢ Une productivité augmentée grâce à un meilleur travail au sein des et entre les équipes.

L’approche DevOps offre de nombreux avantages pour le développement, qui sont tangibles
non seulement pour les clients, mais également pour les entreprises. La collaboration entre les
équipes assure non seulement une meilleure cohérence et une meilleure compréhension globale,
mais empêche également la compartimentation des savoirs dans les différents départements. La
capacité des équipes à résoudre les problèmes s’améliore donc considérablement.
L’inconvénient est que : Si la direction de l’entreprise ne communique pas suffisamment sur
les avantages du système et que les collaborateurs sont sceptiques quant aux changements des
processus de travail que cela implique, il y a un risque que les employés ne soutiennent pas le
concept et que cela entraîne des frictions au sein des équipes ou entre les différents services. Il
est donc essentiel de bien communiquer les avantages de l’approche DevOps afin que les
collaborateurs ne se sentent pas limités dans leur domaine d’activité.

16
 II. ETUDE DES OUTILS D’ORCHESTRATION DevOps
Au paravent, le déploiement des applications se fessait directement sur les systèmes
d’exploitation des serveurs sur lesquels l’on souhaite déployer l’application. Cette manière de
faire engendrait beaucoup de souci d’incompatibilité entre le server et l’application. D’où, les
applications sont passées du déploiement sur le système de la machine physique, au
déploiement de façon virtuel à travers des hyperviseurs qui permettaient d’installer sur le
système d’exploitation d’une machine physiques, des machines virtuelles.

Bien que cela résolve les problèmes de portabilité et de sécurité en partie, il existait toujours
des problèmes d’incompatibilité et chaque machines virtuelle avaient son propre SE. Ceux qui
épuisait les ressources de la machine. C’est de la que les conteneurs vus le jour. Dans cette
partie, nous verrons la différence entre la virtualisation et la conteneurisation, puis étudierons
les différents outils de conteneurisation avant de passer à l’étude des orchestrateurs.

1. Virtualisation et Conteneurisation

La virtualisation et la conteneurisation sont les deux mécanismes les plus fréquemment

utilisés pour héberger des applications dans un système informatique. Dans les lignes
suivantes nous verrons chacun en détails ainsi que leurs particularités.

1.1. Virtualisation

La virtualisation nous aide à créer des versions logicielles ou virtuelles d'une ressource
informatique. Ces ressources informatiques peuvent inclure des dispositifs
informatiques, du stockage, des réseaux, des serveurs ou même des applications. Elle
permet aux organisations de partitionner un seul ordinateur physique ou serveur en
plusieurs machines virtuelles (VM). Chaque VM peut alors interagir indépendamment
et exécuter différents systèmes d'exploitation ou applications tout en partageant les
ressources d'un seul ordinateur. Le logiciel hyperviseur facilite la virtualisation. Un
hyperviseur se trouve au-dessus d'un système d'exploitation. Mais, nous pouvons
également avoir des hyperviseurs qui sont installés directement sur le matériel. Les
hyperviseurs prennent les ressources physiques et les divisent afin que les
environnements virtuels puissent les utiliser. Lorsqu'un utilisateur ou un programme
envoie une instruction à la machine virtuelle qui nécessite des ressources
supplémentaires de l'environnement physique,

17
l'hyperviseur relaie la demande au système physique et met en cache les modifications.
Il existe deux types d'hyperviseurs, le type 1 (barre métal) et le type 2 (hébergé). La
principale caractéristique de la virtualisation est qu'elle vous permet d'exécuter
différents systèmes d'exploitation sur le même matériel. Le système d'exploitation de
chaque machine virtuelle (OS invité) effectue toutes les activités de démarrage
nécessaires telles que l'amorçage, le chargement du noyau, etc. Cependant, chaque
système d'exploitation invité est contrôlé par des mesures de sécurité élevées afin qu'il
n'acquière pas un accès complet au système d'exploitation sous-jacent [1]. Les figures
II.2 et II.3, rendent plus explicite ces propos.

Figure II. 2: Architecture machine virtuel

Figure II. 3: Hyperviseur type 1 et 2

1.2. Conteneurisation

La conteneurisation est une alternative légère à la virtualisation. Cela implique

d'encapsuler une application dans un conteneur avec son propre environnement
d'exploitation.

18
Ainsi, au lieu d'installer un système d'exploitation pour chaque machine virtuelle, les
conteneurs utilisent le système d'exploitation hôte. Chaque conteneur est un package
exécutable de logiciel qui s'exécute sur un système d'exploitation hôte. Un hôte peut
prendre en charge plusieurs conteneurs simultanément. Par exemple, dans un
environnement d'architecture de micro-services, cette configuration fonctionne car tous
les conteneurs s'exécutent sur le processus minimal isolé des ressources auxquelles les
autres ne peuvent pas accéder [2].

Figure II. 4: Architecture conteneur [2]

Le diagramme précédent illustre la disposition de l'architecture conteneurisée.

Au bas de la couche, il y a des infrastructures physiques telles que le processeur, le

stockage sur disque et les interfaces réseaux. Au-dessus de cela, il y a le système
d'exploitation hôte et son noyau. Le noyau fait le pont entre le logiciel du système
d'exploitation et les ressources matérielles. Le moteur de conteneur et son système
d'exploitation invité minimal se trouvent au-dessus du système d'exploitation hôte. Tout
en haut, il y a des binaires, des bibliothèques pour chaque application et les applications
qui s'exécutent sur leurs espaces utilisateur isolés.

1.3. Comparaison

Dans la virtualisation traditionnelle, un hyperviseur virtualise le matériel physique. Le

résultat est que chaque machine virtuelle contient un système d'exploitation invité, une
copie virtuelle du matériel dont le système d'exploitation a besoin pour s'exécuter, ainsi
qu'une application et ses bibliothèques et dépendances associées.

19
Des machines virtuelles avec différents systèmes d'exploitation peuvent être exécutées
sur le même serveur physique. Par exemple, VMware peut s'exécuter à côté d'une VM
Linux, qui s'exécute à côté d'une VM Microsoft. Au lieu de virtualiser le matériel sous-
jacent, les conteneurs virtualisent le système d'exploitation (généralement Linux ou
Windows) afin que chaque conteneur individuel ne contienne que l'application, ses
bibliothèques et ses dépendances. Les conteneurs sont petits, rapides et portables car,
contrairement à une machine virtuelle, les conteneurs n'ont pas besoin d'inclure un
système d'exploitation invité dans chaque instance et peuvent, à la place, simplement
exploiter les fonctionnalités et les ressources du système d'exploitation hôte. Tout
comme les machines virtuelles, les conteneurs permettent aux développeurs d'améliorer
l'utilisation du processeur et de la mémoire des machines physiques. Cependant, les
conteneurs vont encore plus loin, car ils permettent également des architectures de
micro-services, où les composants d'application peuvent être déployés et mis à l'échelle
de manière plus granulaire [3]. Il s'agit d'une alternative intéressante à la mise à l'échelle
d'une application monolithique entière car un seul composant est aux prises avec la
charge. Résumons la comparaison entre la virtualisation et la conteneurisation sur
différents aspects dans le tableau II.1.

Tableau II. 1: Tableau comparatif virtualisation et conteneurisation

Environnement Virtualisation Conteneurisation

Isolement Fournit une isolation complète du Fournit généralement une

système d'exploitation hôte et des
autres machines virtuelles
isolation légère de l'hôte et des
autres conteneurs, mais ne
fournit pas une limite de
sécurité aussi solide qu'une
machine virtuelle

Système Exécute un système d'exploitation Exécute la partie en mode

d’exploitation complet, y compris le noyau,
nécessitant ainsi plus de ressources
système telles que le processeur, la
mémoire et le stockage
utilisateur d'un système
d'exploitation et peut être
personnalisé pour contenir
uniquement les services
nécessaires à votre application

20

Compatibilité Exécute à peu près n'importe quel
avec l’hôte système d'exploitation à l'intérieur de
la machine virtuelle.
Déploiement Déploie des machines virtuelles
individuelles à l'aide du logiciel
Hyperviseur.
Stockage Utilise un disque dur virtuel (VHD)
pour le stockage local d'une seule
machine virtuelle ou un partage de
fichiers SMB (Server Message
Block) pour le stockage partagé par
plusieurs serveurs.
L'équilibrage de L'équilibrage de charge des machines
charge virtuelles est effectué en exécutant
des machines virtuelles sur d'autres
serveurs dans un cluster de
basculement.
La mise en Utilise des adaptateurs réseau virtuels. Utilise une vue isolée d'une
réseau
21
en utilisant moins de ressources
système
Fonctionne sur la même version
du système d'exploitation que
l'hôte.
Déploie des conteneurs
individuels ou Déploie
plusieurs conteneurs à l'aide
d'un orchestrateur.
Utilise des disques locaux pour
le stockage local pour un nœud
unique ou SMB pour le
stockage partagé par plusieurs
nœuds ou serveurs.
Un orchestrateur peut
automatiquement démarrer ou
arrêter des conteneurs sur des
nœuds de cluster pour gérer les
changements de charge et de
disponibilité.
carte réseau virtuelle. Ainsi,
fournit un peu moins de
virtualisation.
 Figure II. 5: Différence entre Virtualisation et Conteneurisation [3]

1.4. Avantages des conteneurs

En utilisant des conteneurs, les utilisateurs évitent les pannes liées aux incompatibilités
entre environnements et bénéficient de performances homogènes sur toutes les
machines. Les développeurs peuvent ainsi se concentrer sur l’application elle-même
plutôt que sur son débogage ou sa réécriture pour différents environnements de
serveurs. Et comme les conteneurs sont dépourvus de système d’exploitation, les
développeurs peuvent les déployer en clusters de manière efficace, sachant que chaque
conteneur renferme les composants uniques d’une application complexe. En
répartissant les composants dans des conteneurs distincts, les développeurs se donnent
également la possibilité de les modifier individuellement plutôt que de remanier
l’application tout entière.

Les conteneurs présentent un ensemble de caractéristiques particulièrement

intéressantes pour les développeurs :

➢ Taille : un conteneur ne pèse que quelques dizaines de Méga octet ;

➢ Vitesse : les conteneurs s’exécutent quasi instantanément ;

➢ Portabilité : Les conteneurs fonctionnent quel que soit l’environnement ;

➢ Modularité : Les développeurs peuvent diviser les conteneurs en modules plus

petits ;

➢ Autonomie : Chaque application est exécutée virtuellement dans son propre

conteneur de taille réduite ;

➢ Coût : Les conteneurs génèrent peu de surcoûts.

22
 2. Les outils de conteneurisation

Chaque fois qu'une application doit être déplacée d'un environnement à un autre, c'est-
à-dire d'une machine à une autre, de la boîte de test à la boîte de production, de la
machine physique au cloud ou à toute autre plate-forme, il y a toujours un défi que
l'application fonctionnera de manière fiable dans un environnement différent. Si
l'environnement logiciel de prise en charge n'est pas identique à son environnement
précédent (il peut y avoir une différence dans le stockage, la topologie du réseau, la
version du logiciel, les politiques de sécurité, etc.), alors l'application commence à se
comporter de manière étrange. Afin de surmonter ce défi, nous disposons d'un logiciel
de conteneur qui fonctionne sur le concept de conteneurisation au niveau du système
d'exploitation. Le logiciel de conteneur comprend l'environnement d'exécution
complet, c'est-à-dire l'application, ses dépendances, tous les fichiers de prise en charge,
les outils et les paramètres de configuration qui sont conservés dans un seul package.
En conteneurisant, les différences dans l'infrastructure de l'environnement peuvent être
extraites. Aujourd’hui, plusieurs solutions de gestion de conteneurs sont disponibles.
Certaines d'entre elles sont open source tandis que d'autres sont sous licence et payantes.
Voyons les plus utilisées compte tenu de leur efficacité [3].

2.1. Docker

Docker est un logiciel de conteneurisation qui effectue la virtualisation au niveau du

système d'exploitation. Le développeur de ce logiciel est Docker Inc.

La version initiale de ce logiciel a vu le jour en 2013 [4]. Il est écrit en langage de

programmation « Go ». Il s’agit d’un logiciel freemium en tant que service et possède
la licence Apache 2.0 comme licence de code source. Avec la technologie Docker, l’on
peut traiter les conteneurs comme des machines virtuelles très légères et modulaires.
En outre, ces conteneurs offrent une grande flexibilité : ils permettent de créer,
déployer, copier et déplacer d'un environnement à un autre, ce qui vous permet
d'optimiser vos applications pour le cloud. La technologie Docker utilise le noyau
Linux et des fonctions de ce noyau, telles que les groupes de contrôle cgroups et les
espaces de noms, pour séparer les processus afin qu'ils puissent s'exécuter de façon
indépendante. Cette indépendance reflète l'objectif des conteneurs :

23
Exécuter plusieurs processus et applications séparément les uns des autres afin
d'optimiser l'utilisation de votre infrastructure tout en bénéficiant du même niveau de
sécurité que celui des systèmes distincts. Docker permet aussi d'automatiser le
déploiement des applications (ou d'ensembles de processus combinés qui forment une
application) au sein d'un environnement de conteneurs. Les conteneurs docker assurent
quatre fonctions essentielles : la modularité, les couches de contrôle des versions
d'image, la restauration et le déploiement rapide.

2.1.1. La modularité

L'approche de Docker en matière de conteneurisation repose sur la décomposition des

applications : c'est-à-dire la capacité de réparer ou de mettre à jour une partie d'une
application sans devoir désactiver l'ensemble de cette dernière. En plus de cette
approche basée sur les micro-services, Docker vous permet de partager des processus
entre différentes applications quasiment comme vous le feriez avec une architecture
orientée services (SOA).

2.1.2. Les couches et contrôle des versions d'image

Chaque fichier image Docker est composé d'une série de couches. Ces couches sont
assemblées dans une image unique. Chaque modification de l'image engendre la
création d'une couche. Chaque fois qu'un utilisateur exécute une commande, comme
run ou copy, une nouvelle couche se crée. Docker réutilise ces couches pour la
construction de nouveaux conteneurs, accélérant ainsi le processus de construction. Les
modifications intermédiaires sont partagées entre les images, ce qui optimise la vitesse,
la taille et l'efficacité. Qui dit superposition de couches, dit contrôle des versions.

À chaque changement, un journal des modifications est mis à jour afin de vous offrir
un contrôle total des images de votre conteneur.

2.1.3. La restauration

C’est sans doute la fonction la plus intéressante de la superposition de couches. Chaque

image est composée de couches. Aussi, si l'itération actuelle d'une image ne vous
convient pas, vous pouvez restaurer la version précédente. Cette fonction favorise le
développement agile et vous aide à mettre en œuvre les pratiques d'intégration et de
déploiement continus (CI/CD) au niveau des outils.

24
 2.1.4. Le développement rapide

Avant, il fallait plusieurs jours pour mettre en place du nouveau matériel, le faire
fonctionner, l'approvisionner et le rendre disponible. C'était un processus complexe et
fastidieux. Aujourd'hui, avec les conteneurs Docker, l’on peut effectuer tout cela en
quelques secondes seulement. En créant un conteneur pour chaque processus, il est
possible de rapidement partager les processus similaires avec les nouvelles
applications. L’inconvénient avec Docker et de façons générale les logiciels de
conteneurisation, c’est qu’à mesure qu'augmente le nombre de conteneurs et
d'applications conteneurisées (tous décomposés en centaines de composants), la gestion
et l'orchestration se complexifient. C’est là qu’intervient les orchestrateurs que nous
verrons bien sûr plus tard.

Figure II. 6: Fonctionnement de Docker [4]

2.2. Linux containers-LXC

Les conteneurs Linux utilisent une collection d'utilitaires Linux natifs open source pour
créer une expérience d'exécution de conteneur. L'objectif du conteneur Linux est
d'offrir un environnement neutre pour le développement des technologies de
conteneurs. Docker utilise LXC dans les coulisses. Ces conteneurs s'efforcent de
maintenir l'expérience du conteneur aussi proche que possible de celle d'une machine
virtuelle [5]. LXC est une plateforme de conteneurs open source qui promet une
utilisation simple et une expérience utilisateur intuitive et moderne. Pour cela, la
plateforme offre différents outils, langues, modèles et bibliothèques.

25
Il assure un développement plus rapide des applications. La technique de conteneurs
aide notamment pour le portage, la configuration et l’isolation. Les Linux Containers
s’adaptent à l’infrastructure ce qui les rend hautement indépendants et permet donc de
les utiliser aussi bien en local que sur un Cloud ou dans un environnement hybride.
Coté avantage, la facilité d’utilisation des Linux Container est un gros avantage
comparé aux techniques de virtualisation classiques. Cependant, la très large diffusion
de LXC, l’écosystème presque complet et les outils innovants sont principalement dus
à la plateforme Docker, qui a mis en place les conteneurs Linux. Comparé à d’autres
systèmes de conteneurs. Un inconvénient majeur de LXC se situe au niveau de la
gestion de la mémoire : bien que différents backend de mémoire (ivm, overlayfs, zfs et
btrfs) soient pris en charge, par défaut, la mémoire est stockée directement sur le rootfs.
Il manque une option d’enregistrement pour les images. D’autres plateformes de
conteneurs offrent des solutions plus intelligentes et plus flexibles pour le stockage des
conteneurs et la gestion des images. Une image Docker est un modèle en lecture seule,
utiliser pour créer des conteneurs Docker. Elle est composée de plusieurs couches
empaquetant toutes les installations, dépendances, bibliothèques, processus et codes
d'application nécessaires pour un environnement de conteneur pleinement opérationnel.
L’alternative la plus populaire à LXC est Docker. La plateforme basée sur les
conteneurs Linux a été développée en continu au cours des dernières années et
fonctionne désormais sur les systèmes Windows. Ainsi les plus gros fournisseurs Cloud
comme Google IBM, AWS et Azure assurent la prise en charge native de Docker.

2.3. CRI-O (Container Runtime Interface)

CRI-O est une implémentation de l’interface d’environnement d’exécution de

conteneurs (Container Runtime Interface, CRI) pour Kubernetes, qui utilise les images
et les environnements d’exécution (runtimes) de « l’Open Container Initiative » (OCI).
Le projet a été lancé en 2016 par l’entreprise « Red Hat » et transféré en 2019 à la «
Cloud Native Computing Foundation » (CNCF) [5]. Pour comprendre le
fonctionnement de CRI-O et son interaction avec les technologies utilisées,

il faut revenir sur l’historique du développement de la virtualisation basée sur les

conteneurs. Le logiciel Docker, qui a popularisé la virtualisation d’applications
individuelles grâce à des conteneurs légers, a servi de base à la création du logiciel.

26
Même s’il est possible d’effectuer l’orchestration avec Docker et des outils comme
Docker Swarm, Kubernetes a réussi à s’imposer comme une alternative à Docker. Lors
de la création de Kubernetes, le daemon Kubernetes kubelet a été doté d’un
environnement d’exécution codé en dur [5]. Mais la nécessité de prendre en charge
d’autres environnements d’exécution s’est rapidement fait sentir. Une modularisation
des aspects individuels promettait un développement simplifié et plus de sécurité. Afin
de rendre différents environnements d’exécution compatibles avec Kubernetes, une
interface a été définie : Container Runtime Interface (CRI). CRI-O est une
implémentation spécifique de cette interface.

CRI-O est composé des éléments suivants :

➢ La bibliothèque de logiciel conteneurs/image pour le téléchargement des

images conteneurs des différentes sources en ligne ;

➢ La bibliothèque de logiciel conteneurs/stockage pour gérer les couches

de conteneurs et créer le système de fichiers des conteneurs d’un pod ;

➢ Un espace d’exécution compatible OCI pour exécuter les conteneurs.

runC est un espace d’exécution standard,

mais il est également possible d’utiliser d’autres espaces d’exécution

compatibles comme Kata Containers ;

➢ L’interface de réseau de conteneurs (« container networking interface »,

CNI) pour la création d’un réseau, utilisation de plug-ins pour Flannel,
Weave et OpenShiftSDN ;

➢ L’outil de surveillance des conteneurs conmon pour une surveillance

continue des conteneurs.

27
 Figure II. 7: Fonctionnement de CRI-o [5]

Ces outils d’orchestrations ainsi présentés peuvent être en local ou en ligne (Cloud)

Tableau II. 2 : Tableau comparatif des conteneurs

Conteneur Prix

CRI-O Open source (en local)

Rktlet – Rkt Open source (en Local)

LXC Open source (en Local)

Docker Open source (en Local)

En entreprise les développeurs utilisent plusieurs machines en parallèles, donc plusieurs

conteneurs. D’où l’intérêt de manager, d’orchestrer ces conteneurs.

3. L’orchestration
3.1. Définition de l’orchestration

L’orchestration de façon générale est l’art de dispatcher un projet en plusieurs taches et de les
attribuer à des personnes ou des choses (orchestre) en fonction de leurs capacités ou leurs
compétences. Et tous cet ensemble est gérer et coordonné par un orchestrateur. Pour faire un
pant sur le sujet qui est le nôtre, on définira de façon spécifique l’orchestration comme
l'automatisation et la gestion du cycle de vie des conteneurs et des services.

28
Il s'agit d'un processus de gestion et d'organisation de plusieurs conteneurs et d'une architecture
de micro-services à grande échelle. Autrement dit, Les conteneurs peuvent être rendus
hautement évolutifs et peuvent être créés à la demande. Gérer quelques conteneurs peut être
aisé, mais imaginez que vous en avez des centaines. Il devient extrêmement difficile de gérer
le cycle de vie du conteneur et sa gestion lorsque le nombre augmente dynamiquement avec la
demande. L'orchestration de conteneurs résout le problème en automatisant la planification, le
déploiement, l'évolutivité, l'équilibrage de charge, la disponibilité et la mise en réseau des
conteneurs.

3.2. Définition de outils d’orchestrations

La gestion d’un ou quelques conteneurs peut sembler facile. Mais avec l’évolution du monde
informatique un administrateur système sera amené à gérer des centaines de millier de
conteneurs. Ceux qui constituera pour lui une tache fastidieuse pouvant créer les problèmes tels
que :

➢ La lenteur dans l’exécution des tâches qui lui sont assignés ;

➢ Oublie de certains accès à certains conteneurs ;
➢ Mise à jour des applications discontinue provoquant plusieurs plaintes ;
➢ Etc.

Pour pallier ces différents inconvénients, il lui faudra un outil capable d’organiser de
coordonner et gérer ou encore de manager ces différents conteneurs. D’où, le terme outil
d’orchestration.

3.3. Etude des différents outils d’orchestrations

Comme cité ci-dessus, les outils d’orchestrations constituent un excellent moyen de palliation
au différent désagrément que peut causer la création de plusieurs conteneurs dans une
architecture de production logiciel basée sur la méthodologie DevOps.

Dans le précédant chapitre nous avons pu entrevoir quelques-uns d’entre eux. Ici nous allons
plus entrer en profondeur pour certains d’entre eux et citer les autres. Il en existe plusieurs.
Nous pouvons citer entre autres :

3.3.1. Docker swarm

➢ Présentation

29
Swarm est le premier gestionnaire de conteneurs Docker, lancé par la société Docker en 2014.
Il est devenu une fonctionnalité native et intégré au daemon Docker depuis 2016 [6].
L'activation du mode Swarm peut pallier les lacunes de Docker en termes de déploiement,
d'exploitation et de gestion sur plusieurs hôtes. Il aide les utilisateurs finaux à créer et à déployer
un cluster de nœuds Docker. Le docker daemon traite les requêtes API afin de gérer les
différents aspects de l’installation tels que les images, les conteneurs ou les volumes de
stockage. Un cluster est un ensemble de nœud (serveur).

➢ Architecture Swarm

Dans Docker Swarm, chaque nœud est un deamon, et tous les démons interagissent à
l'aide de l'API Docker. Chaque conteneur peut être déployé et accessible par les
nœuds du même cluster. Il y a cinq éléments critiques dans un environnement docker
: Docker container, Docker daemon, Docker images, Docker client, Registre Docker
[7].

Figure II. 8 : Architecture Docker Swarm [7]

Docker Swarm peut replanifier les conteneurs en cas de panne de nœud. Le nœud
Swarm a un dossier de sauvegarde (registre docker) que l’on peut utiliser pour
restaurer les données en cas de pertes.

➢ Concepts clés

Il s’agit ici de services, de taches et de nœud.

❖ Services et tâches

30
Les conteneurs Docker sont lancés à l'aide de services. Les services peuvent être
déployés de deux manières différentes : globales et répliquées.

Les services globaux sont responsables de la surveillance des conteneurs qui souhaitent
s'exécuter sur un nœud Swarm. En revanche, les services répliqués spécifient le nombre
de tâches identiques dont un développeur a besoin sur la machine hôte. Ils permettent
aux développeurs de faire évoluer leurs applications. Avant de déployer un service dans
Swarm, le développeur doit implémenter au moins un seul nœud. Il faut clarifier qu’un
service est une description d'une tâche, alors qu'une tâche exécute le travail. Docker
aide ainsi les développeurs à créer des services, qui peuvent démarrer des tâches.
Cependant, lorsqu'une tâche est affectée à un nœud, la même tâche ne peut pas être
attribuée à un autre nœud.

❖ Nœud

Un nœud Swarm est une instance du moteur Docker. Il est possible d'exécuter plusieurs
nœuds sur un seul serveur. Mais dans les déploiements de production, les nœuds sont
répartis sur différents appareils.

➢ Fonctionnement

Il existe deux types de nœuds dans Docker Swarm :

❖ Noeud de gestionnaire : il maintient les tâches de gestion du cluster ;

❖ Nœud travailleur : il reçoit et exécute les tâches du nœud de
gestionnaire.

Concernant le nœud de gestionnaire, il connaît l'état des nœuds de travail dans un

cluster, et les nœuds de travail acceptent les tâches envoyées par le nœud de
gestionnaire. Chaque nœud de travail a un agent qui rend compte de l'état des tâches du
nœud au gestionnaire.

De cette façon, le nœud de gestionnaire peut maintenir l'état souhaité du cluster. Les
nœuds de travail quant à eux communiquent avec le nœud de gestionnaire à l'aide de
l'API sur HTTP. Dans Docker Swarm, les services peuvent être déployés et accessibles
par n'importe quel nœud du même cluster. Lors de la création d'un service, l’on doit
spécifier quelle image de conteneur utiliser. On configure les commandes et les services
pour qu'ils soient globaux ou répliqués :

31
un service global s'exécutera sur chaque nœud Swarm, et sur un service répliqué, le
nœud gestionnaire distribue les tâches aux nœuds de travail. Le fonctionnement du
Swarm peut être résumé comme suit :

Figure II. 9 : Fonctionnement de Docker Swarm [8]

Un service est créé sur la base de l’interface de ligne de commande. L'API que nous
connectons dans notre environnement Swarm nous permet de faire de l'orchestration en
créant des tâches pour chaque service. L'attribution des tâches nous permettra d'allouer
du travail aux tâches via leur adresse IP. Le répartiteur et le planificateur affectent et
ordonnent aux nœuds de travail d'exécuter une tâche. Le nœud de travail se connecte
au nœud de gestionnaire et recherche de nouvelles tâches. La dernière étape consiste à
exécuter les tâches qui ont été affectées du nœud gestionnaire au nœud travailleur
(worker node).

NB : il est important de clarifier que Docker Swarm est un outil d'orchestration de

conteneurs qui vous permet d'exécuter et de connecter des conteneurs sur plusieurs
hôtes. Contrairement à Docker Compose qui est utilisé pour configurer et démarrer
plusieurs conteneurs Docker sur le même hôte.

➢ Caractéristiques

Certaines des fonctionnalités les plus essentielles de Docker Swarm sont :

❖ Accès décentralisé : Swarm permet aux équipes d'accéder et de gérer très

facilement l'environnement ;
❖ Haute sécurité : toute communication entre le gestionnaire et les nœuds clients
au sein du Swarm est hautement sécurisée ;

32
 ❖ Équilibrage de chargement automatique : il existe un équilibrage de chargement
automatique dans votre environnement, et vous pouvez le scripter dans la façon
dont vous écrivez et structurez l'environnement Swarm ;
❖ Évolutivité élevée : l'équilibrage de charge convertit l'environnement Swarm en
une infrastructure hautement évolutive ;
❖ Restauration d'une tâche : Swarm vous permet de restaurer des environnements
dans des environnements sécurisés précédents.
➢ Sécurité de Docker Swarm

Deux fonctions de sécurité clés sont disponibles dans Docker Swarm.

❖ Clé publique (PKI)

Tout d'abord, Docker est livré avec un système d'infrastructure à clé publique (PKI) en
mode swarm qui permet aux administrateurs de déployer en toute sécurité un système
d'orchestration de conteneurs. Docker se désigne comme nœud de gestionnaire chaque
fois qu'un administrateur crée un swarm en exécutant "docker swarm init". C'est alors
que le nœud gestionnaire génère une nouvelle autorité de certification (CA) racine ainsi
qu'une paire de clés pour chiffrer les communications avec les autres nœuds qui
rejoignent swarm à l'aide de Transport Layer Security. Les administrateurs ont la
possibilité de spécifier une autorité de certification racine générée en externe ainsi que
de faire pivoter l'autorité de certification racine de swarm dans le cas où une clé
d'autorité de certification de cluster ou un nœud de gestionnaire serait compromis. Le
mode swarm est en fait celui qui permet de créer un cluster d'un ou plusieurs moteurs
Docker.

Figure II. 10 : Architecture de sécurité de Docker Swarm [8]

❖ Les journaux Raft (Raft logs)

33
Deuxièmement, Docker Swarm crypte les journaux Raft utilisés par les gestionnaires
sur disque afin de protéger les informations de configuration et les données des
attaquants.

La clé TLS utilisée pour chiffrer les communications des nœuds Swarm ainsi que la
clé des journaux Raft sont chargées dans la mémoire de chaque nœud gestionnaire. Les
administrateurs peuvent choisir de protéger ces clés en activant le « verrouillage
automatique », une fonctionnalité qui nécessite que les gestionnaires soient
déverrouillés manuellement avec une clé de chiffrement générée par Docker. Cette
fonctionnalité permet ainsi d'éviter que ces clés de chiffrement ne tombent entre de
mauvaises mains. Raft est un protocole d'implémentation d'un consensus distribué. Un
consensus est un problème qui doit être résolu dans les systèmes distribués tolérants
aux pannes et il implique essentiellement plusieurs serveurs s'accordant sur des valeurs.

Figure II. 11: Architecture global de Docker Swarm[8]

3.3.2. Kubernetes

➢ Présentation

Kubernetes est un outil d'orchestration open source développé par Google pour gérer
des micro-services ou des applications conteneurisées sur un cluster distribué de nœuds.
Il fournit une infrastructure hautement résiliente avec des capacités de déploiement sans
temps d'arrêt, une restauration automatique, une mise à l'échelle et une réparation
automatique des conteneurs (qui consiste en un placement automatique,

34
un redémarrage automatique, une réplication automatique et une mise à l'échelle des
conteneurs en fonction de l'utilisation du processeur). L'objectif principal de
Kubernetes est de masquer la complexité de la gestion d'une flotte de conteneurs en
fournissant des API REST pour les fonctionnalités requises. Kubernetes est de nature
portable, ce qui signifie qu'il peut s'exécuter sur diverses plates-formes cloud publiques
ou privées telles qu'AWS, Azure, OpenStack ou Apache Mesos [8]. Il peut également
fonctionner sur des machines « bare metal ».

➢ Architecture

Kubernetes suit une architecture client-serveur. Il est possible d'avoir une configuration
multimaster (pour une haute disponibilité), mais par défaut, il y a un seul serveur master
qui agit comme un nœud de contrôle et un point de contact. Le master serveur se
compose de divers éléments, notamment un kube-apiserver, un stockage etcd, un kube-
controller-manager, un cloud-controller-manager, un kube-scheduler et un serveur
DNS pour les services Kubernetes. Les composants de nœud incluent kubelet et kube-
proxy au-dessus de Docker.

Figure II. 12: Architecture de Kubernetes [7]

Les principaux composants du master node sont les suivants :

❖ Cluster etcd : un stockage de valeur de clé simple et distribué qui est

utilisé pour stocker les données du cluster Kubernetes (telles que le
nombre de pods, leur état, l'espace de noms, etc.), les objets API et les
détails de découverte de service.

35
 Il n'est accessible que depuis le serveur API pour des raisons de sécurité.
etcd notifie le cluster sur les modifications de configuration à l'aide
d'observateurs. Les notifications sont des requêtes API sur chaque nœud
de cluster etcd pour déclencher la mise à jour des informations dans le
stockage du nœud.
❖ kube-apiserver : Le serveur d'API Kubernetes est l'entité de gestion
centrale qui reçoit toutes les demandes REST de modifications (aux
pods, services, ensembles de réplication/contrôleurs et autres), servant
d'interface au cluster. De plus, c'est le seul composant qui communique
avec le cluster etcd, s'assurant que les données sont stockées dans etcd
et sont en accord avec les détails de service des pods déployés.
❖ kube-controller-manager : il exécute un certain nombre de processus
de contrôleur distincts en arrière-plan (par exemple, le contrôleur de
réplication contrôle le nombre de répliques dans un pod, le contrôleur
de points de terminaison remplit les objets de point de terminaison tels
que les services et les pods, etc.) pour effectuer des tâches de routine.
Lorsqu'un changement dans la configuration d'un service se produit (par
exemple, le remplacement de l'image à partir de laquelle les pods
s'exécutent ou la modification de paramètres dans le fichier YAML de
configuration), le contrôleur détecte le changement et commence à
travailler vers le nouvel état souhaité.
❖ cloud-controller-manager : est responsable de la gestion des processus
de contrôleur avec des dépendances sur le fournisseur de cloud sous-
jacent (le cas échéant). Par exemple, lorsqu'un contrôleur doit vérifier si
un nœud a été résilié ou configuré des routes, des équilibreurs de charge
(load balancing) ou des volumes dans l'infrastructure cloud, tout cela est
géré par le cloud-controller manager.
❖ kube-scheduler : il aide à planifier les pods (un groupe de conteneurs
colocalisés à l'intérieur duquel nos processus d'application s'exécutent)
sur les différents nœuds en fonction de l'utilisation des ressources. Il lit
les exigences opérationnelles du service et le planifie sur le nœud le
mieux adapté. Par exemple, si l'application a besoin d’un Giga octet de
mémoire et de deux cœurs de processeur,

36
 les pods de cette application seront planifiés sur un nœud avec au moins
ces ressources. Le planificateur s'exécute chaque fois qu'il est nécessaire
de planifier des pods. Le planificateur doit connaître le total des
ressources disponibles ainsi que les ressources allouées aux charges de
travail existantes sur chaque nœud. Les principaux composants trouvés
sur un nœud worker sont :
❖ kubelet : le service principal sur un nœud, prenant régulièrement en
compte les spécifications de pod nouvelles ou modifiées
(principalement via le kube-apiserver) et s'assurant que les pods et leurs
conteneurs sont sains et fonctionnent dans l'état souhaité. Ce composant
rend également compte au maître de la santé de l'hôte sur lequel il
s'exécute.
❖ kube-proxy : un service proxy qui s'exécute sur chaque nœud de travail
pour gérer les sous réseaux d'hôtes individuels et exposer les services au
monde extérieur. Il effectue le transfert des demandes vers les
pods/conteneurs appropriés sur les différents réseaux isolés d'un cluster.

➢ Caractéristiques

L'architecture Kubernetes repose sur la disponibilité, l'évolutivité, la portabilité et la

sécurité. Sa conception vise à répartir plus efficacement les charges de travail sur les
ressources disponibles, en optimisant le coût de l'infrastructure.

❖ Évolutivité : Kubernetes fournit une mise à l'échelle horizontale des

pods sur la base de l'utilisation du processeur. Le seuil d'utilisation du
processeur est configurable et Kubernetes démarrera automatiquement
de nouveaux pods si le seuil est atteint. Par exemple, si le seuil est de 70
% pour le processeur, mais que l'application augmente en fait jusqu'à
220 %, 3 pods supplémentaires seront finalement déployés afin que
l'utilisation moyenne du processeur soit inférieure à 70 %. Lorsqu'il
existe plusieurs pods pour une application particulière, Kubernetes
fournit la capacité d'équilibrage de charge entre eux. Kubernetes prend
également en charge la mise à l'échelle horizontale des pods avec état, y
compris les bases de données NoSQL et RDBMS via des ensembles
avec état.

37
 Un ensemble avec état est un concept similaire à un déploiement, mais
garantit que le stockage est persistant et stable, même lorsqu'un pod est
supprimé.
❖ Haute disponibilité : Kubernetes offre une haute disponibilité tant au
niveau de l'application qu'au niveau de l'infrastructure. Les jeux de
réplicas garantissent que le nombre souhaité (minimal) de réplicas d'un
pod sans état pour une application donnée est en cours d'exécution. Les
ensembles avec état jouent le même rôle pour les pods avec état. Au
niveau de l'infrastructure, Kubernetes prend en charge divers backends
de stockage distribué comme AWS EBS, Azure Disk, Google Persistent
Disk, NFS, etc. L'ajout d'une couche de stockage fiable et disponible à
Kubernetes garantit une haute disponibilité des charges de travail avec
état. De plus, chacun des composants maîtres peut être configuré pour
une réplication multi-nœuds (multi-maître) afin d'assurer une plus
grande disponibilité.
❖ Sécurité : Kubernetes traite la sécurité à plusieurs niveaux : cluster,
application et réseau. Les points de terminaison de l'API sont sécurisés
via la sécurité de la couche de transport (TLS). Seuls les utilisateurs
authentifiés (comptes de service ou utilisateurs réguliers) peuvent
exécuter des opérations sur le cluster (via des requêtes API). Au niveau
de l'application, les secrets Kubernetes peuvent stocker des informations
sensibles (telles que des mots de passe ou des jetons) par cluster (un
cluster virtuel si vous utilisez des espaces de noms, physique sinon).
Notez que les secrets sont accessibles depuis n'importe quel pod du
même cluster. Les politiques de réseau pour l'accès aux pods peuvent
être définies dans un déploiement. Une stratégie réseau spécifie
comment les pods sont autorisés à communiquer entre eux et avec
d'autres points de terminaison du réseau.
❖ Portabilité : La portabilité de Kubernetes se manifeste en termes de
choix de système d'exploitation (un cluster peut fonctionner sur
n'importe quelle distribution Linux grand public), d'architectures de
processeur (machines virtuelles ou bare-metal),

38
 de fournisseurs de cloud (AWS, Azure ou Google Cloud Platform) et de
nouveaux runtimes de conteneurs, en plus de Docker, peuvent
également être ajoutés. Grâce au concept de fédération, il peut
également prendre en charge des charges de travail dans des
environnements hybrides (cloud privé et public) ou multi-cloud. Cela
prend également en charge la tolérance aux pannes de la zone de
disponibilité au sein d'un seul fournisseur de cloud.

➢ Sécurité de Kubernetes

Kubernetes Secure est un ensemble de stratégies, de techniques et de technologies

conçues pour sécuriser la plateforme Kubernetes et les conteneurs qu'elle orchestre.

Il repose sur les stratégies suivantes :

❖ Les 4 C de la sécurité cloud native

La sécurité native du cloud est mise en œuvre sur quatre couches clés, appelées les 4 C.
se sont :

- La mesure de sécurité qui protège le code. Par exemple, utiliser des scanners de
vulnérabilité et des pratiques de codage sécurisé ;
- La sécurité au niveau des conteneurs. En effet, restreindre l'accès aux ports réseau
et chiffrer les données en transit ;
- Des clusters sécurisés. Par exemple, définir des politiques de sécurité réseau et
renforcer tous les nœuds maîtres ;
- Et le centres de données cloud ou d'entreprise qui est une mesure de sécurité qui
protègent l'infrastructure. Ceci est généralement mis en œuvre par les fournisseurs
de cloud ou le personnel informatique sur site.
❖ Mécanismes de sécurité dans un cluster Kubernetes

Kubernetes fournit plusieurs concepts et mécanismes pour sécuriser les clusters.

- Politique de réseau : Kubernetes utilise un modèle de réseau plat qui permet à chaque pod
de communiquer par défaut avec n'importe quel autre pod du cluster. Cela crée des
problèmes de sécurité majeurs, car cela permet aux attaquants qui compromettent un pod
de communiquer librement avec toutes les autres ressources du cluster. Pour sécuriser les
communications pod à pod, Kubernetes utilise le concept de politiques réseau.

39
 Une politique réseau est comme un pare-feu virtuel configuré dans chaque pod. Lorsque
des politiques réseau sont définies par un administrateur, elles sont automatiquement mises
à jour au niveau du pod, et le pod accepte ou rejette le trafic réseau en fonction de la
politique. Dans Kubernetes, le mécanisme de définition des communications autorisées ou
non est constitué de sélecteurs d'étiquettes, et non d'adresses ou de plages IP.
- Politique de sécurité des modules : Kubernetes utilisait à l'origine l'objet
PodSecurityPolicy (PSP) pour contrôler la configuration des pods liés à la sécurité. Une
PSP définit les conditions minimales qu'un pod doit remplir pour s'exécuter dans le cluster.
Cependant, PSP s'est avérée difficile à utiliser, présente d'importantes limitations
fonctionnelles et ne peut pas être activé par défaut. La fonctionnalité de remplacement
porte le nom temporaire « Politique de remplacement PSP ». La nouvelle stratégie sera
conçue pour simplifier le déploiement, disposera d'un contrôleur d'admission intégré et sera
facile à utiliser tout en offrant une flexibilité pour les déploiements de production à grande
échelle. Surtout, contrairement à la PSP actuelle, il s'adapter aux clusters existants via un
déploiement en douceur.
- Secrets Kubernetes : Les secrets sont des informations sensibles comme les jetons
d'authentification, les clés SSH ou les mots de passe. Il est dangereux de stocker des secrets
en texte brut dans le cadre d'images de conteneurs ou de configurations de pod, car ceux-
ci peuvent facilement être compromis par des attaquants qui accèdent ensuite à tout
système accessible via ces informations d'identification. La fonctionnalité Kubernetes
Secrets intégrée vous permet de stocker des informations sensibles dans un objet secret
dans Kubernetes. Vous devez d'abord créer un secret, le remplir avec des données secrètes,
mettre à jour un compte de service pour référencer le secret, puis seulement créer des pods
qui utilisent le secret. Un pod peut accéder à un secret en tant que variable d'environnement
ou fichier (c'est ce qu'on appelle un volume secret).
- RBAC Kubernetes : Kubernetes utilise le concept de ClusterRoles et de rôles, qui
spécifient ce que chaque utilisateur peut effectuer dans un cluster ou un espace de noms
Kubernetes entier. ClusterRoleBinding est utilisée pour appliquer un rôle à toutes les
ressources du cluster ou RoleBinding pour appliquer le rôle à chaque ressource dans un
espace de noms. Kubernetes propose des rôles utilisateur par défaut et des rôles
personnalisés supplémentaires :
Cluster-admin : Peut effectuer n'importe quelle action sur
n'importe quoi dans un cluster ;

40
 Admin : Autorise un accès illimité en lecture/écriture aux
ressources d'un espace de noms, mais ne fournit pas d'accès en
écriture à l'espace de noms lui-même ;
Modifier : Autorise l'accès en lecture/écriture dans un espace de
noms, mais n'autorise pas l'affichage ou la modification des rôles
et des liaisons ;
Afficher : Comme Modifier, mais autorise l'accès en lecture
seule dans un espace de noms.
❖ Authentification

Le point d'accès principal d'un cluster Kubernetes est l'API Kubernetes. Les utilisateurs et les
rôles de service y accèdent via l'utilitaire kubectl, les requêtes API REST directes ou les SDK
client. Par défaut, l'API est accessible via le port 445 et est protégée par Transport Layer
Security (TLS).

Le processus d'authentification de l'API Kubernetes fonctionne comme suit :

- Le client tente d'accéder à l'API, présente un certificat client TLS et une connexion
TLS est établie ;
- Le serveur API exécute un ou plusieurs modules Authenticator . Ceux-ci permettent
aux administrateurs de cluster de définir des comptes d'utilisateur et de service et
de spécifier des stratégies d'authentification, y compris des certificats client, des
jetons, des jetons Web JSON et des mots de passe ;
- Les modules d'authentification acceptent l'intégralité de la requête HTTP du client
et tentent de l'authentifier. S'il y a plusieurs modules d'authentification, ils sont
essayés un par un jusqu'à ce qu'un réussisse ;
- Si l'authentification échoue, l'API renvoie le code d'état 401. Si elle réussit, le client
est authentifié en tant que username et peut utiliser ce nom d'utilisateur dans les
activités suivantes ;
- Le module d'authentification peut attribuer l'appartenance au groupe d'utilisateurs.
Si c'est le cas, l'utilisateur aura les privilèges supplémentaires du groupe.

❖ TLS pour l'entrée Kubernetes

Kubernetes Ingress est un objet qui permet d'accéder aux services d'un cluster
Kubernetes depuis l'extérieur du cluster.

41
Il facilite les connexions via HTTP/S, et précise les règles de routage. Pour sécuriser un
objet Ingress, vous spécifiez un secret contenant deux clés tls.crt et tls.key qui
contiennent respectivement le certificat et la clé privée. Le chiffrement TLS fonctionne
jusqu'au point d'entrée et le trafic au sein du cluster n'est pas chiffré par défaut. Si la
configuration d'entrée comprend plusieurs hôtes, ils sont multiplexés sur le même port.

❖ Qualité de service

Kubernetes attribue automatiquement une classe de qualité de service (QoS) aux pods,
ce qui permet d'optimiser la planification et l'éviction des pods. Le kubelet utilise une
classe QoS pour décider de l'ordre dans lequel les pods sont expulsés des nœuds et pour
prendre des décisions plus intelligentes lors de la planification des pods sur les nœuds.
Les équipes DevOps peuvent personnaliser les classes QoS pour les pods si nécessaire.

3.3.3. Rancher

➢ Présentation

Rancher est une plate-forme d’orchestration de conteneur open source créer par la
société RANCHER LAB. Il s'exécute sur linux et repose sur Kubernetes. Il prend en
charge les fonctions intégrées de mise à l'échelle, de surveillance, de journalisation et
de mesure. Il aide à l'automatisation des applications sur des ressources sécurisées et
évolutives dans des environnements de cloud hybride. Il fournit des plates-formes de
niveau entreprise pour la création, le déploiement et la gestion d'applications
conteneurisées. Rancher dispose de diverses fonctionnalités pour gérer les clusters via
l'interface utilisateur et la CLI.

➢ Architecture

Rancher comprend les couches et composants suivants, et chaque composant a ses

fonctions propres. Le schéma suivant montre plusieurs couches et composants
architecturaux clés de Rancher.

42
 Figure II. 13 : Architecture de Rancher [8]

➢ Sécurité de Rancher

Rancher offre une panoplie d’options pour la gestion de la sécurité. On a :

❖ L’audit

L'audit Rancher Container Platform fournit un ensemble chronologique

d'enregistrements pertinents pour la sécurité documentant la séquence des activités qui
ont affecté le système par des utilisateurs individuels, des administrateurs ou d'autres
composants du système. Les administrateurs peuvent configurer la stratégie de journal
d'audit et afficher les journaux d'audit.

❖ Les certificats

Les certificats sont utilisés par divers composants pour valider l'accès au cluster. Les
administrateurs peuvent remplacer le certificat d'entrée par défaut, ajouter des
certificats de serveur d'API ou ajouter un certificat de service.

Plusieurs les types de certificats sont utilisés par le cluster :

➢ Certificats fournis par l'utilisateur pour le serveur d'API ;

43
 ➢ Certificats de procuration ;
➢ Service CA certificats ;
➢ Certificats de nœud ;
➢ Certificats d'amorçage ;
➢ Certificats etcd ;
➢ Certificats OLM ;
➢ Certificats fournis par l'utilisateur pour l'entrée par défaut ;
➢ Certificats d'entrée ;
➢ Surveillance et journalisation du cluster Certificats de composant opérateur ;
➢ Certificats de plan de contrôle.
❖ Le cryptage des données

Il permet d’activer le chiffrement etcd pour le cluster afin de fournir une couche
supplémentaire de sécurité des données. Par exemple, cela peut aider à protéger la perte
de données sensibles si une sauvegarde etcd est exposée aux mauvaises parties.

❖ L’analyse des vulnérabilités

Les administrateurs peuvent utiliser le Container Security Operator (CSO) pour

exécuter des analyses de vulnérabilité et examiner les informations sur les vulnérabilités
détectées [8].

❖ L’aperçu de la conformité

Pour de nombreux clients Rancher, la préparation réglementaire ou la conformité, à un

certain niveau, est requise avant que tout système puisse être mis en production. Cette
préparation réglementaire peut être imposée par les normes nationales, les normes de
l'industrie ou le cadre de gouvernance d'entreprise de l'organisation.

❖ Le contrôle de conformité

Les administrateurs peuvent utiliser l' opérateur de conformité pour exécuter des
analyses de conformité et recommander des solutions pour tout problème détecté. Le
oc-complianceplugin est un plug-in Rancher CLI (oc) qui fournit un ensemble
d'utilitaires pour interagir facilement avec l'opérateur de conformité.

44
 ❖ La vérification de l'intégrité des fichiers

Les administrateurs peuvent utiliser l'opérateur d'intégrité des fichiers pour exécuter en
permanence des contrôles d'intégrité des fichiers sur les nœuds de cluster et fournir un
journal des fichiers qui ont été modifiés.

❖ Les objets de contrôle d'accès basé sur les rôles (RBAC)

Les objets de contrôle d'accès basé sur les rôles (RBAC) déterminent si un utilisateur
est autorisé à effectuer une action donnée dans un projet. Les administrateurs de cluster
peuvent utiliser les rôles et les liaisons de cluster pour contrôler qui dispose de
différents niveaux d'accès à la plate-forme Rancher Container Platform elle-même et à
tous les projets.

Tableau II. 3 : Tableau comparatif des orchestrateurs

Caractéristiques Docker Swarm Kubernetes Rancher

Hautement Les La mise à

évolutif par installations l'échelle est
automatisation intégrées sont effectuée par
avec intégration disponibles à Heapster1 et en
d'outils externes. l'échelle et définissant des

Evolutivité l'évolutivité métriques sur

peut être les Heapsters.
déclenchée par
l'API.

Overlay, Ingress Pour les Rancher est

configurations couramment
Network et
réseau utilisé pour la
docker_gwbridge
avancées, communication
sont utilisés pour
La mise en réseau Ingress, réseau et
les nœuds de
Flannel, Calico d'autres gestions
communication.
et d'autres de réseau.
outils sont

45
 couramment
utilisés.

Docker Swarm Le cluster Rancher

utilise la CLI Kubernetes propose une
comme principal dispose d'une console Web,
moyen d'accès et CLI, d'une API une API et une
Accessibilité de nombreuses et d'une CLI pour
interfaces interface contrôler et
utilisateur Web utilisateur Web gérer l'ensemble
tierces disponibles pour accéder et de la pile.
pour gérer Docker gérer les
Swarm comme clusters
Swarmpit. Kubernetes.

L'équilibrage de Kubernetes Rancher a une

charge simple utilise solution de mise
avec Docker également la en réseau de
Swarm est réalisé même stratégie cluster qui
par de simples que Docker fournira
serveurs proxy Swarm. Ici, l'équilibrage de
comme Nginx. Kubernetes charge et nous
peut être permettra de
intégré à des configurer via
L'équilibrage de charge Loadbalances le fichier de
externes configuration
simplement en ou avec l'API.

46
 ajoutant des
détails de
configuration
dans le fichier
de
configuration
du service.

L'installation est Peu complexe Rancher est

très simple car car il a conçu pour
Swarm fait partie plusieurs linux.
Installation
du package composants et Cependant, il
Docker, donc en doit le peut être
appelant configurer pour facilement
simplement lier tous les installé avec un
quelques CLI, composants gestionnaire de
nous pouvons (etcd, Docker packages
installer et Engine, API comme Helm.
configurer Docker Server).
Swarm.

47
Restauration La fonction de Kubernetes Rancher a l'option
restauration n'est fournit une de restauration par
pas intégrée et option de défaut activée qui
seule la version restauration peut être
17.04 et automatique déclenchée
supérieure de avec une mise manuellement par
Docker à jour CLI/UI ou par
fonctionne, la appropriée n'importe quel
restauration avec système de
fonctionne dans restauration. surveillance et
certaines d'alerte.
conditions.

Monitoring La surveillance La surveillance Rancher utilise

des journaux et la gestion l'outil Grafana
(logs) intégrée des journaux Alertmanager-
n'est pas sont intégrées Prometheus
disponible, mais à Kubernetes. (GAP) pour la
avec l'API et Dans lequel, surveillance et la
l'intégration Scaling, gestion des alertes.
d'autres outils Rollback et
tiers, la d'autres
surveillance et événements
d'autres déclenchables
fonctionnalités peuvent être
peuvent être configurés
réalisées. facilement.

48
 III. CHOIX DE LA SOLUTION
1. Besoins

Le choix doit répondre aux besoins d’une équipes DevOps. Après l’étude ci-dessus
mené, nous avons pu constater que Kubernetes est une composante de Rancher. A
travers Rancher, nous avons toutes les propriétés de Kubernetes et avons la possibilité
d’intégrer d’autres outils pour les cas de supervision. Il nous faut donc faire un choix
entre Docker Swarm et Rancher. Sur quels critères faire donc le choix répondant à nos
besoins ?

2. Critères
Docker Swarm et Rancher font parties des plates-formes open source les plus utilisées
pour l'orchestration de conteneurs et semblent fournir des fonctionnalités presque
identiques. Les critères de sélection portent essentiellement sur la haute disponibilité,
l’interface, et le plus important la sécurité.

2.1. La haute disponibilité tableau

➢ Rancher intègre la haute disponibilité, le basculement et la réparation des

nœuds défaillants. Il détecte les pods non sains, les remplace par de nouveaux
et effectue un équilibrage de charge transparent du trafic ;
➢ La haute disponibilité de Docker Swarm repose principalement sur la
possibilité de cloner des services en tant que nœuds Swarm. Les nœuds du
gestionnaire Swarm gèrent les ressources des nœuds de travail et peuvent
déplacer le nœud vers une autre ressource en cas de panne.

2.2. Interface graphique

➢ Rancher fournit des tableaux de bord via l'interface utilisateur Web qui
permettent aux administrateurs et aux développeurs de cluster d'afficher et de
contrôler l'état du cluster ;
➢ Docker Swarm n'offre pas de tableau de bord intégré pratique et nécessite
une intégration avec des outils open source ou tiers.

2.3. Sécurité
➢ Rancher fournit des contrôles de sécurité de niveau entreprise, notamment
l'autorisation RBAC, l'authentification, la gestion des secrets,

49
 ➢ les politiques de sécurité des pods, les politiques réseau et SSL/TLS. La sécurité
de Rancher peut être améliorée avec des outils de sécurité natifs du cloud
commerciaux ;
➢ La sécurité de Docker Swarm repose principalement sur la sécurité au
niveau du réseau via TLS authentifié, qui fait tourner les certificats de
sécurité entre les nœuds à intervalles réguliers.

Docker Swarm est un outil d'orchestration léger et facile à utiliser dont l'offre est
limitée par rapport à Rancher. En revanche, Rancher est complexe mais puissant et
offre des capacités d'auto-réparation et de mise à l'échelle automatique dès le départ.

3. Choix
A travers toutes les informations qui ont été données un peu plus haut on se rends
compte que Rancher serait le meilleur choix pour nous. Car, il a non seulement une
interface graphique facilitant la lecture de l’état de notre système. Mais aussi, intègre
des outils de supervision pour des besoins futures de l’entreprise.

50
PARTIE II : REALISATION DE LA SOLUTION ET
PRESENTATION DES RESULTATS

51
 CHAPITRE III : REALISATION DE LA SOLUTION
Notre choix étant porté sur l’outil Rancher, nous verrons à présent comment se fait sa mise en
place et son intégration dans le cadre de notre projet.

I. Architecture
L’implémentation d’une architecture basée sur Rancher a deux niveaux d’automatisations :

1. La semi-automatisation
Elle implique une action du DevOps avant le déploiement en production. Ici, lorsque le
développeur fait un merge de son code sur la branche de production Rancher le récupère et
déploie sur le serveur de pré-production et s’approprie le statut en attente. Après des tests le
DevOps doit activer manuellement le déploiement en environnement de production.

Figure III. 1: Architecture semi-automatique avec Rancher

2. L’automatisation complète

Cette automatisation implique de se débarrasser de l’équipe de test, du serveur de pré-

production et même du DevOps.

52
Mais pour cela il faudra au préalable que les développeurs fassent des tests unitaires et de
régressions de leurs applications en locale sur plusieurs niveaux avant de procéder au
déploiement automatique. Cette automatisation n’implique aucune action du DevOps.
Le test unitaire en programmation informatique, (ou « T.U. », ou « U.T. » en anglais) ou test
de composants est une procédure permettant de vérifier le bon fonctionnement d'une partie
précise d'un logiciel ou d'une portion d'un programme (appelée « unité » ou « module »). En
claire, les tests unitaires sont un moyen efficace de tester des bouts de code dans une application
afin de garantir son bon fonctionnement. La figure ci-dessous illustre ces propos.

Figure III. 2: Architecture semi-automatique avec Rancher

On peut comprendre à travers ces deux (02) architectures que ceux qui était réalisés en onze
(11) étapes dans l’existant se fait maintenant, respectivement en neuf (09) et cinq (05) étapes.
La notion de gain de temps se laisse entrevoir clairement. Avec Rancher comme élément
centrale qui assure en grande partie la gestion du système, le travail devient moins fastidieux et
simple à superviser. Aussi, Rancher par le biais de Kubernetes assure l’orchestration. Ceci
permet au système de s’adapter aux besoins des clients.

3. Rôle des composants

Dans cette architecture, nous avons différents objets et acteurs avec différents rôles qui seront
explicités par la suite.

53
 3.1. Le développeur

Dans cette architecture le développeur est l’entité chargé de coder les applications, de les
pousser sur la branche de développement et de faire le merge sur la branche master de GitLab.
En claire, le développeur utilise le logiciel Git. Ce logiciel permet de versionner le code en
local, sauvegarder ce code sur un dépôt distant et d’y faire des merges (passer d’une branche a
une autre sur un dépôt distant). En effet, il fera lorsqu’il fait un merge de la branche de
développement vers la branche master, il déclencher le processus de déploiement continu de
façon partielle. C’est-à-dire, jusqu’au déploiement en pré-production et attend l’approbation du
DevOps.

3.2. DevOps

Le DevOps est ici l’élément qui coordonne toute cette architecture. Ayant pour rôle de mettre
en place toute l’automatisation au sein de cette architecture avec pour objet de contrôle Rancher,
il se charge également du déploiement en production après l’approbation du testeur de ceux que
les tests effectués sont concluant.

3.3. Le client

Il représente l’utilisateur final. Le client, à travers une adresse accède à l’application déployer
sur le(les) serveur(s) de production par le DevOps afin d’avoir certains services. Ces services
lui sont rendu par le biais d’une d’application mobile ou web qu’il ont en leur possessions.

3.4. GitLab

Après le versionning de leurs codes pour une application bien précise, le développeur pousse le
code sur GitLab. Soit pour une conservation personnelle de son code sur la branche de
développement soit, pour permettre au système de déclencher de façon automatique le
processus de déploiement continu en faisant un merge de la branche de développement vers la
branche master.

3.5. Rancher

Rancher est l’élément centrale de cette architecture. Il a, à son compte plusieurs rôle. Rancher,
après le merge sur la branche master de GitLab par le développeur, fait le téléchargement du
code sur cette branche, le build (transformation en image exécutable sur un système) pour en
faire une image docker et le conserve dans un registre (Docker registry).

54
Cette communication est rendue possible grâce un a Webhook (service qui permet la
communication entre GitLab et Rancher). Après avoir stocké cette image, Rancher le déploie
sur le serveur de pré-production et attend l’approbation du DevOps avec un statut en attente
pour la production. Si les tests sont bons, le DevOps lui ordonne de faire le déploiement sur
l’environnement de production. En plus de tout ça, il nous donne une visibilité sur l’ensemble
de tous ceux qui est géré avec des interfaces graphiques.

3.6. Serveur de pré-production

Utiliser pour les tests avant la production par l’équipe de test. Le serveur de pré-production
assure de la bonne fonctionnalité des applications qui seront plus tard misent en production et
consommé par les utilisateurs finaux. Ce serveur a les mêmes fonctionnalités que le serveur de
production. Si une application fonctionne correctement en pré-production, elle fonctionne
inéluctablement aussi bien en production.

3.7. Serveur de production

Il est le serveur sur lequel les applications déjà testées et approuvées sont déployer pour
permettre aux clients de les utiliser.

4. Choix de l’architecture

Pour notre part nous avons opter pour l’approche semi-automatique. Car les développeurs
n’étant pas assez former sur la notion de DevOps pour le moment risquerait de compromettre
la production si l’on choisissait l’approche automatique. En outre les développeurs non pas la
culture des tests unitaires. Ceux qui, pourrait, pour une approche automatique provoquer les
complications en environnement de production.

II. MISE EN PLACE DE LA SOLUTION

Cette étape nous montre comment installer et faire des configurations avec Rancher à travers
l’architecture sélectionnée.

1. Installation
L’installation de rancher est très simple. Et se fait en plusieurs étapes que voici :

55
 1.1. Créer des machines virtuelles

Il sera question de créer des machines virtuelles sur lesquelles seront installées l’outil de
conteneurisation Docker et Kubernetes. Pour notre projet nous allons faire la création de trois
(03) machines virtuelles dont les rôles sont repartis comme suit :

❖ Une machine virtuelle avec 4096 Go de mémoire ROM et 2 CPUs qui

constituera le server sur lequel nous allons exécuter Rancher ;
❖ Une autre d’un (01) CPU avec 2048 Go de mémoire ROM qui jouera le rôle de
server de pré-production ;
❖ Et la dernière avec les mêmes caractéristiques que la deuxième sera notre
environnement de production.

Avec Rancher, nous avons la possibilité de s’approvisionner chez des fournisseurs de service
cloud tel que Amazone en VMs qui intègrent tous se dont nous avons besoins.

1.2. Débuter l’installation

Sur la première machine on exécute la commande suivante dans le terminal de la VM :

docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher:latest

Cette commande permet de télécharger et d’exécuter la dernière version de Rancher disponible

sur la VM sur le port 80 ou 443. Une fois la commande exécutée, Rancher tourne et est
maintenant accessible via une adresse.

2. La connexion a Rancher
La connexion au serveur est maintenant possible à travers une adresse qui se présente comme
suit : « Ip:Port ». Avec Ip, une adresse que l’on aura définie pour la VM. Et Port, le numéro
de port qui aura servis à lancer Rancher dans notre cas le port 80 ou le 443. Nous accédons à
l’interface de Rancher par un navigateur. Après la connexion via l’adresse on a l’interface
suivante :

56
 Figure III. 3: Fenêtre de connexion de Rancher

Cette interface est une fenêtre de connexion définie par Rancher pour une authentification avant
connexion. Si la connexion est faite pour la première fois, des instructions supplémentaires
seront à suivre avant une éventuelle connexion.

57
CHAPITRE VI : PRESENTATION DES RESULTATS ET
DISCUSSIONS
Ce chapitre nous présente les résultats après l’installation de l’outil (Rancher). Nous donnerons
par la suite des difficultés rencontrées au cours de ce projet dans le volet discussion.

I. CONFIGURATION ET RESULTATS
Après l’installations de ladite solution, nous avons pu constater les faits suivants après les
différentes configurations :

1. Création du cluster Kubernetes

Après l’authentification nous accédons à la page d’accueil de rancher. Sur cette page il faut
sélectionnez l'élément « Clusters » dans la barre de menu de l’interface graphique Rancher,
puis cliquez sur le bouton « Ajouter » un cluster comme ceci.

Figure IV. 1: Page d'accueil de Rancher

Une nouvelle page avec les types de clusters disponibles s'ouvre.

Il est possible d’enregistrer un cluster déjà créé auparavant où créer un nouveau cluster en
utilisant les nœuds existants. Dans notre cas, nous allons choisir l’option « Custom » puisque
nous avons déjà des VMs qui constituent nos différents serveurs. Ensuite il suffit de donner un
nom à notre cluster, ici « test ».

Une fois le cluster crée, nos VMs seront importés pour constituer les différents nœuds du
cluster. Pour se faire, dans la création du cluster nous avons une commande qui nous permet de
le faire.

58
La commande installe une version docker d'un agent Rancher. La sortie suivante confirme le
téléchargement réussi du conteneur :

Figure IV. 2 : Terminal du serveur Rancher

Allez dans l'interface graphique de Rancher et cliquez sur « Done » en bas de la page Cluster
Options. Dès lors, la gestion du cluster est possible.

2. Gestion du cluster

Vous devriez voir le tableau de bord classique du cluster Rancher si le cluster est initié avec
succès, comme dans l'image ci-dessous.

Figure IV. 3 : Page de gestion de cluster

La carte fournit des informations sur l'état des composants du cluster. Le système envoie des
alertes en cas de dysfonctionnement des composants et affiche les paramètres de base du
système (CPU, mémoire et pods).

59
Une autre façon de surveiller le cluster est d'utiliser l'explorateur de cluster. Il offre un moyen
plus compact de surveiller et de gérer le cluster et les charges de travail déployées.

3. Déployer une charge de travail en cluster dans Rancher

Rancher permet de déployer et de mettre à l'échelle facilement des charges de travail de cluster
Kubernetes. L'exemple suivant nous montre comment déployer un serveur de démonstration
Nginx sur le cluster. Des explications seront données dans la suite des travaux. Dans le menu
principal, survolez la section globale, puis le nouveau de votre cluster, et enfin, cliquez sur le
projet par défaut. Comme l’indique la figure IV.4.

Figure IV. 4: Tableau de bord Rancher

Ensuite, cliquez sur le bouton « Déployer » dans le tableau de bord du cluster, la page de
déploiement de charge de travail s'affiche.

Figure IV. 5 : page de déploiement

Donnez un nom au déploiement, affectez des pods et fournissez le nom de l'image Docker et
l'espace de nom pour le déploiement. Ensuite, cliquez sur Ajouter un port et saisissez la
configuration de port nécessaire. La figure ci-dessous nous montre comment ce là se fait.

60
 Figure IV. 6 : Page de création d'un déploiement
Faites défiler la page vers le bas pour obtenir d'autres options, telles que la configuration des
variables d'environnement, la planification des nœuds, les contrôles de santé, etc. Lorsque vous
avez terminé, cliquez sur Lancer au bas de la page et attendez que la charge de travail soit
lancée. Lorsque le processus est terminé, la charge de travail affiche l'étiquette Active.

Figure IV. 7 : Page du déploiement effectif

Pour tester le déploiement, nous nous rendons sur le port assigné. La page de démonstration de
Nginx devrait s'afficher. Tout ceci peut être fait de façon automatique en lien l’orchestrateur
Rancher au dépôt distant GitLab. C’est le pipeline d’intégration de déploiement continu.

61
 II. DISCUSSIONS
1. Difficultés rencontrées

Nous sommes tous conscients que la réalisation de tout bon projet engendre des difficultés qui
doivent être surmontées ou contournées par l’équipe projet. Ainsi, les difficultés auxquelles
nous avons fait face lors de la réalisation de ce projet sont entre autres :

➢ La configuration de Rancher a été très complexe pour une première fois. Car, il fallait
avoir des prérequis sur d’autre technologie tel que Docker, Kubernetes et Git etc ;
➢ Pas de grande documentation sur le sujet. Car, l’orchestration est un domaine récent.

2. Les perspectives

Nous sommes au terme de la réalisation de ce projet qui consistait à mettre en place une
solution d’orchestration avec Rancher. Comme perspective il serait judicieux, de mettre en
place une plateforme permettant de faire facilement les migrations vers les nouvelles versions
d’application en mettant en place l’architecture automatique via Rancher. Cela permet
d’augmenter la satisfaction des clients.

3. Planning de réalisation du projet

Pour le suivi de notre projet nous avons pris en compte le planning suivant :

Tableau IV. 1 : Tableau du planning du projet

Sem Sem 3 Sem 5 Sem Sem Sem Sem Sem

1et 2 et 4 et 6 7et 8 9et 10 11et 13et 15
12 14

Analyse du projet 30h

Documentation 16h 18h 20h

Cadre de travail 4h 12h

Prise en main de 8h 20h 20h

Rancher

Conception 15h 16h

62
 Implémentation de 12H 10H
l'architecture

Réalisation de la 35H
solution

Le nombre d’heure de ce projet est évalué à deux cent trente-quatre heures (234 heures).

4. Estimation financière

Tableau IV. 2: Tableau de l'estimation financière du projet

Matériels et Mains Quantité + temps (mois) Prix unitaire par Total (FCFA)
d’œuvre mois (FCFA)

Ordinateur Core i 7,
10-ème génération, 2 650 000 1 300 000
16Giga RAM

Serveur 1 1 500 000 1 500 000

Ingénieurs 2 500 000 1 000 000

Le cout total est de 3 800 000 francs CFA.

63
CONCLUSION GENERALE
Le progrès dans le domaine de l’informatique est croissant. De ce fait, de nos jours, un
utilisateur ou encore un client d’une entreprise qui fournit des services via une application
hébergée sur un server doit pouvoir établir une connexion à tout moment avec les applications
pour récupérer ce dont il a besoin. C’est le principe de la haute disponibilité des serveurs
auxquels répondent la méthodologie DevOps avec ses différents outils tel que Rancher. Rancher
a pour rôle d’assurer l’orchestration des différents conteneurs sur lesquels les services des
applications sont déployées sur les serveurs. L’objectif principal de ce projet était de mettre en
place un outil évolutif d’orchestration des conteneurs pour faciliter la mise en production des
applications sur les serveurs et d’assurer la haute disponibilité de ces derniers. Nous avons donc
commencé par une présentation générale de la méthodologie DevOps, et nous nous sommes
accès sur ces outils d’orchestrations. D’où, nous avons sélectionné Rancher à la suite d’une
comparaison aux technologies précédentes (Kubernetes et Docker Swarm). Après ce travail de
présentation, nous avons exposé l’outil en décrivant les interfaces graphiques avec les
différentes fonctionnalités qu’il offre pour permettre la haute disponibilité des applications vis-
à-vis des utilisateurs. Nous en tant qu’étudiant en réseaux et télécommunications, réfléchi sur
ce sujet permet de mettre en pratique nos connaissances théoriques apprise en classe et par
ricochet permet d’avoir une compétence pratique en matière d’orchestration de conteneurs afin
d’être plus compétitive sur le marché de l’emploi.

64
BIBLIOGRAPHIE
- [1] AWAYNI, Abdelmalek. Mise en place d’une plateforme d’intégration continue. 2018.
Thèse de doctorat. Université Virtuelle de Tunis.
- [2] OZIGRE Charles Adam, Sécurisation d’un système informatique à travers le cloud,
Mémoire de Fin d’étude, 2017-2018, 63 pages.
- [3] KELSEY Hightower, BRENDAN Burns, JOE Beda, Maitriser l’orchestrateur des
infrastructures du futur. Livre,283 pages.
- [4] P-Y. Cloux, T. Garlot, J. Kohler, Docker - Pratique des architectures à base de
conteneurs, livre, 2019, 336 pages.
- [5] S. Goudeau, S. Metias, Découvrir DevOps - L’essentiel pour tous les métiers, 240 pages,
2018.
- [6] A. Sacquet, C. Rochefolle, Mettre en œuvre DevOps - Comment évoluer vers un DSI
agile, livre, 2018, 288 pages.
- [7] Russ McKendrick, Scott Gallagher, Mastering Docker, livre, 384 pages, 2017.
- [8] Steve Buchanan, Janaka Rangama, Ned Bellavance, Introducing Azure Kubernetes
Service, 236 pages, 2020.

65
 Table des matières
DEDICACE ................................................................................................................................. I

REMERCIEMENTS ................................................................................................................. II

SOMMAIRE ............................................................................................................................ III

LISTE DES TABLEAUX ........................................................................................................ IV

LISTE DES FIGURES .............................................................................................................. V

LISTE DES ABREVIATIONS ................................................................................................ VI

INTRODUCTION ...................................................................................................................... 1

PARTIE I : ETUDE GENERALE ............................................................................................. 3

CHAPITRE I : PRESENTATION DU SYSTÈME DE PRODUCTION LOGICIEL DE

NDSER ....................................................................................................................................... 4

I. LA STRUCTURE D’ACCEUIL ........................................................................................ 4

1. Activités .......................................................................................................................... 4
2. Organigramme de NGSER .............................................................................................. 5
II. PRESENTATION DU PROJET ........................................................................................ 6

1. Contexte .......................................................................................................................... 6
2. Cahier des charges du projet ........................................................................................... 7
2.1. Travail à faire ........................................................................................................... 7
2.2. Objectifs ................................................................................................................... 7
III. ETUDE DE L’EXISTANT ............................................................................................. 8

1. Présentation du système de production logiciel actuel de NGSER ................................. 8

1.1. Architecture.............................................................................................................. 8
1.2. Principe de fonctionnement ..................................................................................... 9
2. Limites ........................................................................................................................... 10
3. Solutions envisagées ..................................................................................................... 11
CHAPITRE II : ETAT DE L’ART SUR L’ENRIRONNEMENT ET LES OUTILS
D’ORCHESTRATION DevOps .............................................................................................. 12

I. ETAT DE L’ART SUR L’ENRIRONNEMENT DevOps .............................................. 12

1. Historique ...................................................................................................................... 12
66
 2. Définition ...................................................................................................................... 12
3. Principes du DevOps ..................................................................................................... 13
3.1. Culture.................................................................................................................... 13
3.2. Automatisation ....................................................................................................... 13
3.3. Mesure des KPIs .................................................................................................... 13
3.4. Partage.................................................................................................................... 13
4. Les pratiques DevOps ................................................................................................... 13
5. Outils utilisés ................................................................................................................. 15
6. Avantages et inconvénients ........................................................................................... 16
II. ETUDE DES OUTILS D’ORCHESTRATION DevOps ................................................ 17

1. Virtualisation et Conteneurisation ................................................................................. 17

1.1. Virtualisation.......................................................................................................... 17
1.2. Conteneurisation .................................................................................................... 18
1.3. Comparaison .......................................................................................................... 19
1.4. Avantages des conteneurs ...................................................................................... 22
2. Les outils de conteneurisation ....................................................................................... 23
2.1. Docker .................................................................................................................... 23
2.2. Linux containers-LXC ........................................................................................... 25
2.3. CRI-O (Container Runtime Interface) ................................................................... 26
3. L’orchestration .............................................................................................................. 28
3.1. Définition de l’orchestration .................................................................................. 28
3.2. Définition de outils d’orchestrations ...................................................................... 29
3.3. Etude des différents outils d’orchestrations ........................................................... 29
III. CHOIX DE LA SOLUTION......................................................................................... 49

1. Besoins .......................................................................................................................... 49
2. Critères .......................................................................................................................... 49
2.1. La haute disponibilité tableau ................................................................................ 49
2.2. Interface graphique ................................................................................................ 49
2.3. Sécurité .................................................................................................................. 49
3. Choix ............................................................................................................................. 50
PARTIE II : REALISATION DE LA SOLUTION ET PRESENTATION DES RESULTATS
.................................................................................................................................................. 51

67
CHAPITRE III : REALISATION DE LA SOLUTION .......................................................... 52

I. Architecture ...................................................................................................................... 52

1. La semi-automatisation ................................................................................................. 52
2. L’automatisation complète ............................................................................................ 52
3. Rôle des composants ..................................................................................................... 53
3.1. Le développeur ....................................................................................................... 54
3.2. DevOps .................................................................................................................. 54
3.3. Le client ................................................................................................................. 54
3.4. GitLab .................................................................................................................... 54
3.5. Rancher .................................................................................................................. 54
3.6. Serveur de pré-production...................................................................................... 55
3.7. Serveur de production ............................................................................................ 55
4. Choix de l’architecture .................................................................................................. 55
II. MISE EN PLACE DE LA SOLUTION ........................................................................... 55

1. Installation ..................................................................................................................... 55
1.1. Créer des machines virtuelles ................................................................................ 56
1.2. Débuter l’installation ............................................................................................. 56
2. La connexion a Rancher ................................................................................................ 56
CHAPITRE VI : PRESENTATION DES RESULTATS ET DISCUSSIONS ....................... 58

I. CONFIGURATION ET RESULTATS ........................................................................... 58

1. Création du cluster Kubernetes ..................................................................................... 58

2. Gestion du cluster .......................................................................................................... 59
3. Déployer une charge de travail en cluster dans Rancher............................................... 60
II. DISCUSSIONS ................................................................................................................ 62

1. Difficultés rencontrées .................................................................................................. 62

2. Les perspectives ............................................................................................................ 62
3. Planning de réalisation du projet ................................................................................... 62
4. Estimation financière..................................................................................................... 63
CONCLUSION GENERALE .................................................................................................. 64

BIBLIOGRAPHIE ................................................................................................................... 65

RESUME .................................................................................................................................. 70

68
ABSTRACT ............................................................................................................................. 70

69
RESUME
La migration d’application de son environnement de test à celui de production ne se fait pas
toujours sans problèmes. Il arrive parfois que l’application ne fonctionne même pas. Pour pallier
ce problème une des solutions les plus prisées est le système d’orchestration de conteneurs
sécurisés. C’est dans ce contexte que nous avons eu pour thème, la réalisation d’un orchestrateur
de conteneurs sécurisés en environnement DevOps. Dès lors comment réaliser une telle solution
? Pour ce faire primo nous avons faire des généralités afin de présenter le contexte, l’objectif
général et le cahier de charges. Secundo, une étude théorique pour mettre en exergue la
conception et modélisation de notre solution avec un orchestrateur bien choisi en précisant les
outils et technologies utilisés. Tercio, la toute dernière partie s’est focalisé sur la réalisation de
la solution.

ABSTRACT
The migration of an application from its test environment to the production environment is not
always problem-free. It sometimes happens that the application does not even work. One of the
most popular solutions to this problem is the system of orchestration of secure containers. It is
in this context that we had for theme, the realization of an orchestrator of secure containers in
DevOps environment. So how do we achieve such a solution? To do this, we first made some
generalities in order to present the context, the general objective and the specifications.
Secondly, a theoretical study to highlight the design and modelling of our solution by specifying
the tools and technologies used. Thirdly, the very last part focused on the realization of the
solution.

70