UNIVERSITE DE FIANARANTSOA

ECOLE NATIONALE D’INFORMATIQUE

MEMOIRE DE FIN D’ETUDES
POUR L’OBTENTION DU DIPLOME DE
LICENCE PROFESSIONNELLE

Mention : Informatique

Parcours : Informatique Générale

MISE EN PLACE D’UN STRATEGIE MODERNE DE

DEPLOIEMENT CONTINUE POUR LES CLOUDS AVEC
ZERO-DOWNTIME

Présenté le, 01 Février 2023

Par : ANDRIATSARANIONY Mirado Barijaona

Membres du jury :

• Président : -Monsieur RABETAFIKA Louis Haja, Maitre de conférences

• Examinateur : -Madame RAKOTOASIMBAHOAKA Antsa Cyprienna, Docteur en Informatique
• Rapporteurs : -Monsieur RALAIVAO Jean Christian, Assistant d’Enseignement Supérieur et de
Recherche
-Monsieur RAFAMANTANANTSOA Fontaine, Professeur

Année Universitaire : 2021-2022

 CURRICULUM VITAE

Nom et prénoms : ANDRIATSARANIONY Mirado Barijaona

Date et lieu de naissance : 13 Février 2001 à Fianarantsoa

Situation matrimoniale : Célibataire

Adresse : Lot 39E/3603 Antarandolo

Téléphone : 034 46 656 67

Adresse e-mail : mirado1303@[Link]

FORMATIONS ET DIPLOME OBTENU :

2021-2022 : Troisième année de formation LICENCE PROFESSIONNELLE à l’Ecole Nationale

d’Informatique (ENI), parcours Informatique Générale.

2020-2021 : Deuxième année de formation LICENCE PROFESSIONNELLE à l’Ecole Nationale

d’Informatique (ENI), parcours Informatique Générale

2019-2020 : Première année de formation LICENCE PROFESSIONNELLE à l’Ecole Nationale

d’Informatique (ENI), parcours Informatique Générale

2017-2018 : Obtention du diplôme de Baccalauréat série D au Lycée Sacré Cœur

Ambohimahasoa (LSCA)

STAGES ET EXPERIENCES PROFESSINNNELLES :

2021-2022 | DEVOPS | ENI

Suivi d’un stage de fin d’étude en Licence Professionnel au sein d’Ecole Nationale
d’Informatique (ENI) sur le thème « Mise en place de stratégie de déploiement sur les clouds
avec zero-downtime »

Plateformes et outils devops : GCP, JEKINS, DOCKER, ZKE

I
2020-2021 | Développeur | ENI |CISCO AMBOHIMAHASOA

Suivi d’un stage au sein de CISCO sur le thème « Gestion de paiements de vacation » codé en
PHP

COMPETENCES EN INFORMATIQUE :

- Langage de programmation : C, C++, JavaScript, Python,

- Outils de développement : Code Blocks, NetBeans, Visual Studio Code
- Technologies web : html, CSS, Bootstrap, PHP
- Système d'exploitation : Linux (Ubuntu), Windows (10)
- Système de Gestion de Base de Données : MySQL, No SQL
- Outils DEVOPS : Jenkins, Docker, EKS, kubernetises, ZKE.
- Platform DEVOPS : AWS, GCP
- Outils d’annotation d’images : GIMP, Photoshop

CONNAISSANCES LINGUISTIQUES :

Langues Compréhension Lecture Expression Expression orale

à l’audition écrite
Anglais AB B B AB
Français B B B B

Grille d’évaluation : Très bien (TB), bien (B), assez-bien (AB), passable(P)

DIVERS :

-Sport : Basket-ball

- Passe-temps : surfer sur internet, écouter de la musique, regarder des films

II
 DEDICACE
Je tiens à remercier toutes les personnes qui ont contribuées au succès de mon stage pour
l’obtention de diplôme licence et qui m’ont aidées de la rédaction de ce mémoire.

Toute ma gratitude à chacune de ces âmes : mes chers parents, toute ma famille pour leurs
encouragements, soutiens, dévouements et confiances.

Je voudrais exprimer ma reconnaissance envers les amis et collègues qui m’ont apporté leur
soutien moral et intellectuel tout au long de ma démarche.

Aux enseignants et encadreurs de l’Ecole Nationale de l’Informatique pour leurs aides,

conseils et orienté pendant l’élaboration de notre travail de réalisation.

III
 REMERCIEMENTS
En premier lieu, nous tenons à rendre grâce à Dieu tout puissant, pour nous avoir donné la
force et le courage pour la réalisation de ce rapport de stage dans une parfaite santé.

Sans la contribution de différentes personnes auxquels nous n’aurions pu terminer ce stage Nous
tenons aussi à adresser nos sincères remerciements, en particulier à :

➢ Monsieur HAJALALAINA Aimé Richard, Docteur HDR, Président de

l’Université de Fianarantsoa, de nous avoir accueilli à l'Université de Fianarantsoa
➢ Monsieur MAHATODY Thomas, Docteur HDR, Directeur de l’Ecole Nationale
d’Informatique de nous avoir accueilli à l’ENI.
➢ Monsieur RABETAFIKA Louis Haja, Maitre de Conférences, responsable de
mention à l’Ecole National d’Informatique.
➢ Monsieur SIAKA, Assistant d’enseignement supérieur et de la recherche,
responsable de parcours « Administrateur Système et Réseau »
➢ Monsieur GILANTE Gesazafy, Assistant d’enseignement supérieur et de la
recherche, responsable de parcours « Informatique Générale »
➢ Monsieur RALAIVAO Jean Christian, Assistant d’enseignement supérieur et de
la recherche, responsable de parcours « Génie logiciel et Base de donnée».
➢ Monsieur RAFAMANTANATSOA Fontaine, Professeur, Encadreur
professionnel qui n’a pas cessé de nous partager ses expériences et ses
connaissances durant toute la période de stage.
➢ Tous les enseignants et Chercheurs à l’Ecole Nationale d’Informatique, qui ont
participé à notre formation.
➢ Tous les membres du corps Enseignant de l’Ecole Nationale d’Informatique, pour
les savoirs et connaissances qu’ils nous ont transmis.
➢ A ma famille qui m’a soutenu moralement et financement durant la réalisation de
ce mémoire.
➢ A tous ceux, de près ou de loin, qui ont contribué à la réalisation de ce travail.

IV
 SOMMAIRE
CURRICULUM VITAE .................................................................................................................. I
DEDICACE .................................................................................................................................... III
REMERCIEMENTS ..................................................................................................................... IV
SOMMAIRE ................................................................................................................................... V
LISTE DES ABREVIATIONS ....................................................................................................... X
LISTE DES TABLEAUX ............................................................................................................. IX
LISTE DES FIGURES .................................................................................................................... X
INTRODUCTION GENERALE...................................................................................................... 1
Partie I : PRESENTATIONS ....................................................................................................... 2

Chapitre [Link] DE L’ECOLE NATIONALE D’INFORMATIQUE ............ 3

1.1. Information d’ordre générale ..................................................................................... 3

1.2. Missions et Historiques .............................................................................................. 3

1.3. Organigramme institutionnel de l’ENI ....................................................................... 5

1.4. Domaines et spécialisation ......................................................................................... 7

1.5. Architecture des formations pédagogiques ................................................................ 7

1.6. Relation de l’ENI avec les entreprises et organismes .............................................. 10

1.7. Partenariat au niveau international ........................................................................... 11

1.8. Débouchés professionnels des diplômes .................................................................. 13

1.9. Ressources humaines ................................................................................................ 15

Chapitre [Link] DU PROJET .............................................................................. 16

2.1. Formulation .............................................................................................................. 16

2.2. Objectif et besoins de l’utilisateur ............................................................................ 16

2.3. Moyens nécessaires à la réalisation du projet .......................................................... 16

2.3.1. Moyens humains.............................................................................................. 16

2.3.3. Moyens matériels .................................................................................................. 17

2.4. Résultat attendus ...................................................................................................... 17

2.5. Chronogramme des activités .................................................................................... 17

Partie II : ETUDES THEORIQUES .......................................................................................... 19

V
Chapitre 3. ANALYSE PREALABLE .................................................................................. 20

3.1. DevOps ..................................................................................................................... 20

3.1.1. Les avantages de l’approche DevOps ............................................................ 20

a) Une meilleure collaboration entre les équipes .............................................. 20

b) Gain de temps et un gain d’argent ................................................................ 21

c) Une amélioration de la satisfaction et de l’expérience client ...................... 21

d) Une grande rapidité dans la production et la livraison ............................... 21

e) Une capacité d’innovation .............................................................................. 22

f) Une détection rapide des problèmes .............................................................. 22

3.2. Analyse de l’existant ................................................................................................ 22

3.3. Proposition de solution ............................................................................................. 22

3.3.1. Déploiement Continue............................................................................................. 22

3.3.2. Déploiement sans interruption de service ........................................................ 23

Chapitre 4. ETUDES THÉORIQUES DE LA SOLUTION À METTRE EN PLACE ......... 25

4.1. Gestionnaire de version : Git .................................................................................... 25

4.1.1. Définition ......................................................................................................... 25

4.1.2. Git vs SVN ......................................................................................................... 25

4.2. Choix de solution de virtualisation........................................................................... 27

4.2.1. La virtualisation .............................................................................................. 27

a) Définition .......................................................................................................... 27

b) Types de virtualisation ..................................................................................... 27

b.1) La virtualisation système ............................................................................................ 28

b.2) La virtualisation applicative ........................................................................................ 29
4.2.2. La Technologie Docker ................................................................................... 30

a) Définition .......................................................................................................... 30

b) Poids léger ........................................................................................................ 30

c) Plateforme ........................................................................................................ 30

VI
 d) Comparaison Docker et Machine virtuel ........................................................ 30

4.3. Le script YAML et Groovy ...................................................................................... 32

4.3.1. YAML .............................................................................................................. 32

4.3.2. Groovy .............................................................................................................. 33

4.4. Serveur d’orchestration : Jenkins vs Bamboo vs Travis .......................................... 33

4.5. L’infonuagique (Cloud Computing)......................................................................... 34

4.5.1. Les caractéristiques des Cloud ...................................................................... 34

4.5.2. Les niveaux de service .................................................................................... 35

4.5.3. Les modèles de déploiement ........................................................................... 36

4.5.4. Le Cloud face au défi de l’isolation ............................................................... 36

4.6. Plateformes d’Orchestration de conteneurs docker .................................................. 37

4.6.1. Introduction ..................................................................................................... 37

4.6.2. Caractéristiques d’un orchestrateur de conteneurs .................................... 37

4.6.3. L’orchestrateur Swarm .................................................................................. 38

a) Définition .......................................................................................................... 38

b) Architecture de Swarm..................................................................................... 38

4.6.4. L’orchestrateur Kubernetes .......................................................................... 39

a) Définition ......................................................................................................... 39

b) Architecture de Kubernetes ........................................................................... 40

c) Fonctionnalité de kubernetes ......................................................................... 41

d) GKE (Google Kubernetes Engine) ................................................................ 41

e) Caractéristiques du GKE ............................................................................... 42

4.6.5. Comparaison entre Swarn et Kubernetes ..................................................... 42

4.7. Google Cloud Plateforme ......................................................................................... 43

4.7.1. Google Compute Engine (GCE) .................................................................... 44

4.8. L’intégration Continue ............................................................................................. 44

4.8.1. Définition ......................................................................................................... 44

VII
 4.8.2. Fonctionnement de l’IC .................................................................................. 45

4.8.3. Les étapes de l’Intégration Continue ............................................................ 45

4.8.4. Les différents composants d’une plate-forme d’IC : ................................... 46

4.8.5. Les avantages de l’intégration continue ........................................................ 47

4.9. JMETER ................................................................................................................... 47

Partie III : MISE EN OEUVRE ................................................................................................. 49

Chapitre 5. INSTALLATION ET CONFIGURATION ........................................................ 50

6.1. Configuration GCP .......................................................................................................... 50

6.1.1. Création projet sur GCP .......................................................................................... 50

[Link]. Création instance GCE .................................................................................... 50

[Link]. Création clusters GKE...................................................................................... 51

6.2. Installation et configuration du Jenkins .......................................................................... 53

✓ Vérification de status jenkins : ................................................................................... 55

6.3. Installation docker........................................................................................................... 56

6.4. Installation Kubeclt ......................................................................................................... 57

6.5. Installation et configuration sur Jenkins : .................................................................. 58

6.5.1 Installation des plugins .............................................................................................. 59

6.5.2 Création credential ................................................................................................... 63

 Credential pour le docker Hub.......................................................................... 63

 Credential pour kubernetes ............................................................................... 63

6.6. Création du Pipeline CI/CD ....................................................................................... 66

6.7. Le service et application qu’il faut déployer ................................................................... 69

6.7.1 Dockerfile .................................................................................................................. 69

6.7.2. Loadbalancing .......................................................................................................... 69

Fonctions Loadbalancing : .......................................................................................... 70

6.3.2 Docker Hub ............................................................................................................... 72

5.6. Configuration du webHooks ...................................................................................... 76

VIII
CONCLUSION .............................................................................................................................. 78
REFERENCES BIBLIOGRAPHIQUES ..................................................................................... XII
REFERENCES WEBOGRAPHIQUES ...................................................................................... XIII
GLOSSAIRE ...............................................................................................................................XIV
TABLES DE MATIERES ..........................................................................................................XVI
RESUME .....................................................................................................................................XXI
ABSTRACT ................................................................................................................................XXI

IX
 LISTE DES ABREVIATIONS

API Application Programming Interface

CD Continous Deployment
CDR Centre De Recherche
CNH Commission Nationale d'Habilitation
CI Continous Integration
CPU Central Processing Unit
ENI Ecole Nationale de l’Informatique
GCP Google Cloud Platform
GKE Google Kubernetes Engine
HPA Horizontal Pod Autoscaler
IAAS Infrastructure as a Service
IDE integrated development environment
IP Internet Protocol
JVM Java Virtual Machine
K8S Kubernetes
PAAS Platform as a Service
RAM Random-Access Memory
SAAS Software As A Service
SVN Subversion
VM Virtual Machine
VPA Vertical Pod Autoscaler
VPN Virtual Private Network
YAML YAML Ain’t Markup Language
ZDD Zero Downtime Deployment

X
 LISTE DES TABLEAUX
Tableau 1 : Organisation du système de Formation pédagogique de l'Ecole ................................... 7
Tableau 2 : Architecture des études correspondant au système LMD ............................................. 8
Tableau 3 : Listes des Formations existantes à l'ENI ....................................................................... 9
Tableau 4 : Débouchés professionnels éventuels des diplômes ..................................................... 14
Tableau 5 : Tableau de comparaison su SVN et Git ...................................................................... 25
Tableau 6 : Caractéristiques des technologies de virtualisation. .................................................... 31
Tableau 7 : Comparaison des outils d'intégration continue............................................................ 33
Tableau 8 : Tableau comparatif du swarm et kubernetes ............................................................... 43

IX
 LISTE DES FIGURES
