V - F-Mémoire de Fin de Cycle DIC3-Justine - Faye - AS

REPUBLIQUE DU SENEGAL
* **
**
UNIVERSITE CHEIKH ANTA DIOP DE DAKAR
ECOLE SUPERIEURE POLYTECHNIQUE
DEPARTEMENT GENIE INFORMATIQUE
MEMOIRE DE FIN DE CYCLE

Pour l’obtention du :
DIPLOME D’INGENIEUR DE CONCEPTION EN TELECOMMUNICATIONS ET
RESEAUX
SUJET :
Mise en place d’un cloud souverain :

implémentation de la chaîne CI/CD
Lieu de stage : BeOpenIT Période stage : 02/2020 – 06/2020
Présenté et soutenu par Professeur encadrant Maître de stage

Justine Marie Téning FAYE Pr Ibrahima FALL M. Mor DIOUM
Année universitaire : 2019 – 2020

REPUBLIQUE DU SENEGAL
* **
**
UNIVERSITE CHEIKH ANTA DIOP DE DAKAR
ECOLE SUPERIEURE POLYTECHNIQUE
DEPARTEMENT GENIE INFORMATIQUE
MEMOIRE DE FIN DE CYCLE

Pour l’obtention du :
DIPLOME D’INGENIEUR DE CONCEPTION EN TELECOMMUNICATIONS ET
RESEAUX
SUJET :
Mise en place d’un cloud souverain :

implémentation de la chaîne CI/CD
Lieu de stage : BeOpenIT Période stage : 02/2020 – 06/2020
Présenté et soutenu par Professeur encadrant Maître de stage

Justine Marie Téning FAYE Pr Ibrahima FALL M. Mor DIOUM
Année universitaire : 2019 – 2020

DEDICACES
Je rends grâce à Dieu qui m’a permis de réaliser ce travail.
Je dédie ce mémoire à :
 Ma Famille, ma plus grande motivation dans la vie. Je dédie spécialement ce

mémoire à mes parents Martial Faye et Jeanne Marone pour leur soutien
constant et leurs encouragements. Je n’oublie pas mes sœurs Emilie et Sophie et
mes frères Paul, Wassylla et Blaise Sagne qui m’ont toujours épaulée.
 Mes chers amis.
i
Mise en place d’un cloud souverain : implémentation de la chaîne CI/CD
Justine Marie Téning FAYE
REMERCIEMENTS
J’adresse mes remerciements les plus chaleureux à :
 Pr Ibrahima Fall, chef du Département Génie Informatique et également

professeur encadrant de ce mémoire, pour ses judicieux conseils, sa
disponibilité et son accompagnement durant le stage ;
 Mon maître de stage M. Mor Dioum, pour ses précieux conseils, sa
disponibilité et sa supervision du travail.
Je tiens spécialement à remercier :
 L’ensemble du personnel de BeOpenIT pour leur esprit de partage qui a

largement contribué à la réalisation de ce travail ;
 Tout le personnel enseignant et administratif du département Génie
Informatique de l’ESP ;
 Mon père Martial Faye et mon frère Paul Faye pour les séances de relecture
consenties ;
 Toutes les personnes qui de près ou de loin, ont contribué à la réalisation de
ce document.
ii
AVANT-PROPOS
L’Ecole Supérieure Polytechnique de Dakar (ESP) est un établissement public de

formation professionnelle. Elle fait partie intégrante de l’Université Cheikh Anta Diop de
Dakar (UCAD). Elle a été fondée en mai 1964 et a pour mission de former tant sur le plan
théorique que pratique des techniciens supérieurs, des ingénieurs technologues, des ingénieurs
de conception, des managers en gestion d’entreprise et des docteurs.
Elle dispense un enseignement supérieur en vue de préparer aux fonctions

d’encadrement dans divers domaines tels que la production, la recherche appliquée, etc. L’ESP
compte (6) départements :
 Génie Chimique ;
 Génie Civil ;
 Génie Electrique ;
 Génie Informatique ;
 Génie Mécanique ;
 Gestion.
Dans le cadre de leur formation les étudiants du département Génie Informatique qui sont
en fin de cycle sont tenus d’effectuer un stage pratique au sein d’une entreprise ou d’un service
informatique. A l’issue de ce stage, doit être présenté et soutenu devant un jury, un mémoire
de fin de cycle portant sur le sujet traité.
Ce stage permet à l’étudiant :
 de renforcer son savoir et surtout d’acquérir un savoir-faire, tout en essayant

d’adapter ses connaissances aux cadres de la vie professionnelle ;
 de travailler sur un projet de fin d’études et de mener à bien l’élaboration de
celui-ci depuis l’étude préalable jusqu’à sa mise en œuvre. A l’issue de ce
stage, un mémoire présentant les tâches accomplies est rédigé.
iii
C'est ainsi que nous avons effectué un stage de cinq mois au cours duquel nous avons
travaillé sur le sujet suivant : Mise en place d’un cloud souverain : implémentation de la
chaîne CI/CD.
iv
RESUME
Ce document est un mémoire de fin d’études pour l’obtention du Diplôme d’Ingénieur

de Conception (DIC) en Télécommunications et Réseaux. Il présente la réalisation d’un projet
intitulé : « Mise en place d’un cloud souverain : implémentation de la chaîne CI/CD », effectué
au sein de l’entreprise BeOpenIT.
Ce travail s’inscrit dans le cadre d’un projet de création d’une plateforme cloud SaaS. Ce
projet intitulé « cloud souverain » permet aux utilisateurs de déployer facilement des sites web
et des bases de données sur le cloud. Cloud souverain est un projet subdivisé en plusieurs
parties. Nous avons travaillé sur l’automatisation des déploiements de la plateforme sur
plusieurs environnements grâce au DevOps, en mettant en place une chaîne d’intégration
continue (CI) et de déploiement continu (CD).
Dans un premier temps, nous étudions l’analyse des besoins du système. Ensuite, nous
abordons l’analyse conceptuelle de la solution en nous basant sur l’analyse des besoins
effectuée. Enfin nous présentons les résultats obtenus par rapport à la mise en place de la chaîne
d’intégration continue et de déploiement continu.
Mot clés : Cloud, DevOps, CI/CD.
v
ABSTRACT
This document is an end of studies thesis for obtaining the Diploma of Design Engineer
in Telecommunications and Networks. It presents the work done on a project entitled:
“Creation of a sovereign cloud: implementation of the CI/CD pipeline”, carried out within the
company BeOpenIT.
This work is part of a project to create a SaaS cloud platform. This project called
“sovereign cloud” allows users to easily deploy websites and databases in the cloud. Sovereign
Cloud is a project subdivided into several parts. We have worked on automating the platform's
deployments across multiple environments using DevOps, setting up a continuous integration
(CI) and continuous deployment pipeline (CD).
First, we study the analysis of the system's needs. Then, we approach the conceptual
analysis of the solution based on the analysis of the needs carried out. Finally, we present the
results obtained in relation to the implementation of the continuous integration and continuous
deployment pipeline.
Keywords: Cloud, DevOps, CI/CD.
vi
TABLE DES MATIERES
SIGLES ET ABREVIATIONS ........................................................................................ x
TABLE DES FIGURES .................................................................................................. xi
TABLE DES TABLEAUX .......................................................................................... xiii
INTRODUCTION ............................................................................................................ 1
CHAPITRE 1 : PRESENTATIONS GENERALES ................................................... 2
1. Présentation de la structure d’accueil .................................................................. 2
1.1. Contexte de création ..................................................................................... 2
1.2. Présentation de BeOpenIT ............................................................................ 3
1.3. Innovation et partenaires .............................................................................. 3
1.4. Organisation de l’entreprise.......................................................................... 4
2. Présentation du cadre du projet ............................................................................ 5
2.1. Contexte ........................................................................................................ 5
2.2. Problématique ............................................................................................... 6
2.3. Objectifs........................................................................................................ 6
2.4. Méthode de développement du projet .......................................................... 7
2.4.1. Caractéristiques du projet ........................................................................ 7
2.4.2. Présentation des méthodes de développement du projet ......................... 7
a) L’approche agile SCRUM ......................................................................... 8
b) L’approche DevOps................................................................................... 9
CHAPITRE 2 : ANALYSE DES BESOINS ............................................................. 13
1. Généralités sur le cloud .......................................................................................... 13
1.1. La virtualisation et le cloud ....................................................................... 13
1.2. Caractéristiques du cloud............................................................................ 14
vii
1.3. Modèles de services du cloud ..................................................................... 14
1.4. Modèles de déploiement du cloud .............................................................. 16
2. Spécifications et Analyse des besoins du système ............................................. 17
2.1. Spécifications des besoins du système ....................................................... 17
2.1.1. Les acteurs ............................................................................................. 17
2.1.2. Les besoins non fonctionnels ................................................................. 17
2.1.3. Les besoins fonctionnels ........................................................................ 18
2.2. Analyse du système .................................................................................... 18
CHAPITRE 3 : CONCEPTION DE LA SOLUTION .............................................. 24
1. Proposition d’une chaîne d’intégration continue et de déploiement continu ..... 24
1.1. Technologies et des outils utilisés .............................................................. 25
1.1.1. Outils de l’intégration continue ............................................................. 25
a) Gestion des sources de code .................................................................... 26
b) Serveur d’intégration continue ................................................................ 26
c) Serveur de gestion de la qualité de code ................................................. 26
d) La conteneurisation ................................................................................. 27
1.1.2. Outils pour la livraison continue ............................................................ 29
1.1.3. Outils pour le déploiement continu........................................................ 29
a) Orchestration des conteneurs ................................................................... 29
b) La culture GitOps .................................................................................... 31
1.2. Proposition d’une chaîne CI/CD................................................................. 32
1.3. Architecture logicielle du pipeline CI/CD .................................................. 34
2. Mise en œuvre de la chaîne CI/CD .................................................................... 35
2.1. Environnement de déploiement de la plateforme SaaS .............................. 36
2.2. Mise en œuvre de l’intégration continue et de la livraison continue .......... 38
2.2.1. Configuration sur GitHub ...................................................................... 38
viii
a) Le gitflow................................................................................................. 38
b) Configuration du webhook sur GitHub ................................................... 40
2.2.2. Configuration sur Jenkins ...................................................................... 41
2.2.3. Création du Jenkinsfile et du Dockerfile .............................................. 42
a) Le Jenkinsfile ........................................................................................... 42
b) Le Dockerfile ........................................................................................... 43
2.3. Mise en œuvre du déploiement continu ...................................................... 45
CHAPITRE 4 : RESULTATS OBTENUS ................................................................. 48
1. Intégration continue ........................................................................................... 48
1.1. SonarQube .................................................................................................. 48
1.2. Compilation et création de l’image ............................................................ 49
2. Livraison continue ............................................................................................. 50
3. Déploiement continu .......................................................................................... 51
4. Objectifs atteints au cours de ce stage ............................................................... 54
5. Apports du projet pour l’entreprise .................................................................... 55
CONCLUSION .............................................................................................................. 57
BIBLIOGRAPHIE ......................................................................................................... 58
ANNEXES ..................................................................................................................... 59
Annexe : Implémentation de la chaîne CI du microservice cloud-CMS. ................... 59
ix
SIGLES ET ABREVIATIONS
AWS Amazon Web Services

