République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National de Licence Appliquée en Sciences et Technologies

Spécialité : Administration des Systèmes et Réseaux

Par

Jarraya Ahmed

Mise en place d’une plateforme CICD

Encadrant professionnel : Essaies Meriem Ingénieure R&D

Encadrant académique : Ben Rejeb Sonia Maître Assistante

Réalisé au sein de Ooredoo Tunisie

Année Universitaire 2020 - 2021

 République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National de Licence Appliquée en Sciences et Technologies

Spécialité : Administration des Systèmes et Réseaux

Par

Jarraya Ahmed

Mise en place d’une plateforme CICD

Encadrant professionnel : Madame Essaies Meriem Ingénieure R&D

Encadrant académique : Madame Ben Rejeb Sonia Maître Assistante

Réalisé au sein de Ooredoo Tunisie

Année Universitaire 2020 - 2021

J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.

Encadrant professionnel, Madame Essaies Meriem

Signature et cachet

J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.

Encadrant académique, Madame Ben Rejeb Sonia

Signature
Dédicaces

J’ai le grand plaisir de dédier ce travail à :

Mes chers parents pour leur soutien,leur patience, leur encouragement durant mon parcours
scolaire. Aucun hommage ne pourrait être a la hauteur de l’amour dont ils ne cessent de me
combler. Que dieu leur procure bonne santé et longue vie.

Madame Essaies Meriam, Madame Ben Rejeb Sonia pour m’avoir encadré et fait de
leurs mieux afin de m’aider.

Toute ma famille et mes amis,source d’espoir et de motivation.

A tous ceux qui de près ou de loin m’ont soutenu

Jarraya Ahmed

ii
Table des matières

Introduction générale 1

1 Contexte général du projet 2

1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Étude et critique de l’éxistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Étude bibliographique (sur un thème précis) . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Solution proposée et objectifs globaux du projet . . . . . . . . . . . . . . . . . . . . . 4
1.6 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Etat de l’art 5
2.1 Intégration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Livraison continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Déploiment continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Elements clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 Conteneur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.2 Pod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.3 Playbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Etude comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5.1 Livraison continue VS Déploiment continue . . . . . . . . . . . . . . . . . . . 7
2.5.2 Outils d’intégration continue Jenkins vs Circle CI vs Travis CI . . . . . . . . 8
2.5.3 Virtualisation : Machine virtuelle vs Docker . . . . . . . . . . . . . . . . . . . 9
2.5.4 Outil d’autmaisation de déploiment . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.5 Plateforme d’orchestration de conteneurs : Kubernetes VS Docker Swarm . . 10
2.6 Synthèse et choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Spécification des besoins et conception 11

3.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Spécification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 13

iii
 3.2.2 Spécification des besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . 13
3.3 Représentation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Réalisation 16
4.1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Environement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1 besoins en machines virtuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Mise en place d’infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1 Mise en place du Cluster k8s . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.2 Mise en place d’un serveur d’intégration Jenkins . . . . . . . . . . . . . . . . 18
4.3.3 Mise en place d’Ansible pour l’automatisation du déploiment . . . . . . . . . 18
4.4 Mise en place du Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.1 création d’un Dockerfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.2 création des fichier de configuration de kubernetes . . . . . . . . . . . . . . . 19
4.4.3 configuration des playbooks Ansible . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.4 création des credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.5 création du script de la pipeline . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Planning réel du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Conclusion générale 21

Bibliographie 22

Annexes 23
Annexe 1. Exemple d’annexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Annexe 2. Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iv
Table des figures

1.1 Logo Entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Figure illustrant la différence entre déploiment et livraison continue . . . . . . . . . . 8

2.2 Machine virtuelle VS Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Figure illustrant le diagramme de cas d’utilisation générale de notre système . . . . . 14

4.1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Dockerfile de notre application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 example d’un fichier de configuration YAML de type deployment . . . . . . . . . . . 19
4.4 Exemple d’une playbook Ansible utilisée pour exécuter l’objet deployment . . . . . . 20

Annexe 2.1 Logo d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

v
Liste des tableaux

1.1 Tableau long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Tableau comparatif entre Chef Puppet et Ansible . . . . . . . . . . . . . . . . . . . . 10

2.2 Gitlab CI/CD declarations table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Annexe 1.1 Exemple tableau dans l’annexe . . . . . . . . . . . . . . . . . . . . . . . . . . 23