Figure 1 Organigramme de l'ENI ..................................................................................................... 6
Figure 4 : Concept du déploiement continue ................................................................................. 23
Figure 2 : Types d'hyperviseur ....................................................................................................... 29
Figure 3 :Comparaison du machine virtuel avec docker ................................................................ 31
Figure 4 : Les niveaux de services dans le cloud ........................................................................... 35
Figure 5: Architecture de Swarm ................................................................................................... 39
Figure 6 : Architecture kubernetes ................................................................................................. 41
Figure 7 : Les étapes d'intégration Continue .................................................................................. 46
Figure 8 : Fonctionnement du JMETER ........................................................................................ 48
Figure 10 : Création du projet GCP ............................................................................................... 50
Figure 11 : Création instance GCE ................................................................................................ 50
Figure 12 : Choix de type de configuration.................................................................................... 51
Figure 13 : Les différentes champs de configuration ..................................................................... 51
Figure 14 : Cluster Bien crée.......................................................................................................... 52
Figure 15 : Commande de connexion au cluster ............................................................................ 52
Figure 16 : CloudShell pour connecter au cluster GKE ................................................................. 52
Figure 17 : Accès à l'instance du jenkin ......................................................................................... 53
Figure 18 : Mise à jour de repository ............................................................................................. 54
Figure 19 : Installations du Jenkins ................................................................................................ 54
Figure 20 : Ajout de l'user jenkins dans le groupe sudoers ............................................................ 55
Figure 21 : Vérification du service Jenkins .................................................................................... 56
Figure 22 : Installation du docker .................................................................................................. 56
Figure 23 : Vérification d'installation GCLOUD ........................................................................... 57
Figure 24 : Installation snap ........................................................................................................... 57
Figure 25 : Installation du kubectl.................................................................................................. 58
Figure 26 : Creation Utilisateur ...................................................................................................... 58
Figure 27 : Jenkins prêt à être utiliser ............................................................................................ 59
Figure 28 : Page d'authentification du Jenkins ............................................................................... 59
Figure 29 : : Installation Maven Invoker ........................................................................................ 60
Figure 30 : : Installation Maven Integration................................................................................... 60
Figure 31 : : Installation du plugins Google kubernetes Engine .................................................... 61

X
Figure 32 : Plugins installé avec succès ......................................................................................... 61
Figure 33 : Installation du plugins Docker pipeline ....................................................................... 62
Figure 34 : Configuration du Maven .............................................................................................. 62
Figure 35 : Création credential pour connecter au DockerHub ..................................................... 63
Figure 36 : Le compte de service du projet .................................................................................... 64
Figure 37 : Création de la clé ......................................................................................................... 64
Figure 38 : choix du type du clé à créer ........................................................................................ 65
Figure 39 : Création credential pour Goole Service Account ........................................................ 65
Figure 40 : Création du pipeline ..................................................................................................... 66
Figure 41 : Nom du pipeline ......................................................................................................... 66
Figure 42 : Configuration de repository utilisé .............................................................................. 67
Figure 43 : Configuration de branche utilisé .................................................................................. 67
Figure 44 : Script du pipeline ......................................................................................................... 68
Figure 45 : Script du pipeline (suite) .............................................................................................. 69
Figure 46 : Code du dockerfile ....................................................................................................... 69
Figure 47 : Script de déploiement du service Loadbalancer .......................................................... 70
Figure 48: Script de déploiement de l'application ......................................................................... 71
Figure 49 : Build du pipeline......................................................................................................... 71
Figure 50 : résultat du commande kubectl get all .......................................................................... 72
Figure 51 : Les images du repository Dockerhub .......................................................................... 72
Figure 52 : Détails de l'image dans dockerhub ............................................................................. 73
Figure 53 : Service Nginx en marche ............................................................................................. 73
Figure 54 :: Services Tomcat marche ............................................................................................. 74
Figure 55 : accès de l'application par l'IP [Link] ............................................................... 74
Figure 56 : accès de l'application par l'IP [Link] .............................................................. 75
Figure 57 : accès de l'application par le node 1.............................................................................. 75
Figure 58 : accès de l'application par le node 2.............................................................................. 76
Figure 59 : Configuration WeebHook sur le github ...................................................................... 77
Figure 60 : Activation GitHub hook trigger dans Jenkins ............................................................. 77

XI
 INTRODUCTION GENERALE
Actuellement, la plupart de différents secteurs d’activités sont absolument
informatisé[Link] à l’Ecole Nationale d’Informatique et troisième année de Licence
professionnelle, un stage pratique au sein d’une entreprise est obligatoire. En abrégé, pour cette
année 2021-2022. Ce stage s’est déroulé au sein de l’Ecole Nationale d’Informatique (ENI)
Antanambao Fianarantsoa à partir du 19 septembre2022 jusqu’au décembre 2022.
Nous savons tous que de notre temps tout le monde s’incline dans le domaine de
l’informatique et que plusieurs d’entreprises utilisent le cloud computing pour faciliter leur travail.
Dans ce cadre, il y a diverses sortes de thème et durant le stage on a eu comme thème « MISE EN
PLACE DE STRATEGIE MODERNE DE DEPLOIMENT CONTINUE POUR LES CLOUDS
AVEC ZERO-DOWNTIME » Lorsqu’on dit de cloud, on parle toujours de sécurisation et de
stockage mais dans ce domaine il n’y a pas que sécurisation et de stockage. Mais dans ce mémoire,
on appelle de déploiement d’un ou plusieurs applications pour avoir la disponibilité de cette
application n’importe où. Le présent mémoire a pour but de montrer comment gérer les applications
en utilisant le déploiement sous cloud ainsi que de gérer les ressources utilisées par cette application
mais aussi sur l’automatisation en utilisant l’outil Jenkins.
Ce mémoire est divisé en trois parties, la première partie s’agit de la présentation générale
où l’on trouvera la présentation de l’Ecole Nationale d’Informatique (ENI) et le contexte du projet,
la deuxième partie s’agit des études théoriques, et pour la troisième et dernière partie nous allons
passer à la mise en œuvre.

1
Partie I : PRESENTATIONS

2
 Chapitre 1. PRESENTATIONS DE L’ECOLE NATIONALE
D’INFORMATIQUE
1.1. Information d’ordre générale
L’Ecole Nationale d’Informatique, en abrégé ENI, est un établissement d’enseignement
supérieur rattaché académiquement et administrativement à l’Université de Fianarantsoa. Le siège
de l’Ecole se trouve à Tanambao- Antaninarenina à Fianarantsoa.
L’adresse pour la prise de contact avec l’Ecole est la suivante :
Ecole Nationale d’Informatique (ENI) Tanambao, Fianarantsoa.
Le numéro de sa boîte postale est 1487 avec le code postal 301. Téléphone :034 05 733 36. Son
adresse électronique est la suivante : eni@[Link]. Site Web : www. eni-univ-
[Link].
1.2. Missions et Historiques
L’ENI se positionne sur l’échiquier socio-éducatif malgache comme étant le plus puissant
secteur de diffusion et de vulgarisation des connaissances et des technologies informatiques.

Cette Ecole Supérieure peut être considérée aujourd’hui comme la vitrine et la pépinière des
élites informaticiennes du pays.

L’Ecole s’est constituée de façon progressive au sein du Centre Universitaire Régional

(CUR) de Fianarantsoa.

De façon formelle, l’ENI était constituée et créée au sein du (CUR) par le décret N° 83185
du 24 Mai 1983, comme étant le seul établissement Universitaire Professionnalisé au niveau
national, destiné à former des techniciens et des Ingénieurs de haut niveau, aptes à répondre aux
besoins et exigences d’Informatisation des entreprises, des sociétés et des organes implantés à
Madagascar.

L’ENI a pour conséquent pour mission de former des spécialistes informaticiens compétents
et opérationnels de différents niveaux notamment :

En fournissant à des étudiants des connaissances de base en informatique ;

En leur transmettant le savoir-faire requis, à travers la professionnalisation des formations

dispensées et en essayant une meilleure adéquation des formations par rapport aux besoins évolutifs
des sociétés et des entreprises

3
 En initiant les étudiants aux activités de recherche dans les différents domaines des
Technologies de l’information et de la communication (TIC).

L’implantation de cette Ecole Supérieure de technologie de pointe dans un pays en

développement et dans une Province (ou Faritany) à tissu économique et industriel faiblement
développé ne l’a pourtant pas défavorisée, ni empêchée de former des spécialistes informaticiens
de bon niveau, qui sont recherchés par les entreprises, les sociétés et les organismes publics et
privés sur le marché de l’emploi.

La filière de formation d’Analystes Programmeurs a été mise en place à l’Ecole en 1983, et a

été gelée par la suite en 1996, tandis que la filière de formation d’ingénieurs a été ouverte à l’Ecole
en 1986.

Dans le cadre du Programme de renforcement en l’Enseignement Supérieur (PRESUP) la filière

de formation des Techniciens Supérieurs en Maintenance des Systèmes des informatiques a été
mise en place en 1986 grâce à l’appui matériel et financier de la Mission Française de coopération
auprès de l’Ambassade de France à Madagascar.

Une formation pour l’obtention de la certification CCNA et / ou NETWORK + appelée «

CISCO Networking Academy » a été créée à l’Ecole en 2002-2003 grâce au partenariat avec
CISCO SYSTEM et l’Ecole Supérieure Polytechnique d’Antananarivo (ESPA). Cependant, cette
formation n’avait pas duré longtemps.

L’organisation de stage en entreprise continue non seulement à renforcer la

professionnalisation des formations dispensées, mais elle continue surtout à accroître de façon
exceptionnelle les opportunités d’embauche pour les diplômés de l’Ecole :

• Génie Logiciel et base de Données.

• Administration des Système et réseaux.

La mise en place à l’Ecole de ces deux options de formation devait répondre au besoin de
basculement vers le système Licence – Master – Doctorat (LMD).

Mais la filière de formation des Techniciens Supérieurs en Maintenance des Systèmes

Informatiques a été gelée en 2009.

En vue de surmonter les difficultés de limitation de l’effectif des étudiants accueillis à l’Ecole,
notamment à cause du manque d’infrastructures, un système de « Formation Hybride » a été mise

4
en place à partir de l’année 2010. Il s’agit en effet d’un système de formation semi-présentielle et
à distance avec l’utilisation de la visioconférence pour la formation à distance.

Le système de formation hybride a été ainsi créé à Fianarantsoa ainsi qu’Université de Toliara.

1.3. Organigramme institutionnel de l’ENI

Cet organigramme de l’Ecole est inspiré des dispositions du décret N° 83-185 du 23 Mai 1983.

ENI est administrée par un conseil d’Ecole, et dirigée par un directeur nommé par un décret
adopté en conseil des Ministres.

Le Collège des enseignants regroupant tous les enseignants-chercheurs de l’Ecole est chargé
de résoudre les problèmes liés à l’organisation pédagogique des enseignements ainsi que à
l’élaboration des emplois du temps.

Le Conseil Scientifique propose les orientations pédagogiques et scientifiques de

l’établissement, en tenant compte notamment de l’évolution du marché de travail et de l’adéquation
des formations dispensées par rapport aux besoins des entreprises.

Trois départements de formation caractérisent l’organigramme :

- Le département de formation théorique à l’intérieur de l’Ecole ;

- Le département de formation pratique pour la coordination et la supervision des stages en
entreprise et des voyages d’études ;

Le département de formation doctorale pour l’organisation de la formation de 3ème cycle

5
 Figure 1 Organigramme de l'ENI

Sur cet organigramme, l’Ecole placée sous la tutelle académique et administrative de

l’Université de Fianarantsoa, et dirigée par un Directeur élu par les Enseignants – Chercheurs
permanents de l’Etablissement et nommé par un décret pris en Conseil des ministres pour un
mandat de 3 ans.

Le Conseil de l’Ecole est l’organe délibérant de l’Ecole.

Le Collège des Enseignants propose et coordonne les programmes d’activités

pédagogiques. Le Conseil scientifique coordonne les programmes de recherche à mettre en œuvre
à l’Ecole.

Le Secrétariat principal coordonne les activités des services administratifs (Scolarité,

Comptabilité, et Intendance).

Conformément aux textes en vigueur régissant les Etablissements malgaches

d’Enseignement Supérieur, qui sont barrés sur le système LMD, les Départements de Formation
pédagogique ont été ainsi remplacés par des Mentions et des parcours. Et les chefs des
Départements ont été ainsi remplacés par des responsables des mentions et les responsables des
parcours.

Un administrateur des Réseaux et Systèmes gère le système d’information de l’Ecole et celui

de l’Université.

6
 1.4. Domaines et spécialisation
Les activités de formation et de recherche organisées à l’ENI portent sur les domaines suivants:

- Génie logiciel et Base de Données ;

- Administration des Systèmes et Réseaux ;
- Informatique Générale ;
- Modélisation informatique et mathématique des Systèmes complexes.

D’une manière plus générale, les programmes des formations sont basés sur l’informatique de
gestion et sur l’informatique des Systèmes et Réseaux. Et les modules de formation intègrent aussi
bien des éléments d’Informatique fondamentale que des éléments d’Informatique appliquée.

Le tableau 1 décrit l’organisation du système de formation pédagogique de l’Ecole.

Tableau 1 : Organisation du système de Formation pédagogique de l'Ecole

Formation Théorique Formation Pratique

- Enseignement théorique - Etude de cas
- Travaux dirigés - Travaux de réalisation
- Travaux pratiques - Projets/ Projets tutoriels
- Voyages d’Etudes
- Stages

1.5. Architecture des formations pédagogiques

Le recrutement des étudiants à l’ENI se fait uniquement par voie de concours d’envergure
nationale en première année.

Les offres de formation organisées à l’Ecole ont été validées par la Commission Nationale
d’Habilitation (CNH) auprès du Ministères de l’Enseignement Supérieur et de la Recherche
Scientifique selon les dispositions de l’Arrêté N°31.174/2012-MENS en date du 05 Décembre
2012.

Au sein de l’ENI, il existe une seule mention (INFORMATIQUE) et trois parcours : Génie
logiciel et Base de Données :

• Administration des Systèmes et Réseaux ;

• Informatique Générale

7
 L’architecture des études à trois niveaux conforment au système Licence-Master-Doctorat
(LMD) permet les comparaisons et les équivalences académiques des diplômes au niveau
international.

• L =Licence (Bac + 3) = L1, L2, L3 = 6 semestres S1 à S6

• M = Master (Bac + 5) = M1, M2 = 4 semesters S7 à S10

Le diplôme de licence est obtenu en 3 années des études après Baccalauréat. Et le diplôme de
Master est obtenu en 2 ans après obtenu du diplôme de LICENCE.

Le MASTER PROFESSIONNEL est un diplôme destiné à la recherche emploi au terme des

études.

Le MASTER RECHERCHE est un diplôme qui remplace l’ancien Diplôme d’Etudes

Approfondies (DEA), et qui permet de s’inscrire directement dans une Ecole [Link] terme
des études.

• D = Doctorat (Bac +8)

Le Doctorat est un diplôme qu’on peut obtenir en 3 ans après l’obtention du diplôme de
MASTER RECHERCHE.

Le tableau 2 présente l’architecture des études correspondant au système LMD.

Tableau 2 : Architecture des études correspondant au système LMD

DTS : Diplôme de Technicien Supérieur

BTS : Brevet de Technicien Supérieur

DUT : Diplôme Universitaire de Technicien

8
La licence peut avoir une vocation générale ou professionnelle.

Le master peut avoir une vocation professionnelle ou de recherche.

Tableau 3 : Listes des Formations existantes à l'ENI