CD Continuous Delivery and /or Continuous Deployment
CI Continuous Integration
CI/CD Continuous Integration and Continuous Deployment
CMS Content Management System
CNCF Cloud Native Computing Foundation
CPU Central Processing Unit
DevOps Development and operations
EKS Elastic Kubernetes Service
ELB Elastic Load-Balancer
ESP Ecole Supérieure Polytechnique
GCP Google Cloud Platform
IaaS Infrastructure as a Service
IGW Internet Gateway
IP Internet Protocol
NAT Network Address Translation
PaaS Platform as a Service
RAM Random Access Memory
SaaS Software as a Service
SCM Source Code Management
SQL Structure Query Language
UML Unified Modeling Language
VCS Version Control System
VPC Virtual Private Cloud
YAML Yet Another Markup Language
x
TABLE DES FIGURES
Figure 1 : Secteurs d’activités de BeOpenIT ............................................................................. 4

Figure 2 : La méthode agile SCRUM ........................................................................................ 8
Figure 3 : Complémentarité entre la méthode Agile et l’approche DevOps ........................... 10
Figure 4 : Schéma du DevOps ................................................................................................. 12
Figure 5 : Différences entre les services cloud ....................................................................... 15
Figure 6 : Fonctionnalités accessibles aux développeurs ....................................................... 20
Figure 7 : Description graphique de la fonctionnalité “fusionner un code d’une branche dans
une autre branche” .................................................................................................................. 22
Figure 8 : Étapes d’une chaîne CI/CD .................................................................................... 25
Figure 9 : Différences entre virtualisation et conteneurisation .............................................. 28
Figure 10 : Architecture de kubernetes ................................................................................... 30
Figure 11 : Fonctionnement de flux......................................................................................... 32
Figure 12 : Déroulement de la chaîne CI proposée ................................................................ 33
Figure 13 : Déroulement de la chaîne CI proposée ................................................................ 34
Figure 14 : Architecture logicielle de la chaîne CI/CD .......................................................... 35
Figure 15 : Architecture de l’environnement de développement............................................. 37
Figure 16 : Organisation des branches dans le dépôt ............................................................. 39
Figure 17 : Configuration du webhook du microservice cloud-dashboard ............................ 40
Figure 18 : Configuration du SonarQube scanner .................................................................. 41
Figure 19 : Intégration de Jenkins au serveur SonarQube. .................................................... 42
Figure 20 : Jenkinsfile du microservice cloud-dashboard ...................................................... 43
Figure 21 : Dockerfile du microservice cloud-dashboard ...................................................... 44
Figure 22 : Configuration du fichier flux-patch.yaml ............................................................. 45
Figure 23 : Fichier de déploiement du microservice cloud-dashboard .................................. 46
Figure 24 : Configuration du service pour les conteneurs cloud-dashboard ......................... 47
Figure 25 : Scan du code du microservice Cloud-Dashboard ................................................ 49
Figure 26 : Exécution de la chaîne CI du microservice cloud-dashboard .............................. 50
Figure 27 : Livraison des images du microservice cloud-dashboard ..................................... 51
Figure 28 : Espaces de nom cloud-cms, cloud-dashboard et flux-system .............................. 52
Figure 29 : Liste des déploiements dans le namespace cloud-dashboard............................... 52
xi
Figure 30 : Conteneurs cloud-dashboard en cours d'exécution .............................................. 52
Figure 31 : Events de création des pods .................................................................................. 52
Figure 32 : Liste des images docker Hub ................................................................................ 53
Figure 33 : Service de cloud-dashboard ................................................................................. 53
Figure 34 : Page d'authentification ......................................................................................... 54
Figure 35 : Dashboard Information sur les sites web déployés .............................................. 54
xii
TABLE DES TABLEAUX
Tableau 1 : Liste des partenaires de BeOpenIT ........................................................................ 4

Tableau 2 : Description textuelle de la fonctionnalité "fusionner le code d'une branche sur une
autre branche" ......................................................................................................................... 21
xiii
INTRODUCTION
Le cloud fournit un ensemble de ressources informatiques accessibles à la demande à

travers un réseau. Aussi, les entreprises tendent à externaliser leurs services vers le cloud. En
effet, avec la quantité de ressources mise à disposition, le cloud présente des avantages non
négligeables. Ces entreprises ont besoin de proposer aux utilisateurs, leurs services sur le cloud
sans grande complexité. C’est dans ce cadre que BeOpenIT accompagne les entreprises dans
la mise en place de leur cloud. Aussi, s’est-elle proposée d’en faire davantage en proposant aux
entreprises une solution cloud qui leur permet d'offrir des services de stockage de données et
de création de sites web. Cette solution nommée « cloud souverain » présente plusieurs volets
dont une partie portant sur l’implémentation d’une chaîne d’intégration continue et de
déploiement continu communément appelée chaîne CI/CD. Une telle chaîne permet de réduire
les délais de livraison des applications tout en rendant l'adaptation aux retours du marché facile
et rapide. C’est dans ce contexte que s’inscrit notre stage de fin de cycle qui porte sur la mise
en place de cette chaîne CI/CD pour automatiser le déploiement de la solution cloud souverain.
Pour atteindre cet objectif, nous avons adopté une démarche qui s’articule autour des
quatre chapitres suivants :
 un premier chapitre intitulé « présentation générale » dans lequel nous présentons la

structure d’accueil et décrivons le cadre du projet en indiquant le contexte, la
problématique, les objectifs du sujet ainsi que la méthode de développement adoptée ;
 un second chapitre intitulé « Analyse des besoins » qui présente dans un premier temps
des généralités sur le cloud afin de mieux saisir la solution cloud à mettre en œuvre.
Dans un second temps, ce chapitre présente l’analyse des besoins pour la mise en place
de la chaîne CI/CD ;
 un troisième chapitre intitulé « Conception de la solution » dans lequel nous présentons
la chaîne d’intégration continue et de déploiement continu adoptée ainsi que les outils
choisis pour l’implémenter. Nous y présentons également une conception détaillée de
la chaîne mise en place ;
 Enfin, le quatrième et dernier chapitre nommé « Résultats obtenus » présente
les résultats obtenus ainsi que les apports du projet pour l’entreprise.
1
CHAPITRE 1 : PRESENTATION GENERALE
CHAPITRE 1
PRESENTATIONS GENERALES
Ce chapitre permet de définir le cadre d’évolution du stage ainsi que le projet de fin
d’études. Il présente en premier lieu la structure d’accueil : BeOpenIT. En second lieu il permet
de définir le sujet de travail en spécifiant son contexte, sa problématique, ses objectifs et la
méthode de développement adoptée.
1. Présentation de la structure d’accueil
1.1. Contexte de création
Les entreprises ont besoin de stocker leurs données qui augmentent exponentiellement
d’année en année. Sentant ce besoin, des entreprises comme Amazon, Google et Microsoft ont
créé des systèmes de cloud qui permettent aux entreprises de stocker et de sauvegarder leurs
données sur des serveurs comme AWS d’Amazon ou encore Google cloud plateforme.
Même si ces plateformes sont très performantes et simples d’utilisation, il n’en demeure
pas moins qu’elles ne peuvent servir qu’aux entreprises dont les activités ne sont pas critiques
ou dont les données ne sont pas sensibles.
Pour les entreprises aux activités sensibles comme les banques et les sociétés
gouvernementales, stocker des données sur les serveurs de ces grands groupes n’est pas une
option envisageable. Elles ont besoin de stocker leurs données sur leurs propres clouds pour
assurer la confidentialité de leurs données. Aussi, faudrait-il avoir des entreprises qui ont assez
d’expertise pour accompagner ces sociétés dans la mise en place de leurs clouds privés.
Le marché du cloud est un domaine peu exploité. Il n’existe quasiment pas d’entreprises
avec une expertise très pointue proposant de résoudre cette problématique à savoir de pouvoir
stocker les données en interne tout en bénéficiant des avantages du Cloud.
BeOpenIT est l’une des pionnières dans ce domaine et aide les entreprises dans leur
processus de transition vers le cloud.
2
1.2. Présentation de BeOpenIT
BeOpenIT est une entreprise spécialisée dans des domaines porteurs d’avenir tels que le
Cloud, le DevOps, l’intelligence artificielle et la sécurité des systèmes d’information. Elle
accompagne ses clients dans leur processus de transition étape par étape vers ces domaines.
BeOpenIT veut former les entreprises pour qu’elles puissent être autonomes afin de lever le
mythe autour du Cloud et la sécurité des données personnelles.
Depuis 2018, elle accompagne les entreprises pour qui l'informatique est un puissant
levier de transformation et les aide à construire des systèmes d'information et des applications
qui transforment leurs entreprises. Le cloud permet de réduire les coûts de l’innovation
numérique. Nombreuses sont donc les entreprises qui cherchent des profils ou formateurs dans
ce domaine. BeOpenIT forme et conseille les entreprises qui veulent une transformation
digitale digne de ce nom.
Elle a son siège social en France. Elle est également présente à Londres et en Afrique en
particulier au Sénégal. Elle met en place des moyens pour permettre aux jeunes de se
familiariser avec les nouvelles technologies de l’information telles que les formations AWS,
cloud et kubernetes.
1.3. Innovation et partenaires
BeOpenIT est la première entreprise certifiée « Kubernetes Training Partner » en

France. BeOpenIT accompagne plusieurs entreprises du CAC 40 dans leur processus de
déploiement Kubernetes. Les formations qu’elle dispense permettent aux entreprises d’avoir
les compétences pour déployer leurs applications sur Kubernetes.
Elle a des partenaires dans le domaine de l’informatique avec qui elle collabore pour
fournir une expertise certifiée à ces clients.
Le tableau 1 présente la liste de ses partenaires ainsi que leurs activités.
3
La Cloud Native Foundation est une organisation

fondée en 2015 par la Linux Foundation qui vise à faire
avancer l’état de l’art des technologies permettant de
créer des applications cloud native. Le terme Cloud
native désigne les applications et services développés
en microservices et conteneurisés pour être déployés
facilement.
Red Hat, Inc. est une société multinationale américaine

de logiciels qui fournit des produits logiciels open
source à la communauté des entreprises.
VMware Tanzu est une entreprise qui offre un

portefeuille de produits et services visant à transformer
le développement, l’exécution et la gestion de logiciels
sur Kubernetes.
Tableau 1 : Liste des partenaires de BeOpenIT
1.4. Organisation de l’entreprise
La partie informatique de l’entreprise est subdivisée en « Business Unit » selon les secteurs
d’activités de l’entreprise. La figure 1 présente les « business units » de l’entreprise.
Figure 1 : Secteurs d’activités de BeOpenIT
4
2. Présentation du cadre du projet
2.1. Contexte
Les serveurs locaux permettent d'héberger des services informatiques tels que des
applications, des systèmes de stockage de données, des serveurs web, etc.
Ils demandent un investissement financier conséquent. En effet, il faut investir dans des
serveurs physiques et assurer la maintenance des sites où sont localisés ces serveurs. Des
coûts supplémentaires tels que l’approvisionnement en électricité et la climatisation de ces
sites sont également à prévoir.
De plus, avec l’augmentation exponentielle des données qui accompagne la transition