vi
Liste des abréviations

— GISI = Génie Informatique des Systèmes Industriels

— GLSI = Génie Logiciel et Systèmes d’Information

— GTR = Génie des Télécommunications et Réseaux

vii
Introduction générale

Habituellement la mise en production d’une application est l’étape ultime d’un processus bien
élaboré faisant intervenir, assez souvent, des équipes différentes, à savoir l’équipe de développement
et celle d’operations. Ainsi, le développement, le test et la mise en production sont assez souvent
considères comme trois étapes distinctes.
Faire intervenir autant d’équipes peut mener à des conflits tant le but de chaque équipe
est différent de l’autre. Quand les développeurs souhaitent innover et faire évoluer les applications
en ajoutant de nouveaux fonctionnalités, l’équipe d’opérations cherche, avant tout, à garantir la
stabilité du système informatique. D’ailleurs, chacun suit ses processus, et travaille avec ses propres
outils qui d’une maniére isolée aux autres. En conséquence, les relations entre ces équipes peuvent
être conflictuelles, ces conflits génèrent des retards de livraison par suite des coûts supplémentaires
pour l’entreprise qui n’ont pas été prévu au départ, avec un impact sur le client dont la satisfaction
est au centre des préoccupations de l’entreprise.
Mettre en place une approche permettant l’unification de processus de dévelepomment et
celle de production devient donc une tâche évidente afin d’éviter les problèmes précédemment cités.
De ce fait, la notion de DevOps est née. Il s’agit d’une approche qui se base sur la communication
et la collaboration entre les équipes chargées du développement et des opérations comme son nom
l’indique, sur un objectif commun c’est de garantir une livraison rapide et efficace avec un minimum
de retard possible afin d’augmenter la productivité et d’optimiser la satisfaction client .

1
 Chapitre 1

Contexte général du projet

Plan
1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Étude et critique de l’éxistant . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

4 Étude bibliographique (sur un thème précis) . . . . . . . . . . . . . . . . 3

5 Solution proposée et objectifs globaux du projet . . . . . . . . . . . . . 4

6 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Chapitre 1. Contexte général du projet

Introduction

Text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text,
text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text, text,
text, text...

1.1 Organisme d’accueil [1]

La figure 4.4 présente le logo de la tunisie télécom. (Il est déconseiller de mettre le logo de la
société dans le rapport, il est déjà présent dans la page de garde).

Figure 1.1: Logo Entreprise

1.2 Étude et critique de l’éxistant

1.3 Problématique

1.4 Étude bibliographique (sur un thème précis)

Le tableau 1.1 présente un exemple d’un tableau qui peut être divisé automatiquement dans
les pages.

Tableau 1.1: Tableau long

0 0

1 1

2 2

3
Chapitre 1. Contexte général du projet

3 3

4 4

5 5

6 6

7 7

8 8

9 9

10 10

11 11

12 12

1.5 Solution proposée et objectifs globaux du projet

1.6 Choix méthodologique

Conclusion

Conclusion partielle ayant pour objectif de synthétiser le chapitre et d’annoncer le chapitre

suivant.

4
 Chapitre 2

Etat de l’art

Plan
1 Intégration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Livraison continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Déploiment continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Elements clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5 Etude comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

6 Synthèse et choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Chapitre 2. Etat de l’art

Introduction

Dans ce chapitre, nous commençons par définir les notion d’intégration,livraison et déploiment
continue continu, ensuite, nous exposons quelques éléments clés avant d’entammer une étude comparative.
Enfin, nous faisons la synthèse de nos choix technologiques

2.1 Intégration continue

L’intégration continue peut se définir comme etant un ensemble de pratiques en génie logiciel
qui consistent à intégrer les changements apportés au code informatique d’un projet logiciel de
façon continuelle, afin de détecter et de corriger immédiatement les éventuelles erreurs. La phase
d’integration contient generalement :
- une phase de construction dans laquelle le code est compilé dans un exécutable ou package.
- Une phase de test ou une suite de tests automatisés sont executés
- Une phase d’archivage ou le code est versionné et stocké afin qu’il puisse être distribué

2.2 Livraison continue