FORMATION

LICENCE MASTER
PROFESSIONNEL LE ET
HYBRIDE
Condition d’admission Par voie de concours
Formation Professionnelle :
100 candidats
Formation hybride : 150
candidats
Condition d’Accès Bac de série C, D ou Être titulaire de licence
Technique professionnelle
Durée de Formation 3 ans 2 ans
Diplôme délivré Diplôme de Licence Diplôme de Master
Professionnelle en Professionnel
Informatique Diplôme de Master
Recherche

L’accès en première année de MASTER se fait automatiquement pour les étudiants de

l’Ecole qui ont obtenu le diplôme de Licence Professionnelle.

Le Master Recherche permet à son titulaire de poursuivre directement des études en

doctorat et de s’inscrire directement dans une Ecole Doctorale.

Les Ecoles Doctorales jouissent d’une autonomie de gestion par rapport aux Etablissements
de formation universitaire.

Il convient de signaler que par arrêté ministériel N° 21.626/2012 – MESupRES publié le 9

Août 2012 par la Commission Nationale d’habilitation (CNH), l’Ecole Doctorale « Modélisation
– Informatique » a été habilitée pour l’Université de Fianarantsoa.

9
 Depuis l’année universitaire 2010-2011, l’ENI s’est mise à organiser des formations hybrides
en informatique dans les différentes régions (Fianarantsoa, Toliara) en raison de l’insuffisance de
la capacité d’accueil des infrastructures logistiques. En effet, le système de formation hybride semi
- présentielle utilise la visioconférence pour la formation à distance.

Bien qu’il n’existe pas encore au niveau international de reconnaissance écrite et formelle des
diplômes délivrés par l’ENI, les étudiants diplômés de l’Ecole sont plutôt bien accueillis dans les
instituts universitaires étrangères (Canada, Suisse, France…).

1.6. Relation de l’ENI avec les entreprises et organismes

Les stages effectués chaque année par les étudiants mettent l’Ecole en rapport permanent avec
plus de 300 entreprises et organismes publics, semi-publics et privés, nationaux et internationaux.

L’Ecole dispose ainsi d’un réseau d’entreprises, de sociétés et d’organismes publics et privés
qui sont des partenaires par l’accueil en stage de ses étudiants, et éventuellement pour le
recrutement après l’obtention des diplômes par ces derniers.

Les compétences que l’Ecole cherche à développer chez ses étudiants sont l’adaptabilité, le
sens de la responsabilité, du travail en équipe, le goût de l’expérimentation et l’innovation.

En effet, la vocation de l’ENI est de former des techniciens supérieurs de niveau LICENCE et
des ingénieurs de type généraliste de niveau MASTER avec des qualités scientifiques, techniques
et humaines reconnues, capables d’évoluer professionnellement dans des secteurs d’activité variés
intégrant l’informatique.

Les stages en milieu professionnel permettent de favoriser une meilleure adéquation entre les
formations à l’Ecole et les besoins évolutifs du marché de l’emploi. Les principaux débouchés
professionnels des diplômés de l’Ecole concernent les domaines suivants :

L’informatique de gestion d’entreprise :

➢ Les technologies de l’information et de la communication (TIC)

➢ La sécurité informatique des réseaux
➢ L’administration des réseaux et des systèmes
➢ Les services bancaires et financiers, notamment le Mobile Banking
➢ Les télécommunications et la téléphonie mobile
➢ Les Big Data
➢ Le commerce, la vente et l’achat, le Marketing

10
 ➢ L’ingénierie informatique appliquée
➢ L’écologie et le développement durable

Parmi les sociétés, entreprises et organismes partenaires de l’Ecole, on peut citer :

ACCENTURE Mauritius, Air Madagascar, Ambre Associates, Airtel, Agence Universitaire de la
Francophonie ( AUF) , B2B, Banque Centrale, BFG-SG, BIANCO, BLUELINE, Bureau national
de gestion des Risques et des catastrophes (BNGRC), CEDII Fianarantsoa, Data Consulting,
Central Test, Centre National Antiacridien, CNRE, CHU, CNRIT, COLAS, Direction Générale
des Douanes, DLC, FID, FTM, GNOSYS, IBONIA, INGENOSIA, INSTAT, JIRAMA, JOUVE,
MADADEV, MEF, MEN, MESupRES, MFB, MIC, Min des postes/Télécommunications et du
Développement Numérique, NEOV MAD, Ny Havana, Madagascar National Parks, OMNITEC,
ORANGE, OTME, PRACCESS, QMM Fort-Dauphin, SMMC, SNEDADRS Antsirabe, Sénat,
Société d’Exploitation du Port de Toamasina (SEPT), SOFTWELL, Strategy Consulting, TELMA,
VIVETEC, Société LAZAN’I BETSILEO, WWF …

L’organisation de stage en entreprise continue non seulement à renforcer la

professionnalisation des formations dispensées, mais elle continue surtout à accroître de façon
exceptionnelle les opportunités d’embauche pour les diplômés de l’Ecole.

1.7. Partenariat au niveau international

Entre 1996 et 1999, l’ENI avait bénéficié de l’assistance technique et financière de la Mission
Française de Coopération et d’action culturelle dans le cadre du Programme de Renforcement de
l’Enseignement Supérieur (PRESUP) consacré à l’Ecole a notamment porté sur :

 Une dotation en logiciels, micro-ordinateurs, équipements de laboratoire de

maintenance et de matériels didactiques
 La réactualisation des programmes de formation assortie du renouvellement du fonds
de la bibliothèque
 L’appui à la formation des formateurs
 L’affectation à l’Ecole d’Assistants techniques français

De 2000 à 2004, l’ENI avait fait partie des membres du bureau de la Conférence Internationale
des Ecoles de formation d’Ingénieurs et Technicien d’Expression Française (CITEF).

Les Enseignants-Chercheurs de l’Ecole participent régulièrement aux activités organisées dans

le cadre du Colloque Africain sur la Recherche en Informatique (CARI)

11
 L’ENI avait également signé un accord de coopération interuniversitaire avec l’Institut de
Recherche en Mathématiques et Informatique Appliquées (IREMIA) de l’Université de la Réunion,
l’Université de Rennes 1, l’INSA de Rennes, l’Institut National Polytechnique de Grenoble
(INPG).

A partir du mois de Juillet 2001, l’ENI avait abrité le Centre de Réseau Opérationnel (Network
Operating Center) du point d’accès à Internet de l’Ecole ainsi que de l’Université de Fianarantsoa.
Grâce à ce projet américain qui a été financé par l’USAID Madagascar, l’ENI de l’Université de
Fianarantsoa avait été dotées d’une ligne spécialisée d’accès permanent au réseau Internet.

L’ENI avait de même noué des relations de coopération avec l’Institut de Recherche pour le
Développement (IRD).

L’objet du projet de coopération avait porté sur la modélisation environnementale du Corridor

forestier de Fandriana jusqu’à Vondrozo (COFAV). Dans ce cadre, un atelier scientifique
international avait été organisé à l’ENI en Septembre 2008. Cet atelier scientifique avait eu pour
thème de modélisation des paysages.

Et dans le cadre du programme scientifique PARRUR, l’IRD avait financé depuis 2010 le
projet intitulé « Forêts, Parcs et Pauvreté dans le Sud de Madagascar (FPPSM). Des étudiants en
DEA et des Doctorants issus de l’ENI avaient participé à ce Programme.

Par ailleurs, depuis toujours la même année 2010, l’ENI de Fianarantsoa avait été sélectionnée
pour faire partie des organismes partenaires de l’Université de Savoie dans le cadre du projet
TICEVAL relatif à la certification des compétences en TIC ;

Le projet TICEVAL avait été financé par le Fonds Francophone des Inforoutes pour la période
allant de 2010 à 2012, et il avait eu pour objectif de généraliser la certification des compétences en
Informatique et Internet du type C2i2e et C2imi.

Dans le cadre du projet TICEVAL, une convention de coopération avec l’Université de Savoie
avait été signée par les deux parties concernées. La mise en œuvre de la Convention de 13
Coopération avait permis d’envoyer des étudiants de l’ENI à Chambéry pour poursuivre des études
supérieures en Informatique.

Enfin et non des moindres, l’ENI avait signé en Septembre 2009 un protocole de collaboration
scientifique avec l’ESIROI – STIM de l’Université de la Réunion.

12
 Comme l’ENI constitue une pépinière incubatrice de technologie de pointe, d’emplois et
d’entreprises, elle peut très bien servir d’instrument efficace pour renforcer la croissance
économique du pays, et pour lutter contre la Pauvreté.

De même que le statut de l’Ecole devrait permettre de renforcer la position concurrentielle de

la Grande Ile sir l’orbite de la modélisation grâce au développement des nouvelles technologies.

1.8. Débouchés professionnels des diplômes

Le chômage des jeunes diplômés universitaires fait partie des maux qui gangrènent
Madagascar. L’environnement socio-politique du pays depuis 2008 jusqu’ à ce jour a fait que le
chômage des diplômés est devenu massif par rapport aux établissements de formation supérieure
existants.

Cependant, les formations proposées par l’Ecole permettent aux diplômés d’être
immédiatement opérationnels sur le marché du travail avec la connaissance d’un métier complet
lié à l’informatique aux TIC.

L’Ecole apporte à ses étudiants un savoir-faire et un savoir-être qui les accompagnent tout au
long de leur vie professionnelle. Elle a une vocation professionnalisante.

Les diplômés en LICENCE et en MASTER issus de l’ENI peuvent faire carrière dans
différents secteurs.

L’Ecole bénéficie aujourd’hui de 34 années d’expériences pédagogiques et de reconnaissance

auprès des sociétés, des entreprises et des organismes. C’est une Ecole Supérieure de référence en
matière informatique.

Par conséquent, en raison de fait que l’équipe pédagogique de l’Ecole est expérimentée, les
enseignants-chercheurs et les autres formateurs de l’Ecole sont dotés d’une grande expérience dans
l’enseignement et dans le milieu professionnel.

L’Ecole est fière de collaborer de façon régulière avec un nombre croissant d’entreprises, de
sociétés et d’organismes publics et privés à travers les stages des étudiants. Les formations
dispensées à l’Ecole sont ainsi orientées vers le besoin et les attentes des entreprises et des sociétés.

L’Ecole fournit à ses étudiants de niveau LICENCE et MASTER des compétences

professionnelles et métiers indispensables pour les intégrer sur le marché du travail.

13
 L’Ecole s’efforce de proposer à ses étudiants une double compétence à la fois technologique
et managériale combinant l’informatique de gestion ainsi que l’administration des réseaux et
systèmes.

D’une manière générale, les diplômés de l’ENI n’éprouvent pas de difficultés particulières à
être recrutés au terme de leurs études. Cependant, l’ENI recommande à ses diplômés de promouvoir
l’entrepreneuriat en TIC et de créer des cybercafés, des SSII ou des bureaux d’études.

Tableau 4 : Débouchés professionnels éventuels des diplômes

LICENCE - Analyste
- Programmeur
- Administrateur de Site Web/ de portail Web
- Assistant Informatique et Internet
- Chef de projet Web ou MultiMedia
- Développeur Informatique ou MultiMedia
- Intégrateur Web ou Web Designer
- Hot Liner/ Hébergeur Internet
- Agent de référencement
- Technicien/Supérieur de help desk sur Informatique
- Responsable de sécurité web
- Administrateur de réseau
- Administrateur de cybercafé
MASTER - Administrateur de cyber café
- Administrateur de réseau et système
- Architecture de système d’information
- Développeur d’application /web /java/Python/ IOS /Android
- Ingénieur réseau
- Webmaster /web designer
- Concepteur Réalisateur d’applications
- Directeur du système de formation
- Directeur de projet informatique
- Chef de projet informatique
- Responsable de sécurité informatique
- Consultant fonctionnel ou freelance

14
 1.9. Ressources humaines
Directeur de l’Ecole : Monsieur MAHATODY Thomas
Responsable de Mention : Monsieur RABETAFIKA Louis Haja
Responsable de Parcours « Génie Logiciel et Base de Données » : Monsieur RALAIVAO Jean
Christian
Responsable de Parcours « Administration Systèmes et Réseaux » : Monsieur SIAKA
Responsable de Parcours « Informatique Générale » : Monsieur GILANTE Gesazafy
Nombre d’Enseignants permanents : 13 dont deux (02) Professeurs Titulaires, un (01) Professeur
Cinq (05) Maîtres de Conférences et cinq (05) Assistants d’Enseignement Supérieur et de
Recherche
Nombre d’Enseignants vacataires : 10
Personnel Administratif : 23

15
 Chapitre 2. DESCRIPTION DU PROJET
Dans ce chapitre, nous allons voir une brève description de notre projet. Cela portera sur la
formulation du projet, ainsi que le recensement des objectifs et des besoins de l’utilisateur et puis
nous enquêterons sur les moyens utiles pour mettre en œuvre les rouages du projet et enfin nous
exposerons les résultats attendus par le client en aval du projet.
2.1. Formulation
Actuellement, l’avancée dans le domaine de l’informatique a fait que le développement de
la technologie ne se bornée pas tandis dans le cloud. Cependant plusieurs des utilisateurs ne
connaissent pas ses principales utilisations.

Ainsi, dans le présent projet, nous devons élucider ces problèmes en créant une stratégie de
déploiement sur le cloud pouvant aider ces entreprises dans la quête de solution fiable, durable.

2.2. Objectif et besoins de l’utilisateur

L’objectif de ce projet est de déployer automatiquement une application avec Zero-downtime
ou aussi déploiement sans temps d'arrêt c’est à dire une méthode de déploiement d'un site Web,
d'une application ou d'un système sans jamais mettre hors service ou dans un état instable une
application pendant son processus de déploiement.

2.3. Moyens nécessaires à la réalisation du projet

La réalisation de ce projet a fait recourt aux personnels suivants :

2.3.1. Moyens humains

Pour la réalisation de ce projet, il nous faut :
 Un chef de projet, qui est l’encadreur professionnel
 Le stagiaire, nous-mêmes.

16
 2.3.2. Moyens logiciels

Le tableau décrit les applications qui ont permis d’effectuer le projet

Tableau 4. Application installe pour la mise en œuvre

UTILITE DANS LE
DESIGNATION VERSION
PROJET

Visual Studio Code 1.74 - Préparation

Infrastructure
Docker 20.10.16 - Conteneurisation
Google Chrome 108.0.5359.99 - Pour faire des tests
Microsoft Office Word Office 2016 - Rédaction

2.3.3. Moyens matériels

Le tableau 4 propose la configuration du matériel utilisé
Tableau 5 : configuration du matériel utilisé

Marque type Système processeur RAM Disque Fréquence

d’exploitation dur
ASUS Portable Windows 10 Core i5 8Go 1To 2.5 Ghz

2.4. Résultat attendus

Le résultat attendu de ce projet est de déployer un application ou service d’une manière à

ce que l’utilisateur n’ait pas conscience d’un quelconque temps d’arrêt pendant le déploiement.

2.5. Chronogramme des activités

Le tableau 5 décrit les taches durant le stage
Tableau 6 : Description des tâches au cours du stage

Tâches Date
Début du stage 19 septembre 2022
− Integration a l’équipe et prise en main 19 septembre 2022 – 18 octobre 2022
de Google Cloud Plateform
− Maitriser et analyser des existants
− Choix définitif du thème