des entreprises vers le numérique, il devient difficile pour les entreprises de garder leurs
données et applications sur des serveurs locaux.
Les entreprises se tournent alors de plus en plus vers une solution

externalisée d'hébergement de leurs services informatiques : le cloud, privé pour des besoins
de confidentialité, ou public si l’activité de l’entreprise n’est pas critique.
Le cloud est un environnement qui met à disposition un ensemble de ressources

informatiques telles que la puissance de calcul et le stockage. Ces ressources sont évolutives et
accessibles à la demande via un réseau.
Il permet aux entreprises de développer leurs activités en se concentrant uniquement sur

leurs produits tout en réduisant les coûts liés à la gestion des infrastructures et en ayant accès à
un large éventail de solutions pour leurs activités.
BeOpenIT accompagne les entreprises pour la mise en place de leur cloud privé si
l’entreprise possède l’infrastructure nécessaire, ou les accompagne dans leur processus de
migration vers le cloud public. Elle aide ces entreprises à offrir des services sur leur cloud. Elle
identifie leurs besoins spécifiques et apporte la solution la plus adaptée leur permettant ainsi
de tirer le meilleur de l’utilisation du cloud. Aussi s’est-elle penchée sur le cas des développeurs
ou personnes lambda qui souhaitent déployer leurs applications sur le cloud.
5
2.2. Problématique
Le constat est qu’il est souvent complexe pour les personnes qui développent leurs
applications de les déployer. En effet, selon le type de l’application et les technologies utilisées,
elles doivent savoir comment déployer les fichiers à exécuter en environnement de production
et assurer la continuité du service. Elles doivent aussi s’assurer que les technologies utilisées
sont compatibles avec ledit environnement. Le cas non échéant, elles sont souvent contraintes
de réadapter leur code afin qu’il soit compatible avec l’environnement mis en place.
De plus, si elles souhaitent déployer leurs applications dans le cloud, elles doivent
connaître les solutions cloud adaptées à leurs applications et les ressources nécessaires (CPU,
mémoire RAM, Stockage, etc.) à l'exécution de leurs services. Il leur faut décrire et configurer
l’environnement de déploiement sur le cloud pour qu’il soit adapté aux services qu’elles
souhaitent héberger. Ceci représente une charge de travail supplémentaire et potentiellement
de nouvelles ressources à engager.
Elles se heurtent donc aux problèmes liés au déploiement de leurs applications dans un
premier temps et ensuite à la complexité de choisir l'environnement cloud adapté.
2.3. Objectifs
L’objectif est donc de mettre en place une solution cloud qui leur permettra de s'affranchir
des problèmes liés au déploiement de leurs applications dans le cloud. Cette solution est
nommée Cloud Souverain. Elle permettra de déployer facilement des applications sur un cloud.
Il faudra pour cela :
 mettre en place un cloud : un SaaS (Software as a Service) qui permettra dans un

premier temps de créer et déployer facilement des sites web et de déployer des bases de
données ;
 créer une distribution Enterprise de cette plateforme pour les entreprises disposant des
infrastructures pour la déployer.
6
2.4. Méthode de développement du projet
2.4.1. Caractéristiques du projet
Le produit que nous mettons en place est un logiciel standard. En effet, le produit est créé
à l’initiative de l’entreprise. L’entreprise sera donc chargée de suivre l’avancement du projet
et de vérifier que les résultats obtenus sont conformes à ses attentes.
Pour réaliser ce projet, une équipe constituée de huit personnes a été formée. Elle est
répartie en sous-groupes :
 un sous-groupe de développement et DevOps constitué de deux développeurs. J’ai

intégré cette équipe en tant que stagiaire DevOps, dans le but de mettre en place les
mécanismes de génération des fichiers à déployer et d’automatisation du déploiement ;
 un sous-groupe constitué de quatre ingénieurs systèmes ou opérateurs chargés de la

mise en place des environnements (infrastructure) sur lesquels sera déployée la
plateforme ;
 un coordinateur qui suit l’avancement du projet.
2.4.2. Présentation des méthodes de développement du projet
Au regard de la solution que nous devons mettre en place : un SaaS, nous devons être en
mesure d’intégrer de nouvelles fonctionnalités, de les tester et de les déployer rapidement en
prenant compte des retours des utilisateurs finaux. Ceci dans le but d’améliorer
continuellement l'expérience client.
Par conséquent, deux méthodes de développement ont été adoptées : l’approche agile
SCRUM et l’approche DevOps.
7
a) L’approche agile SCRUM

L’approche Agile est basée sur un développement itératif et incrémenté où les
caractéristiques et solutions viennent de la collaboration entre équipes organisées
individuellement, mais avec le même but commun. Cette approche permet de prendre
rapidement en compte les exigences du client. La méthode SCRUM est la méthode agile
utilisée dans ce projet.
SCRUM est un framework qui regroupe un ensemble de pratiques et de rôles. Ces rôles
sont :
 le scrum master : Il gère l’avancement du projet. Sur ce projet le Scrum master est un
des développeurs ;
 le product owner : c’est la personne représentant le client, à savoir BeOpenIT dans ce

contexte ;
 la Team : qui est l’équipe chargée de réaliser ce projet.
Avec la méthode SCRUM, les tâches à faire sont entreposées dans le “backlog”. Ces
tâches sont réalisées par Sprint qui sont des périodes d’une à quatre semaines. A la fin d’un
sprint un livrable est produit puis un nouveau sprint est ouvert. Ce cycle continue jusqu’à
épuisement du backlog. Des réunions journalières sont tenues pour connaître l’avancement du
projet ainsi que les points de blocage. La figure 2 illustre la méthode agile SCRUM
Figure 2 : La méthode agile SCRUM
8
Dans ce projet, la méthode agile SCRUM est totalement implémentée en respectant

les bonnes pratiques. Le logiciel de gestion de projet utilisé est: Jira Software de la société
Atlassian.
Ce projet implémente donc l’approche agile pour permettre de facilement prendre en

compte les retours de l’entreprise. Cependant pour accélérer la livraison de ces retours en
production une approche DevOps a été adoptée.
b) L’approche DevOps
Le terme « DevOps » est la contraction des mots anglais « Development »
(développement) et « Operations » (exploitation). Le DevOps accélère la concrétisation d’une
idée du développement au déploiement. Il s'appuie sur l'automatisation des tâches
d'exploitation courantes et la standardisation des environnements associés au cycle de vie d'une
application. Il se base aussi sur une étroite communication entre les équipes de développement
et de production afin d’améliorer l’efficacité de l’équipe. Le DevOps est donc un ensemble de
bonnes pratiques qui vise à faire collaborer les équipes de développement et d’opération dans
le but de réduire le délai de livraison des applications.
 Nécessité du DevOps :
Les technologies et les environnements évoluant sans cesse, les applications existantes
doivent être constamment adaptées. Les développements d’applications doivent se faire vite en
implémentant les exigences des clients. Aussi, pour une meilleure satisfaction de ces clients,
ces nouvelles fonctionnalités doivent être rapidement accessibles. Donc la méthode de
déploiement des applications doit suivre le rythme de développement des nouvelles
fonctionnalités.
Or, beaucoup d'entreprises implémentent une méthode de développement agile et s’en

tiennent là. Avec cette méthode, elles prenaient certes en compte les exigences de leurs clients
mais le rythme de déploiement se fait toujours aussi lentement.
D'où la naissance de l’approche DevOps. Le DevOps vient donc compléter la méthode

agile en augmentant le rythme de livraison des applications. La figure 3 illustre la
complémentarité des approches agile et DevOps. Cette figure montre comment l’agilité permet
9
de briser les barrières entre les clients et les équipes de développement, et d’autre part comment
le DevOps enlève les barrières cette fois entre les équipes de développement et d'opérations.
Figure 3 : Complémentarité entre la méthode Agile et l’approche DevOps
Le DevOps a un impact majeur dans trois domaines :
 l’amélioration de l'expérience client ;
 l’accroissement de la capacité à innover en augmentant le rythme de livraison des

applications ;
 l’accélération du retour sur investissement.
 Fonctionnement du DevOps
Pour implémenter efficacement une approche DevOps, il faut d’abord mettre en place
une politique de communication efficace entre les différentes équipes du projet. En effet le
DevOps repose sur la collaboration des différentes équipes pour remonter facilement les retours
des utilisateurs et leur permettre de voir rapidement leurs suggestions.
Le DevOps repose aussi essentiellement sur l’automatisation de certaines tâches dans

le cycle de développement de l’application. Il faut réduire au maximum l'intervention de
l’homme de la fin du développement à la mise en production et ceci pour augmenter la rapidité
10
de livraison des applications. Ce principe est mis en œuvre dans le DevOps à travers les notions
d’intégration continue, de livraison continue et de déploiement continu (CI/CD).
L’intégration continue (continuous integration CI) est une pratique de développement

qui consiste pour les développeurs à apporter des modifications régulières à leurs codes. Ces
codes sont automatiquement testés et fusionnés dans un référentiel commun (par exemple
GitHub). Cela corrige les éventuelles erreurs de code et permet de développer rapidement de
nouvelles fonctionnalités.
La livraison ou distribution continue (continuous delivery) est l’étape où les

modifications apportées par les développeurs sont automatiquement testées et téléchargées
dans un référentiel commun où elles peuvent être déployées en production par l’équipe
d’exploitation. Le processus de distribution continue permet de résoudre les problèmes de
visibilité et de communication entre l'équipe de développement et l'équipe métier. Ainsi, son
objectif consiste à simplifier au maximum le déploiement de nouveaux codes.
Le déploiement continu automatise le déploiement en environnement de production du

code publié dans le référentiel lors de l’étape de distribution continue.
On obtient ainsi une chaîne entièrement automatisée jusqu’en production dès lors que
les développeurs soumettent leurs codes.
Ceci permet de mettre rapidement à la disposition des utilisateurs de nouvelles

fonctionnalités et de prendre en compte leurs remarques.
L’entreprise gagne donc en efficacité et est en mesure de rester compétitive car elle
s’adapte rapidement.
Nous avons donc décider d’utiliser cette approche pour mettre en place notre cloud car
celui-ci doit pouvoir évoluer et apporter de nouvelles fonctionnalités mais aussi intégrer le plus
rapidement possible les retours des utilisateurs. La figure 4 illustre l’approche DevOps.
11
Figure 4 : Schéma du DevOps
Ce premier chapitre nous a permis d’effectuer une présentation générale en deux