La livraison continue est une pratique DevOps consistant à développer, à tester et à délivrer
des améliorations au code d’un logiciel ou aux environnements utilisateurs à l’aide d’outils automatisés.
Les équipes de développement produisent et testent le code par cycles courts. De cette façon, le code
est toujours dans un état déployable. Ainsi, même si la version en cours de développement d’un
logiciel doit être déployée soudainement, ce n’est pas un problème avec cette approche. L’objectif
est également de raccourcir la « feedback loop » pour améliorer la qualité du logiciel. Le code
est régulièrement délivré à l’environnement de test ce qui permet de rendre les causes et les effets
observables. Toutes les fonctionnalités du code peuvent être testées, ce qui permet de réduire les
problèmes de performances inattendus une fois en production.

2.3 Déploiment continue

Le déploiement continu est une stratégie de développement logiciel où toute validation de

code qui réussit le cycle de test automatisé est automatiquement transférée dans l’environnement de
production, propulsant ainsi les modifications vers les utilisateurs du logiciel. En cas de déploiement
continu, aucune intervention humaine n’empêche le transfert d’un code non éprouvé dans un logiciel

6
Chapitre 2. Etat de l’art

en production. On ne doit y avoir recours que lorsque les équipes de développement et informatique
respectent scrupuleusement les pratiques de développement dévolues à une mise en production et
des procédures de test rigoureuses. Il convient aussi de prévoir un suivi sophistiqué en temps réel en
production afin de détecter au plus tôt les problèmes éventuels que poseraient les nouvelles versions.

2.4 Elements clés

2.4.1 Conteneur

Un conteneur est un processus ou un ensemble de processus isolés du reste du système. Tous

les fichiers nécessaires à leur exécution sont fournis par une image distincte, ce qui signifie que les
conteneurs Linux sont portables et fonctionnent de la même manière dans les environnements de
développement, de test et de production.

2.4.2 Pod

Un Pod est l’objet Kubernetes qui représente un groupe d’un ou plusieurs conteneurs. Les
pods sont l’unité fondamentale de tous les objets Kubernetes supérieurs. Il peut être créé à l’aide de
la commande kubectl et un fichier YAML / JSON representant ces caractéristiques notamment son
nom et l’image a utiliser .

2.4.3 Playbook

Un Playbook est un fichier YAML dans lesquels sont mentionnés toutes les tâches qu’Ansible
doit exécuter : de la configuration de l’environnement informatique de production jusqu’à l’orchestration
de toutes les étapes de déploiement d’une application ou d’une mise à jour sur celui-ci.

2.5 Etude comparative

2.5.1 Livraison continue VS Déploiment continue

La livraison et le déploiement continus font ensemble partie de ce que l’on appelle le développement
logiciel continu, et sont souvent associés aux méthodologies Agile et DevOps. La livraison continue et
le déploiement continu sont directement dérivés de l’intégration continue. Le déploiement continu se
distingue de la livraison continue, bien que la confusion règne entre ces deux concepts, d’autant plus
que ces deux termes partagent le même acronyme en anglais (CD). On parle de livraison continue

7
Chapitre 2. Etat de l’art

lorsque les développeurs livrent souvent et de manière régulière du nouveau code à tester aux équipes
de l’assurance qualité et de l’exploitation. Cette démarche suppose généralement un environnement
de test semblable à l’environnement de production et implique souvent un laps de temps entre la
publication et le moment où une version est testée, où les modifications sont manuellement acceptées
et où le nouveau code est mis en production. À l’inverse, le déploiement continu ne nécessite aucune
évaluation ni vérification manuelles des changements de code dans l’environnement de test, puisque
les tests automatisés sont intégrés très tôt dans le processus de développement et se poursuivent tout
au long des phases du lancement. Le déploiement continu présente un avantage certain : l’absence
d’attente entre la réussite des tests d’un changement de code aux niveaux de l’application et de la
plateforme et sa mise en production.

Figure 2.1: Figure illustrant la différence entre déploiment et livraison continue

2.5.2 Outils d’intégration continue Jenkins vs Circle CI vs Travis CI

Le deploiment d’applications lors d’avoir plusieurs environnement de de deploiments peut

s’avérer une tâche fastidieuse répétitive et sujette aux erreurs de manipulation. L’apparrition d’outils
tel que Chef Puppet, SaltStack Ansible a eté largement attendu. Grace a ces outils il n’est plus
necessaire de configure machine individuellement. Il siffut simplement d’executer un script et indiquer
les ips ou les noms des machines cibles. Ici nous dressons un tableau comparatif entre ces quatres
outils de configuration basé sur plusieurs criteres.