17
 − Documentation et recherche
concernant le thème
− Choix et installation du système
d’exploitation pour le faire
− Relevé des problèmes et étude des 19 Octobre 2022 - 26 Octobre 2022
solutions apporter
Mise en œuvre du projet : 27 Octobre 2022 –03 Décembre 2022
✓ Configuration et installation
des serveurs
✓ Installation des outils
✓ Création d’application CRUD
✓ Configuration des outils

Finalisation du stage : 04 Décembre2022-19 Décembre2022

✓ Validation et tests du
fonctionnement du projet
✓ Rédaction mémoire
Fin du stage 19 Décembre 2022

18
Partie II : ETUDES THEORIQUES

19
 Chapitre 3. ANALYSE PREALABLE
L’analyse est une découverte suivi d’une étude. Elle permet ansi d’identifier s’il y a des
problemes, de critique, et d’apporter des solutions ensuite.

Cette partie, dans laquelle seront découverts et analysés les existants, constitue une étape
primordial pour bien mener ce projet. Avant de procéder à cette analyse, il parait indispensable de
décrire d’abord et de se familiariser dans le monde et la notion Devops.

[Link]
Le terme « DevOps » est la contraction des mots anglais « Development» (développement)
et « Operations » (exploitation). Il reflète toutefois un ensemble d’idées et de pratiques bien plus
large que ces deux seuls mots pris ensemble ou séparément. Ce concept englobe la sécurité, le
travail collaboratif, l’analyse des données et bien d’autres principes. Mais de quoi s’agit-il
exactement ?
Le DevOps décrit des approches d’accélération des processus selon lesquels une idée (par
exemple, une nouvelle fonction logicielle, une demande d’amélioration ou la correction d’un
bogue) passe de la phase de développement à celle du déploiement dans un environnement de
production où elle peut apporter de la valeur à l’utilisateur. Ces approches nécessitent que les
équipes de développement et d’exploitation communiquent fréquemment entre elles et abordent
leur travail en gardant à l’esprit celui de leurs collaborateurs. Le provisionnement doit également
etre évolutif et flexible. Avec le modèle DevOps, ceux qui ont le plus de besoins sont satisfaits,
grace au libre-service et à l’automatisation. Les développeurs, qui travaillent généralement dans un
environnement de développement standard, collaborent étroitement avec les équipes d’exploitation
informatique pour accélérer la conception des logiciels, les tests et les lancements sans pour autant
sacrifier la fiabilité.
3.1.1. Les avantages de l’approche DevOps

DevOps offre de nombreux avantages, autant sur le plan humain que professionnel. Ainsi, si vous
souhaitez mettre en place cette approche pour votre entreprise, vous tirerez parti divers avantages.

a) Une meilleure collaboration entre les équipes

Le développement et les opérations sont 2 activités qui sont le plus souvent traitées de façon séparée
dans les processus de développement classiques. Cela pose un problème entre l’équipe de
développement logicielle et l’équipe opérationnelle chargée de l’explication. Les deux parties étant

20
occupées à œuvrer pour la réussite de leurs missions respectives n’ont aucune idée des obstacles
que chacun rencontre dans son domaine.

Pour remédier à ce problème, DevOps permet une collaboration directe entre les développeurs de
logiciels et les équipes chargées des opérations IT. Cette approche repose sur en place de processus
automatisés, la mise à disposition d’outils et la mise en œuvre de bonnes pratiques. Ainsi, les
équipes peuvent communiquer en permanence afin qu’elles puissent mieux comprendre les défis
de chacun et travailler ensemble à la réussite des projets.

b) Gain de temps et un gain d’argent

Avec la mise en place du DevOps, les entreprises peuvent déployer très rapidement de nouveaux
systèmes, processus et applications. Les opérations commerciales seront plus efficaces et vous
conservez un avantage concurrentiel sur le marché. Le temps de cycle réduit qui est dépensé
entraine la réduction du cout de fabrication du produit. Cela représente pour vous un gain d’argent
et de temps considérable.

c) Une amélioration de la satisfaction et de l’expérience client

La relation client occupe une place importante dans le succès et la pérennité de toute entreprise.
C’est pourquoi elles accordent la priorité à cette dimension. DevOps intègre la satisfaction de la
clientèle et l’amélioration de l’expérience client. Ainsi, vous pourrez augmenter vos opportunités
de vente. Aujourd’hui, les entreprises qui ont adopté une approche DevOps enregistrent un taux de
satisfaction de la clientèle supérieur de 52%.

d) Une grande rapidité dans la production et la livraison

Les entreprises sont parfois confrontées à des problèmes de gestion et cela peut entrainer un retard
dans la production ou la livraison des services. De même, il peut arriver que le service proposé ne
répondre pas aux exigences du client. De tels incidents peuvent nuire à la notoriété de votre
entreprise et se traduire par un préjudice pour vos clients.

L’adopter de DevOps vous permet de simplifier les processus et d’automatiser la grande majorité
de vos opérations. Grace à cette approche, le rythme de production et de livraison est beaucoup
plus rapide et la qualité des services offerts est supérieure.

21
 e) Une capacité d’innovation

Adopter l’approche DevOps permet aux entreprises d’avoir du temps à consacrer à l’innovation.
La création et la livraison des produits étant rapides, les équipes peuvent consacrer le temps gagné
au développement de nouvelles idées, à l’expérimentation de nouvelles fonctionnalités ou à
l’amélioration de celles déjà existantes. Plus vous disposez de temps pour innover et plus votre
entreprise se développera.

f) Une détection rapide des problèmes

Un problème qui n’est pas vite résolu lors de la production entraine inévitablement un retard dans
la livraison et une perte d’argent. La mise en place d’un processus DevOps vous permet de détecter
rapidement les problèmes et de les résoudre sans plus tarder. Vous avez ainsi moins de perte de
temps et d’argent.

[Link] de l’existant
ENI utilise déjà le système d’intégration et déploiement continue mais parfois l’application
arrête quand il y a des nouveaux mis à jour sur l’application, c’est-à-dire quand les développeurs
ont déployé un nouveau code vers le serveur.

[Link] de solution
3.3.1. Déploiement Continue
Il existe de nombreux nombre stratégie moderne de déploiement d’une application ou
logiciel, le déploiement continue et l’un de ces stratégies.

Le déploiement continu ne nécessite aucune évaluation ni vérification manuelles des

changements de code dans l'environnement de test, puisque les tests automatisés sont intégrés très
tôt dans le processus de développement et se poursuivent tout au long des phases du lancement.

Le déploiement continu présente un avantage : l'absence d'attente entre la réussite des tests
d'un changement de code aux niveaux de l'application et de la plateforme et sa mise en production.
[1]

22
 Figure 2 : Concept du déploiement continue

3.3.2. Déploiement sans interruption de service

Il existe de nombreux moyens pour les équipes informatiques de faciliter les déploiements
d’applications, et le ZDD n’est que l’un d’entre eux.

L’une des principales caractéristiques du ZDD est qu’il est réalisé de manière à ce que
l’utilisateur n’ait pas conscience d’un quelconque temps d’arrêt pendant que vous déployez la
nouvelle version de l’application sur votre réseau. Cela signifie que le serveur Web ne publie pas
le code modifié ou les changements tant que le déploiement n’est pas terminé.

Et comme il s’agit d’une tâche que les entreprises doivent accomplir souvent (plus encore
que la plupart des utilisateurs), l’exécution continue d’un ZDD réussi est une partie essentielle du
maintien de la réputation de l’entreprise auprès des clients. En effet, les clients attendent des
entreprises qu’elles soient opérationnelles 24 heures sur 24, 7 jours sur 7 et 365 jours par an.
Dans le même temps, ils s’attendent à ce que les applications fonctionnent efficacement et sans
bugs. C’est pourquoi le ZDD est si important [2].

L’objectif est d’associer le mécanisme de répartition de charge (Load Balancer) au

processus de déploiement :
• Le loadbalancer dirige la requête sur laquelle est déployée la version N.
• Un processus interne procéder à l'installation de la version N+1 de l'application.
• Une fois cette migration effective, le loadbalancer dirige les utilisateurs vers ce nouveau
serveur en version N+1,

23
• Il déconnecte le serveur avec la version N de l'application et redirige les requêtes vers le
nouveau serveur.

24
 Chapitre 4. ETUDES THÉORIQUES DE LA SOLUTION À
METTRE EN PLACE
4.1. Gestionnaire de version : Git
4.1.1. Définition
Git est de loin le système de contrôle de version le plus largement utilisé aujourd'hui. Git
est un projet open source avancé, qui est activement maintenu. À l'origine, il a été développé en
2005 par Linus Torvalds, le créateur bien connu du noyau du système d'exploitation Linux. De plus
en plus de projets logiciels reposent sur Git pour le contrôle de version, y compris des projets
commerciaux et en open source. Les développeurs qui travaillent avec Git sont bien représentés
dans le pool de talents disponible, et la solution fonctionne bien sur une vaste gamme de systèmes
d'exploitation et d'environnements de développement intégrés (IDE).

4.1.2. Git vs SVN

Ci-dessous un tableau comparatif entre ces deux outils ce qui permettra par la suite
d’effectuer notre choix technique.

Tableau 5 : Tableau de comparaison su SVN et Git

Aspect SVN Git

Distribué, tous les développeurs qui vérifient
Centralisé, uniquement le répertoire
le code à partir d’un dépôt / serveur central
central a l’historique complet des
auront leur propre référentiel cloné installé
changements. Les utilisateurs doivent
sur leur machine.
Architecture communiquer via le réseau avec le
Ce qui permet les développeurs de pouvoir
répertoire central pour obtenir
créer une nouvelle branche, de faire
l’historique. Les backup sont gérés et
un « commit » sur un fichier et de revoir une
maintenus indépendamment du SVN.
version même en absence de connexion.
Si le répertoire central est La notion de « single point of failure »
Single point endommagé, alors uniquement les n’existe pas car il y a autant de copie du
Failure données enregistrées dans le dernier dossier
backup sont récupérable. qu’il y’en a d’utilisateur si ce n’est plus.
Nécessité d’un « commit Access » due Non nécessite d’un « Commit access »
Contrôle d’accès
au fait de la centralisation. puisque le système est distribué. Il faut juste

25
 décider
de fusionner quoi à partir de quel utilisateur.
Stockage des métadonnées des Stockage de tout le contenu dans un dossier
Stockage
fichiers sous forme de dossier caché .git, c’est le dépôt du code cloné sur la
contenu
.svn machine client
Les branches sont gérées comme étant
un La gestion des branches est assez simple,
autre dossier dans le dépôt du code, nous pouvons facilement naviguer entre les
elles ne différentes branches d’un même répertoire de
sont pas historiées. Pour connaître s’il y travail. Chaque répertoire de travail existant
a eu chez un utilisateur est considéré comme une
fusion entre des branches, il faut branche. La fusion de la branche inclut les
Les branches explicitement exécuter une commande. informations suivantes : auteur, heure, date,
Cette façon de gérer les branches informations relatives à la branche et à la
démultiplie les chances de créer des révision, les changements effectués par
branches « orpheline ». Une fois la rapport
fusion est à la version antécédente. La fusion suivante,
faite nous ne pouvons plus savoir ce qui commence automatiquement là où la dernière
a fusion a été faite.
été modifié.
Le répertoire de travail contient deux
copie Taille du dépôt de code et répertoire de travail
de chaque fichier, un pour travailler relativement petit (30X inférieur à celui de
Espace avec et SVN). Ceci est due au fait que pour Git, le
un caché dans le .svn, ce qui rend répertoire de travail nécessite seulement un
l’espace fichier d’index de taille 100 bits pour
nécessaire relativement grand.

Cette comparaison a été faîtes pour un but académique, le choix du gestionnaire

du code source a été fait par l’entreprise.

26
 [Link] de solution de virtualisation
4.2.1. La virtualisation
a) Définition

La virtualisation consiste à créer une version virtuelle d'un dispositif ou d'une ressource,
comme un système d 'exploitation, un serveur, un dispositif de stockage ou une ressource ré- seau.
Elle peut donc être considérée comme l'abstraction physique des ressources informatiques. En
d'autres termes, les ressources physiques allouées à une machine virtuelle sont abstraites à partir
de leurs équivalentes physiques. Chaque dispositif virtuel, qu'il s'agisse d'un disque, d'une interface
réseau, d'un réseau local, d'un commutateur, d'un processeur ou d'une mémoire, correspond à une
ressource physique sur un système informatique. Les machines virtuelles hébergées par la machine
hôte sont donc perçues par ce dernier comme des applications auxquelles il est nécessaire de dédier
ou distribuer ses ressources. Cependant, il existe plusieurs types de virtualisation (Hess et Newman,
2010). Chaque type correspond à un cas d'utilisation spécifique, comme cela sera présenté dans la
section suivante.

b) Types de virtualisation

Il existe de nombreux domaines d'application à la virtualisation, s'agissant généralement de

la virtualisation du stockage, du réseau, ou du serveur.

• La virtualisation du stockage : Elle est obtenue en isolant les données de leur

localisation physique. Elle permet de masquer les spécificités physiques des unités de stockage.
Vues de l'extérieur, les unités de stockage sont perçues comme étant un volume unique. La
virtualisation du stockage est couramment utilisée dans un réseau de stockage ( SAN et NAS).
• La virtualisation du réseau : Elle consiste à combiner des ressources réseaux
physiques (commutateurs, routeurs, etc.) et logiques (bande passante, adressage, etc.) pour créer
des réseaux virtuels, découplés du matériel réseau sous-jacent. L'objectif est de garantir aux
systèmes et aux utilisateurs un partage efficace et sécurisé des ressources physiques du réseau.
• La virtualisation du serveur : Ce type de virtualisation se définit comme l'ensemble des
techniques matérielles ou logiciels qui permettent de faire fonctionner plusieurs systèmes, serveurs
ou applications sur une seule machine en donnant l'illusion qu'ils fonctionnent sur différentes
machines. Dans la suite de ce mémoire, nous nous intéressons à la virtualisation du serveur. Plus
précisément, nous étudions ci-après les deux techniques de virtualisation du serveur, à savoir la
virtualisation système et la virtualisation applicative.

27
 b.1) La virtualisation système