parties : la première présente la structure qui nous a accueilli dans le cadre du stage, à savoir
BeOpenIT, en donnant son contexte de création ainsi que ses activités ; la seconde partie,
dédiée à la présentation du projet sur lequel nous avons travaillé au cours de ce stage, présente
le contexte, la problématique, les objectifs, ainsi que la méthode de développement du projet
12
CHAPITRE 2 : ANALYSE DES BESOINS
CHAPITRE
2
ANALYSE DES BESIONS
Afin de mieux saisir les besoins fonctionnels et non fonctionnels du système à réaliser, il
est nécessaire de comprendre ce système. Dans le cadre de ce projet, nous devons mettre en
place un cloud SaaS. Nous allons étudier d’abord, dans ce chapitre, le cloud et ses spécificités.
Ensuite comprenant mieux le système, nous allons dégager les besoins du système à mettre en
place.
1. Généralités sur le cloud
1.1. La virtualisation et le cloud
Les concepts de virtualisation et de cloud Computing peuvent prêter à confusion. Il est

donc nécessaire de comprendre les différences entre ces deux concepts.
La virtualisation est une technologie qui permet de créer plusieurs environnements

simulés ou ressources spécialisées à partir d'un seul système physique [1]. En d’autres termes
la virtualisation est un ensemble de techniques et logiciels qui permettent d’émuler sur une
seule machine physique plusieurs systèmes d’exploitation et applications. Ces systèmes
d’exploitation s’exécutent de manière isolée les uns des autres comme sur des machines
distinctes. Il existe plusieurs types de virtualisation : la virtualisation totale, la
paravirtualisation et hyperviseur, la virtualisation assistée par le matériel, le cloisonnement ou
la virtualisation niveau noyau [2]. La virtualisation est une technologie utilisée dans le cloud.
Le cloud d’autre part est un ensemble d’environnements qui regroupent et partagent des
ressources évolutives sur un réseau. Le cloud est utilisé dans le cadre d’une stratégie de cloud
computing. Le cloud computing consiste en l’exécution de charges de travail (par exemple
déployer des applications, stocker des données, etc.) sur le cloud. Donc le cloud computing
permet un accès à la demande aux ressources informatiques partagées du cloud et ceci à travers
un réseau. Aussi, le modèle cloud Computing s’articule autour de caractéristiques essentielles,
13
et se composent principalement de trois modèles de service et de quatre modèles de

déploiement.
1.2.Caractéristiques du cloud
Un certain nombre de métriques essentielles caractérisent le cloud computing. Ces

dernières sont :
 l’accès aux services à la demande : les utilisateurs ont accès à l’ensemble des ressources
informatiques du cloud, fournies sous forme de services autant qu’ils en ont besoin ;
 l’accès réseau large bande : il faut assurer une excellente connectivité réseau afin
d’offrir un meilleur temps d’accès aux ressources ;
 l’élasticité : les utilisateurs peuvent redimensionner leurs ressources en quelques
secondes en intégrant facilement de nouvelles instances ;
 mutualisation des ressources : le cloud computing donne accès à des
ressources disponibles selon le type de cloud sur plusieurs zones géographiques ;
 Facturation à l’usage : la facturation se fait selon la quantité de ressources consommées.
Cela permet de réduire les coûts par rapport à une infrastructure physique où le risque
de surdimensionnement est élevé.
1.3.Modèles de services du cloud
Le cloud offre trois principaux modèles de services : l’Infrastructure as a Service (IaaS),

la Platform as a Service (PaaS) et le Software as a Service (SaaS). Ces modèles de services
sont à déployer sur des environnements respectant les caractéristiques citées pour être
considérés comme du cloud Computing.
 L’Infrastructure as a Service ou IaaS :

Sur ce modèle de service, l’utilisateur a accès à une puissance de calcul et de stockage, des
capacités réseaux et autres services comme les firewalls, des systèmes d’équilibrage de charge
(load-balancer), etc. L’utilisateur dispose d’une infrastructure sur laquelle il peut installer
14
n’importe quel type de logiciels y compris des systèmes d’exploitation. Il ne gère pas
l’infrastructure cloud sous-jacente.
Les leaders de ce type de services sont Amazon Web Service (AWS), Microsoft Azure,
Google Cloud Platform (GCP).
 La Platform as a Service ou PaaS :

Le fournisseur met à disposition l’Infrastructure Cloud (IaaS) ainsi que les machines
virtuelles et les plateformes de développement. L’utilisateur ne gère que les applications à
déployer sur cette plateforme.
Comme exemples de PaaS on peut citer : Windows Azure, Google App Engine, etc.
 Le Software as a Service ou SaaS :

Ce type de service met à disposition des applications. L’utilisateur contrôle le
paramétrage et ses données. Le fournisseur cloud garantit dans ce cas la maintenance de
l’application et sa disponibilité. Voici quelques exemples de SaaS : Google Apps, Salesforce,
etc.
La figure 5 montre les principaux services du cloud. La partie rouge représente les
fonctionnalités que l’utilisateur doit gérer et en noir celles prises en charge par le fournisseur
selon le type de services.
Figure 5 : Différences entre les services cloud
15
1.4. Modèles de déploiement du cloud
Il existe quatre types de déploiement de cloud.
 Le cloud public
L’infrastructure cloud appartient à une organisation. L’infrastructure est ouverte au
public et aux grands groupes industriels, ils se partagent les ressources.
 Le cloud privé
L’infrastructure cloud est utilisée par une seule organisation. L’infrastructure peut être
gérée par l’organisation ou par une tierce partie.
 Le cloud communautaire
Pour ce type de déploiement, l’infrastructure est partagée par plusieurs organisations
pour le besoin d’une communauté souhaitant mettre en commun des ressources informatiques.
 Le cloud hybride
Ce type de déploiement regroupe deux ou plusieurs modèles de déploiement privé, public
ou communautaire. Ces infrastructures sont liées entre elles par la même technologie qui
autorise la portabilité des applications et des données.
Nous avons vu ce qu’est le cloud, ses caractéristiques, les modèles de services qu’il
propose et ses types de déploiement. Le cloud présente de nombreux avantages tels que la
réduction des coûts, l’accessibilité garantie à des services à la demande, adaptables à volonté.
Le cloud est donc un atout incontournable pour les entreprises sur plusieurs niveaux.
Dans ce projet, nous mettons en place un SaaS qui fournit comme service la possibilité
de déployer des sites rapidement et de stocker des données en quelques clics, à partir d’une
interface Web. Pour ce faire, nous devons respecter les caractéristiques du cloud computing,
du développement de l’application SaaS à son déploiement sur une infrastructure.
Nous analyserons dans la suite les besoins d’une telle plateforme par rapport à la chaîne
de déploiement, donc de la fin du développement d’une fonctionnalité du logiciel à son
déploiement en production.
16
2. Spécifications et Analyse des besoins du système
2.1. Spécifications des besoins du système
La plateforme est destinée aux personnes qui souhaitent déployer des sites web ou stocker
des données et plus tard aux entreprises qui souhaitent déployer ce cloud.
2.1.1. Les acteurs

Un acteur représente un rôle joué par une personne ou un autre système qui interagit
directement avec l’application [3].
Dans ce projet, nous sommes chargés de la mise en place de la chaîne DevOps. Nous
recevons le code des développeurs et nous effectuons tous les traitements jusqu’au déploiement
sur les différents environnements de production et de test.
Les développeurs interagissent directement avec le système de déploiement mise en

place. Ils sont donc des acteurs du système. Ils développent l’application, le reste de la chaîne
de déploiement est automatisée.
2.1.2. Les besoins non fonctionnels

Une exigence non-fonctionnelle est une condition qui spécifie les critères qui peuvent
être utilisés pour juger du fonctionnement d’un système, plutôt que des comportements de
celui-ci [4]. Les exigences non-fonctionnelles à assurer du point de vue DevOps sont :
 la rapidité de déploiement : pour ce projet il est important pour l’entreprise de réduire

le “Time To Market” (délai de livraison) afin de pouvoir déployer rapidement les
nouvelles fonctionnalités dont les tests sont validés et d’étudier les retours sur ces
fonctionnalités ;
 la haute disponibilité et tolérances aux pannes : la haute disponibilité permet d’assurer