8
Chapitre 2. Etat de l’art

2.5.3 Virtualisation : Machine virtuelle vs Docker

Au lieu d’utiliser une machine physique ou un serveur, maintenant avec la virtualisation, nous
pouvons utiliser une seule machine et créer plusieurs VM ou machines virtuelles. Celles-ci peuvent
en utilisant une couche d’abstraction / couche de virtualisation appelée «Hypervisor» Une machine
virtuelle nous procure plusieurs avantages tel que la minimisation du cout de materiel,l’economisation
d’energie malgré cela il ya quelques limites a citer tel que la nécessité d’un système d’xploitation
(OS) pour chaque machine.Celui ci a sa propre durcharge de calcul et stockage. Une nécessité de
maintenance et mise a jour est primordiale pour chaque machine virtuelle D’où vient la notion des
conteneurs qui partagent qui sont plus flexibles et evolutifs de maniére synchrone Avec les machines
virtuelles, On exécute essentiellement une pile d’exploitation entière dans une machine virtuelle. Le
système d’exploitation hôte sert simplement de base à l’exécution des machines virtuelles. Tout ce
qui se trouve à l’intérieur des machines virtuelles est configuré individuellement pour les applications
qu’on y exécute. Les conteneurs, quant à eux, partagent le système d’exploitation et le noyau
sous-jacents. Cela signifie qu’un seul environnement peut alimenter plusieurs conteneurs plus efficacement.
Considérez les conteneurs comme une méthode de virtualisation au niveau du processus (ou de
l’application).

Figure 2.2: Machine virtuelle VS Docker

9
Chapitre 2. Etat de l’art

2.5.4 Outil d’autmaisation de déploiment

Tableau 2.1: Tableau comparatif entre Chef Puppet et Ansible

Chef Puppet Ansible Saltstack

Architecture Serveur/Client Serveur/Client Seulement Client Serveur/Client

Langage Procédurale Déclarative Procédurale Déclarative

Scalabilité Scalable Scalable Scalable Scalable

Communication Outil Knife SSL SSH SSH

2.5.5 Plateforme d’orchestration de conteneurs : Kubernetes VS Docker

Swarm

Kubernetes et Docker Swarm sont tous deux des solutions efficaces pour la gestion et le
déploiement d’application a grande échelle. Les deux modèles divisent les applications en conteneurs,
permettant une automatisation efficace de la gestion et de la mise à l’échelle des applications. Voici
un résumé général de leurs différences

Tableau 2.2: Gitlab CI/CD declarations table

Kubernetes Docker Swarm

Installation Installation complexe Installation facile

Puissance et complexité Trés puissant et complexe a apprendre Léger et facile a utiliser

Scalabilité Auto-scalabilité Manuelle

Besoin d’un CLI posséde sa propre CLI Integre la meme CLI que celle de docker

2.6 Synthèse et choix

Conclusion

u cours de ce chapitre, nous avons définit l’intégration continue et le déploiement continu,

nous avons aussi présenté quelques éléments clés. Nous avons, par la suite, fait une étude comparative
sur les outils qui peuvent répondre à notre besoin et enfin, nous avons fait la synthèse de nos choix
technologique. Le prochain chapitre portera sur l’analyse et spécifications.

10
 Chapitre 3

Spécification des besoins et

conception

Plan
1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Représentation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Chapitre 3. Spécification des besoins et conception

Introduction

Dans ce chapitre, nous nous intéressons aux fonctionnalités que notre système doit satisfaire.
Pour cela nous commençons ce chapitre par une identification des acteurs de notre système. Ensuite,
nous entamons nos spécification des besoins pour clôturer avec une représentation de ces besoins de
notre a l’aide des digrammes UML.

3.1 Identification des acteurs

Pour notre système, nous avons identifié 4 acteurs