Cette technique de virtualisation du serveur fait référence à l'utilisation d'un hyperviseur
pour permettre à la machine hôte d'exécuter plusieurs instances virtuelles en même temps. Ces
dernières sont communément appelées des VMs (Virtual Machines), tandis que l'hyperviseur est
connu sous le nom de VMM (Virtual Machines Monitor), c'est-à-dire gestionnaire de VM. Ces
nouvelles notions sont définies comme suit :
- Machine virtuelle ( VM) : il s'agit d'une version virtuelle d'un matériel dédié
avec son propre système d'exploitation (Operating System- OS'). Comme dans une machine réelle,
chaque VM conserve un fonctionnement normal, défini comme suit : une VM gère les accès
mémoire (RAM) , disque, réseau, processeurs (CPU) et autres périphériques de ses processus.
- Hyperviseur ( VMM) : il implante les mécanismes d 'isolation et de partage
des ressources matérielles. Il est capable de démarrer simultanément plusieurs machines virtuelles
de différents types (Linux, Mac ou Windows) sur le même matériel. Quoique les VM gèrent les
accès aux ressources, aucun accès aux ressources n'est possible sans l'aval du VMM. Ce dernier
décide notamment des attributions de temps processeurs aux machines virtuelles.
Quant à la communication avec l'extérieur, l'hyperviseur peut fournir plusieurs techniques pour
rendre accessible ou non les VM. Il peut réaliser cette tâche par l'assignation d'adresses IP (Internet
Protocol) et par implantation de mécanismes d'accès réseau aux VM (par routage, filtrage de
communication, etc.). On peut distinguer deux types d'hyperviseur (Soriga et Barbulescu) :
• Hyperviseur de type 1 (natif) : Il s'installe directement sur la couche physique du matériel
du serveur. Ainsi, au démarrage de ce dernier, ce VMM prend le contrôle exclusif du matériel.
Hyper-V, Xen, VMware, ESXi, KVM sont des hyperviseurs de type 1 (Fayyad-Kazan et al.,
2013).
• Hyperviseur de type 2 (hébergé) : Comparable à un émulateur, il s'installe sur l' OS installé
sur le matériel du serveur. Il démarre comme un logiciel installé sur le système d'exploitation.
Comme exemples, on peut citer Oracle VM (Virtual Box), Workstation, Parallèles et Fusion.

28
 Figure 3 : Types d'hyperviseur

b.2) La virtualisation applicative

Contrairement à la virtualisation système, le principe de cette technique est de
mettre en œuvre une couche de virtualisation sous forme d'une application qui elle-même crée des
instances virtuelles et les isole des spécificités de la machine hôte, c'est-à-dire de celles de son
architecture ou de son système d'exploitation. Ceci permet au concepteur de l'application de ne pas
avoir à rédiger plusieurs versions de son logiciel pour qu'il soit exécutable dans tous les
environnements. Les machines virtuelles applicatives les plus connues sont la J VM (Java Virtual
Machine).
• Java Virtual Machine (JVM) : Elle est gratuite, propriétaire jusqu'à la version 6
(stable) et libre sous la GPL (General Public License) à partir de la version 7. La JVM permet aux
applications J ava compilées de produire les mêmes résultats quelle que soit la plateforme, tant que
celle-ci est pourvue de la machine virtuelle Java adéquate (Czajkowski, 2000).
• Conteneurs : Mieux que la JVM, les conteneurs fonctionnent avec toutes les
technologies compatibles avec Linux (par exemple Java, Python , Ruby, Nodejs et Go) . Les
conteneurs sont isolés les uns des autres et peuvent optimiser l'utilisation des ressources (CPU,
RAM, stockage) de la machine hôte.

29
 4.2.2. La Technologie Docker
a) Définition
Docker est une solution de virtualisation légère pour Linux créée en 2013 et possédant une forte
dynamique de développement et de déploiement. Docker est une plateforme permettant de
construire, déployer, et lancer des applications cloisonnées. Contrairement à d'autres systèmes de
virtualisation légère comme OpenVZ ou LXC qui ont des approches purement "virtualisation" d'un
système Docker se place dans un cadre applicatif.
L'objectif est de permettre aux développeurs et administrateurs de créer facilement des
"Dockerfiles" décrivant un système : packages, fichiers de configuration, ports utilisés, etc. Cette
description permet ensuite à n'importe qui possédant Docker de construire le conteneur applicatif,
assurant ainsi un environnement compatible. La virtualisation légère de Docker se base sur les
fonctionnalités fournies par le kernel Linux comme les cgroups et les kernel namespaces,
permettant de garder des performances attendues d'un système de virtualisation légère.

b) Poids léger
Les conteneurs en cours d'exécution sur une seule machine partagent tous le même noyau
du système d'exploitation afin qu'ils commencent instantanément et de faire une utilisation plus
efficace de la RAM. Les images sont construites à partir de systèmes de fichiers en couches afin
qu'ils puissent partager des fichiers communs, ce qui rend l'utilisation du disque et de l'image de
téléchargements beaucoup plus efficace.
c) Plateforme
La plateforme Docker est composée de deux éléments :
• Le démon Docker qui s’exécute en arrière-plan et qui s’occupe de gérer les conteneurs
• Le client Docker qui permet d’interagir avec le démon par l’intermédiaire d’un outil en
ligne de commande.
d) Comparaison Docker et Machine virtuel
Les conteneurs ont des avantages d'isolement des ressources et de répartition similaire
à des machines virtuelles, mais une approche architecturale différente leur permet d'être
beaucoup plus portables et efficaces.
Contrairement aux machines virtuelles traditionnelles, un conteneur Docker n'inclut pas
de système d'exploitation, s'appuyant sur les fonctionnalités du système d’exploitation fournies
par l'infrastructure sous-jacente.

30
 • Machine virtuelle : Chaque machine virtuelle comprend l'application, les binaires et les
bibliothèques nécessaires et tout un système d'exploitation invité - qui peuvent être des
dizaines de GBs taille.
Conteneur : Les conteneurs comprennent l'application et toutes ses dépendances, mais partagent le
noyau avec d'autres conteneurs. Ils fonctionnent comme un processus isolé dans l'espace utilisateur
sur le système d'exploitation hôte. La figure 4 explique la différence entre la virtualisation
traditionnelle par VMware et la nouvelle solution par Docker.

Figure 4 :Comparaison du machine virtuel avec docker

Le tableau 6 montre les caractéristiques des technologies de virtualisation

Tableau 6 : Caractéristiques des technologies de virtualisation.

Paramètres Machine Virtuel Conteneur Docker

OS invité Chaque VM virtualise le Aucun conteneur n'émule le
matériel hôte et charge son matériel hôte. Il utilise directement
propre OS l’OS hôte
Communication Via des périphériques Via les mécanismes IPC
Ethernet (InterProcess Communication)

31
 standard tels que les sockets, les
pipes, la mémoire partagée, etc
Utilisation des Forte utilisation Utilisation presque native
ressources ( CPU et RA M)
de la machine hôte
Temps de démarrage La VM prend quelque Ne prends que quelque seconde
minutes pour démarrer
Pour démarrer
Nécessite beaucoup plus de Utilise moins d'espace de stockage
stockage car son OS tout car le système d 'exploitation de
Stockage entier et ses programmes base est partagé
associés doivent être installés
et exécutés

Isolation Le partage de librairies, Les sous-répertoires peuvent être

fichiers, etc. entre VM est montés de manière transparente
impossible
Sécurité Dépend de la configuration de Nécessite un contrôle des accès
l 'hyperviseur

Vu ses points forts, sa légèreté, son portabilité et l’isolation qu’il offert, nous avons décidés de
choisir docker comme solution de virtualisation pour mettre en place notre plateforme de
déploiement continue.

[Link] script YAML et Groovy

Dans notre projet, nous avons utilisés deux types de scripts, yaml et groovy.

4.3.1. YAML

Pour le développement des scripts, nous avons utilisés le langage de sérialisation YAML
qui fournit de puissants paramètres de configuration, sans avoir à apprendre un type de code
plus complexe comme CSS, JavaScript et PHP.
YAML est l’acronyme de «Yet Another Markup Language», il se définit comme étant «un
standard de sérialisation de données pour tous les langages, facile à utiliser pour les humains ».

32
• Standard : car il n’y a pas d’approximation à avoir sur le contenu écrit en YAML.
• Sérialisation de données : consiste en la transformation d’une structure de données en un fichier
texte.
• Human-friendly : une structure de données écrite en YAML est très simple à lire, facile à
comprendre, et facile à éditer.

4.3.2. Groovy

Groovy est le nom d'un langage de programmation orienté objet destiné à la plate-forme Java.
Il constitue une alternative au langage Java pour cette plate-forme et est inspiré de Python, Ruby
et Smalltalk. Groovy utilise une syntaxe très proche de Java, avec des accolades, et est directement
compilé, soit à la volée dynamiquement, soit classiquement avec un compilateur en bytecode.
Groovy s'intègre et est entièrement compatible avec la JVM étant donné que le bytecode est le
même. Il peut donc :
• utiliser les bibliothèques Java ;
• être utilisé dans des classes Java.
Groovy peut être comparé à BeanShell, l'objectif de faire un langage de scripting proche de
java est le même, la mise en œuvre étant différente.

[Link] d’orchestration : Jenkins vs Bamboo vs Travis

Jenkins, travis et bamboo sont des outils d’orchestration bien connu sur le marché, chacun
d’entre eux présente ses avantages et ses inconvénients. Le tableau 7 permet de comparer entre ces
outils. La comparaison se base sur l’aspect Open source du code, le nombre de plugins, la simplicité
d’utilisation et l’interfaçage avec les différents outils de gestion de version.

Tableau 7 : Comparaison des outils d'intégration continue

Aspect Jenkins Bamboo Travis

Open source Oui Non Oui
Plugins Oui Cher Peu
Simplicité Non Oui Non
Outil de
Tout Tout GitHub
versioning

33
 L’étude comparative entre ces différents serveurs d’orchestration a dirigé notre choix vers
Jenkins, qui, grâce à ses nombreux plugins, permet un interfaçage facile avec de nombreux outils
dont nous avons besoin tel que kubernetes.

4.5.L’infonuagique (Cloud Computing)

Le cloud computing ou l'infonuagique, est une infrastructure informatique distribuée de
processeurs et de mémoires, accessible à des usagers via un réseau, généralement l’Internet. Ainsi,
n'importe quel matériel connecté (ordinateur de bureau, portable, tablette, téléphone, ou autre objet
connecté) peut servir d'outil pour exécuter diverses applications ou consulter des données
hébergées sur des serveurs cloud. Le NIST (National Institute of Standards and Technology) définit
ce concept comme étant « l'accès via le réseau, à la demande et en libre-service, à des ressources
informatiques virtualisées et partagées » (Mell et al., 2011). L'informatique nuagique permet donc
de décharger les serveurs et les services traditionnellement localisés sur des serveurs locaux vers un
ou plusieurs fournisseurs tiers dotés de la compétence et des ressources requises au maintien de cette
architecture réseau et de ces services.

4.5.1. Les caractéristiques des Cloud

Le cloud se distingue des environnements informatiques classiques par les caractéristiques

suivantes :
• Service à la demande : les services sont fournis au client automatiquement et sans intervention
humaine ;
• Élasticité rapide : les ressources de stockage, de calcul, et de bande passante peuvent être
rapidement ajustées statiquement ou dynamiquement en fonction des besoins immédiats de chaque
client ;
• Mutualisation : les différents clients bénéficient de ressources de serveurs allouées de manière
dynamique et rapide dans le cadre d'un modèle de cloud communautaire ;
• Résilience : le cloud computing se doit d'apporter des mécanismes hétérogènes où les
technologies présentes supportent une multitude de clients légers (ordiphones, tablettes) et de
clients lourds (ordinateurs) ;
• Paiement à l’utilisation : contrairement aux centres d'hébergement web classiques dans lesquels
le paiement se fait à l'avance sous forme de forfait, le cloud propose une facturation à l'usage. Les
services se facturent en fonction

34
 4.5.2. Les niveaux de service

Le terme cloud computing est apparu au début des années 2000 mais, historiquement, le
concept de l'informatique en tant que service existe depuis bien plus longtemps. Il remonte aux
années 1960, quand des sociétés de services informatiques permettaient aux entreprises de louer
du temps sur une plateforme matérielle, au lieu de devoir en acheter une elles-mêmes. Les années
1990 voient l'explosion de l’Internet ; l'accès aux services peut s'effectuer via le réseau. Le cloud
computing distribue à présent ces services sous la dénomination Software as a Service (SaaS). Le
concept n'utilise plus de clients lourds comme des logiciels dédiés, mais un simple navigateur
Internet

Le cloud peut offrir trois niveaux de service : le IaaS, le PaaS et le SaaS. Dans le niveau
IaaS (Infrastructure as a Service), le matériel est l'unique élément à être décentralisé. Les clients
s'abstraient donc de toute contraintes de gestion du matériel physique.

Le niveau PaaS (Plateform as a Service) constitue sur le niveau supérieur à IaaS.

Il offre aux entreprises un environnement de développement ou d'hébergement de leurs
applications. L'entreprise client ne se soucie plus de l'infrastructure sous-jacente.

Le niveau le plus commun est le SaaS (Software as a Service). Il qui apporte aux clients une
application (logiciel) à la demande et sous la forme d'un service prêt à l'emploi. Les utilisateurs du
service ne se préoccupent plus de l'architecture matérielle (installation, maintenance) et logicielle
(mises à jour) sous-jacente. La figure5 montre l'interaction entre te fournisseur du cloud et le client
en fonction des niveaux de service. Ces derniers doivent être déployés sur des infrastructures qui
possèdent les caractéristiques essentielles présentées dans la section 4.4.1 pour être considérées
comme étant des plateformes de cloud computing.

Figure 5 : Les niveaux de services dans le cloud

35
 4.5.3. Les modèles de déploiement

Les trois niveaux de service cités dans la section précédente peuvent être déployés
chez le client via :

1. Un cloud public géré par un prestataire de services privé, par exemple Google, Amazon, etc. ;

2. Un cloud privé prévu pour les besoins de l'entreprise. Il y a les clouds privés internes, où
l'entreprise bâtit son propre centre de données pour ses propres besoins, et les clouds privés
externes, où un fournisseur réserve une partie de ses serveurs à l'usage exclusif d 'un client. Dans
ce dernier cas, l'infrastructure est entièrement dédiée au client et accessible via des réseaux
sécurisés de type VPN ( Virtual Private Network) .

3. Un cloud communautaire où l'infrastructure est partagée par plusieurs organisations qui ont des
intérêts communs (par exemple des exigences de sécurité, de conformité, etc.). Comme le cloud
privé, il peut être géré par les organisations elles-mêmes ou par un tiers.

4. un cloud hybride où l'entreprise peut gérer des ressources internes via deux nuages ou plus (privé,
communautaire ou public), qui restent des entités uniques, mais qui sont liées par une technologie
normalisée ou propriétaire.

Ceci permet la portabilité des données ou des applications.

4.5.4. Le Cloud face au défi de l’isolation

Comme dans toute infrastructure informatique, la mutualisation de ressources dans le cloud

implique la mise en place de divers mécanismes de sécurité, de comptage de ressources, de gestion
des conflits d'accès, etc. L'isolation a été proposée afin de garantir la mutualisation des ressources.
Isoler revient à gérer les contraintes suivantes :

1. Garantir au client l'exclusivité d'accès à un ensemble de ressources durant toute sa présence dans
le cloud (malgré la mutualisation).

2. Donner à chaque client du cloud l'illusion d'être le seul utilisateur. Rien ne doit le laisser présager
la présence d'autres utilisateurs ou applications.

3. Assurer la non-monopolisation des ressources globales du cloud par un seul client.

4. Assurer la non-violation des espaces utilisateurs dans le cloud.

36
 [Link] d’Orchestration de conteneurs docker
4.6.1. Introduction
Les conteneurs Docker constituent une méthode de virtualisation légère au niveau du système
d'exploitation qui permet de lancer une application et ses dépendances à travers un ensemble de
processus isolés du reste du système. Cette méthode permet d'assurer le déploiement rapide et
stable des applications dans n'importe quel environnement informatique.
En plein essor depuis quelques années, les conteneurs Docker ont modifié la façon dont nous
développons, déployons et maintenons des logiciels. Leur légèreté et flexibilité ont favorisé
l'apparition de nouvelles formes d'architectures qui organisent les applications au sein de
conteneurs Docker, prêts à être déployés sur un cluster (groupe) de machines virtuelles ou
physiques. Toutefois, cette nouvelle approche requiert des nouveaux outils d'orchestration de
conteneurs Docker