l'accessibilité des services pour une période donnée. Un service hautement disponible
est à 99% disponible (soit au plus 3,65 jours d'indisponibilité par an) [5]. Le système
que nous mettons en place doit être hautement disponible pour permettre aux
utilisateurs d’avoir accès en continu à leurs données. Le système doit être également
17
tolérant aux pannes toujours dans le souci d'améliorer l'accessibilité des services
proposés ;
 la scalabilité (l’élasticité) : la scalabilité permet de gérer le phénomène de montée en

charge. Le système soit automatiquement s’adapter en augmentant le nombre des
répliques des services proposés selon le nombre de sollicitations en simultanée ;
 la portabilité : le SaaS que nous devons mettre en place doit pouvoir être implémenté
sur différents environnements. La chaîne DevOps mise en place doit gérer cette
problématique tout en libérant les développeurs de la complexité d’adapter les
technologies qu’ils utilisent selon les différents environnements ;
 la sécurité des services déployés : il faudra s’assurer que les services déployés en
environnement de production ne comportent pas des failles de sécurité.
Il est important de prendre en compte ces besoins lors de la mise en place de la chaîne
DevOps.
2.1.3. Les besoins fonctionnels

Le SaaS qui est mis en place est constitué d’un ensemble de microservices. L’architecture
en microservices est un modèle de développement logiciel qui, par opposition au modèle de
développement monolithique traditionnellement adopté, consiste à développer l’application en
une suite de services indépendants. Ces services sont des processus qui communiquent entre
eux pour fournir un résultat particulier. Ce type de développement permet d’assurer
l'évolutivité de l’application, l’isolation des erreurs, la diversité des technologies utilisée lors
du développement, la rapidité des tests et déploiement. Cette méthode est très orientée cloud
computing car facilitant le déploiement sur les environnements clouds. Donc la chaîne DevOps
à mettre en place devra permettre de déployer en environnement de production tous les
microservices qui concourent au fonctionnement de la plateforme.
La mise en place de cette chaîne DevOps consiste à :
 mettre en œuvre l'intégration continue (CI) ;

 mettre en place la chaîne de déploiement continu (CD).
2.2. Analyse du système
18
L’analyse des besoins permet de dégager les spécifications à mettre en œuvre lors de la
phase de conception. Pour rendre cette analyse lisible par tous, le langage de modélisation
UML est souvent adopté.
La notation UML est un langage visuel constitué d’un ensemble de schémas, appelés
des diagrammes, qui donnent chacun une vision différente du projet à traiter. UML fournit un
ensemble de diagrammes qui permettent de représenter le projet à réaliser.
UML est constitué de 13 diagrammes qui représentent chacun un concept du système

d’après le site de cours en ligne Openclassroom [6].
Pour analyser notre système, nous aurons besoin du diagramme des cas d’utilisation et
du diagramme de séquence.
Le diagramme de cas d’utilisation représente les fonctionnalités nécessaires aux acteurs.
La figure 6 représente les fonctionnalités disponibles pour l’acteur « Développeurs » sous

la forme d’un diagramme de cas d’utilisation.
Les développeurs interagissent avec le système de contrôle de versions. Dans celui-ci on

rencontre les notions de branche, de pull-request et de merge.
Les développeurs se partagent un code de base se trouvant dans le système de contrôle

de versions sur un “répertoire” appelé branche principale. Les branches sont des ramifications
créées permettant de travailler sur des versions de code qui divergent de la branche principale.
Cela permet aux développeurs de pouvoir travailler sur différentes fonctionnalités à la fois.
Une fois ces fonctionnalités codées en local, il faut les pousser dans le VCS. Pour intégrer ces
fonctionnalités à la branche principale qui contient le code courant, il faut demander une
vérification de ces fonctionnalités par des pairs : c’est le “pull-request” ou demande de revue
de code. Si le code des nouvelles fonctionnalités est validé, il est fusionné avec le code de la
branche principale, c’est le “merge”.
19
Figure 6 : Fonctionnalités accessibles aux développeurs
Nous allons étudier la fonctionnalité « fusionner le code d’une branche à une autre » avec
une description textuelle. Le tableau 2 permet de visualiser cette description textuelle.
20
Titre Fusionner le code d’une branche dans une autre
Acteurs Développeurs
Objectifs Permettre aux développeurs de fusionner un code déjà testé sur une
branche
Précondition  S’authentifier si on ne s’est pas authentifié auparavant pour

effectuer une action sur le système ;
 Revue du code à fusionner validé par au moins un autre

développeur
Scénario nominal 1. Le développeur pousse sur sa branche de travail le code de la

fonctionnalité sur laquelle il travaille.
2. Il ouvre un « pull request » c’est à dire une revue de code par

d’autres développeurs afin d'intégrer son code dans une branche
principale.
3. Si les développeurs valident les modifications, il est possible

de fusionner cette nouvelle fonctionnalité au code de la branche sur
laquelle un « pull request » est demandé.
Scénario alternatif aucun
Post conditions Un build du nouveau code obtenu après fusion est automatiquement
déclenché sur le serveur d’intégration continue.
Tableau 2 : Description textuelle de la fonctionnalité "fusionner le code d'une branche sur

une autre branche"
Nous allons voir à travers une description graphique (figure 7) sur un diagramme de
séquence illustrant le scénario nominal décrit dans le tableau 2
21
Figure 7 : Description graphique de la fonctionnalité “fusionner un code d’une branche

dans une autre branche”
22
Ce chapitre nous a permis de mieux comprendre le système à mettre en place grâce à

une étude du cloud. Il nous a également permis de connaître quels sont les acteurs du système
à réaliser. Nous avons pu, à travers ce chapitre étudier les besoins fonctionnels et non
fonctionnels ainsi que l’analyse du système.
23
CHAPITRE 3 : CONCEPTION DE LA SOLUTION
CHAPITRE 3
CONCEPTION DE LA SOLUTION
L'analyse des besoins effectuée dans le chapitre précédent nous a permis de dégager les
points essentiels que le système à réaliser devra prendre en charge pour atteindre les objectifs
définis. Dans ce chapitre nous allons étudier comment réaliser ce système en prenant en
compte les besoins définis. Nous effectuerons donc l’analyse conceptuelle de la solution.
Nous allons d’abord proposer une chaîne CI/CD qui implémente les besoins non-
fonctionnels définis dans le chapitre précédent, nous préciserons les technologies et outils
utilisés à cet effet. Ensuite nous ferons une conception détaillée en expliquant comment sera
implémentée la chaîne CI/CD.
1. Proposition d’une chaîne d’intégration continue et de

déploiement continu
L’approche CI/CD s’inscrit dans le cadre de la réduction du délai de livraison des

applications. En effet, les pratiques traditionnelles de développement consistent pour les
développeurs en l’intégration de leurs codes en un moment défini avant le déploiement de
l’application dans un environnement. Cette étape d’intégration des codes donne souvent lieu à
des conflits de codes et erreurs qui ralentissent la distribution des applications.
L’approche CI/CD vient résoudre ce problème en automatisant les étapes du cycle de

développement des applications. En effet elle permet une bonne gestion de codes qui facilite
les tests et la fusion des codes (phase d’intégration continue). Elle permet aussi d’automatiser
la distribution des applications (déploiement continu).
La figure 8 permet de visualiser les étapes de l’approche CI/CD.
24
Figure 8 : Étapes d’une chaîne CI/CD
L’étape d’intégration continue consiste comme dit dans le chapitre 1 en l’intégration

régulière de portions de code et en la mise en commun de ces portions de code dans un
référentiel commun.
L’étape de distribution continue ou livraison continue permet de disposer d’artefacts

prêts à être déployés dans un environnement. Lorsque ce déploiement est automatisé, on parle
de déploiement continu.
Pour mettre en œuvre la chaîne d'intégration continue et de déploiement continu, il faut:
 assurer l'intégration facile des codes ;

 assurer les builds et tests des codes. Les codes sont organisés en microservices. Les
microservices, comme présenté dans le chapitre sur l’analyse des besoins, sont
différents services d'une application, développés de manière indépendante. Nous
présenterons les différents microservices de la plateforme SaaS dans la
seconde partie de ce chapitre portant sur la mise en œuvre de la solution ;
 conteneuriser les microservices à déployer ;
 assurer la livraison et le déploiement des conteneurs de microservices en
environnement de test et de production.
1.1. Technologies et des outils utilisés
1.1.1. Outils de l’intégration continue
Cette étape regroupe plusieurs sous-étapes allant de la gestion des codes à la création
d’artéfacts livrables en production.
25
a) Gestion des sources de code

L’intégration de code se fait dans un système de contrôle de sources ou SCM. Les outils
de gestion des versions de code fournissent un historique clair des modifications apportées au
code et identifient les auteurs de ces modifications. Ils permettent donc de gérer l’accès
commun au code de différents utilisateurs.
Il existe plusieurs SCM parmi lesquels nous pouvons citer SVN qui est un système de
gestion de code centralisé et Git qui est un système décentralisé. Dans le cadre de ce projet,
Git est plus adapté car il permet de travailler en simultané sur le code.
Nous travaillons donc avec Git comme système de gestion de versions de code. Il existe
plusieurs logiciels de gestion de code basés sur Git tels que GitHub, Gitlab, bitbucket.
Nous utilisons GitHub dans le cadre de ce projet. GitHub est un SCM en ligne. Il permet
de gérer efficacement les différentes versions de codes et de déclencher l’exécution de la chaîne
d’intégration continue.
b) Serveur d’intégration continue

Un serveur d’intégration continue est un outil permettant de tester et de compiler les
modifications apportées au code. Cela permet de connaître l’impact des modifications sur le
code et d'éviter les régressions de code.
Il existe dans le marché plusieurs serveurs d’intégration continue tels que Jenkins,
bamboo, circle CI, etc.
Jenkins est un serveur d’intégration continue open-source facilement extensible et

adaptable grâce à l’usage des plugins. Il permet d’automatiser les étapes de tests, builds et
livraison des applications. Nous utilisons Jenkins comme serveur d’intégration.
c) Serveur de gestion de la qualité de code

Les scans de code permettent d'améliorer la qualité du code en repérant les redondances,
les bugs, le non-respect des bonnes pratiques de programmation, etc. Ils permettent aussi de
détecter les vulnérabilités présentes dans le code.
SonarQube est un logiciel libre qui permet d’évaluer la couverture de code par les tests
unitaires, les duplications de code, le respect des règles de programmation. Il permet également
de détecter un certain nombre de failles de sécurité dans le code telles que :
26
 l’injection sql ;
 le cross-site scripting ;
 l’injection de code.
SonarQube s'intègre parfaitement avec Jenkins. Jenkins peut alors déclencher

l’inspection du code en contactant le serveur SonarQube auquel il est connecté.
SonarQube permet donc de prendre en charge le besoin d’assurer la sécurité des données
des utilisateurs de la plateforme en permettant d’améliorer la qualité du code.
d) La conteneurisation
La conteneurisation consiste à embarquer ensemble le code ainsi que les dépendances,
fichiers et bibliothèques nécessaires à son exécution créant ainsi une image du code. Cela évite
les erreurs lors du déploiement dues au fait que les environnements utilisés lors du
développement diffèrent de l’environnement de production mis en place. En effet la manière
traditionnelle de déployer des applications consiste à installer les applications sur une machine
en utilisant les systèmes de gestions de paquets natifs. Cela a pour conséquence que les
exécutables produits ainsi que les dépendances et les librairies soient fortement liés au système
d’exploitation de la machine hôte. Ce qui constitue un frein à la portabilité.
La conteneurisation permet de prendre en charge pour chaque application les librairies

et dépendances dont elle a besoin. Ces conteneurs créés sont immuables. Ils conservent donc
leur état quel que soit l’environnement d'exécution. Cela permet de garantir la portabilité.
D’autre part, l'exécution des conteneurs se fait de manière isolée, on peut donc exécuter
plusieurs applications sur un même environnement sans risque.
Cependant, il ne faut pas confondre la conteneurisation et la virtualisation. En effet,

comme mentionné dans le chapitre précédent, la virtualisation consiste en l’émulation d’une
machine physique grâce à un hyperviseur. Ces machines virtuelles embarquent un système
d’exploitation qui les rend lourds.
Les conteneurs quant à eux utilisent directement le système d'exploitation de la machine

hôte et dialogue avec celui-ci grâce à l’environnement d'exécution embarqué du conteneur. Les
27
conteneurs sont donc plus légers et leur exécution est plus rapide. La figure 9 illustre les
différences qui existent entre la virtualisation et la conteneurisation.
Figure 9 : Différences entre virtualisation et conteneurisation

Les conteneurs sont scalables, ce qui permet de gérer facilement les phénomènes de
montée en charge. En effet, il est très simple et rapide de démarrer de nouveaux conteneurs.
Cela permet aussi de prendre en charge la haute disponibilité en créant rapidement de nouveaux
conteneurs en cas d’arrêt de ces derniers.
Ils permettent aussi de gérer le besoin de portabilité induit par le fait que la plateforme
doit pouvoir être déployée dans un cloud public et dans le cloud privé d’une entreprise. Cela
permet également d’augmenter la rapidité de déploiement car il n’est plus nécessaire d’adapter
les environnements selon le code ; chaque conteneur s'exécute de la même manière quel que
soit l’environnement de déploiement.
En résumé la conteneurisation permet :
 d’assurer la portabilité sur plusieurs environnements ;
 d’augmenter la rapidité de déploiement (en séparant l’application de

l’infrastructure) ;
 d’assurer la scalabilité et la haute disponibilité (création facile et rapide des

conteneurs) ;
 d’assurer l’isolation des ressources ;
28
 d’assurer l’observabilité et la maintenance facile de l’application ;
Il existe plusieurs outils de conteneurisation tels que : docker, linux Container (LXC),
etc.
Docker est outil de conteneurisation open-source qui permet de gérer facilement des
conteneurs grâce à une interface en ligne de commande simple. La création d’une image docker
se fait à travers un fichier nommé Dockerfile. Le Dockerfile est une description exacte de la
constitution de l’application (dépendances, librairies, artefacts obtenus après le build de
l’application, etc.).
Les conteneurs s'intègrent donc facilement avec l’approche CI/CD en diminuant