- Développerur c’est le premier acteur,c’est celui qui va déclancher la pipeline en déposant
du code.il peut aussi bien suivre son état si elle est russie ou non.
- Responsible DevOps c’est l’acteur principal qui sera responsable de la mise en place de
l’infrastructure CICD y comris le cluster Kubernetes ainsi que la création de la pipeline CI/CD et
son optimisation.
- Le client qui c’est l’acteur finale c’est lui va accéder à l’application à travers son son son
service
- Administrateur du cluster c’est celui qui est responsible a la surveillance de l’état du cluster
et des pods après la phase de la déploiment. Notre système inclut aussi certains composants comme
étant des acteurs :
- Git : c’est une gestionnaire de versions de code, il permet de stocker le code et de l’exposer
aux différents développeurs
- Jenkins : c’est un orchestrateur et un outil important dans notre pipeline, il permet de
déclencher des builds
Docker registry : c’est un composant qui permet le stockage des images docker et leur
récupération
- Ansible : c’est l’outil utilisé dans notre système afin d’automatiser le déploiment

3.2 Spécification des besoins

Dans cette partie, nous commençons par la spécification des besoins fondamentaux à travers la
partie besoins fonctionnels ensuite nous entamons une partie concernant les besoins non fonctionnels
à considérer pour notre système.

12
Chapitre 3. Spécification des besoins et conception

3.2.1 Spécification des besoins fonctionnels

— Le système permet le déclenchement de la pipeline en exposant un code.

— Le système permet au Responsable DevOps de créer un script Jenkins qui décrit toutes
les étapes de la pipeline.
— Le système permet a Jenkins de faire la construction du code a travers l’outil Maven et
en fessant référence a un fichier pom.xml.
— Le système permet de faire l’analyse des vulnérabilités du code grâce a Sonnarqube.
— Le système permet a Jenkins de créer une image Docker du code construit a l’aide d’un
Dockerfile écrit par le développeur.
— Le système permet a Jenkins d’envoyer l’image créée vers un Docker Registry spécifié dans
la pipeline.
— Le système permet de faire notifier le développeur en envoyant un e-mail dans le cas d’un
échoue dans l’une des phases du Pipeline.
- Le système permet a Ansible d’automatiser le déploiement d’application en exécutant des
playbooks.
— Le système permet au client d’accéder à l’application via son service configuré a travers
un fichier YAML.
— Le système permet a l’administrateur du Cluster de suivre l’état d’application a travers
ces pods.
- Le système permet a l’administrateur de surveiller l’état du Cluster.

3.2.2 Spécification des besoins non fonctionnels

Par conjonction aux besoins fonctionnels précédemment cités, notre système doit respecter
un nombre de critères donnant une meilleure qualité de la solution obtenue. Parmi ces critères nous
citons
— Performance : le temps d’exécution des différentes étapes de la pipeline doit être minimal.
— Extensibilité : le système doit pouvoir supporter l’évolution et l’extensibilité de ses composants,nous
pouvons ainsi ajouter autant un nœud à notre Cluster Kubernetes ou bien un serveur tel que Tomcat
pour le dépôt des artefacts.

13
Chapitre 3. Spécification des besoins et conception

3.3 Représentation des besoins

3.3.1 Diagrammes de cas d’utilisation

Au niveau de cette partie nous nous intéressons a la traduction des besoins précédemment
dégagés sous forme de diagrammes de cas d’utilisation.
Le diagramme de cas d’utilisation général, nous permet d’exposer de façon semi-formelle les
principales fonctionnalités auxquels le système doit répondre.En effet nous avons identifié différents
sous système pour le pipeline, à savoir :
- intégration continue
- Déploiement continue
- Pré-configuration
- Configuration du pipeline

Figure 3.1: Figure illustrant le diagramme de cas d’utilisation générale de notre système

14
Chapitre 3. Spécification des besoins et conception

3.3.2 Diagrammes de séquence

Conclusion

Conclusion partielle ayant pour objectif de synthétiser le chapitre et d’annoncer le chapitre

suivant.

15
 Chapitre 4

Réalisation

Plan
1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Environement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Mise en place d’infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Mise en place du Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Planning réel du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Chapitre 4. Réalisation

Introduction

Après avoir traité la partie conceptuelle, nous entamons la partie réalisation de notre projet
Cette partie sera compose de 3 parties Mise en place de l’infrastructure , préparation des fichirs
nécessaires utilisés mbaad fel pipeline, enfin mise en place de la pipeline où nous présentons l’environnement
matériel de notre travail différentes technologies utilisées pour la mise en place de notre système.

4.1 Architecture de la solution

Pour la mise en place de notre solution nous avons utilisé Vmware ESXI comme etant

Figure 4.1: Architecture de la solution

4.2 Environement de travail

Pour la mise en place de notre solution nous avons utilisé Vmware ESXI comme etant

17
Chapitre 4. Réalisation