4.6.2. Caractéristiques d’un orchestrateur de conteneurs

Manipuler quelques conteneurs Docker sur une seule machine est une tâche facile.
Lorsqu'il s'agit de faire passer ces conteneurs en production (sur un ensemble d'hôtes distribués),
de nombreuses questions se posent :
• Comment gérer les déploiements et leurs emplacements?
• Comment gérer l'équilibrage des charges?
• Comment gérer la communication entre les conteneurs ?
• Comment gérer la découverte de services?
• Comment gérer les mises à jour ?
• Comment gérer la montée en échelle ?
• Comment gérer le stockage nécessaire à la persistance des données ?
• Comment gérer la configuration et les secrets ?
• Mais aussi, comment gérer les dysfonctionnements ?

Tout gérer de manière manuelle n'est pas concevable, car il serait difficile d'assurer la
viabilité, la maintenance et la pérennité du système. Un outil autonome capable de répondre à ces
besoins est donc requis. Cet outil constituera la plateforme d'orchestration de conteneurs.
Il existe plusieurs orchestrateurs, par exemple, Fleet, Mesas Apache, Swarm et Kubernetes.
Toutefois, dans la suite de ce chapitre, nous nous intéressons à Swarm et à Kubernetes. Ces derniers
se présentent comme étant des solutions stables, gratuites et capables d'automatiser le déploiement,

37
la migration, la surveillance, la mise en réseau, l'extensibilité et la disponibilité des applications
basées sur la technologie des conteneurs Docker. Cependant, chacun d'eux propose ses propres
architectures et méthodologies pour la gestion de conteneurs. Leurs définitions, architectures et
fonctionnements seront détaillés ci-après

4.6.3. L’orchestrateur Swarm

a) Définition
Swarm (Luzzardi et Victor, 2014 ; Soppelsa et Kaewkasi, 2016) 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 démon Docker depuis la version 1.12 en 2016. 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
(Naik,2016).

b) Architecture de Swarm
L'orchestration avec Swarm est axée sur une simple architecture en cluster(s)(Luzzardi et
Victor, 2014; Cérin et al., 2017; Kovacs et al., 2018). Un cluster Swarm est constitué d'un nœud
gestionnaire (manager Swarm) et de nœud(s) de travail (worker Swarm)

• Le manager Swarm : Il effectue les fonctions d'orchestration et de gestion nécessaires à la

conservation de l'état souhaité du cluster. Il planifie et dé- ploie les conteneurs vers les nœuds de
travail. L'initialisation du cluster se fait au niveau du manager.

• Les workers Swarm : Ils reçoivent et exécutent les conteneurs répartis à partir du manager. Un
agent Swarm s'exécute sur chaque worker et rend compte des tâches qui lui sont assignées.

38
 Figure 6: Architecture de Swarm

4.6.4. L’orchestrateur Kubernetes

a) Définition
Kubernetes, K8s en abrégé (Bernstein, 2014 ; Rensin, 2015 ; Burns et al., 2016; Google,
2018) , est un projet initié par Google en 2014 quand il a perçu l'avantage des conteneurs Docker
par rapport à la virtualisation traditionnelle. Il s'agit d'une innovation après plus d'une décennie
d'expérience avec Borg (Burns et al., 2016), son premier gestionnaire de conteneurs.
L'orchestrateur Kubernetes automatise le déploiement et la gestion d'applications conteneurisées à
grande échelle. La plateforme K8s permet d'exécuter et de coordonner des conteneurs sur un
ensemble de machines physiques et/ ou virtuelles. Elle est conçue pour gérer entièrement le cycle
de vie des applications conteneurisées en utilisant des méthodes de prédictibilité, d'extensibilité et
de haute disponibilité (Kratzke et Quint, 2017). D'autres kubeconlig entreprises, telles que Red Hat,
contribuent également au développement de Kubernetes, disponible sur GitHub (K8s, 2014), la
plateforme de partage de code la plus populaire au monde.

39
 b) Architecture de Kubernetes
Kubernetes orchestre les conteneurs Docker suivant une architecture maître/ esclaves (Bila
et al., 2017) constituée d'un nœud maître et de nœud(s) de travail (minion). Un agent K8s est
instaUé sur chaque nœud client (les exécuteurs) et renvoie des rapports au nœud maître. Ce dernier
est le responsable du cluster Kubernetes.

• Le maître Kubernetes : Ce nœud est responsable de la gestion globale et de la disponibilité du

cluster Kubernetes. Ses composants, c'est-à-dire le serveur API, le contrôleur et le planificateur
prennent en charge les tâches d'interaction, de surveillance et de planification au sein du cluster.
Le serveur API fournit l'interface à l'état partagé du cluster via laquelle tous les autres corn posants
interagissent. Le contrôleur surveille l'état partagé du cluster via le serveur API et apporte des
modifications afin de ramener le cluster de l'état actuel instable vers un état stable. Le planificateur
gère la charge du cluster. Il prend en compte les besoins en ressources individuels et collectifs, les
exigences de qualité de service, les contraintes matérielles/ logicielles, les politiques, etc. Les
données du cluster Kubernetes sont stockées dans une base de données, (etcd (CoreOS, 2018) par
exemple). L'administration du cluster se fait donc au niveau du maître via la kubectl, l'interface de
ligne de commande de K8s. La kubectl a un fichier de configuration appelé kubeconfig. Ce dernier
contient les informations de configuration et d'authentification pour accéder au serveur API.

• Les minions Kubernetes : Ceux-ci sont les nœuds sur lesquels s'exécutent les applications
conteneurisées. D'une part, les nœuds clients communiquent avec le nœud maître via leur kubelet.
Le kubelet reçoit les ordres du nœud maître et les exécute via son moteur Docker. Il rapporte
également l'état du nœud client au serveur API du nœud maître. D'autre part, le kubeproxy s'exécute
sur chaque nœud client afin de gérer l'accès des utilisateurs finaux aux services déployés. Chaque
service est compilé dans un ou plusieurs pod. Un pod est un ensemble logique d 'un ou plusieurs
conteneurs. Il s'agit de la plus petite unité pouvant être programmée en tant que déploiement dans
Kubernetes. Les conteneurs d'un même pod partagent, entre autres, la
capacité de stockage et l'adresse IP sur le réseau. Le placement de ces pods se fait en suivant une
stratégie propre à Kubernetes [5].

40
 Figure 7 : Architecture kubernetes

c) Fonctionnalité de kubernetes

Kubernetes a un certain nombre de fonctionnalités. Il peut être considéré comme :

• une plate-forme de conteneurs

• une plate-forme de microservices
• une plate-forme cloud portable et beaucoup plus.

Kubernetes fournit un environnement de gestion focalisé sur le conteneur (container-centric).

Il orchestre les ressources machines (computing), la mise en réseau et l’infrastructure de stockage
sur les workloads des utilisateurs. Cela permet de se rapprocher de la simplicité des Platform as a
Service (PaaS) avec la flexibilité des solutions d'Infrastructure as a Service (IaaS), tout en gardant
de la portabilité entre les différents fournisseurs d'infrastructures (providers).

d) GKE (Google Kubernetes Engine)

Google Kubernetes Engine (GKE) est un environnement de déploiement d’applications

containerisée. Google Kubernetes Engine est mature pour la production. Cet environnement est
managé par Google. Contrairement à Google Compute Engine, on ne se préoccupe plus de VM
mais uniquement de container. Cette méthode permet de séparer le système d’exploitation du code
et des dépendances d’une application. Expliquer en détail le concept des conteneurs dépasse le
cadre de cette page.

41
 Pour ce service, anciennement appelé “Google Container Engine”, on parle de CaaS :
Container as a Service.

e) Caractéristiques du GKE

• Kubernetes managé
• Haute disponibilité avec déploiements multizones intégrés
• Intégration transparente des autres services de GCP
• Très bon rapport performance/prix
• Flexible et interopérable avec les clusters hébergés on-premise ou chez d’autres cloud
providers

4.6.5. Comparaison entre Swarn et Kubernetes

Bien que les deux orchestrateurs soient implémentés en Go (Go, 2018) (un langage
de programmation orientée service initié par Google) et fournissent à peu près les mêmes
fonctionnalités, il existe des différences fondamentales entre les deux approches. Le tableau ci-
après énumère les points de différences les plus remarquables. À la suite de cette étude
comparative, il est possible de noter que Swarm se focalise sur la facilité d'utilisation avec
l'intégration au Docker Deamon, tandis que Kubernetes prône la vision d'une plateforme
d'orchestration modulaire, personnalisable et donc évolutive.

En plus, pour encourager l'adoption des conteneurs dans les environnements modernes et
dynamiques (tels que les clouds publics, privés et hybrides), des entreprises (Google, Docker,
Microsoft, Mesosphere, Vmware, IBM, Oracle, etc.) ont mis en place la fondation de l'informatique
nuagique native, la CNCF (Cloud Native Computing Foundation), L’objectif principal de la CNCF
est la création de normes pour le fonctionnement des conteneurs. Kubernetes a été adopté comme
l'orchestrateur standard de conteneurs. Ainsi le projet K8s est désormais maintenu par la CNCF

42
 Tableau 8 : Tableau comparatif du swarm et kubernetes

Paramètres Swarn Kubernetes

Mise en œuvre Facile et rapide à installer Nécessite quelques configurations
manuelles. De plus, les instructions
d'installation varient en
fonction de l'OS du serveur

Vitesse de déploiement Se basant sur des critères qui ne Kubernetes a besoin de connaître
tiennent pas compte de l'état réel à l'avance l'état du cluster, ce qui
du cluster, Swarm est capable de ralentit le déploiement des pods
déployer rapidement des
conteneurs
Modularité Swarm utilise l'API Docker Kubernetes est modulaire. Il offre
deamon pour gérer tout le d'un ensemble unifié d' AP!s qui
cluster · collaborent pour gérer le cluster
Surveillance Pas de garanties solides sur Grâce à son ensemble unifié d'AP!s, le
l’état du cluster nœud maître connaît en temps réel l'état
global du cluster

Tolérance aux Faible tolérance aux pannes Kubernetes est tolérant aux pannes
fautes (pannes) franches comme l'arrêt d'un nœud de
travail, d'un pod ou d'un conteneur

[Link] Cloud Plateforme

Google Cloud Platform (GCP) est une suite de services d’informatique en cloud proposée
par Google LLC. GCP a vu le jour en 2008 et offre divers services allant de l’informatique au
stockage, en passant par la mise en réseau et l’IA en cloud, entre autres. Une chose qui rend GCP
unique est qu’il a développé TensorFlow, un logiciel gratuit et open-source utilisé par la plupart
des programmes de machine learning.

43
 4.7.1. Google Compute Engine (GCE)

Google Compute Engine (GCE) est une offre d'infrastructure à la demande (IaaS,
Infrastructure as a Service) qui permet à des clients d'exécuter des charges de travail sur du matériel
Google. A cet effet, Google Compute Engine met à disposition un nombre évolutif de machines
virtuelles (VM, Virtual Machine), utilisables comme des clusters informatiques de grande
envergure. GCE peut être géré par le biais d'une API RESTful, d'une interface de ligne de
commande (CLI) ou d'une console Web. Compute Engine est un service facturé à l'utilisation, avec
un minimum de 10 minutes, sans frais initiaux ni engagement de durée. GCE est en concurrence
avec Elastic Compute Cloud (EC2) d'Amazon et Microsoft Azure.

L'interface de programmation (API) de GCE fournit aux administrateurs des fonctionnalités

de machine virtuelle, de serveur DNS et d'équilibrage de charge. Les VM sont disponibles selon
plusieurs configurations de CPU et de RAM et sous plusieurs distributions Linux, dont Debian et
CentOS, et les clients peuvent les personnaliser en utilisant leurs propres images système. Les
données au repos sont chiffrées à l'aide de l'algorithme AEC-128-CBC.

GCE permet aux administrateurs de choisir la région et la zone où certaines ressources de

données seront stockées et utilisées. Actuellement, trois régions sont disponibles : les Etats-Unis,
l'Europe et l'Asie. Chaque région comporte deux zones de disponibilité, chacune prenant en charge
des processeurs Sandy Bridge. Enfin, GCE propose une suite d'outils permettant de créer des
réseaux évolués au niveau régional.

4.8.L’intégration Continue
4.8.1. Définition

L’intégration continue est définit comme étant un ensemble de pratiques utilisés afin de
s’assurer que chaque modification dans le code source ne produit pas des problèmes de régression
dans l’application en cours de développement, c’est-à-dire qu’aucun défaut n’a été introduit à la
partie du système qui n’a pas été modifié.

Le principal but de cette approche est d’anticiper et d’identifier rapidement les bugs avant
la mise en production du logiciel. Ce qui permet d’avoir une vision plus complète du logiciel,
notamment sur les différents points faibles et points forts du code ou de l’équipe. Ceci permet de

44
gagner en réactivité pour faire face aux différents problèmes pouvant être présents dans les diverses
phases du projet.

Pour bénéficier des avantages qu’apporte le concept d’intégration continue, il est nécessaire
de suivre quelques règles de bonne pratique comme le maintien d’un unique dépôt pour le code
source visionné, effectuer plusieurs commit par jour et par développeur, automatiser la compilation
du code, et le maintien d’un de compilation court

4.8.2. Fonctionnement de l’IC

Cette méthode repose sur la mise en place d’une brique logicielle qui va permettre
l’automatisation de plusieurs tâches :
• La compilation automatique du code et de ses dernières modifications,
• Les tests unitaires et fonctionnels,
• La validation du produit en fonction de plusieurs critères,
• Des tests de performances afin de procéder à certaines optimisations

Tout au long de l’évolution du projet, cette brique va exécuter un ensemble de tâches et de

tests. Les résultats produits sont consultables par l’équipe de développeurs, pour comprendre ce
qui pose problème dans les dernières modifications de code. Cette méthode d’intégration continue
permet aussi de ne pas oublier certains éléments lors de la mise en production et donc d’améliorer
la qualité de l’application.

4.8.3. Les étapes de l’Intégration Continue

Le développeur va procéder à son commit : cela consiste en une opération de validation des
dernières mises à jour du code source. Ces modifications sont effectuées en local, il faut donc
exporter le code vers le serveur de gestion de source. Le développeur doit au passage assurer la
bonne fusion de son code avec celui de ses voisins.

• L’ordonnanceur constate qu’une nouvelle version est disponible, il lance une compilation
sur l’une des machines prévues à cet effet.
• Une compilation est effectuée sur une machine de compilation.
• Le code étant compilé, des tests unitaires sont lancés sur des machines de tests.
• En parallèle la qualité du code est vérifiée.

45
 • Si la qualité du code et les tests unitaires sont satisfaisants, le(s) nouveau(x) binaire(s) est
(sont) envoyé(s) dans le dépôt. Ils peuvent être déployés par la suite dans d’autres
environnements. En cas d’échec, une notification est générée au chef de projet et/ou à
l’équipe de développement. Le développeur concerné par l’erreur fait une update du
référentiel de gestion de configuration et corrige l’anomalie.