considérablement les délais de livraison.
1.1.2. Outils pour la livraison continue
L'étape de la livraison continue consiste à publier dans un référentiel, les artefacts obtenus
à l’étape de l’intégration continue. Elle permet d’avoir un historique des différentes versions
des applications déployées. L’intégration continue nous livre des images des différents
microservices de la plateforme. Ces images sont publiées dans le dépôt d’images de
l’entreprise. Comme exemple de système de gestion d'artefacts nous pouvons citer docker
Hub, Nexus. Docker Hub permet de stocker des images docker en ligne dans des registres.
C’est le système de gestion d'artefacts que nous utilisons.
1.1.3. Outils pour le déploiement continu

Le déploiement continu automatise le déploiement des artefacts (images docker dans le
cas de ce projet) en environnement de production. Il s’agit donc de mettre en place un ensemble
de bonnes pratiques et technologies permettant de déployer automatiquement les artéfacts.
a) Orchestration des conteneurs

L’orchestration consiste à gérer un grand nombre de conteneurs déployés dans un cluster
ou dans plusieurs clusters. Elle permet de connaître l’état des conteneurs en cours d'exécution
29
et d’effectuer des actions sur ces derniers. Comme orchestrateur on peut citer docker swarm,
kubernetes.
Kubernetes est un logiciel open-source qui permet de déployer et de gérer des

applications conteneurisées. Il est capable de gérer d’importantes charges de travail. Il permet
d’automatiser le déploiement des conteneurs grâce à des configurations déclarées dans des
fichiers yaml appelés manifestes. Il permet également de gérer la communication entre
conteneurs, la scalabilité et la disponibilité des applications.
Kubernetes permet donc de déployer et de gérer les conteneurs en environnement de

production. La figure 10 représente l'architecture de kubernetes.
Figure 10 : Architecture de kubernetes
Cette architecture permet de comprendre le fonctionnement de kubernetes.
Kubernetes fonctionne en mode master-node. Le master est le centre de contrôle et est

constitué :
 du kube-apiserver qui permet de gérer les requêtes du cluster ;
 du kube-controller manager qui assure le maintien de l’état désiré du cluster ;
 du kube-scheduler qui programme l'exécution de nouveau conteneur dans le cluster ;
 de l’etcd qui est une base de données contenant les informations du cluster kubernetes.
Les «worker nodes» sont les nœuds d'exécution des conteneurs. Sur ces nœuds tournent :
30
 le kubelet qui permet aux noeuds de dialoguer avec le master ;
 le kube-proxy qui permet d'assurer la communication en réseau des conteneurs.
Nous déploierons donc les images des microservices sur un cluster Kubernetes. Ainsi nous
pourrons gérer les conteneurs en cours d’exécution.
b) La culture GitOps
GitOps est un ensemble de bonnes pratiques qui consiste à décrire exactement l’état
voulu de l’environnement de déploiement dans des fichiers placés dans un dépôt Git. Il s’agit
de faire de Git le référentiel permettant de connaître la description exacte de l’environnement
de déploiement, par exemple les images à déployer, le nombre de conteneurs qui doivent être
déployés, etc. Ainsi on a un historique des différents états voulus des environnements. On peut
ainsi revenir à un état précédent en cas de bug survenu en production.
Un système de synchronisation permet de détecter automatiquement des changements

sur les descriptions des environnements sur Git. L’environnement est automatiquement mis à
jour pour correspondre à la nouvelle description.
L’implémentation de GitOps nous permet d’automatiser l’ensemble de la chaîne CI/CD.
Comme outil implémentant les pratiques GitOps nous pouvons citer: Flux et Argo CD.
Flux est un opérateur kubernetes qui permet de synchroniser les manifestes kubernetes
contenus dans le dépôt Git. Il détecte s’il y’a des modifications dans ces manifestes à chaque
commit sur la branche indiquée et met à jour le cluster kubernetes. Il est relié à docker Hub et
charge les nouvelles images que l’on souhaite déployer. La figure 11 montre le fonctionnement
de Flux que nous avons décrit.
31
Figure 11 : Fonctionnement de flux
1.2. Proposition d’une chaîne CI/CD
Nous avons défini les technologies et outils que nous utilisons pour réaliser la chaîne
CI/CD. Les diagrammes d’activités illustrés par les figures 12 et 13 donnent des
représentations graphiques des différentes actions effectuées lors du déroulement du pipeline
CI/CD. En bleu est représentée la chaîne d’intégration continue, en orange la livraison continue
et en rouge le déploiement continu.
32
Figure 12 : Déroulement de la chaîne CI proposée
33
Figure 13 : Déroulement de la chaîne CI proposée
1.3. Architecture logicielle du pipeline CI/CD
L’architecture logicielle permet de voir comment les outils choisis intègrent la chaîne
CI/CD proposée. La figure 14 présente cette architecture logicielle.
34
Figure 14 : Architecture logicielle de la chaîne CI/CD
2. Mise en œuvre de la chaîne CI/CD
La plateforme SaaS est constituée de cinq microservices nommés :
 cloud-dashboard : c’est le microservice qui prend en charge l’interface utilisateur.

Il permet de poster les demandes de création de sites web personnalisés et de base
de données. Il est codé en utilisant le framework Angular.
 cloud-CMS : ce microservice prend en charge les demandes de création de site web

avec les CMS. Un CMS (Content Management System) ou système de gestion de
contenu est un logiciel qui permet de concevoir, gérer et mettre à jour des sites et
des applications mobiles de manière dynamique. Le CMS utilisé est WordPress. Ce
microservice est développé avec Jhipster, un framework Spring Boot.
 cloud-BDD : ce microservice gère la création et les opérations sur les bases de

données. Des bases de données de type SQL sont déployées pour le moment. Le
microservice est également développé avec Jhipster.
35
 cloud-k8s : il permet de créer et de lancer les déploiements des sites et base de

données dans un cluster kubernetes. Il est développé en Golang.
 cloud-projet qui gère les demandes de création de projets pour déployer après un
site web et/ou une base de données.
Le code de chaque microservice est sur un dépôt GitHub portant le même nom que le
microservice. La chaîne CI/CD définie sera intégrée dans chacun de ces dépôts.
Pour illustrer l’intégration de la chaîne CI/CD mise en place, nous allons travailler avec
le microservice cloud-dashboard.
2.1. Environnement de déploiement de la plateforme SaaS
Ces microservices seront déployés dans deux types d'environnements : un environnement de

développement et un environnement de production. L’environnement de développement sert
à tester l’intégration de toutes les fonctionnalités. Une fois ces tests validés, ces microservices
peuvent être déployés en environnement de production où ils sont accessibles aux utilisateurs
finaux.
Sur cet environnement seront déployés les microservices qui constituent la plateforme SaaS
ainsi que les données des utilisateurs telles que leurs sites web et leurs bases de données. La
figure 15 représente l'architecture de l’environnement de développement.
36
Figure 15 : Architecture de l’environnement de développement
L’environnement de développement est déployé sur un cluster AWS. Le cluster est

subdivisé en deux zones de disponibilité. Une zone de disponibilité est un centre qui héberge
des ressources du cloud provider. Les zones de disponibilité permettent de gérer la haute
disponibilité des données en cas de panne. Les éléments présents dans une zone de disponibilité
sont exactement répliqués sur l’autre zone.
Le cluster dispose d’un réseau virtuel nommé VPC (Virtual Private Cloud) subdivisé en
deux sous-réseaux, un privé et un public. Les opérateurs effectuent des actions sur les noeuds
situés dans le sous-réseau privé en passant par le sous-réseau public. Cette interaction se fait
grâce à une suite de composants que sont :
 l’Internet Gateway (IGW) qui fournit des adresses IP Elastic utilisées pour permettre
les connexions SSH entrantes dans les sous-réseaux ;
 le Network Elastic Load Balancer (ELB) qui répartit les requêtes sur des cibles
définies ;
37
 Le bastion host qui fournit un accès sécurisé aux instances situées dans le sous-réseau
privé ;
 Le NAT Gateway qui autorise les accès internet sortants pour les noeuds situés dans le
sous-réseau privé.
Dans le sous-réseau privé se trouve le cluster Kubernetes déployé grâce au service

Amazon EKS (Elastic Kubernetes Service). Le cluster est constitué de noeuds sur lesquels
tournent Kubernetes et sont dans un groupe Auto-Scaling. Le groupe auto-scaling permet à
EKS d’augmenter automatiquement le nombre de noeuds.
Le composant ingress placé dans le VPC permet de garantir l’accès externe aux services
déployés dans les noeuds Kubernetes. C’est donc grâce à ce composant que les utilisateurs
pourront avoir accès aux services de la plateforme SaaS.
2.2. Mise en œuvre de l’intégration continue et de la livraison continue
2.2.1. Configuration sur GitHub
a) Le gitflow
Il est important de définir l’organisation des branches dans le dépôt GitHub. Cette
organisation est connue sous le terme de gitflow. Un gitflow définit un modèle de création de
branches ; il permet d’assigner un rôle spécifique à chaque branche et de définir les interactions
entre ces branches.
La figure 16 représente le gitflow adopté dans le cadre de ce projet :
38
Figure 16 : Organisation des branches dans le dépôt

Nous avons les branches suivantes :
 Features : ces branches contiennent le code des différentes fonctionnalités des

microservices. Les développeurs clonent le code de la branche Dev (2) et effectuent
des modifications sur ce code. le code modifié est à nouveau fusionné avec la
branche dev (3) ;
 Dev : sur cette branche sont fusionnés les codes des différentes fonctionnalités de
la plateforme. Le code de cette branche est testé dans l’environnement de
développement ;
 Release : une fois que toutes les nouvelles fonctionnalités de la branche dev sont
testées et prêtes à être déployées, une nouvelle release est créée (4). Ainsi cette
branche contient l’historique des versions de l’application déployée en production ;
39
 Master : contient le code à déployer en environnement de production. Ce code est

reçu de la branche «release» (5). La version initiale du code est clonée depuis cette
branche (1). C’est une branche principale, la branche créée par défaut ;
 Hotfix : si des bugs surviennent en production, des corrections peuvent être

rapidement apportées à partir de cette branche (6). Ces corrections sont ensuite
intégrées au code de la branche master pour régler le bug (7) et au code de la branche
dev pour être pris en compte lors des prochaines itérations du code (8).
Le cycle décrit reprend pour la création d’une nouvelle release (9).
b) Configuration du webhook sur GitHub

Sur GitHub, il est possible de configurer des branches de telle sorte qu’à chaque fois
que du code est poussé sur ces branches, des builds sont déclenchés sur Jenkins. Cette
configuration est nommée webhook et consiste à fournir au niveau des paramètres de la
branche, l’adresse du serveur Jenkins.
Le webhook a été configuré au niveau des branches de dev, release et master sur chaque
dépôt pour déclencher automatiquement des builds au niveau de Jenkins à chaque fois que du
code est poussé sur ces branches. Ces trois branches sont également protégées ; pour y pousser
du code, il faut une validation d’au moins un développeur.
La figure 17 représente la configuration du webhook du microservice cloud-dashboard