4.2.1 besoins en machines virtuelles

4.3 Mise en place d’infrastructure

4.3.1 Mise en place du Cluster k8s

Pour la mise en place du cluster kubernets, nous avons opté a la creation d’un multi noeuds
cluster avec un noeud maître(Master) et deux noedus de travail (Workers)

4.3.1.1 Roles composants de chaque noeud dans un cluster Kubernetes

- Le noeud maitre : C’est le noeud qui contrôle et gère un ensemble de nœuds de travail
(runtime de charges de travail) pour clea il est composé de plusieurs composants :
- Kube-APIserver : C’est le point d’entrée au cluster. Toutes les communications externes
avec le cluster se font via le serveur API.
- Kube-Controller-Manager : Il exécute un ensemble de contrôleurs pour le cluster en cours
d’exécution. Le contrôleur-gestionnaire met en œuvre la gouvernance à travers le cluster.
-ETCD : C’est la base de données d’état du cluster
-KubeScheduler :C’est lui qui planifie les activités sur les nœuds de travail en fonction des
événements survenant sur etcd. Il contient également le plan de ressources des nœuds pour déterminer
l’action appropriée pour l’événement déclenché. Par exemple, le planificateur déterminerait quel
nœud de travail hébergera un pod nouvellement planifié.

4.3.2 Mise en place d’un serveur d’intégration Jenkins

4.3.3 Mise en place d’Ansible pour l’automatisation du déploiment

4.4 Mise en place du Pipeline

4.4.1 création d’un Dockerfile

Il s’agit de la recette pour la construction d’une image Docker. Pour notre cas notre image
sera basé sur un serveur Tomcat dans lequel on va copier les fichiers WAR de notre application.

18
Chapitre 4. Réalisation

Figure 4.2: Dockerfile de notre application

4.4.2 création des fichier de configuration de kubernetes

Ils s’agissent des fichiers de configuration écrites avec le langage YAML utilisés pour le
deploiments des differentes objets kubernetes tel que les objets de type service aussi bien de type
pod et deployment.

Figure 4.3: example d’un fichier de configuration YAML de type deployment

4.4.3 configuration des playbooks Ansible

Ils s’agissant des fichiers écrites avec la langage YAML,ils seront utilisés pour exécuter les
fichiers de configuration de Kubernetes par suite le deploiment de nos objets dans notre environnement
cible qui est la machine master de notre cluster Kubernetes

19
Chapitre 4. Réalisation

Figure 4.4: Exemple d’une playbook Ansible utilisée pour exécuter l’objet deployment

4.4.4 création des credentials

4.4.5 création du script de la pipeline

4.5 Planning réel du projet

Conclusion

Conclusion partielle ayant pour objectif de synthétiser le chapitre et d’annoncer le chapitre

suivant.

20
Conclusion générale

Rappel du contexte et de la problématique.

Brève récapitulation du travail réalisé et de la soultion proposée.

La taille de la conclusion doit être réduite, une page de texte tout au plus. Il est important
de souligner que la conclusion ne comporte pas de nouveaux résultats ni de nouvelles interprétations.

Le plus souvent, la conclusion comporte :

• un résumé très rapide du corps du texte ;

• un rappel des objectifs du projet ;

• un bilan professionnel qui indique clairement les objectifs annoncés dans l’introduction et en
particulier ceux qui n’ont pu être atteints. Il présente et synthétise les conclusions partielles ;

• un bilan personnel qui décrit les principales leçons que vous tirez de cette expérience sur le
plan humain ;

• les limites et les perspectives du travail effectué.

21
Bibliographie

[1] M. Shell. (Jan. 2007). « IEEEtran Homepage. » [Accès le 5-Février-2016], adresse : http :
//www.michaelshell.org/tex/ieeetran/.

22
Annexes

Annexe 1. Exemple d’annexe

Les chapitres doivent présenter l’essentiel du travail. Certaines informations-trop détaillées

ou constituant un complément d’information pour toute personne qui désire mieux comprendre ou
refaire une expérience décrite dans le document- peuvent être mises au niveau des annexes. Les
annexes, placées après la bibliographie, doivent donc être numérotées avec des titres (Annexe1,
Annexe2, etc.).
Le tableau annexe 1.1 présente un exemple d’un tableau dans l’annexe.
Tableau annexe 1.1 : Exemple tableau dans l’annexe

0 0