Figure 8 : Les étapes d'intégration Continue

4.8.4. Les différents composants d’une plate-forme d’IC :

L’ordonnanceur : c’est le chef d’orchestre du système. Il ordonne les tâches pour qu’elles
se réalisent dans le bon ordre. Il remonte également les erreurs aux utilisateurs. L’ordonnanceur le
plus classique à utiliser est Jenkins
• Le gestionnaire de source (VCS) : dans cette application se retrouve l’ensemble des sources
sous différentes versions. Il est possible de revenir en arrière facilement, de créer des
branches (pour différentes versions d’un même projet). Le gestionnaire de source classique
est Git
• Le compilateur : c’est l’outil qui permet de traduire le code source (par exemple, du C) en
langage compréhensible par la machine, ou par un interpréteur. Il en existe des milliers, les
plus connu étant GCC et le JDK.
• Les tests unitaires : ce composant permet d’effectuer et de jouer l’ensemble des tests
unitaires définis dans un projet.
• Le contrôle qualité : ce composant est chargé d’assurer la qualité du code en fonction de
plusieurs paramètres. L’outil le plus classique est SonarQube

46
 • Le dépôt de binaire : ce composant permet le stockage des différentes versions d’un projet
après compilation. Il peut aussi servir comme source pour des composants utilisés dans son
propre projet. L’outil Nexus peut servir comme moyen de dépôt binaire.
4.8.5. Les avantages de l’intégration continue

L’intégration continue à de nombreux avantages et qualités, tant en matière de

développement, qu’en termes d’amélioration d’organisation de projet. Par exemple, la détection
d’erreurs est faite plus rapidement tout en réduisant ainsi le délai nécessaire pour les corriger. Par
conséquent, plus tôt une erreur est corrigée, moins la qualité du code final sera impactée. Outre que
cet aspect, les bénéfices sont nombreux.
• Améliorer la productivité des développeurs qui passent moins de temps à corriger des
bugs, ceux-ci sont repérés et corrigés plus rapidement, grâce à l’utilisation des tests
unitaires.
• Amélioration de la visibilité sur le projet via un système de versions.
• Livrer plus rapidement des versions et des mises à jour.
• Meilleure intégration des applications aux environnements existants.

[Link]
JMeter est un logiciel permettant d'effectuer des tests de charge de plusieurs services différents
(ftp, mail, ldap, …), mais nous nous concentrerons ici sur la mise en œuvre d'un test de charge
d'une application web. JMeter est écrit en Java et son développement est géré par la fondation
Apache.
Son utilisation consiste dans un premier temps à établir un scénario de test, c'est-à-dire un
exemple de session de navigation d'un visiteur, puis à faire répéter ce scénario autant de fois et par
autant de visiteurs (ou threads) simultanés que vous l'aurez décidé.

Fonctionnement Global du Jmeter

La figure 9 représente de manière générale le fonctionnement de JMeter. Le contrôleur est la

machine à partir de laquelle vous avez créé votre scénario. Cette instance vous permettra également
de contrôler les injecteurs qui eux se chargent d'exécuter le scénario. Lorsque vous fournissez un
scénario à plusieurs injecteurs à la fois, le même scénario est exécuté par chacun d'entre eux, c'est-
à-dire qu'il n'y a pas de répartition du nombre de threads entre les 2 instances.

47
 Ce schéma représente le cas idéal où vous posséderiez des ressources matérielles disponibles.
Seulement ce n'est pas toujours le cas et on pourrait plus simplement se contenter d'une seule
instance de JMeter à partir de laquelle vous élaborerez le scénario et lancerez le test de charge.
Cependant, il faut noter que lors d'un test, la charge générée par JMeter n'est pas négligeable, donc
plus l'infrastructure de votre site est robuste et plus vous aurez besoin d'injecteurs et de bande
passante afin de pousser vos tests le plus loin possible.

Figure 9 : Fonctionnement du JMETER

48
Partie III : MISE EN OEUVRE

49
 Chapitre 5. INSTALLATION ET CONFIGURATION
5.1. Configuration GCP
5.1.1. Création projet sur GCP
Il faut tout d’abord crée un compte sur GCP, après l’inscription sur GCP, ensuite il faut crée
un projet pour pouvoir utiliser service GCP. L’image ci-après montre comment le faire, c’est-à-
dire aller dans le Menu et cliquer créer un projet,

Figure 10 : Création du projet GCP

[Link]. Création instance GCE

Ensuite, on va créer une (1) instance GCE pour le serveur Jenkins, et un cluster GKE avec
2 nodes pour notre le serveur kubernete. Les figures ci-dessous montrent comment créer un
instance GCE et cluster GKE :

Figure 11 : Création instance GCE

50
 [Link]. Création clusters GKE
Dans le Menu du GCP mais dans la partie Kubernetes, cliquez sur kubernetes Engine et
sur Clusters, le bouton CREER permet de créer un nouveau cluster. On choisit l’option Standard
pour pouvoir gérer notre propre cluster, contrairement à l’option Autopilot qui est gérer par Google,

Figure 12 : Choix de type de configuration

Figure 13 : Les différentes champs de configuration

51
 Il faut remplir toutes les configurations de cluster a notre besoin, ici nous allons garder la
configuration par défaut.

Pour connecter au cluster, il nous donne une commande à exécuter sur Google Shell en cliquant
sur le bouton connecter.

Figure 14 : Cluster Bien crée

Figure 15 : Commande de connexion au cluster

Figure 16 : CloudShell pour connecter au cluster GKE

52
 5.2. Installation et configuration du Jenkins
Sur le plateforme GCP en clique le bouton SSH pour accède directement au serveur Jenkins,
la figure suivant montre qu’on est dans le serveur Jenkins.

Figure 17 : Accès à l'instance du jenkin

Les étapes à suivre pour l’installation du Jenkins sur l’instance GCP sont sur les figures
suivants, il faut d’abord mettre à jour le repository dans notre instance pour pouvoir télécharger le
paquet Jenkins avec le commande : $ apt update.

53
 Figure 18 : Mise à jour de repository

Installation jenkins par le commande, le commande suivant permet d’installer Jenkins :

$ apt-get install jenkins.

Figure 19 : Installations du Jenkins

54
Ici, on donne la permission au jenkins user, il faut ajouter dans le groupe sudoers, pour cela il faut
éditer /etc/sudoers et on ajoute la ligne jenkins ALL = (ALL) NOPASSWD : ALL (figure 23 )

Figure 20 : Ajout de l'user jenkins dans le groupe sudoers

✓ Vérification de status jenkins :

Le commande suivant permet de vérifier si jenkins est en fonction
$ systemctl status jenkins (figure19).

55
 Figure 21 : Vérification du service Jenkins

5.3. Installation docker

On va exécuter la commande suivante sur notre serveur Jenkins :
$ apt install [Link] –y.

Figure 22 : Installation du docker

56
 5.4. Installation Kubeclt
Kubectl est un outil en ligne de commande pour contrôler des clusters Kubernetes.”. C’est
avec cela que l’on va pouvoir effectuer diverses opérations sur notre cluster. Avant d’installer le
kubectl dans notre instance Jenkins, on va d’abord vérifier l’installation du GCLOUD par la
commande which, normalement il est installé par défaut dans notre instance.

Figure 23 : Vérification d'installation GCLOUD

Lorsque l’installation snap est fait, on va installer kubectl par la commande snap.
C’est est un système d'empaquetage et de déploiement de logiciels développé par Canonical pour
les systèmes d'exploitation utilisant le noyau Linux
$ install kubectl –classic.

Figure 24 : Installation snap

57
 Figure 25 : Installation du kubectl

5.5. Installation et configuration sur Jenkins :

$ sudo usermod –AG docker Jenkins : Ajouter l’utilisateur jenkins dans le groupe docker.
$ systemctl restart Jenkins
$ systemctl status Jenkins
Après toutes les installations, on peut accéder à Jenkins via l’adresse IP public de l’instance
avec le port 8080. Ensuite, on va accéder à Jenkins par l’adresse IP de l’instance avec le port 8080.

Jenkins demande la création d’une utilisateur admin après l’installation, il suffit juste de
compléter les champs, et appuyer sur Save and Continue, comme l’image suivant montre :

Figure 26 : Creation Utilisateur

58
 Figure 27 : Jenkins prêt à être utiliser

Figure 28 : Page d'authentification du Jenkins

5.5.1 Installation des plugins

L’installation des plugins est nécessaire pour la bonne fonctionnement Jenkins. Alors il faut
installer : Google kubernetes Engine, Docker Pipeline, Maven Integration et Maven invoker.

Il faut juste clique sur Administrer Jenkins et Gestion des plugins pour faire l’installation.
Ensuite il faut chercher Maven dans le bar de recherche et installer les plugins, ainsi de suite.

59
 Figure 29 : : Installation Maven Invoker

Figure 30 : : Installation Maven Integration

60
Figure 31 : : Installation du plugins Google kubernetes Engine

La figure ci-dessous montre que les plugins sont bien installés :

Figure 32 : Plugins installé avec succès

61
Ensuite lance l’installation docker pipeline, l’etapes à suivre est le même comme l’installation
Maven :

Figure 33 : Installation du plugins Docker pipeline

Configuration MAVEN, il faut ajouter le chemin d’installation sur serveur dans la

configuration. Menu Jenkins, ensuite cliquer sur Administrer Jenkins après Configuration Global
des outils et puis ajouter Maven.

Figure 34 : Configuration du Maven

Cocher l’installation automatique.

62
 5.5.2 Création credential
Il faut crée crentiel pour Docker Hub et Kubernetees.

 Credential pour le docker Hub

On ajoute le mot de passe du compte docker hub dans la case Secret

Figure 35 : Création credential pour connecter au DockerHub

 Credential pour kubernetes

Il faut telecharger une cle privee depuis le comptes se service avant de creer le credential
pour Kubernetes. Dans le menu de console GCP, cliquer sur le IAM et administration et puis
compte de service.

63
 Figure 36 : Le compte de service du projet

Cliquez sur le lien dans la colonne E-mail, et on va directement dans le menu de création de clé :

Figure 37 : Création de la clé

On se redirigé automatiquement vers la fenêtre de choix clé, après avoir clique sur Créer
une clé, il faut choisir l’extension .json et après le téléchargement se lance :

64
 Figure 38 : choix du type du clé à créer

Nous allons ensuite, importer la clé vers Jenkins après le téléchargement en accédant dans le
menu Administre Jenkins ensuit Mange credentiel et Add credentiels.

Figure 39 : Création credential pour Goole Service Account

65
 5.6. Création du Pipeline CI/CD
Pour cree pipeline CI/CD, il faut cliquer sur créer un job, pour que le build s’exécuter
automatiquement lorsqu’il y a des changements dans notre code.

Figure 40 : Création du pipeline

Après avoir nommé le pipeline qu’on a choisi, cliquer sur Ok pour valide.

Figure 41 : Nom du pipeline

66
 En utilise le script SCM pour configurer notre pipeline, on choisit Git, et ajouter dans le
champs Repository URL le lien repository qui contient le Jenkinsfiles et les différents codes qu’il
faut déployer. Et puis cliquer sur Sauvegarder.

Figure 42 : Configuration de repository utilisé

Figure 43 : Configuration de branche utilisé

67
Notre stage de pipeline :

1. SCM checkout pour la vérification du SCM

2. Le Build
3. Le Test
4. Push vers le Docker Hub
5. Et le déploiement vers le kubernetes

Les figures suivant montre les stages du pipeline dana le script :

Figure 44 : Script du pipeline

68
 Figure 45 : Script du pipeline (suite)

5.7. Le service et application qu’il faut déployer

5.7.1 Dockerfile
Docker peut créer des images automatiquement en lisant les instructions d'un
fichier Dockerfile. C’est un document texte qui contient toutes les commandes qu'un utilisateur
peut appeler sur la ligne de commande pour assembler une image.

Le figure suivant montre le dockerfile :

Figure 46 : Code du dockerfile

5.7.2. Loadbalancing
Load-Balancing consiste à répartir efficacement le trafic réseau entrant sur un groupe de
serveurs principaux, également appelé batterie de serveurs ou pool de serveurs.

69
 Fonctions Loadbalancing :

• Distribue efficacement les demandes des clients ou la charge du réseau sur plusieurs
serveurs,
• Garantit une disponibilité et une fiabilité élevées en envoyant des requêtes uniquement aux
serveurs en ligne,
• Offre la possibilité d'ajouter ou de soustraire des serveurs en fonction de la demande.

Pour assurer la répartition des requêtes on utilise Nginx Loadbalancer. La figure suivant montre
le script YAML du service Load Balancer :

Figure 47 : Script de déploiement du service Loadbalancer

70
 Figure 48: Script de déploiement de l'application

Dans le menu Jenkins on va lancer Build, pour faire il faut cliquer sur Lancer un build :

Figure 49 : Build du pipeline

71
Le commande suivant permet de vérifier que le déploiement et bien faite dans kubernetes :$
kubectl get all

La figure suivant montre que l’application est bien installée :

Figure 50 : résultat du commande kubectl get all

5.7.3 Docker Hub

Docker Hub est un service de registre de référentiel fourni par Docker Inc. Il nous permet
d'extraire et de pousser des images Docker vers et depuis Docker Hub.

Il faut vérifier dans notre repository Docker Hub que les images sont bien pusher à chaque
fois qu’on lance le build.

Figure 51 : Les images du repository Dockerhub

72
 Figure 52 : Détails de l'image dans dockerhub

Nous allons maintenant accéder dans différents services pour chaque IP :

Figure 53 : Service Nginx en marche

73
 Figure 54 :: Services Tomcat marche

Pour accéder à notre application déployée on a deux possibilité soit par l’adresse IP du
loadbalancer soit par l’adresse Ip des nodes, il faut juste préciser le port du Loadbalancer pour la
deuxième possibilité.

La figure suivante suivant montre comment accéder à l’application par la première adresse
du Loadbalancer, [Link] suivi du chemin de la page :

Figure 55 : accès de l'application par l'IP [Link]

74
La figure suivant nous montre l’accès par [Link], c’est-à-dire le deuxième Loadbalancer :

Figure 56 : accès de l'application par l'IP [Link]

Et on va voir aussi par l’adresse IP de node1 en précisant le port du loadbalancer c’est-à-dire

[Link] :30870.

Figure 57 : accès de l'application par le node 1

Et celle du node2 par [Link]:30870.

75
 Figure 58 : accès de l'application par le node 2

5.8 Configuration du webHooks

En termes simples, les webHooks sont des notifications déclenchées par des événements. Dans
la plupart des cas, ils sont utilisés pour la communication entre les systèmes. C'est le moyen le plus
simple de recevoir une alerte lorsque quelque chose se passe dans un autre système. Ils sont appelés
webhooks car ils fonctionnent comme des crochets logiciels sur le Web.
On va utiliser webhooks pour que GitHub puisse envoyer une requête vers Jenkins quand il y
a du changement lorsqu’on push.
On va configurer d’abord le webhooks dans le Git hub qui est dans le Settings en ajoutant
comme Payload l’URL d’accès au Jenkins et enregistré après.

76
 Figure 59 : Configuration WeebHook sur le github

Après, on va cocher l’option GitHub hook trigger dans notre pipeline du Jenkins :

Figure 60 : Activation GitHub hook trigger dans Jenkins