sur GitHub.
Figure 17 : Configuration du webhook du microservice cloud-dashboard
40
La configuration du webhook permet d’automatiser le déclenchement de la chaîne

CI/CD.
2.2.2. Configuration sur Jenkins
Jenkins est un serveur d’intégration continue extensible, nous pouvons ajouter les extensions
nécessaires pour connecter Jenkins aux outils CI/CD de la chaîne. Pour intégrer le scan de code
sur Jenkins, il faut installer sur celui-ci le plugin « SonarQube scanner ». Ce plugin permet de
configurer l’analyse du code dans le pipeline Jenkins. Il faut aussi indiquer à Jenkins l’adresse
du serveur SonarQube ainsi que le token de connexion au serveur. Ainsi Jenkins peut
déclencher l’analyse de code. Cette analyse se fait en se référant au fichier sonar-
project.properties défini dans le code du microservice. Ce fichier contient les paramètres
d’analyse du code tels que l’adresse du serveur SonarQube, le nom du projet, éventuellement
les fichiers à exclure lors de l’analyse du code, etc.
La figure 18 représente l'installation du SonarQube Scanner sur Jenkins. La figure 19

représente l’intégration de Jenkins avec le serveur SonarQube.
Figure 18 : Configuration du SonarQube scanner
41
Figure 19 : Intégration de Jenkins au serveur SonarQube.
2.2.3. Création du Jenkinsfile et du Dockerfile
a) Le Jenkinsfile
Une fois toutes les configurations faites sur Jenkins, nous pouvons dérouler la chaîne
d’intégration continue. Jenkins permet de définir les étapes d’une chaîne d'intégration
continue dans un fichier texte nommé Jenkinsfile. Ce fichier est mis dans le dépôt Git et
Jenkins le détecte automatiquement à chaque fois qu’il reçoit le code. Il exécute alors les étapes
définies dans ce fichier comme l'exécution des tests, la compilation, etc.
Nous avons défini un Jenkinsfile placé dans le dépôt de chaque microservice.
Pour chaque microservice, nous avons créé au niveau de Jenkins un projet de type
«pipeline multi branches». Ce type de projet permet de repérer les différentes branches
présentes au niveau du dépôt Git et d’effectuer des builds sur celles-ci. Nous avons également
indiqué sur ces projets le lien vers les microservices sur GitHub. Ainsi Jenkins peut
automatiquement récupérer le code sur de ces microservices à chaque fois que le webhook est
déclenché.
Sur le Jenkinsfile, on définit les actions à effectuer pour des branches définies. A titre
d’illustration, pour le microservice cloud-dashboard les étapes du Jenkinsfile sont les
suivantes :
 Vérifier si la branche en cours de build est soit la branche dev, release ou master ;
42
 Faire un «npm install» pour installer les dépendances ;
 Déclencher le scan du code sur le serveur SonarQube ;
 Exécuter les étapes du Dockerfile et créer une image ;
 Taguer l’image avec le numéro de build Jenkins et un suffixe latest permettant ainsi
de gérer l’historisation ;
 Livrer l’image sur le dépôt docker Hub (livraison continue) ;
 Supprimer l’image créée dans l’agent Docker.
Il faut noter que l'exécution du Jenkinsfile est linéaire et un échec à une étape fait
échouer la chaîne d'exécution.
La figure 20 illustre le Jenkinsfile de cloud-dashboard.
Figure 20 : Jenkinsfile du microservice cloud-dashboard
b) Le Dockerfile
Le Dockerfile permet de conteneuriser le microservice. La figure 21 représente le
Dockerfile créé du microservice cloud-dashboard.
43
Figure 21 : Dockerfile du microservice cloud-dashboard
Sur ce Dockerfile, nous partons d’une image node qui permet d’exécuter les commandes
npm. Nous définissons un répertoire de travail et pour préciser que le build de l’application est
pour l'environnement de dev, la variable ENVIRONMENT est mise à dev. Le fichier
package.json contenant l’ensemble des dépendances de l’application est copié dans le
conteneur node. Les dépendances sont ensuite installées avec la commande npm install. Le
code est copié dans le conteneur node puis il est compilé. Le résultat de la compilation d’une
application angular se trouve dans le dossier dist. Pour démarrer le microservice, il faut un
serveur web d’où l’utilisation du conteneur nginx. Le dossier dist obtenu est copié dans le
dossier de base du conteneur nginx : « /usr/share/nginx/html ». Nous remplaçons enfin les
configurations par défaut de nginx par les configurations que nous avons définies dans le fichier
nginx.conf.
Les étapes définies dans ce fichier permettent donc d’embarquer tous les fichiers
nécessaires à l'exécution de l’application.
Pour les autres microservices développés avec Jhipster ou avec Golang, les étapes du
Jenkinsfile sont les mêmes. Cependant pour les microservices développés avec Jhipster, le
framework permet d’embarquer une dépendance docker qui permet de générer directement une
image docker. Pour ces microservices, nous avons défini un Makefile contenant une liste de
44
commandes à exécuter. Ce fichier contient les commandes permettant d’effectuer les tests, de
compiler les microservices et de créer l’image correspondant au microservice. Le Jenkinsfile
fait appel à ce fichier à la place du Dockerfile dans ce cas. Pour illustrer cela, nous avons mis
en annexe le Jenkinsfile et le Makefile du microservice cloud-CMS.
2.3. Mise en œuvre du déploiement continu
L’automatisation du déploiement des microservices se fait grâce à l’opérateur Flux. Il

s'exécute sur le cluster où sont déployés les microservices.
Flux permet de générer les fichiers permettant d’automatiser le déploiement d’un

microservice. Parmi ces fichiers générés se trouve le fichier «flux-patch.yaml». On indique
dans celui-ci le lien du dépôt Git et la branche sur laquelle se trouvent les manifestes
Kubernetes à déployer. L'opérateur flux crée le namespace sur lequel le microservice sera
déployé.
La figure 22 représente la configuration du fichier flux-patch.yaml.
Figure 22 : Configuration du fichier flux-patch.yaml
45
Sur le dépôt du microservice ; nous créons trois fichiers: flux.yaml, flux-patch.yaml et le

kustomization.yaml. Le fichier flux.yaml contient une commande permettant de lancer le build
du fichier Kustomization.yaml. Ce dernier indique la location des fichiers kubernetes à créer.
Dans ce fichier est indiqué le répertoire «workloads» dans lequel nous avons placé les
manifestes kubernetes à créer.
Nous créons donc un répertoire nommé “workloads” sur lequel nous définissons les
manifestes kubernetes que l’on souhaite déployer. Ces manifestes contiennent la description
de l’état voulu du cluster kubernetes. Nous avons créé dans ce répertoire un fichier
deployment.yaml. Ce fichier décrit l’état du cluster avec des informations comme le nom du
conteneur, l’image à déployer, le nombre de conteneurs à déployer, la quantité de ressources
(CPU et mémoire RAM) que chaque conteneur doit utiliser, ainsi qu’un service permettant
d’exposer les conteneurs pour des accès externes.
La figure 23 représente le fichier deployment.yaml du microservice cloud-dashboard.

Nous avons défini deux répliques du conteneur. Nous avons aussi indiqué le nom du conteneur
ainsi que l’image à utiliser et les ressources allouées à chaque conteneur.
Figure 23 : Fichier de déploiement du microservice cloud-dashboard
46
La figure 24 représente la configuration du service qui permettra de contacter les

conteneurs dans le cluster. On indique le port d’accès et l’application cloud-dashboard.
Figure 24 : Configuration du service pour les conteneurs cloud-dashboard
Flux est synchronisé avec le répertoire workloads des microservices et détecte tous les
changements effectués dans ces fichiers à chaque commit sur la branche dev. Il applique les
changements détectés au niveau du cluster Kubernetes.
Ainsi nous avons pu automatiser le déploiement des microservices grâce à flux. Les
étapes de configuration de la chaîne CD définies pour le microservice cloud-dashboard sont les
mêmes pour les autres microservices.
Dans ce chapitre, nous avons pu définir la chaîne CI/CD adoptée ainsi que les outils
permettant de le réaliser. Ensuite nous avons pu montrer les étapes de la mise en œuvre de
cette chaîne.
47
CHAPITRE 4 : RESULTATS OBTENUS
CHAPITRE 4
RESULTATS OBTENUS
Le chapitre précédent nous a permis de concevoir et d’implémenter une chaîne

d’intégration continue et de déploiement continu. Ce chapitre permet de présenter les résultats
obtenus dans un premier temps. Ensuite, il permet de voir les objectifs atteints ainsi que les
apports du projet.
Nous allons présenter les artefacts obtenus lors de la mise en place de la chaîne CI/CD.
Nous présenterons d’abord les résultats obtenus lors de la phase d’intégration continue ensuite
ceux obtenus lors de la livraison continue et du déploiement continu.
Nous allons illustrer ces résultats avec le microservice cloud-dashboard.
Au moment de la mise en place de la chaîne CI/CD, les microservices ne sont pas prêts
à être déployés. Cependant la chaîne d’intégration continue est entièrement mise en place.
Quant à la chaîne de déploiement continu, nous avons utilisé un cluster kubernetes temporaire
pour pouvoir implémenter cette dernière étape.
1. Intégration continue
1.1.SonarQube
SonarQube analyse et note le taux de couverture du code, les duplications de code, la
maintenabilité, la fiabilité et la sécurité du code. Une note inférieure aux valeurs définies
entraîne un échec du scan du code.
La figure 25 montre le résultat du scan du code du microservice cloud-dashboard.
48
Figure 25 : Scan du code du microservice Cloud-Dashboard
SonarQube indique la partie du code contenant des bugs, des vulnérabilités, des
duplications de codes, etc. Ainsi, le code peut être amélioré en toute facilité.
1.2. Compilation et création de l’image

Jenkins effectue la compilation du code en se référant au Jenkinsfile fourni. Lorsque les
tests et la compilation passent, la phase de scan est exécutée.
Après cette phase, une image docker est créée à partir du Dockerfile défini.
La figure 26 représente l’exécution du pipeline CI du microservice cloud-dashboard.
49
Figure 26 : Exécution de la chaîne CI du microservice cloud-dashboard
2. Livraison continue
Une fois les images générées, elles sont nommées selon le microservice et taguées avec
le numéro du commit pour cloud-CMS, cloud-BDD, cloud-K8S ou le numéro du build sur
Jenkins pour le microservice cloud-dashboard. Elles sont ensuite automatiquement publiées sur
docker Hub.
La figure 27 montre la livraison des images docker du cloud-dashboard.
50
Figure 27 : Livraison des images du microservice cloud-dashboard
3. Déploiement continu
L'opérateur Flux déployé au niveau du cluster détecte automatiquement les nouvelles

images poussées sur docker Hub et les déploie sur le cluster Kubernetes.
La figure 28 montre les espaces de nom cloud-cms, cloud-dashboard et flux-system créés