1 1

2 2

3 3

4 4

23
Annexes

Annexe 2. Entreprise

La figure annexe 2.1 présente le logo entreprise.

Figure annexe 2.1 : Logo d’entreprise

24
 PÌl›
‰Rw§ ...An¡ Tyr`˜ TŒl˜A Plm˜ ‰Rw§ ...An¡ Tyr`˜ TŒl˜A Plm˜ ‰Rw§ ...An¡ Tyr`˜ TŒl˜A Plm˜ ‰Rw§
‰Rw§ ...rWF
rK`˜ ¤d ¨  wk§  
ºAr˜ ...An¡ Tyr`˜ TŒl˜A Plm˜ ‰Rw§ ...An¡ Tyr`˜ TŒl˜A Plm˜
 
ºAr˜ ...An¡ Tyr`˜ TŒl˜A Plm˜ ‰Rw§ ...rWF
rK`˜ ¤d ¨  wk§  
ºAr˜ ...An¡ Tyr`˜ TŒl˜A Plm˜
‰Rw§ ...rWF
rK`˜ ¤d ¨  wk§  
ºAr˜ ...An¡ Tyr`˜ TŒl˜A Plm˜ ‰Rw§ ...rWF
rK`˜ ¤d ¨  wk§
 
ºAr˜ ...An¡ Tyr`˜ TŒl˜A Plm˜ ‰Rw§ ...rWF
rK`˜ ¤d ¨  wk§  
ºAr˜ ...An¡ Tyr`˜ TŒl˜A Plm˜
–nkm§ ...rWF
rK`˜ ¤d ¨  wk§  
ºAr˜ ...An¡ Tyr`˜ TŒl˜A Plm˜ ‰Rw§ ...rWF
rK`˜ ¤d ¨  wk§
...An¡ Tyr`˜ TŒl˜A Plm˜ ‰Rw§ Exemple ici šA› Plm˜ XF¤ ¨ Tyny¯ ‘¤r Aml• tk  

Aml• Hm˜ E¤A dˆ ºAr˜ : yAf› Aml•

Résumé
Mettez le resumé en français ici... Mettez le resumé en français ici... Mettez le resumé en français
ici... Mettez le resumé en français ici... Merci de ne pas dépasser les dix lignes. Mettez le resumé
en français ici, merci de ne pas dépasser les dix lignes. Mettez le resumé en français ici, merci de
ne pas dépasser les dix lignes. Mettez le resumé en français ici, merci de ne pas dépasser les dix
lignes. Mettez le resumé en français ici, merci de ne pas dépasser les dix lignes. Mettez le resumé
en français ici, merci de ne pas dépasser les dix lignes. Mettez le resumé en français ici, merci de
ne pas dépasser les dix lignes. Mettez le resumé en français ici, merci de ne pas dépasser les dix
lignes. Mettez le resumé en français ici, merci de ne pas dépasser les dix lignes.

Mots clés : Merci de ne pas dépasser les cinq mots

Abstract
Put the English abstract here, put the English abstract here, put the English abstract here, put
the English abstract here, put the English abstract here, put the English abstract here... Please
don’t exceed ten lines, Please don’t exceed ten lines, Please don’t exceed ten lines, Please don’t
exceed ten lines. Put the English abstract here, please don’t exceed ten lines. Put the English
abstract here, please don’t exceed ten lines. Put the English abstract here, please don’t exceed
ten lines. Put the English abstract here, please don’t exceed ten lines. Put the English abstract
here, please don’t exceed ten lines. Put the English abstract here, please don’t exceed ten lines.
Put the English abstract here, please don’t exceed ten lines. Put the English abstract here,
please don’t exceed ten lines.

Keywords : Please don’t use more than five keywords

contact@company.com : ¨ž¤rtk˜¯ d§rb˜ 71 222 222 : H•Af˜ 71 111 111 : Ah˜ Hžw - ­ryb˜ ‘AfR -   C®› ­ry hž
Rue du Lac Malaren, Les Berges du Lac 1053 Tunis Tél : 71 111 111 Fax : 71 222 222 Email : contact@company.com
isi@isim.rnu.tn : ¨ž¤rtk˜¯ d§rb˜ 71 706 698 : H•Af˜ 71 706 164 : Ah˜ TžA§C
2080 ¨ž¤CAb˜  A§r˜ w
hž 2
2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : isi@isim.rnu.tn