77
 CONCLUSION
Pendant ce mémoire on a eu l’opportunité d’être initiés dans le domaine d’intégration et
déploiement Continue avec Zero-Downtime, du Cloud, kubernetes, et de comprendre ses
différents fonctionnements.
Le choix de la technologie de virtualisation Docker met le déploiement de notre solution
très rapide grâce à son outil Dockerfile. Le principe fondateur de cette approche moderne est de
créer des environnements virtuels au niveau applicatif. Ceci révolutionne la virtualisation
traditionnelle qui consiste à la création d'environnements virtuels au niveau de l'infrastructure.
Cette approche de virtualisation légère a pour principaux avantages l'utilisation efficace des
ressources du fournisseur, l'amélioration des performances et la diminution des coûts pour les
utilisateurs. Ceci implique l'apparition de nouvelles formes d'architectures qui organisent les
services du cloud au sein de conteneurs prêts à être instanciés dans des machines virtuelles ou
physiques.
Toutefois, l'utilisation des conteneurs Docker dans l'environnement cloud n'est pas
sans défi . En effet, plusieurs difficultés doivent être résolues, parmi elles on peut citer
l'orchestration (gestion des déploiements, migrations, mises à jour, etc.) et la garantie de la
continuité de service (tolérance aux fautes). Le défi d'orchestration de conteneurs Docker est
résolu par l'adoption de Kubernetes comme plateforme évolutive d'orchestration des applications
conteneurisées.
La rapidité de déploiement de notre architecture présente une grande importance dans
notre projet, en effet, nous pouvons tester n’importe quel logiciel en mode de développement
dans un intervalle de temps très court..
Ce stage nous a beaucoup apporté, tant sur le plan personnel que professionnel. Il nous a
permis de mieux comprendre et d’appréhender l’organisation d’une entreprise, ses contraintes
et ses missions. Ceci présente pour nous une opportunité pour mieux comprendre le concept du
Déploiement avec Zero-Downtime.

78
 REFERENCES BIBLIOGRAPHIQUES

[1] Docker : Pratique des architectures à base de conteneurs Johann Kohler, 7 septembre 2016.

[2] Jonathan McAllister Mastering Jenkins, 2015

[3] Ranjit Singh Thakurratan, Google Cloud Platform Administration, 29 Sept 2018
[4] Cloud Computing François Stéphan, 13 Mai 2015

[5] Arnaud Weil, Learn Kubernetes - Container orchestration using Docker, 2018

XII
 REFERENCES WEBOGRAPHIQUES
[6] [Link] consulté le 30
Octobre 2022

[7] [Link] consulté le

11 Novembre 2022

[8] [Link] ?Kubernetes consulté le 20 Novembre 2022

[9] [Link] dockerhub consulté le 22 Novembre 2022

[10] [Link] docker consulté le 24 Novembre 2022

[11] [Link] jenkins consulté le 23 Novembre 2022

XIII
 GLOSSAIRE
Administrateur : Indique l’utilisateur d’une ressource (matériel ou logiciel) qui possède un
privilège spécial (ajout, suppression, modification ou mise à jour) par rapport aux autres. C’est
entre autres le super utilisateur de la ressource.
Cloud : Processus consistant à utiliser des serveurs informatiques distants au travers des
réseaux Internet.
Cloud Computing : Le Cloud Computing est un terme général employé pour désigner la livraison
de ressources et de services à la demande par internet.
Conteneurs : Un conteneur est le regroupement d'un logiciel et toutes ses dépendances (librairies,
code source, fichiers de configuration...) empaquetés au même endroit.
Déploiement Continue : Le déploiement continu est une stratégie de développement logiciel où
toute validation de code qui réussit le cycle de test automatisé est automatiquement transférée dans
l'environnement de production, propulsant ainsi les modifications vers les utilisateurs du logiciel.

Docker : Docker est un logiciel libre permettant de lancer des applications dans des conteneurs
logiciels.
Docker hub : Docker Hub est un référentiel cloud dans lequel les utilisateurs et partenaires Docker
créent, testent, stockent et distribuent des images de conteneur

Horizontal Scaling : signifie modifier les ressources de calcul d'un cluster existant, par exemple
en y ajoutant de nouveaux nœuds ou en ajoutant de nouveaux pods en augmentant le nombre de
réplicas de pods (Horizontal Pod Autoscaler).

Image : Une image de conteneur est un fichier statique non modifiable. Il renferme un code
exécutable de manière à exécuter un processus isolé dans une infrastructure informatique.

Intégration Continue : est un ensemble de pratiques utilisées en génie logiciel consistant à

vérifier à chaque modification de code source que le résultat des modifications ne produit pas de
régression dans l'application développée.

Kubernetes : est un système open source qui vise à fournir une « plate-forme permettant
d'automatiser le déploiement, la montée en charge et la mise en œuvre de conteneurs d'application
sur des clusters de serveurs ».

Machine virtuelle : En informatique, une machine virtuelle (anglais virtual machine, abr. VM)
est une illusion d’un appareil informatique créée par un logiciel d’émulation. Le logiciel
d’émulation simule la présence de ressources matérielles et logicielles telles que la mémoire, le

XIV
Node (Noeud) : Un nœud est une machine de travail dans Kubernetes, connue auparavant sous le
nom de minion. Un nœud peut être une machine virtuelle ou une machine physique, selon le
cluster. Chaque nœud contient les services nécessaires à l'exécution de pods et est géré par les
composants du master
Processeur, le disque dur, voire le système d’exploitation et les pilotes, permettant d’exécuter des
programmes dans les mêmes conditions que celles de la machine simulée

Pod : Un pod Kubernetes est un ensemble composé d'un ou plusieurs container linux. Il s'agit de
la plus petite unité d'une application Kubernetes. Un pod peut contenir plusieurs conteneurs
étroitement couplés (cas d'utilisation avancé) ou un conteneur unique (cas d'utilisation plus
courant)

Vertical Scaling : signifie modifier les ressources attribuées (comme CPU ou RAM) de chaque
nœud du cluster. Dans la plupart des cas, cela signifie créer un pool de nœuds entièrement nouveau
à l'aide de machines ayant des configurations matérielles différentes. La mise à l'échelle verticale
sur les pods signifie l'ajustement dynamique des demandes de ressources et des limites en fonction
des exigences actuelles de l'application (Vertical Pod Autoscaler).

YAML : YAML, acronyme récursif de YAML Ain’t Markup Language, est un format de
représentation de données par sérialisation Unicode. Il reprend des concepts d’autres langages
comme XML, ou encore du format de message électronique tel que documenté par RFC 2822.
YAML a été proposé par Clark Evans en 20011, et implémenté par ses soins ainsi que par Brian
Ingerson et Oren Ben-Kiki.

Zero Downtime : Le Zero Downtime Deployment ou encore déploiement sans temps d'arrêt en
français est une méthode de déploiement d'un site Web, d'une application ou d'un système sans
jamais mettre hors service ou dans un état instable une application pendant son processus de
déploiement.

XV
 TABLES DE MATIERES
CURRICULUM VITAE .................................................................................................................. I
DEDICACE .................................................................................................................................... III
REMERCIEMENTS ......................................................................................................................IV
SOMMAIRE ................................................................................................................................... V
LISTE DES ABREVIATIONS ....................................................................................................... X
LISTE DES TABLEAUX ..............................................................................................................IX
LISTE DES FIGURES .................................................................................................................... X
INTRODUCTION GENERALE...................................................................................................... 1
Partie I : PRESENTATIONS ....................................................................................................... 2

Chapitre 1. PRESENTATIONS DE L’ECOLE NATIONALE D’INFORMATIQUE ......... 3

1.1. Information d’ordre générale ..................................................................................... 3

1.2. Missions et Historiques .............................................................................................. 3

1.3. Organigramme institutionnel de l’ENI ....................................................................... 5

1.4. Domaines et spécialisation ......................................................................................... 7

1.5. Architecture des formations pédagogiques ................................................................ 7

1.6. Relation de l’ENI avec les entreprises et organismes .............................................. 10

1.7. Partenariat au niveau international ........................................................................... 11

1.8. Débouchés professionnels des diplômes .................................................................. 13

1.9. Ressources humaines................................................................................................ 15

Chapitre 2. DESCRIPTION DU PROJET .......................................................................... 16

2.1. Formulation .............................................................................................................. 16

2.2. Objectif et besoins de l’utilisateur ............................................................................ 16

2.3. Moyens nécessaires à la réalisation du projet .......................................................... 16

2.3.1. Moyens humains.............................................................................................. 16

2.3.3. Moyens matériels .................................................................................................. 17

2.4. Résultat attendus ...................................................................................................... 17

2.5. Chronogramme des activités .................................................................................... 17

Partie II : ETUDES THEORIQUES .......................................................................................... 19

XVI
Chapitre 3. ANALYSE PREALABLE .................................................................................. 20

3.1. DevOps ..................................................................................................................... 20

3.1.1. Les avantages de l’approche DevOps ............................................................ 20

a) Une meilleure collaboration entre les équipes .............................................. 20

b) Gain de temps et un gain d’argent ................................................................ 21

c) Une amélioration de la satisfaction et de l’expérience client ...................... 21

d) Une grande rapidité dans la production et la livraison ............................... 21

e) Une capacité d’innovation .............................................................................. 22

f) Une détection rapide des problèmes .............................................................. 22

3.2. Analyse de l’existant ................................................................................................ 22

3.3. Proposition de solution ............................................................................................. 22

3.3.1. Déploiement Continue............................................................................................. 22

3.3.2. Déploiement sans interruption de service ........................................................ 23

Chapitre 4. ETUDES THÉORIQUES DE LA SOLUTION À METTRE EN PLACE ......... 25

4.1. Gestionnaire de version : Git .................................................................................... 25

4.1.1. Définition ......................................................................................................... 25

4.1.2. Git vs SVN ......................................................................................................... 25

4.2. Choix de solution de virtualisation........................................................................... 27

4.2.1. La virtualisation .............................................................................................. 27

a) Définition .......................................................................................................... 27

b) Types de virtualisation ..................................................................................... 27

4.2.2. La Technologie Docker ................................................................................... 30

a) Définition .......................................................................................................... 30

b) Poids léger ........................................................................................................ 30

c) Plateforme ........................................................................................................ 30

d) Comparaison Docker et Machine virtuel ........................................................ 30

4.3. Le script YAML et Groovy ...................................................................................... 32

XVII
 4.3.1. YAML .............................................................................................................. 32

4.3.2. Groovy .............................................................................................................. 33

4.4. Serveur d’orchestration : Jenkins vs Bamboo vs Travis .......................................... 33

4.5. L’infonuagique (Cloud Computing)......................................................................... 34

4.5.1. Les caractéristiques des Cloud ...................................................................... 34

4.5.2. Les niveaux de service .................................................................................... 35

4.5.3. Les modèles de déploiement ........................................................................... 36

4.5.4. Le Cloud face au défi de l’isolation ............................................................... 36

4.6. Plateformes d’Orchestration de conteneurs docker .................................................. 37

4.6.1. Introduction ..................................................................................................... 37

4.6.2. Caractéristiques d’un orchestrateur de conteneurs .................................... 37

4.6.3. L’orchestrateur Swarm .................................................................................. 38

a) Définition .......................................................................................................... 38

b) Architecture de Swarm..................................................................................... 38

4.6.4. L’orchestrateur Kubernetes .......................................................................... 39

a) Définition ......................................................................................................... 39

b) Architecture de Kubernetes ........................................................................... 40

c) Fonctionnalité de kubernetes ......................................................................... 41

d) GKE (Google Kubernetes Engine) ................................................................ 41

e) Caractéristiques du GKE ............................................................................... 42

4.6.5. Comparaison entre Swarn et Kubernetes ..................................................... 42

4.7. Google Cloud Plateforme ......................................................................................... 43

4.7.1. Google Compute Engine (GCE) .................................................................... 44

4.8. L’intégration Continue ............................................................................................. 44

4.8.1. Définition ......................................................................................................... 44

4.8.2. Fonctionnement de l’IC .................................................................................. 45

4.8.3. Les étapes de l’Intégration Continue ............................................................ 45

XVIII
 4.8.4. Les différents composants d’une plate-forme d’IC : ................................... 46

4.8.5. Les avantages de l’intégration continue ........................................................ 47

4.9. JMETER ................................................................................................................... 47

Partie III : MISE EN OEUVRE ................................................................................................. 49

Chapitre 5. INSTALLATION ET CONFIGURATION ........................................................ 50

5.1. Configuration GCP .......................................................................................................... 50

5.1.1. Création projet sur GCP .......................................................................................... 50

[Link]. Création instance GCE .................................................................................... 50

[Link]. Création clusters GKE...................................................................................... 51

5.3. Installation et configuration du Jenkins ..................................................................... 53

✓ Vérification de status jenkins : ................................................................................... 55

6.3. Installation docker........................................................................................................... 56

6.4. Installation Kubeclt ......................................................................................................... 57

6.5. Installation et configuration sur Jenkins : .................................................................. 58

5.5.1 Installation des plugins .............................................................................................. 59

5.5.2 Création credential ................................................................................................... 63

 Credential pour le docker Hub.......................................................................... 63

 Credential pour kubernetes ............................................................................... 63

5.6. Création du Pipeline CI/CD ....................................................................................... 66

5.7. Le service et application qu’il faut déployer ................................................................... 69

5.7.1 Dockerfile .................................................................................................................. 69

5.7.2. Loadbalancing .......................................................................................................... 69

5.7.3 Docker Hub .............................................................................................................. 72

5.8 Configuration du webHooks ............................................................................................ 76

CONCLUSION .............................................................................................................................. 78
REFERENCES BIBLIOGRAPHIQUES ..................................................................................... XII
REFERENCES WEBOGRAPHIQUES ...................................................................................... XIII

XIX
GLOSSAIRE ............................................................................................................................... XIV
TABLES DE MATIERES ..........................................................................................................XVI
RESUME.....................................................................................................................................XXI
ABSTRACT ................................................................................................................................ XXI

XX
 RESUME
Durant son cycle de vie, le logiciel passe par plusieurs étapes de développement et
évolution. Le déploiement est une phase cruciale parmi d’autres, qui transforme le code source en
programme en exécution. Traditionnellement, cette étape est exécutée manuellement ce qui la rend
particulièrement critique et source de problèmes pour l’entreprise. Grâce aux méthodes agiles, le
déploiement a connu des bouleversements majeurs avec l’apparition de nouvelles techniques tels
que l’intégration continue, la livraison continue et le déploiement continu.

Ce mémoire traite de la manière dont le déploiement continu avec Zero-downtime a été mis
en place, de la conception à l’implémentation tous en décrivant les étapes de ce projet.

Mots clés : Cloud, déploiement continue, Zero-downtime, Intégration continue

ABSTRACT
During its life cycle, the software goes through several stages of development and
evolution. Deployment is a crucial phase among others, which transforms the source code into a
running program. Traditionally, this step is performed manually, which makes it particularly
critical and a source of problems for the company. Thanks to agile methods, deployment has
undergone major upheavals with the appearance of new techniques such as continuous integration,
continuous delivery and continuous deployment.

This thesis discusses how continuous deployment with Zero-downtime was implemented,
from design to implementation, all by describing the stages of this project.

Keywords: Cloud, continuous deployment, zero-downtime, continuous integration

XXI