par Flux dans le cluster kubernetes. C’est dans l’espace de nom cloud-dashboard que les
conteneurs de ce microservice s'exécutent dans des objets kubernetes appelés pods. Le flux-
system gère l’état du cluster. Kubectl est un outil en ligne de commande qui permet de
dialoguer avec le cluster Kubernetes. Pour accéder au cluster Kubernetes, il faut disposer en
51
local d’un fichier kubeconfig qui contient des informations sur le cluster. Ainsi on peut obtenir
des informations sur le cluster comme l’ensemble des namespaces, les conteneurs en exécution
dans ces namespaces ainsi que leur état.
Figure 28 : Espaces de nom cloud-cms, cloud-dashboard et flux-system
La figure 29 montre les déploiements effectués dans le namespace cloud-dashboard.

Nous pouvons constater que le microservice a été déployé.
Figure 29 : Liste des déploiements dans le namespace cloud-dashboard

Les figures 30 et 31 représentent respectivement la liste des conteneurs cloud-dashboard
en cours d’exécution et les logs renseignant la création des conteneurs. Le nombre de répliques
spécifié dans le fichier deployment.yaml a été respecté.
Figure 30 : Conteneurs cloud-dashboard en cours d'exécution
Figure 31 : Events de création des pods
52
En outre, Flux charge bien l’image indiquée sur le fichier de déploiement mais aussi
récupère la liste des images sur le registre Docker Hub (cf. figure 32).
Figure 32 : Liste des images docker Hub
Ces conteneurs déployés sont accessibles grâce au service mis en place (cf. figure 33).
Ce service permet aux utilisateurs d'accéder aux dashboards du projet cloud-souverain, illustrés
par les figures 34 et 35.
Figure 33 : Service de cloud-dashboard
53
Figure 34 : Page d'authentification
Figure 35 : Dashboard Information sur les sites web déployés
4. Objectifs atteints au cours de ce stage
54
Les objectifs au départ de ce projet étaient d’abord de mettre en place un cloud SaaS qui
permet de déployer des sites web et de stocker des données. Ensuite, il fallait être en mesure
de distribuer facilement cette solution aux entreprises qui possèdent les infrastructures pour la
déployer et qui souhaitent l’exploiter.
Pour le premier objectif il faut donc :
 assurer le développement des microservices ;
 mettre en place les environnements de développement et de production ;
 mettre en place une chaîne d’intégration continue et de déploiement continu.
Pour le dernier point, la chaîne d’intégration continue est entièrement mise en place ;
pour la chaîne de déploiement continu la conception a été réalisée et les tests effectués. La
création des fichiers de déploiement a été également faite. Nous pourrons déclencher le
déroulement de la chaîne CD sur les environnements définitifs.
Pour le second objectif, une fois les développements finis, les techniques mises en place
lors de la création de la chaîne d’intégration continue et de déploiement continu
permettent d'obtenir des artéfacts prêts à être facilement déployés quel que soit
l’environnement. Nous pouvons donc dire que le second objectif est atteint sous réserve de la
fin des développements.
5. Apports du projet pour l’entreprise

Ce projet permet à l’entreprise de consolider sa position sur le marché du cloud en
fournissant une plateforme cloud avant-gardiste. En effet, avec ce projet l’entreprise fournit un
cloud SaaS qui permettra aux entreprises notamment sénégalaises, de pouvoir conserver en
toute simplicité leurs données dans des clouds public ou privé, gérés par elles-mêmes d’où le
nom du projet : cloud-souverain.
D’autre part, il lui permet de répondre rapidement aux besoins des utilisateurs grâce
notamment à l’implémentation de la chaîne CI/CD.
55
Ce chapitre nous a permis de présenter la réalisation de la chaîne CI/CD à l’aide de

captures. Il nous a également permis de déterminer les objectifs atteints ainsi que l’impact de
cette réalisation pour l’entreprise.
56
CONCLUSION
Dans le cadre d’un stage de fin d’études effectué au sein de l’entreprise BeOpenIT, nous
avions comme tâche la « mise en place d’un cloud-souverain : implémentation de la chaîne
CI/CD. »
Le premier objectif était de mettre en place une plateforme SaaS qui permet de créer et
de déployer facilement des sites web avec le CMS WordPress, et des bases de données de type
MySql. Cet objectif implique d’assurer les développements d’une telle plateforme ainsi que
son déploiement dans un environnement cloud.
Ensuite le second objectif était d'assurer la portabilité de cette plateforme SaaS pour
qu’elle puisse être distribuée aux entreprises qui souhaitent la déployer.
C’est dans le souci de remplir l'objectif du déploiement continu de la plateforme par

l'implémentation d’une chaîne CI/CD et d’assurer la portabilité de la plateforme que notre
stage de fin de cycle a eu lieu.
Pour atteindre ces objectifs, nous avons combiné l’agilité avec la méthode SCRUM et le
DevOps comme méthodes de développement du projet.
En nous basant sur l’analyse des besoins fonctionnels effectuée dans le chapitre 2 nous
avions pu dégager deux tâches majeures à réaliser :
 mettre en œuvre l'intégration continue (CI) ;
 mettre en place la chaîne de déploiement continu (CD).
En somme, la mise en œuvre de la chaîne CI/CD a été faite. L'automatisation des

déploiements est cependant en attente de la fin des développements. Ainsi, nous comptons pour
la suite continuer les développements de la plateforme SaaS et enfin appliquer le pipeline CD.
Une autre perspective serait d’étendre le catalogue des bases de données et CMS proposé
en intégrant les bases de données de type PostgreSql et le CMS Drupal.
57
BIBLIOGRAPHIE
[1] « Quelle est la différence entre le cloud computing et la virtualisation ? »

https://www.redhat.com/fr/topics/cloud-computing/cloud-vs-virtualization (consulté le juin
22, 2020).
[2] ec2lt, « Virtualisation et Cloud ». https://www.ec2lt.sn/?page_id=93 (consulté

le juin 22, 2020).
[3] « UML : Recherche et analyse des besoins | SUPINFO, École Supérieure

d’Informatique ». https://www.supinfo.com/articles/single/6549-uml-recherche-analyse-
besoins (consulté le mai 19, 2020).
[4] maxibou, « exigence non-fonctionnelle », Affaires et TI.

https://maxibou.wordpress.com/tag/exigence-non-fonctionnelle/ (consulté le mai 19, 2020).
[5] « La Haute Disponibilité | SUPINFO, École Supérieure d’Informatique ».

https://www.supinfo.com/articles/single/1083-haute-disponibilite (consulté le juin 02, 2020).
[6] « Les différents types de diagrammes », OpenClassrooms.

https://openclassrooms.com/fr/courses/2035826-debutez-lanalyse-logicielle-avec-
uml/2048781-les-differents-types-de-diagrammes (consulté le juin 22, 2020).
58
ANNEXES
Annexe : Implémentation de la chaîne CI du microservice cloud-CMS.

Le serveur SonarQube utilise le fichier sonar-project.properties pour déterminer les paramètres
d’analyse du code.
Pour effectuer les tests, le build et la conteneurisation des microservices développés avec
Jhipster, un Makefile a été défini. Ce Makefile sera utilisé dans le Jenkinsfile pour connaître
les étapes du pipeline à suivre.
59
Jenkins va exécuter ce Makefile grâce au Jenkinsfile. Le Jenkinsfile est subdivisé en étapes
appelée «stage».
60
61

V - F-Mémoire de Fin de Cycle DIC3-Justine - Faye - AS

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

V - F-Mémoire de Fin de Cycle DIC3-Justine - Faye - AS

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DU SENEGAL

UNIVERSITE CHEIKH ANTA DIOP DE DAKAR

ECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENT GENIE INFORMATIQUE

MEMOIRE DE FIN DE CYCLE

Mise en place d’un cloud souverain :

Lieu de stage : BeOpenIT Période stage : 02/2020 – 06/2020

Présenté et soutenu par Professeur encadrant Maître de stage

Année universitaire : 2019 – 2020

UNIVERSITE CHEIKH ANTA DIOP DE DAKAR

ECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENT GENIE INFORMATIQUE

MEMOIRE DE FIN DE CYCLE

Mise en place d’un cloud souverain :

Lieu de stage : BeOpenIT Période stage : 02/2020 – 06/2020

Présenté et soutenu par Professeur encadrant Maître de stage

Année universitaire : 2019 – 2020

Je rends grâce à Dieu qui m’a permis de réaliser ce travail.

 Ma Famille, ma plus grande motivation dans la vie. Je dédie spécialement ce

J’adresse mes remerciements les plus chaleureux à :

 Pr Ibrahima Fall, chef du Département Génie Informatique et également

Je tiens spécialement à remercier :

 L’ensemble du personnel de BeOpenIT pour leur esprit de partage qui a

L’Ecole Supérieure Polytechnique de Dakar (ESP) est un établissement public de

Elle dispense un enseignement supérieur en vue de préparer aux fonctions

Ce stage permet à l’étudiant :

 de renforcer son savoir et surtout d’acquérir un savoir-faire, tout en essayant

Ce document est un mémoire de fin d’études pour l’obtention du Diplôme d’Ingénieur

Mot clés : Cloud, DevOps, CI/CD.

Keywords: Cloud, DevOps, CI/CD.

SIGLES ET ABREVIATIONS ........................................................................................ x

TABLE DES FIGURES .................................................................................................. xi

TABLE DES TABLEAUX .......................................................................................... xiii

CHAPITRE 1 : PRESENTATIONS GENERALES ................................................... 2

1. Présentation de la structure d’accueil .................................................................. 2

1.1. Contexte de création ..................................................................................... 2

1.2. Présentation de BeOpenIT ............................................................................ 3

1.3. Innovation et partenaires .............................................................................. 3

1.4. Organisation de l’entreprise.......................................................................... 4

2. Présentation du cadre du projet ............................................................................ 5

2.1. Contexte ........................................................................................................ 5

2.2. Problématique ............................................................................................... 6

2.4. Méthode de développement du projet .......................................................... 7

2.4.1. Caractéristiques du projet ........................................................................ 7

2.4.2. Présentation des méthodes de développement du projet ......................... 7

a) L’approche agile SCRUM ......................................................................... 8

CHAPITRE 2 : ANALYSE DES BESOINS ............................................................. 13

1. Généralités sur le cloud .......................................................................................... 13

1.1. La virtualisation et le cloud ....................................................................... 13

1.2. Caractéristiques du cloud............................................................................ 14

1.4. Modèles de déploiement du cloud .............................................................. 16

2. Spécifications et Analyse des besoins du système ............................................. 17

2.1. Spécifications des besoins du système ....................................................... 17

2.1.1. Les acteurs ............................................................................................. 17

2.1.2. Les besoins non fonctionnels ................................................................. 17

2.1.3. Les besoins fonctionnels ........................................................................ 18

2.2. Analyse du système .................................................................................... 18

CHAPITRE 3 : CONCEPTION DE LA SOLUTION .............................................. 24

1. Proposition d’une chaîne d’intégration continue et de déploiement continu ..... 24

1.1. Technologies et des outils utilisés .............................................................. 25

1.1.1. Outils de l’intégration continue ............................................................. 25

a) Gestion des sources de code .................................................................... 26

b) Serveur d’intégration continue ................................................................ 26