TouziInesDEVOPSPFE2020 V1.6

République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Sousse
Institut Supérieur d’Informatique et des Techniques de

Communication de Hammam Sousse
Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du
Diplôme National d’Ingénieur

Spécialité : Téléinformatique
Par
Inès TOUZI
Mise en place d’une solution DevOps

d’automatisation de l’infrastructure des
applications RIF
Encadrant académique : Mr. Bayram Triki Maître assistant

Encadrant professionnel : Mr. Abdelhamid Azaiez Ingénieur R&D
Responsables du projet : Mr. Ramzi Dridi Directeur technique
Mr. Taoufik keskes Directeur R&D
Réalisé au sein de la société RIF
Année Universitaire 2019 - 2020

République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Sousse
Institut Supérieur d’Informatique et des Techniques de

Communication de Hammam Sousse
Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du
Diplôme National d’Ingénieur

Spécialité : Téléinformatique
Par
Inès TOUZI
Mise en place d’une solution DevOps

d’automatisation de l’infrastructure des
applications RIF
Encadrant académique : Mr. Bayram Triki Maître assistant

Encadrant professionnel : Mr. Abdelhamid Azaiez Ingénieur R&D
Responsables du projet : Mr. Ramzi Dridi Directeur technique
Mr. Taoufik keskes Directeur R&D
Réalisé sein de la société RIF
Année Universitaire 2019 - 2020

J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.
Encadrant académique, Mr. Bayram Triki
Signature
J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.
Directeur technique de RIF , Mr. Ramzi Dridi
Signature et cachet
Dédicaces
De plus profond de mon cœur, je dédie ce travail
A mon très cher père Hédi

A ma fabuleuse mère Sihem,
A qui je dois tout,
Pour tout le bonheur qu’ils m’apportent par leur soutien moral,
matériel et affectif.
Pour leur encouragement durant mes études et tout au long de la
réalisation de ce travail.
Qu’ils trouvent avec ce travail l’expression de ma sincère gratitude
et mon affectation.
Que dieu, le tout puissant, leurs protège et leurs procure santé et
longue vie.
A Ma sœur Sirine et son époux Hamed

A Mon frère Aymen et son épouse Meriem,
A Mon frère Marwen

Je leur souhaite tout le succès et le bonheur du monde.
A mes adorables amis que je considère ma deuxième famille, Amina, Eya,

Wissal, Abir, Fatma, Asma, Rihab, Souha, Cyrine, Maha, Achraf,
Slah, Ali,Wael, Zoubayer, Rami et Hatem

pour les encouragements et les conseils qu’ils n’ont cessé de me prodiguer,
Qu’ils trouvent avec ce travail l’expression de ma sincère gratitude
Votre fidèle Inès
ii
Remerciements
Au terme de ce travail modeste, je tiens à exprimer toute ma gratitude et mes vifs remerciements
à:
Mr. Abdelhamid Azaiez, mon encadreur technique, pour sa rigueur dans le travail, pour
l’effort qu’il a fourni, son expérience qu’il m’a fait partager et ses conseils avisés qui m’ont permis
de progresser sans cesse durant ces quatres mois de stage ainsi que pour le temps qu’il m’a consacré
tout au long de cette période.
Mr. Bayram Triki, maître assistant à l’Institut Supérieur d’Informatique et des Techniques
de Communication de Hammam Sousse, pour sa confiance, son effort et son soutien qu’il a accordé
à ce Projet et pour avoir accepté de m’encadrer avec tant d’amabilité et dévouement.
L’équipe de RIF, plus particulièrement Mr. Taoufik Keskes et Mr. Ramzi Dridi qui
m’ont accueilli d’une manière ci chaleureuse et également pour leurs conseils judicieux et leurs
suggestions pertinentes ainsi à Mr Riath Lahmar pour sa disponibilité et sa rigoureusité au travail
Aux membres de jury pour avoir accepté d’évaluer mon travail.
Et à Tous ceux qui m’ont fait honneur d’être présent le jour de ma soutenance.
Veuillez tous trouver le témoignage de mes sincères reconnaissances et de mes profonds respects.
iii
Table des matières
Introduction générale 1
1 Cadre générale du projet 3

1.1 Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 La société RIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Organisation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Produits et services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Présentation du contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Problématique du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Approche de gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Artéfacts de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.3 Différents rôles du Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Planification du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.1 Outil de gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.2 Découpage du projet en Releases et Sprints . . . . . . . . . . . . . . . . . . . 9
2 État de l’art 11
2.1 Présentation du DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Définition du devops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2 Avantages du DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3 Cycle de vie de Devops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Présentation du Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Introduction au Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Services du Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.3 Modèles de déploiement Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Étude comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Cloud à choisir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
iv
2.3.2 Outil de création de diagramme . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 Outil CI/CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.4 Infrastructure en tant que code . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.5 Virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.6 Orchestration des contenaires . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.7 Kops vs Kubespray vs Kubeadm . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Synthèse des choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 RELEASE 1 : Automatisation de l’infrastructure de kubernetes 28

3.1 Planification de la première Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Conception de la première Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Sprint1 : Conception de l’architecture technique . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.2 Analyse Conceptuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Sprint2 : Création du cluster de kubernetes en local . . . . . . . . . . . . . . . . . . . 32
3.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.3 Réalisation de la création du cluster kubernetes . . . . . . . . . . . . . . . . . 34
3.5 Sprint3 : Mise en place de l’infrastructure sur le Cloud . . . . . . . . . . . . . . . . . 36
3.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.3 Réalisation de la mise en place de l’infrastructure manuellement . . . . . . . . 37
3.6 Sprint4 : Automatisation de la création de l’infrastructure . . . . . . . . . . . . . . . 42
3.6.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.6.3 Réalisation de la création du cluster des applications . . . . . . . . . . . . . . 43
3.6.4 Réalisation de l’automatisation du cluster (Version2) . . . . . . . . . . . . . . 45
3.6.5 Réalisation de création de l’infrastructure du Cluster des outils . . . . . . . . 46
4 RELEASE 2 : Conteneurisations et orchestrations 48

4.1 Planification de la deuxiemme Release . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Conception de la deuxiemme Release . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
v
4.3 Sprint5 : Déploiement des applications sur le cluster des apps . . . . . . . . . . . . . 50
4.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.2 Analyse Conceptuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.3 Réalisation de déploiement de Odoo . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 Sprint6 : Déploiement de Gitlab sur le cluster des outils. . . . . . . . . . . . . . . . . 54
4.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.2 Analyse Conceptuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.3 Réalisation du déploiement de notre application Gitlab . . . . . . . . . . . . . 56
4.5 Sprint7 : Préparation des images Docker . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.3 Réalisation de la préparation des images docker . . . . . . . . . . . . . . . . . 61
Conclusion générale 64
Biblioographie 65
Webographie 66
vi
Table des figures
1.1 Logo de RIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Organigramme de RIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Processus Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Logo JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Découpage de projet en Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Valeur ajouté de l’agilité dans le processus du DevOps . . . . . . . . . . . . . . . . . 13

2.2 Cycle de vie de devops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Principaux axes du Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Modèles de déploiements du Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Architecture de kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6 Différents objets de kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Diagramme de Cas d’Utilisation de Release 1 . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Architecture Cible de l’Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Architecture de kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Diagramme de séquence du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 Création du cluster kubernetes avec kubeadm . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Capture du fichier Vagrantfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7 Capture du répertoire de la création du cluster avec kubeadm . . . . . . . . . . . . . 36
3.9 Création Manuelle VPC et subnet sur le GCP . . . . . . . . . . . . . . . . . . . . . . 38
3.10 Création Manuelle d’une machine sur le GCP . . . . . . . . . . . . . . . . . . . . . . 39
3.11 Reservation Manuelle ip statique sur le GCP . . . . . . . . . . . . . . . . . . . . . . . 40
3.12 Mise en place du cluster kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.13 Installation Manuelle de Kubespray . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.14 Mise en place du cluster kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.15 Automatisation de la Mise en place de l’architecture . . . . . . . . . . . . . . . . . . 43
3.16 Création VPC et subnets automatisé sur le GCP . . . . . . . . . . . . . . . . . . . . 44
3.17 Réservation automatisé de ip statique sur le GCP . . . . . . . . . . . . . . . . . . . . 44
vii
3.18 Provisionement des instances du cluster application sur le GCP . . . . . . . . . . . . 44
3.19 Template script de démarrage de la machine bastion . . . . . . . . . . . . . . . . . . 45
3.20 Plugin template ajouté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.21 Répertoire des fichiers de provisionnement de l’infrastructure . . . . . . . . . . . . . 46
3.22 Provisionnement des instances du projet . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.23 Réservation des adresses statiques pour les machines bastion . . . . . . . . . . . . . . 47
4.1 Diagramme de Cas d’Utilisation de Release 2 . . . . . . . . . . . . . . . . . . . . . . 50

4.2 Déploiement de l’application avec kubernetes . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Consulter les services de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 Consulter les déploiements de odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.5 Consulter les volumes persistant de odoo . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6 Page d’acceuil de odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7 Étude conceptuelle de déploiement de Gitlab avec kubernetes . . . . . . . . . . . . . 55
4.8 RBAC du déploiement gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.9 Répertoire projet de déploiement de gitlab . . . . . . . . . . . . . . . . . . . . . . . . 56
4.10 Les déploiements de gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.11 Ingress de gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.12 Volumes associé au déploiement gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.13 Page d’acceuil de gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.14 Runners partagés de notre Gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.15 Diagramme de cas d’utilisation du sprint 7 . . . . . . . . . . . . . . . . . . . . . . . . 60
4.17 Architecture de Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.18 Service Account pour accéder au container registry de Gitlab . . . . . . . . . . . . . 62
4.19 Résultat du pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.20 Résultat d’ajout dans le registre de conteneurs de GCP . . . . . . . . . . . . . . . . . 63
viii
Liste des tableaux
1.1 Tableau des rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Découpage du projet en Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Étude comparative du modèle de déploiement . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Étude comparative entre AWS, AZURE et GCP . . . . . . . . . . . . . . . . . . . . 18
2.3 Étude comparative des outils de créations de diagrammes . . . . . . . . . . . . . . . 19
2.4 Étude comparative des outils de CI/CD . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Étude comparative des IaaC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6 Étude comparative d’outil de virtualisation . . . . . . . . . . . . . . . . . . . . . . . 22
2.7 Tableau de synthèses de choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8 Étude comparative d’outil d’automatisation de kubernetes . . . . . . . . . . . . . . . 26
2.9 Tableau de synthèses des choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1 Apercu des spints de la release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 Apercu des spints de la release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
ix
Liste des abréviations
RIF RASSEMBLEMENT DES INGÉNIEURS FRANCOPHONES
CI Intégration Continue (en anglais Continuous Integration)
CD Déploiement Continue (en anglais Continuous Deployment)
OS Système d’exploitation ( en anglais Operating System)
PV Volume persistant(en anglais Persistent Volume)
PVC demande de volume persistant (en anglais Persistent Volume Claim)
RBAC Contrôle d’accès basé sur les rôles ( en anglais Roles Based Access Control)
GCP Plate-forme de Google Cloud ( en anglais Google Cloud Platform)
GCR Registre des conteneurs de Google ( en anglais Google Container Registry)
GCS Conteneur de Stockage de Google ( en anglais Google Container Storage)
IaaS Infrastructure En Tant que Code ( en anglais Infrastructure as a Service)
PaaS Plate-forme En Tant que Code ( en anglais Platform as a Service)
SaaS Logiciel En Tant que Service ( en anglais Software as a Service)
IaC Infrastructure En Tant que Code ( en anglais Infrastructure as Code)
K8s Kubernetes( en anglais Kubernetes)
SSH shell sécurisé ( en anglais Secure Shell)
UI Interface Utilisateur( en anglais User Interface)
SA Compte de Service( en anglais Service Account)
x
Introduction générale
Dans un contexte de compétitivité accrues, les entreprises IT ne cessent pas d’innover et

mettre en œuvre leurs stratégies de transformation digitale afin d’améliorer leurs performances et
efficacités, s’imposer et s’octroyer d‘une part de marché. En fait, les entreprises doivent adopter des
processus et des démarches plus agiles et alignés aux besoins de leurs clients, tout en adoptant des
modèles économiques plus souple. Les développements réalisés doivent répondre aux spécifications
exigées et déployer d’une façon plus rapide sur les différents environnements des clients, tout en
assurant une assurance de la qualité des livraisons.
Par ailleurs, la préparation de l’environnement de déploiement, quoiqu’elle soit une tâche

répétitive, la diversité des technologies et la complexité de l’infrastructure des clients, représentent
des grands challenges qui consomment un temps assez important lors des déploiements chez les
clients. Par conséquent, il fallait réfléchir à digitaliser ces processus internes et mettre en place un
dispositif unifié permettant d’automatiser ...
Consciente de l’importance de l’automatisation pour remédier à ces challenges et optimiser

l’efficience de ses processus internes de développement, l’entreprise « RASSEMBLEMENT DES
INGÉNIEURS FRANCOPHONES » (désignée ci-après RIF) a pris la décision d’élaborer une automatisation
totale de son infrastructure ainsi du déploiement de ces applications.
Notre projet de fin d’études consiste, donc, à concevoir et à mettre en place une solution
permettant l’automatisation de la création et de la gestion des infrastructures des applications
critiques de la société RIF et d’optimiser le cycle de vie des projets IT tout en assurant une meilleure
qualité et en respectant les délais prédéfinis.
Dans un premier chapitre, nous situons notre projet dans son cadre général et nous présentons la
méthodologie de gestion de projet adopté tout le long de notre projet de fin d’études.
Dans un second chapitre, nous introduisons les divers concepts adoptés et nous présenterons la
démarche d’évaluation et de sélection des principaux composants de l’architecture technique de la
solution d’automatisation.
Dans un troisième chapitre, nous procéderons à la conception et à l’implémentation d’un premier
1
Introduction générale
prototype de la solution permettant l’automatisation de la création de l’infrastructure.
Enfin, dans un quatrième chapitre, nous avons illustré les travaux réalisés pour améliorer la
solution permettant ainsi la livraison et le déploiement des applications critiques de la société RIF
d’une façon plus agile.
2
Chapitre 1
Cadre générale du projet
Plan
1 Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Présentation du contexte du projet . . . . . . . . . . . . . . . . . . . . . 5
3 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Planification du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapitre 1. Cadre générale du projet
Introduction
Dans ce chapitre, nous nous entamerons, tout d’abord, par définir le cadre général de notre
projet. Il s’agit en effet de présenter l’organisme d’accueil. Nous abordons par la suite l’existant
et les enjeux de l’entreprise dans le but de dévoiler les objectifs de notre travail. Nous décrirons,
enfin, la méthode adoptée et la démarche à établir lors de ce projet en jetant un coup d’œil sur la
planification du projet correspondant.
1.1 Présentation de l’entreprise
1.1.1 La société RIF
RIF [1] est une société spécialisée dans le domaine informatique. L’équipe RIF est responsable
de la conception, de la mise en œuvre et de la production de nombreuses applications d’IA et de big
data. Après son succès en France, l’équipe du RIF a décidé d’ouvrir une agence en Tunisie, qui a
pour objectif de former des ingénieurs tunisiens à leurs futures carrières et de rejoindre leur équipe
de France.
Figure 1.1: Logo de RIF
1.1.2 Organisation de l’entreprise
La figure suivante présente l’organigramme de la société afin de découvrir les différents services
qu’elle offre.
4
Figure 1.2: Organigramme de RIF
1.1.3 Produits et services
RIF a développé un portefeuille complet de solutions de connectivité, principalement basées

sur le concept, la conception et la programmation d’applications innovantes basées sur les microservices,
l’IA et le Bigdata. En effet, la plupart des applications développées autour de l’IA s’appuient sur des
outils innovants (frameworks et API) créés par les principaux acteurs du digitale : GAFA, comme
Tensor Flow, kera, KAFKA, microservices de construction, écosystème Hadoop et écosystème Spark.
1.2 Présentation du contexte du projet
1.2.1 Problématique du projet
Les progrès technologiques ont facilité énormément l’automatisation de la livraison des applications
et de l’infrastructure. L’utilisation de l’automatisation ne peut qu’aider le mouvement DevOps a se
développer. En effet, le DevOps est consacrer à la gestion des communications critiques, des processus
et des défis humains dans le développement et dans l’opération.
Depuis longtemps, la recompilation du code dans un environnement différent conduirait à
des résultats de build différents et causerait de nombreux problèmes dans les environnements futurs.
De la même manière, les sociétés sont de plus en plus conscients que le manque d’uniformité dans le
déploiement dans divers environnements est également source de grandes difficultés et défis. Donc,
Le déploiement de l’application et l’automatisation de l’installation et des paramètres système peut
garantir la cohérence à tous les niveaux.
De plus, l’automatisation réduit le temps de réalisation des déploiements. Elle améliore aussi
5
la qualité des produits fournis vu que la machine ne fait pas des erreurs et n’oublie jamais d’exécuter
des commandes.
Le déploiement ne se fait pas par un simple copie des fichiers. Toutefois, il faut une modification
dans l’infrastructure pour prendre en charge de nouvelles fonctionnalités. Pour fixer ça, il faut
effectuer des configurations manuelles routines et compliquées.
C’est dans ce cadre que la société RIF se propose d’intégrer les différentes fonctions d’automatisation
de l’infrastructure et du lancement d’applications afin de bénéficier des avantage de la culture de
DevOps.
1.2.2 Objectifs du projet
Dans le cadre de mon projet de fin d’études, nous allons essayer de résoudre les constatations
citées par les solutions adéquates. RIF a besoin de créer sa propre architecture pour faire le déploiement
de ces applications développées. Cette architecture doit être automatisée et extensible et prête
pour faire le déploiement des applications. Nous allons tout d’abord assurer le déploiement d’une
application Odoo de RIF.
• La conception de notre architecture dont nous allons déployer notre application Odoo.
• La mise en place de notre architecture selon une étude comparatives des outils à utiliser
• L’automatisation de notre infrastructure en utilisant les outils DevOps nécessaires.
• Le déploiement de l’application Odoo sur l’infrastructure crée
• Le déploiement de l’application Gitlab notre sur l’infrastructure crée
• Un pipeline de test de l’application choisie en utilisant Gitlab
1.3 Méthodologie de travail
Pour réussir la réalisation de notre projet, RIF adopte une méthodologie idéale qui aidera à
réaliser ce projet dans les meilleurs conditions.
1.3.1 Approche de gestion de projet
Agile est un mode de gestion de projet qui permet de :
• solider la communication entre le client, les développeurs, les utilisateurs et toute autre professionnels
du projet.
6
• Répondre au different changement plutôt que de suivre un plan déterminer au préalable.
• Délivrer des logiciels fonctionnels au lieu de fournir une documentation complète.
RIF a penché l’approche Agile grâce à sa souplesse en cours de réalisation, sa facilité de

modération des plans et sa rapidité de livraison. En effet, nous préférons toujours de donner la
priorité à la communication étendue et à la négociation sur le processus de développement.
Scrum possède primordialement la capacité de diriger la réalisation au cours de son avancement
pour toujours être convenable avec les attentes des clients. La méthode Scrum concentre d’une
manière itérative sur les fonctionnalités à effectuer. Dans un premier lieu, le projet sera divisé en
modules fonctionnels. Ensuite, chacun de ces modules contient des sprints. Et chacun de ces sprints a
pour but d’achever un but à partir duquel sont choisies les fonctionnalités à implémenter durant cette
phase. Cette méthode se fonde sur le principe de l’apprentissage continue des erreurs commises. En
effet, le début est toujours accompagné par un manque d’information et de connaissances. Mais cela
renforcera l’équipe et donnera la possibilité d’apprendre tout au long du processus de développement.
Le schéma 1.3 résume le cycle de vie de la méthode de Scrum :
Figure 1.3: Processus Scrum
La liste des tâches prioritaires est appelée Product Backlog. Pour chaque sprint, nous allons
prendre une partie des tâches du Product Backlog. La liste des tâches d’un sprint sont appelées
Sprint Backlog. Ensuite, l’équipe communique la manière avec laquel elle va réaliser ces tâches. Pour
réaliser ce sprint dans les durées fixées, l’équipe planifie des Daily Work chaque jour. Chaque sprint
possède une durée qui s’appelle Sprint Duration et qui peut être entre deux a quatre semaines.
Au début du Sprint suivant, Nous prendrons une nouvelle liste depuis la liste de Product
7
Backlog et nous ferons une répétition en boucle jusqu’à ce que la liste des tâches du Product Backlog
est terminé ou bien jusqu’a ce que le budget est insuffisant ou même la date limite est atteinte.
1.3.2 Artéfacts de Scrum
Les artéfacts[2] sont des outils faite pour résoudre des problèmes. Le scrum possède trois
principaux classiques artéfacts : le backlog de produit, le backlog de sprint et un incrément pour
présenter l’état “Done”.
• Le product backlog : Il est produit par le product owner ou product manager. C’est une
liste dynamique de fonctionnalités, améliorations ou même des correctifs. . .
• Le sprint backlog : Ce sont des éléments, des “users stories” et même des “bug fixes” qui ont
été sélectionnés au démarrage du sprint. Ils répondent aux objectifs du sprint correspondant.
Ils peuvent être modifiés et sont flexibles durant le sprint.
• L’incrément : Représente la liste des éléments avec le statut “Done” du sprint "In progress"
et même de ceux précédents.
1.3.3 Différents rôles du Scrum
Il existe quatre principaux rôles fondamentaux lorsqu’il s’agit du scrum :
• Le Product Owner : Il doit comprendre les attentes du client et du marché, puis il essaye
de répartir le travail d’une façon équilibré entre les membres de l’équipe.
• Le Scrum Master : C’est celui qui dirige, suveille le flux et maintient l’équipe en pleine
concentration sur les objectifs fixés.
• L’Équipe de Développement : Ce sont ceux qui exécutent le travail et doivent l’accomplir

dans les délais bien déterminés. Ils sont généralement de cinq à sept membres.
• L’équipe de DevOps : C’est elle qui a pour rôle principal l’automatisation de toute tâche
manuelle.
Avant de clôturer cette partie, nous allons définir les membres de notre équipe Scrum. Cette
répartition est utile pour clarifier le rôle de chacun de nous.
8
Tableau 1.1: Tableau des rôles

Product Owner Scrum Master Équipe de DevOps
Dridi Ramzi + Keskes Azaiez Abdelhamid Touzi Inès
Taoufik
1.4 Planification du Projet
1.4.1 Outil de gestion de projet
RIF utilise le JIRA pour faire la gestion de ces projet. En fait, JIRA est un produit atlassian
dédié à la gestion d’un projet de développement d’applications. JIRA nous permet de créer des
tableaux de bord Scrum, tracer une vue d’ensemble du projet, travailler sur des templettes personnalisé
selon le besoin et beaucoup d’autres fonctionnalités.
Figure 1.4: Logo JIRA
1.4.2 Découpage du projet en Releases et Sprints
Nous avons essayé d’organiser notre Backlog qui contient plusieurs user stories selon les
fonctionnalités de notre projet. On peux répartir notre projet sous forme de deux releases de la
maniere suivante :
Tableau 1.2: Découpage du projet en Releases
Release Titre Release Description Durée
1 Automatisation et Dans cette release, nous allons avoir notre 6 semaines
mise en place de infrastructure automatisé et prête pour le
l’infrastructure dépliement de nos applications
2 Conteneurisation et Déploiements des applications sur les clusters et 10 semaines
Orchestration des mise en place de la chaine CI de l’application
applications sur notre
infrastructure
Un sprint désigne un travail qui doit être accompli dans une durée bien définie par le scrum
master. Nous allons définir les sprints correspondants à chaque release dans la partie qui suit en
utilisant JIRA :
9
Figure 1.5: Découpage de projet en Sprints
Conclusion
Ce premier chapitre présente l’étape préliminaire du cadre générale de notre projet. Il comprend
deux parties principales : la présentation de la société accueillante et la description du projet.
En outre, suite à la démarche fixée, nous commençons, dans le chapitre suivant, par une étude
comparative afin de bien se préparer pour la mise en place de l’infrastructure.
10
Chapitre 2
État de l’art
Plan
1 Présentation du DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Présentation du Cloud Computing . . . . . . . . . . . . . . . . . . . . . . 15
3 Étude comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Synthèse des choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Chapitre 2. État de l’art
Introduction
Dans ce chapitre, nous allons expliquer les notions de base qui tracent le thème du DevOps.
Ensuite, nous allons parler du domaine de Cloud Computing pour expliquer quelques termes que
nous allons affronter toute au long de notre rapport. Après, nous allons parler des principaux notions
fondamentales de kubernetes. Après avoir comprendre ces concepts de bases, nous allons aborder la
phase de l’étude comparative tout en justifiant chacun de nos choix. Nous finissons ce chapitre avec
une synthèse qui résume tous les choix que nous avons adoptés.
2.1 Présentation du DevOps
2.1.1 Définition du devops
Le concept de DevOps représente la collaboration et la fusion entre l’équipe de développement

(Dev) et l’équipe d’opérations (Ops) dans le but de tester, acheminer et déployer les logiciels avec
plus de fiabilité et plus de rapidité selon le besoin des clients. Le DevOps est l’automatisation du
processus de livraison de logiciels et les mise à jour d’infrastructure effectué selon le besoin. Le
DevOps donc est une culture, un mouvement, une philosophie.
2.1.2 Avantages du DevOps
Le DevOps possède plusieurs avantages [3] . Ce sont ces avantages qui laissent la plupart des
sociétés dans la prise de décision de changer et adapter le DevOps comme approche de travail. Le
DevOps permet de :
• Rendre le cycle de vie plus court et plus rapide : Le DevOps possède de multiple
différents outils facilitant l’intégration des différentes nouvelles fonctionnalités. Ces fonctionnalités
joue un rôle important pour assurer les mises à jour nécessaires et sécurisées.
• Le gain du temps et la diminution des erreurs : Rendre le développement plus rapide

et diminution des erreurs. En introduisant le DevOps, l’automatisation des tests de code source
diminue les travaux manuels. Ce qui nous rend plus concentré sur les tâches qui ne sont pas
automatisées.
• Diminuer les coûts : Les bénéfices du DevOps englobent la réduction du besoin des
personnelles informatiques. Nous allons avoir plus de membres disponibles et nous pouvons les
attachés à d’autres projets.
12
L’agilité est une approche qui enrichis la culture de DevOps. En effet, l’Agilité et le DevOps
ne sont pas là pour choisir un entre eux. Ce sont deux structures permettant de rendre notre livraison
de logiciels plus rapide. Nous ne sommes pas obligés de choisir entre ces deux approches, mais plutôt
se bénéficier de leur combinaison. L’approche agile organise la méthodologie de travail. Par contre,
le DevOps est une culture assez grande de livraison rapide et fiable des logiciels dans les délais fixés.
Donc, nous allons essayer de créer un environnement qui prendra la combinaison du bénéfice du
DevOps et de l’agilité. La figure 2.1 montre la relation entre l’agilité et le DevOps :
Figure 2.1: Valeur ajouté de l’agilité dans le processus du DevOps
2.1.3 Cycle de vie de Devops
Nous pouvons jamais parler du cycle de vie du DevOps [4] sans dévoiler ces deux principales
chaînes : la première est la chaîne d’intégration continue et la seconde est du déploiement continu.
La figure 2.2 présente les différentes étapes que nous allons rencontrer pour assurer l’automatisation
complète d’un cycle de vie des applications.
13
Figure 2.2: Cycle de vie de devops
2.1.3.1 Intégration continue CI
Dans un premier lieu, le cycle de vie de DevOps commence par une planification de ce que
nous allons faire. Cette planification se fait en utilisant des tableaux de bord ou tableau de tâches
agile. Une fois que la phase de planification est établie, nous allons passer à l’étape de codage dont les
développeurs vont répondre aux besoins fonctionnels en codant les attentes de leurs clients. Après,
le code source doit être préparé pour le build. Dans cette phase, nous allons faire le build de notre
solution avec un pipeline qui va cloner le code source et le compile pour avoir un artefact. Arrivant
à ce stage-là, la chaîne d’intégration est bien établie. D’où, l’intégration continue est un ensemble
des étapes permettant à un développeur d’intégrer le code source d’un projet sous un répertoire
partagé. Nous pouvons assurer cette intégration en utilisant des outils comme Gitlab et Jenkins. Ces
outils nous permettent de vérifier chaque intégration effectuée. Cela nous aidera à localiser l’erreur
rapidement à chaque modification effectuée.
14
2.1.3.2 Déploiement continue CD
La deuxième chaîne consiste à assurer le déploiement continu. À partir du release obtenue,

nous allons faire le déploiement de notre application. Cette étape englobe le déploiement de l’infrastructure,
et même le déploiement des applications souhaitées. Le déploiement continue est un ensemble des
étapes rendant le déploiement automatisé. Il suffit de vérifier que les changements effectués sont bien
stables et correcte comme prévue. Un succées de cette vérification conduit à déploiement automatisé
sur notre infrastructure. Une fois le déploiement est assuré, le travail n’est pas encore fini. Il faut se
concentrer sur la phase de surveillance continue. Cette phase est très bénéfique pour voir si notre
infrastructure et nos applications sont en bon état ou non. La chaîne se boucle encore pour refaire
la planification des tâches qui reste encore dans notre backlog jusqu’à ce que notre backlog est vide
de nouvelles fonctionnalité. Une fois que le cycle de vie est automatisé en utilisant le bon outil
de CI/CD, nous n’allons plus exécuter des tâches manuelles répétitives, mais nous allons plutôt se
focaliser sur les tâches qui peuvent être automatisées. En résumé, le but de DevOps est toujours
d’automatiser les choses dans le bon sens.
2.2 Présentation du Cloud Computing
2.2.1 Introduction au Cloud Computing
Le cloud computing [5] est un ensemble de services informatiques à la demande. Ces services
incluent de différents outils et applications comme les données de stockage, serveurs, bases de
données, réseaux et logiciels. Un des principaux concepts de base du cloud est de payer au fur
et à mesure de ce qu’on utilise.
Grâce au cloud computing, nous n’avons plus besoin d’installer chaque logiciel en local sur
chaque poste. Mais, nous intégrons les fonctionnalités nécessaires pour la société et nous allons les
mettre toutes en ligne ou sur un serveur interne.
Lorsque nous parlons du Cloud Computing, nous parlons de deux axes principaux : les services
du cloud offerts et les modèles de déploiements à utilisé. Le schéma 2.3 représente les axes que nous
allons étudier dans la prochaine section
15
Figure 2.3: Principaux axes du Cloud Computing
2.2.2 Services du Cloud
Le cloud computing nous fournit plusieurs types de services [6] , mais ce sont les plus
importants :
• Infrastructure as a Service (IaaS) : une informatique prête, provisionnée et gérée sur Internet.
Dans ce cas, le cloud va gérer l’infrastructure.
• Platform as a Service (PaaS) : un modèle de cloud computing dans lequel un fournisseur fournit
des outils matériels et logiciels aux utilisateurs sur Internet.
• Software as a Service (SaaS) : un moyen de fournir des applications hébergées de manière

centralisée sur Internet en tant que service. Dans ce cas, tout est bien géré par votre cloud.
La figure 2.4 résume ce que nous avons expliqué dans la partie précédente :
Figure 2.4: Modèles de déploiements du Cloud
16
2.2.3 Modèles de déploiement Cloud
Nous pouvons distinguer trois principaux modèles de déploiement Cloud [6] :
• Cloud Publique : Toute l’infrastructure est servie par un cloud computing.
• Cloud Privé : (appelé aussi cloud dédié ) toute l’infrastructure est géré par l’entreprise en
d’autres termes, ce type de cloud présente une infrastructure qui nous est totalement dédiée.
Ce cloud est généralement utilisé pour sa Haute sécurité.
• Cloud Hybride : il combine son utilisation entre un cloud privé et un cloud public selon son
besoin et selon la priorité de la sécurité qu’il doit avoir.
2.3 Étude comparative
Durant ce stage, nous étions chanceux puisque nous avons les permissions de faire une
étude comparative et choisir entre les outils ceux qui conviennent le mieux à notre besoin. Aucune
contrainte n’a été exigée et tout choix est accompagné par sa justification. Dans cette section, nous
essayerons de citer les différents axes de comparaison et choisir l’outil qui répondra mieux à notre
besoin.
Dans un premier lieu, nous allons choisir quel outil de création de diagrammes pour tracer notre
architecture correspondante. Ensuite, nous allons choisir le cloud sur lequel nous allons créer notre
infrastructure. Puis, nous abordons la partie du choix de l’outil qui va automatiser la création de
notre architecture. Dans un deuxième lieu, nous allons penser à ce que nous devons fixer notre choix
de virtualisation. Selon le choix de virtualisation, nous allons dévoiler l’outil d’orchestration. Après,
un outil d’automatisation pour l’orchestrateur est évident pour réussir à achever notre besoin dans
les délais fixés.
Une fois que nous avons mis en place correctement notre architecture, nous allons fixer l’outil
d’automatisation du cycle de vie des applications qui sera l’outil pour assurer l’intégration continue
et le déploiement continue.
17
2.3.1 Cloud à choisir
2.3.1.1 Modèle de déploiement de Cloud à utiliser
nous devons tout d’abord choisir quel modèle de Cloud [7]nous allons utiliser. Voilà, selon
nos recherches, les résultats que nous avons trouvés :
Tableau 2.1: Étude comparative du modèle de déploiement

Critères de Cloud Privé Cloud Publique
comparaison
Infrastructure Adéquate au besoin. Pas necessairement
adéquate au besoin.
Mise en place Une mise en place lente Une mise en place
et coûteuse. rapide et non coûteuse.
Monté en charge N’est pas pertinant. Pertinant
Puisque RIF est une nouvelle entreprise qui est en train de s’élever, nous avons préféré de
travailler avec un cloud public. En effet, la mise en place d’un cloud privé exige beaucoup des coûts
et prendra beaucoup de temps. Pourtant, pour un cloud public, nous aurons une mise en place rapide
et pas tellement coûteuse par rapport à celle du cloud privé. Même en cas de monter en charge, le
cloud public sera meilleur qu’un cloud privé. D’où le Cloud Public est suffisant pour atteindre nos
objectifs.
2.3.1.2 Le quel à choisir selon le type
Les leaders dans le marché de nos jours sont : le AWS, le GCP et l’Azure. C’est pour cela,
nous avons décidé de comparer seulement ces 3 plus populaires. [8].
Tableau 2.2: Étude comparative entre AWS, AZURE et GCP

Points de AWS AZURE GCP
comparaison
Interface interface lisible et interface compliquée interface simple et
utilisateur pratique lisible
Sécurité bonne sécurité bonne sécurité plusieurs nouvelles
fonctionnalités pour
intégrer plus de sécurité.
Nous avons conclu à partir d’une recherche étendue que chacun de ces providers possède les
mêmes services mais avec des noms différents et des prix différents mais qui ne sont pas trop loin.
Tout d’abord, l’interface de GCP est simple. Nous ne devons pas faire plusieurs cliques pour venir
à des tâches assez simples.
18
Ensuite, la migration d’une VM qui marche déjà d’un serveur physique vers un autre est très
transparente.
Un des plus forts arguments pour considérer le choix de GCP est la sécurité qu’il maintient. En effet ;
les données entre Google, les clients et les centres de données est totalement cryptés au cours du
transfert. GCP prend ces données et les met dans les disques persistants et cryptées. Après, chaque
clé de cryptage est crypté encore une autrefois.
En plus, les couches de l’application Google et de la pile de stockage obligent le fait que les demandes
venant d’autres composants soient autorisées. Ajoutant le fait que Google entretient beaucoup des
relations avec certains des plus grands fournisseurs d’accès Internet au monde. Ceci améliore la
sécurité de nos données.
2.3.2 Outil de création de diagramme
Nous devons choisir un outil pour la création de diagrammes. En effet, c’est toujours plus
lisible et plus simple de présenter les choses complexes avec une visualisation. C’est grâce aux
diagrammes que nous mémorisons des détails. Nous avons choisi de comparer trois des outils de
créations des diagrammes les plus utilisés de nos jours Draw.io, Diagrams As Code et Gliffy
Tableau 2.3: Étude comparative des outils de créations de diagrammes

Critères de Draw.io Diagrams As Code Gliffy
comparaisons
Gratuit Oui Oui Oui
Travail Oui Non Non
collaboratif
Utilisation Glisser et déposer Programmation python Glisser et déposer
Rapidité de Non Oui Non
création des
tâches répétitifs
Nous cherchons toujours à contrôler tout aspect de cycle de vie des applications par plusieurs
approches : Approche de documentation, provisionnement d’infrastructure, automatisation de déploiement,
intégration continue ...
Diagrams as a Code est un outil d’automatisation qui nous permet de créer nos propres diagrammes
avec un simple code python. Nous avons trouvé cet outil assez utile et facile à utiliser. Il supporte
plusieurs providers : AWS, Azure, gcp, Kubernetes, Oracle Cloud . . .
Il supporte même des langages de programmation et des frameworks. C’est pour cela, nous allons
utiliser Diagrams As Code.
19
2.3.3 Outil CI/CD
2.3.3.1 Comparaisons des outils CI/CD
Un outil qui assure l’intégration continue et le déploiement continue est nécessaire pour
assurer l’automatisation du cycle de vies des applications. Le cycle de vie d’une application doit être
rapide et court. Ceci met les équipes à utiliser ces outils d’automatisation de CI/CD qui aideront à
livrer nos solutions dans les plus court délais.
Tableau 2.4: Étude comparative des outils de CI/CD

Critères de JENKINS CIRCLE CI GITLAB
comparaisons
Open source Oui Non Oui
License Gratuit Payante Gratuit mais il y a une
version payante
Pipeline Groovy Yaml Yaml
Supervision Non Non Oui
(monitoring)
Container Non Non Oui
Registry
Cloud Native Oui Oui Oui
Comme outil pour intégration continue et déploiement continue, nous utiliserons GITLAB
grâce à sa disposition de plusieurs fonctionnalités que JENKINS et TRAVIS CI. En effet, GITLAB
est Open source. La version gratuite de GITLAB est suffisante. Puis, GITLAB possède son propre
registry ce qui nous résolu le probleme de registry interne où nous devons stocker nos images docker.
2.3.3.2 Présentation de la solution choisie
Gitlab présente une des solution collaborative. Elle englobe plusieurs fonctionnalités de
DevOps. En utilisant Gitlab, nous pouvons gérer nos différentes versions de codes. GitLab CI/CD
[9] permet de faire l’automatisation de nos builds, tests, et même nos déploiements. Il faut tout
d’abord définir un pipeline dans laquelle nous allons mettre des tâches. Ces tâches peuvent même
être écartées en des étapes. Chacune de nos tâches est lancée avec un runneur.
2.3.4 Infrastructure en tant que code
Une des primordiales tâches en DevOps est de faire l’automatisation de la configuration et le

provisionnement d’infrastructure. On essayera de présenter les plus importants outils d’automatisation
pour arriver à notre décision.
20
• Terraform : C’est un outil de provisionnement d’infrastructure créée par Hashicorp. Il nous

permet de décrire notre infrastructure en tant que code ce qui permet de décrire exactement
ce qui se passera lorsque nous exposerons notre code. Il permet d’automatiser les changements
avec une interaction humaine minimale.
• Chef : C’est un outil utilisé pour assurer la gestion de configuration. Il sert à créer des recettes
et des livres de cuisine
C’est l’un des outils de gestion de configuration les plus populaires que les organisations
utilisent dans leurs processus d’intégration et de livraison continus. Il nous permet de créer des
«recettes» et des «livres de cuisine» en utilisant son DSL basé sur Ruby. Ces recettes et livres
de recettes précisent les étapes exactes nécessaires pour obtenir la configuration souhaitée de
nos applications et utilitaires sur les serveurs existants.
• Puppet : Semblable à Chef, Puppet est un autre outil de gestion de configuration populaire
qui aide à fournir en permanence des logiciels. Grâce au DSL basé sur Ruby de Puppet, vous
pouvez définir l’état final souhaité de votre infrastructure et exactement ce que vous voulez
qu’elle fasse.
• Ansible : C’est un outil d’automatisation d’infrastructure créé par Red Hat. Ansible modélise
votre infrastructure en décrivant les relations entre vos composants et votre système, par
opposition à la gestion indépendante des systèmes. Ansible n’utilise pas d’agents et son code
est écrit en YAML sous la forme d’Ansible Playbooks, de sorte que les configurations sont très
faciles à comprendre et à déployer.
• Vagrant : Vagrant est un outil très fameux développé par Hashicorp, celui qui a developpé
Terraform. La différence entre le Terraform et le Vagrant est que Vagrant focalise sur la création
rapide des environnements qui ne necessitent pas un grands nombres de machines virtuelles.
Vagrant utilise des solutions de machines virtuelles comme Virtualbox ou bien Vmware et peut
fonctionner aussi avec les outils de configuration continue.
Il existe de nombreux outils de gestion et de provisionnement d’infrastructure. Cette fois,

nous n’allons pas choisir un seul outil. Mais nous allons choisir une combinaison d’outils selon notre
besoin et selon les points forts de chaque outil. Premièrement, nous allons utiliser vagrant pour
tous nos tests en local. En effet, Vagrant fait la provisionnement de l’infrastructure ainsi que de la
configuration.Il ne supporte pas la gestion de plusieurs machines et c’est simple à gérer.
21
Tableau 2.5: Étude comparative des IaaC

Critères de Language Sans Agent Provisionnement Gestion de
comparaisons d’infrastructure configuration
Terraform Go Oui Non
(Hashicorp)
Ansible Python Non Oui Oui
Puppet Ruby Oui Non Oui
Chef Ruby Oui Non Oui
Vagrant Ruby Oui Oui
(Hashicorp)
Ensuite, nous allons utiliser Terraform pour faire le provisionnement de notre infrastructure
sur le Cloud. Terraform est un outil assez populaire, qui possède plusieurs fonctionnalités et qui est
compatible avec plusieurs plateform.
Puis, Ansible sera le plus efficace pour toutes les configurations automatiques et surtout que
kubespray est en origine un script ansible.
2.3.5 Virtualisation
Dans cette partie , nous allons comparer les deux solutions de virtualisation les plus connues
et les plus utilisées [10]
Tableau 2.6: Étude comparative d’outil de virtualisation

Points de Machines Virtuelles Contenaires
comparaison
IsolationFournit Oui Moins importante que
celle des VMs
Virtualisation Virtualisation niveau Virtualisation de l’OS
matériel
Consommation Consomme beancoup Consommation
mémoire négligable par rapport
au VM
Utilisation systèmes Environnement isolés
d’exploitations
différents dans le
même hote
Nous pouvons remarquer que durant ce projet nous avons besoin d’une virtualisation au
niveau matériel pour créer des environnement isolés. De plus, la consommation en mémoire est
moins importante pour les contenaires que celle pour les VMs. Cette comparaison nous assure que
l’utilisation des conteneurs sera plus adapté à notre besoins vu les avantages qu’elle présente par
22
rapport à celle des machines virtuelles.
2.3.6 Orchestration des contenaires
2.3.6.1 Comparaison des solutions d’orchestration
Au cours de cette partie, nous allons focaliser sur les solutions OpenSource [11] . Kubernetes
et Docker Swarm sont les deux orchestrateurs de contenaires les plus répandus de nos jours. Ils
fournissent des fonctionnalités presque similaires. Mais il existe quelques différences entre eux qui
peuvent nous aider à choisir le mieux adapté à notre solution..
Le tableau ci-dessous illustre les principaux points de différence entre les deux :
Tableau 2.7: Tableau de synthèses de choix

Critères de comparaison kubernetes Docker Swarm
Crée par Google Docker
Interface visuelle Oui Non
Tolérances aux pannes Haute Faible
Rollback Oui Non
Mise à l’échelle Oui Non
automatique(Autoscaling)
Journalisation Oui Non
Choisir notre orchestrateur n’était pas une affaire assez inquiétant. Tout d’abord, kubernetes
est développé par Google. Vu que nous allons travailler sur le Google Cloud Platform, c’est préférable
de choisir un des produits de Google. Ensuite, Kubernetes possède une interface claire même aux
personnes non techniques. Pourtant en utilisant la Docker swarm nous devons intégrer un outil
comme Portainer.Io pour gérer l’interface utilisateur. Après, Kubernetes possède des fonctionnalités
plus riches que docker swarm. Ce qui nous mène à choisir kubernetes comme un orchestreur de nos
contenaires.
2.3.6.2 Présentation de la solution à adoptée
Un cluster kubernetes est dévisé en deux principaux partie :
— Serveur Master : Il est résponsable de la gestion du cluster. Nous lui donne les commandes
pour les executer sur les workers.
— Serveur Worker : Il héberge les conteneurs qui constitue notre application.
Un master est à son tour composé de plusieurs elements qui lui rend capable de gérer notre
cluster.
23
— kube-apiserver : C’est le premier point de contact avec le master. Il nous permet de voir
l’etat de notre cluster à travers l’interface ou bien à travers la commande kubectl.
— Etcd : Represente une base de données pour stocker les differents configuration du cluster.
— kube-controller-manager : Identifie les utilisateur de notre cluster.
— kube-scheduler : Il répartie les charge pour assurer une migration par exemple.
Passant maintenant au composant du worker, nous allons citons les plus connus :
— kubelet : C’est celui qui dialogue avec le master.
— kube-proxy : expose quelques ports pour pouvoir acceder depuis l’extérieur.
Figure 2.5: Architecture de kubernetes
2.3.6.3 Objets de kubernetes
Dans les chapitre qui suit, nous allons essayer de déployé nos applications sous formes de
conteneurs en utilisant des différents objets de kubernetes. Cela nous mène à découvrir les objets et
expliquer chacun entre eux.
24
— Pod [12] : Il n’existe pas un élément plus petit que les pods dans kubernetes. Il comporte un
ou plusieurs conteneurs.
— Déployment [13] : C’est comme une surcouche de pod. Les pods administrent les réplicas de
notre instance. Les réplicas est le faite de faire un réplication de nos conteneurs pour assurer
leur disponibilité.Ils sont responsables à ouvrir les ports supposés ouvert pour faire l’écoute,
et même responsable du point de montage des volumes attachés à nos pods.
— Service [14] : Présente une autre surcouche de pod. Il expose le port utilisé par les conteneurs
sur le port du worker correspondant.
— : Ingress [15] : C’est celui qui autorisera ou interdira l’exposition du service sur le port choisi.
La figure 2.6 explique les différents objets existant de kubernetes et leurs relations entre eux.
Figure 2.6: Différents objets de kubernetes
2.3.7 Kops vs Kubespray vs Kubeadm
Pour déployer un cluster kubernetes dans un environnement de production, les installations

gérées permettent une flexibilité et une personnalisation accrues. Il existe plusieurs outils qui facilitent
le processus de déploiement : kops, kubespray et kubeadm.
25
Tableau 2.8: Étude comparative d’outil d’automatisation de kubernetes

Critères de Kops Kubeadm kubespray
comparaison
C’est quoi Maintenu par l’équipe Fournit ’kubeadm init’ Basé sur un playbook
de kubernetes et ’kubeadm join’ ansible
Supporte AWS et GCP presque tous les clouds plusieurs clouds
et les bare metales
Provisionnement Oui Non Non
Personnalisation Un outil flexible Complexe à
personnaliser pour
les elements non
personnalisés.
Inconvéniants Pas bien développé Necessite beaucoup de Lent comme un script
configuration manuelle
RIF est en train de se développer et c’est possible qu’elle pense à faire une migration vers
un cloud privée lorsqu’elle aura les moyens. Donc, il nous faut que notre solution d’automatisation
supporte plusieurs clouds. Nous avons décider de choisir kubespray puisqu’il ne nécessite pas beaucoup
de configuration manuelles et beaucoup d’intervention. Même s’il est lent comme un script, mais le
fait qu’il est basé sur l’ansible et qu’il est facile d’intégrer les éléments personnalisés, kubespray est
notre solution d’automatisation de notre cluster kubernetes.
2.4 Synthèse des choix
Après avoir fait notre étude comparative, voila un tableau récapitulatif qui englobe nos choix
finaux :
Tableau 2.9: Tableau de synthèses des choix
Fonctionnalité Outil à utiliser
Nom provider Google Cloud Plateform
Virtualisation Contenaires
Outil CI/CD Gitlab
Outil de création de Diagrams As a Code
diagramme
Outil d’Infrastructure Terraform
en tant que code Ansible
Vagrant
outil d’Orchestration de Kubernetes
contenaires
Outil d’automatisation Kubespray
de kubernetes
26
Conclusion
Dans ce chapitre, nous avons essayé de faire un coup d’œil sur les concepts de base du DevOps
et du cloud computing. Ensuite, nous avons fait une étude comparative qui nous à amener à tracer un
tableau récapitulatif à la fin contenant tous les outils que nous allons utiliser après. C’est seulement
lorsque les outils se collaborent que le travail devient plus riche et plus difficile à gérer. Nous allons
voir dans le chapitre suivant l’architecture effectué en utilisant ces outils ainsi que le rôle de chaque
composant de l’architecture.
27
Chapitre 3
RELEASE 1 : Automatisation de
l’infrastructure de kubernetes
Plan
1 Planification de la première Release . . . . . . . . . . . . . . . . . . . . . 29
2 Conception de la première Release . . . . . . . . . . . . . . . . . . . . . . 29
3 Sprint1 : Conception de l’architecture technique . . . . . . . . . . . . . 30
4 Sprint2 : Création du cluster de kubernetes en local . . . . . . . . . . . 32
5 Sprint3 : Mise en place de l’infrastructure sur le Cloud . . . . . . . . . 36
6 Sprint4 : Automatisation de la création de l’infrastructure . . . . . . . 42

Chapitre 3. RELEASE 1 : Automatisation de l’infrastructure de kubernetes
Introduction
Ce chapitre a pour objectif de préparer la première RELEASE de notre projet. Ce travail

constitue l’étape primordiale qui doit être effectuer pour pouvoir faire le déploiement de nos applications
et assurer une architecture consistante dont on peut toujours ajouter d’autres fonctionnalités pour
la rendre plus efficace selon notre besoin. Notre travail se fonde sur cette première RELEASE. En
effet,sans elle , nous ne pouvons pas avancer sur ce projet. Tout d’abord, nous allons faire une étude
conceptuelle pour tracer notre architecture dont nous allons déployer nos applications. Ensuite, nous
allons faire la mise en place de cette architecture. Enfin, nous allons chercher le moyen pour faire
l’automatisation de notre infrastructure en utilisant des outils de DevOps.
3.1 Planification de la première Release
Le premier Release contient essentiellement deux Sprints qui sont les suivants :
Tableau 3.1: Apercu des spints de la release 1

Num Sprint Titre sprint Description Durée
1 Conception de faire une etude comparative et modéliser 2 semaines
l’architecture technique l’architecture à provisionner durant notre projet.
2 Création du cluster Test en local de la création du cluster en utilisant 2 semaines
kubernetes en local kubeadm pour faciliter l’intégration par la suite
3 Mise en place de Mise en place de l’infrastructure sur le GCP 3 semaines
l’infrastructure sur le
provider choisie
4 Automatisation de automatisation de l’infrastructure et du cluster 3 semaines
l’infrastructure et du en utilisant les outils devops convenable
cluster kubernetes
3.2 Conception de la première Release
Dans cette section, nous allons présenter le diagramme de cas d’utilisation de notre Release
selon les besoins fonctionnels que nous avons déjà fixés.
Comme montré dans la figure 3.1 Un ingénieur DevOps peut soit crée la mise en place de l’infrastructure
manuellement ou bien faire cette création en utilisant des scripts autrement dit, automatisation de
l’infrastructure. Ces deux cas d’utilisation doivent procédés par une authentification.
29
Figure 3.1: Diagramme de Cas d’Utilisation de Release 1
3.3 Sprint1 : Conception de l’architecture technique
3.3.1 Description
Au cours de ce sprint, nous avons effectué notre étude comparative. Cette étude est bien
expliqué dans le chapitre précédent. Nous allons maintenant dévoiler notre architecture de base dont
nous allons déployer les applications de RIF
3.3.2 Analyse Conceptuelle
De nos jours, nous ne parlons que de la conteneurisation de nos applications en utilisant

des conteneurs et en choisissons un orchestrateur pour les bien définir. Notre architecture initiale
se fonde sous le principe de conteneurisation des applications. Elle est principalement composée
de deux clusters un est celui du déploiement des applications de l’entreprise et l’autre est celui de
déploiement des outils. D’un point de vue générale, notre architecture est représentée dans la figure
3.2.
30
Figure 3.2: Architecture Cible de l’Infrastructure
Parlons tout d’abord du cluster des applications, à l’aide des scripts à créer en utilisant le
principe de l’infrastructure en tant que code, notre equipe devops peut crée son cluster kubernetes
qui contient principalement deux subnet :
• Subnet privé : Contient le cluster kubernetes.
• Subnet publique : Contient le bastion qui sera le responsable de la création du cluster

kubernetes et qui acheminera le traffic.
Parlons ensuite du cluster des outils, ce cluster va contenir les outils que nous allons utiliser
tout au long du projet et qui vont aider à garder un fonctionnement idéale et un cycle de vie
automatisé de notre cluster.
• Subnet privé : Contient le cluster kubernetes.
• Subnet publique : Contient le bastion qui sera le responsable de la création du cluster

kubernetes et qui acheminera le traffic.
Pour sécuriser les trafiques entrantes et sortantes de notre VPC, nous allons installé un
pare-feu qui prendra en charge l’autorisation ou le bloquage du traffic.
Nous avons remarqué que Chaque subnet privé dans notre architecture contient un cluster
kubernetes.
Chacun des noeuds node01 joue le rôle d’un master et contient un ETCD. Rappelons ce que
nous avons expliqué dans le chapitre 2, un ETCD est un espace de stockage où nous mettons les
données nécessaires pour le bon fonctionnement de Kubernetes. Les noeuds node02 et node03 jouent
31
le rôle de workers. Par contre le master joue le rôle d’un worker et un master aussi. Le noeud ansible
est la machine qui contient le script en asible de kubespray et qui sera elle responsable de la création
de notre cluster. Toutes les machines node01, node02 et node03 sont basé sur un système REDHAT
qui est le CentOS. La figure 3.3 montre l’architecture crée de notre cluster kubernetes.
Figure 3.3: Architecture de kubernetes
Après avoir terminé ce sprint, on peux bien démarrer la phase pratique. Dans le sprint suivant,
nous allons entamer la phase de création de notre cluster en locale.
3.4 Sprint2 : Création du cluster de kubernetes en local
3.4.1 Description
Durant ce sprint, nous allons approfondir le monde de kubernetes. D’abord, nous allons
présenter une petite analyse conceptuelle dont nous allons présenter notre sequencement des actions.
Ensuite, nous allons présenter un chemin d’analyse technique de ce que nous ferons. Après, nous
présentant quelques captures du travail réalisé.
Pour faire le déploiement en local de kubernetes, nous devons tout d’abord faire le provisionnement
de notre infrastructure et puis faire la création de notre cluster kubernetes. Nous allons définir notre
diagramme de séquence pour voir le séquencement des actions :
32
Figure 3.4: Diagramme de séquence du sprint 2
Un Ingénieur système execute la commande vagrant up qui déclenchera le lancement de

notre fichier Vagrantfile. Dans Vagrant, un Vagrantfile est un fichier dont nous pouvons faire le
provisionnement de notre machines et mêmes faire des configurations automatisés. Durant ce sprint,
nous avons fait le provisionnement de nos machines avec Vagrant. Pendant le lancement de fichier
Vagrantfile, une adresse ip est fixée à chacune de ces machines. Puis, à leur création, un script
ansible est lancé automatiquement pour assurer l’installation des dépendances dans le but de faire
la création de notre cluster.
Une des plus interessante étape dans le playbook ansible est la création d’un kube join. Cela va nous
aider par la suite pour relier les workers à notre master. Une fois que les deux playbook sont executés
avec succées, le cluster est crée dans un bon état. La figure 3.5 décrit techniquement le processus du
travail à effectuer durant ce sprint.
33
Figure 3.5: Création du cluster kubernetes avec kubeadm
3.4.3 Réalisation de la création du cluster kubernetes
3.4.3.1 Provisionnement des machines
Vagrant est celui qui prendra en charge le provisionnement de nos machines virtuelles de test
en utilisant un fichier qui s’appelle Vagrantfile. Ce fichier contient toutes les informations relatives
a nos machines : le nom d’hôte, son adresse IP, image du système d’exploitation, spécification de la
machine virtuelle, ainsi que la partie script pour préparer le fichier hôte, le mot de passe utilisateur
et installer les packages. C’est grâce à vagrant, nous n’avons pas à faire ces choses manuellement avec
virtualbox. Il suffit de bien décrire le fichier Vagrantfile pour créer tout ce que nous avons besoins.
Si nous avons terminé la description de notre fichier Vagrantfile, nous pouvons l’exécuter pour avoir
le provisionnement de nos machines virtuelles d’une façon propre et automatisé. La figure 3.6 nous
montre une capture de notre fichier Vagrantfile.
34
Figure 3.6: Capture du fichier Vagrantfile
3.4.3.2 Création du cluster kubernetes
Après avoir fait le provisionnement, nous sommes prête pour effectuer l’installation du cluster
en local sur les machines provisionnées. Après avoir fait la configuration nécessaire de l’inventory
selon les adresses IPs correspondantes à nos machines provisionnées, nous pouvons lancer nos deux
playbook ansible le premier est du master et le second est du worker pour faire la création de notre
cluster. La figure 3.7 montre les fichiers qui nous ont permis de créer notre cluster.
35
Figure 3.7: Capture du répertoire de la création du cluster avec kubeadm
L’installation de notre cluster avec kubeadm necessite beacoup de travaux manuelle. Ceci
nous a aider à bien démarrer avec le kubernetes et sur la bonne voie. La création de notre cluster
kubernetes est une étape très importante qui nous a permis de découvrir les notions de bases de
kubernetes. Dans le sprint suivant, nous serons prêt pour faire la mise en place de notre infrastructure.
3.5 Sprint3 : Mise en place de l’infrastructure sur le Cloud
3.5.1 Description
Durant ce Sprint, nous avons essayé de faire la mise en place de notre architecture selon des
versions successives. Nous avons découpé l’architecutre en deux principaux partie, une sera la mise
en place du cluster des applications et l’autre sera la mise en place du cluster des outils. À chaque
fois, nous allons montrer quels sont les étapes que nous avons suivie pour assurer leur mise en place
manuelle tout d’abord et leur automatisation à l’aide du principe infrastructure en tant que code.
Dans cette analyse, nous allons présenter la mise en place de notre infrastructure. Après
avoir s’authentifier, un ingénieur devOps crée manuellement ces clés ssh, le vpc dont il va travailler,
les subnets et fait toute autre tâche pour configurer la mise en place de notre infrastructure. Dés
que les machines seront provisionnée, nous pouvons connecter par ssh et lancer le script ansible
correspondant à l’automatisation de la création du cluster kubernetes. Ceci installera toutes les
dépendances nécessaires dans chacun des machines. Nous allons ensuite copier notre certififcat
d’authentification qui existe dans la machine master par défaut. à partir de la description que nous
36
avons effectué, nous allons élaborer le diagramme de séquences pour mieux comprendre ce sprint :
3.5.3 Réalisation de la mise en place de l’infrastructure manuellement
Dans cette section, nous allons mettre les étapes que nous avons suivie pour reussir à faire la
mise en place de notre infrastructure.
37
3.5.3.1 Création du VPC et des subnets
Nous devons tout d’abord créer notre VPC et nos subnets publiques et privés. Pour faire
cela, nous devons connecter à la console et faire cela avec quelques cliques :
Figure 3.9: Création Manuelle VPC et subnet sur le GCP
C’est de la même façon que nous pouvons créer les autre subnets. Après avoir créer notre
VPC et nos subnets, nous devons faire le provisionnement de nos machines virtuelles qui vont être
placées dans ce VPC et vont être repartie entre les différents subnets privés et publiques.
38
3.5.3.2 Provisionnement des machines virutelles à utiliser
Après avoir connecter à notre console google, nous devons créer nos machines une par une.
Nous devons préciser tous les informations relatif à cette machine : le nom, la zone, la region, l’image
de l’os ...
Figure 3.10: Création Manuelle d’une machine sur le GCP
3.5.3.3 Réservation d’une adresse statique pour le bastion
Vu que nous allons gerer le cluster en accédant à notre machine bastion, nous avons besoin
de réserver une adresse ip statique pour ce bastion. L’interface Google est très facile et rapide pour
faire une telle tâche :
39
Figure 3.11: Reservation Manuelle ip statique sur le GCP
Nous pouvons réserver des IPs statiques à tous nos instances et selon notre besoin.
3.5.3.4 Script de démarage de la machine bastion
Après avoir terminé le provisionnement des éléments de notre cluster, il faut installer les
binaires sur nos machines. Comme une première étape nous allons tester le kubeadm en local.
Puisque le kubespray est basé sur le kubeadm alors ça sera plus facile à travailler avec. Après avoir
tester le kubeadm. Le schéma suivant montre les étapes qu’il faudra pour automatiser notre cluster
avec kubespray.
40
Figure 3.12: Mise en place du cluster kubernetes
Le kubespray est installé sur la machine bastion et s’assurer que notre cluster est en bon état.
Nous avons déjà effectué ce travail en local pour le tester. Pour faire cela, il faut refaire les mêmes
étapes, mais en accédant à la machine bastion. Ensuite, il nous reste que de lancer notre playbook
pour trouver le résultat qui est indiqué dans la figure 3.13.
Figure 3.13: Installation Manuelle de Kubespray
Après, un certificat d’authentification doit être générer dans la machine du master. nous
devons la copier dans la machine bastion pour pouvoir utiliser notre cluster et executer nos commandes
necessaires. la figure 3.14 montre l’état de notre cluster.
Figure 3.14: Mise en place du cluster kubernetes
Nous devons répéter quelques configurations pour effectuer cela sur le deuxième cluster. Cela
41
nous mène à chercher une autre méthode pour interagir avec le GCP sans l’interface utilisateur et
essayer d’automatiser au maximum les tâches répétitives.
3.6 Sprint4 : Automatisation de la création de l’infrastructure
3.6.1 Description
Durant ce sprint, nous allons voir comment réussir la mise en place de l’infrastructure en
utilisant un outil que nous avons aborder dans la partie de l’étude comparative. Il s’agit de notre
fameux Terraform qui sera le responsable du provisionnement de l’infrastructure en tant que code.
Dans cette partie, nous allons décrire le scénario qui va se lancer pour assurer l’automatisation
de l’infrastructure en utilisant le Terraform.
Tout d’abord, nous devons créer un Service Account pour pourvoir se connecter avec terraform
sur le GCP. Ceci engendre la création d’un fichier JSON qui autorisera Terraform à créer l’infrastructure.
Une fois l’ingénieur de DevOps lancera son script, GCP va vérifier l’existance des composants que
nous allons créer. S’il ne trouve pas de redondances, il nous enverra le resultat de ce qui se passe. Ce
script engendre le provisionnement des machines. Une fois crée, la machine bastion exécutera son
script de démarrage qui va installer les dépendances nécessaire à la création d’un cluster. La copie
du certificat d’authentification est effectuée du master vers le bastion. Une fois consultée, la machine
bastion affichera l’état de notre cluster.
La figure 3.15 montre le séquencement complète du cas d’utilisation automatisation de la

mise en place de l’architecture.
42
Figure 3.15: Automatisation de la Mise en place de l’architecture
Nous avons remarqué que l’interaction entre l’acteur et les autres objets est vraiment négligeable.
Ceci montre la valeur ajouté de l’automatisation qui essaye d’éliminer les tâches répétitives et
routines par des scripts.
3.6.3 Réalisation de la création du cluster des applications
Pour la réalisation de ce sprint nous allons suivre quelques étapes que nous décrirons dans la
partie suivante.
43
3.6.3.1 Provisionnement du cluster des applications
En utilisant le Terraform, tous devient pratique et rapide à effectuer. Avec du simple code,
nous pouvons créer tous ce que nous avons besoin. Après avoir lancer un Terraform Apply voila le
résultat que nous avons trouver sur le GCP. Tous d’abord, la figure 3.16 montre la création de VPC
avec succées.
Figure 3.16: Création VPC et subnets automatisé sur le GCP
Concernant la réservation d’une adresse statique, la figure 3.17 montre l’adresse statique
reservé pour la machine bastion.
Figure 3.17: Réservation automatisé de ip statique sur le GCP
Ensuite, le provisionnement des machines est affichés dans la ficgure 3.18
Figure 3.18: Provisionement des instances du cluster application sur le GCP
Une fois que nous avons effectuer le provisionnement du cluster des applications, le cluster
des outils se fait de la même façon.
44
3.6.3.2 Automatisation de la création du cluster des applications
Puisqu’il existe plusieurs tâches manuelles et répétitives, nous avons décidé d’automatiser la
création de notre cluster kubernetes. L’automatisation est l’une des activités principaux de l’équipe
de DevOps. Nous allons automatiser la création de notre cluster kubernetes en utilisant kubespray.
Pour cela, nous allons introduire un script bash qui va s’executer au démarage de notre machine
bastion. ce script va être utile pour installer les binaires de kubernetes.
3.6.4 Réalisation de l’automatisation du cluster (Version2)
Durant cette section, nous allons essayer d’améliorer l’automatisation de notre cluster kubernetes.
L’utilisation de script n’est pas toujours une bonne pratique. Puisque nous allons déjà utiliser
la même démarche pour le cluster des outils, nous devons utiliser le principe des templettes de
Terraform.
3.6.4.1 Utilisation des templates dans le projet
Les templates sont des sources de données qui prennent un fichier modèle et constitue un
modèle qui peut être utiliser plusieurs fois. Ce fichier modèle est généralement un fichier extérieur.
Figure 3.19: Template script de démarrage de la machine bastion
Une fois qui nous fessons une initialisation de terraform, nous pouvons remarquer que le
plugin de templette est ajouté :
45
Figure 3.20: Plugin template ajouté
3.6.5 Réalisation de création de l’infrastructure du Cluster des outils
3.6.5.1 Provisionnement du cluster des outils
Notre cluster des outils va contenir tous les outils à utiliser(pour le moment le Gitlab). Ce
cluster va démarer notre pipeline, automatiser le cycle de vie de nos applications déployées et même
faire le suivie de l’état de nos applications.
Pour faire l’automatisation de notre cluster d’applications, nous avons utiliser le Terraform
pour faire la création de l’infrastructure en tant que code. De même, pour automatiser le provisionnement
de nos machines du cluster des outils, nous allons utiliser le terraform. Voilà la racine de notre projet :
Figure 3.21: Répertoire des fichiers de provisionnement de l’infrastructure
46
Les fichiers ajoutés sont préfixés avec un CO autrement dit cluster des outils. Avec un simple
commande, le cluster est automatisé avec succès. Nous pouvons voir les résultats du provisionnement
des instances sur l’interface :
Figure 3.22: Provisionnement des instances du projet
Nous pouvons aussi voir les adresses statiques que nous avons réservées : un sera du bastion
du cluster des applications et l’autre du bastion du cluster des outils :
Figure 3.23: Réservation des adresses statiques pour les machines bastion
Au cours de ce sprint, nous avons effectué l’automatisation de la création de l’infrastructure

de notre cluster d’application. Grâce à cette automatisation, avec une simple commande de terraform
apply nous allons faire le provisionnement de tous les éléments de notre cluster et faire le démarrage
du script qui va faire l’automatisation de notre cluster kubernetes en utilisant le kubespray.
Conclusion
Durant cette release, nous avons pu faire la mise en place de l’infrastructure tout en automatisant
le provisionnement et la configuration des tâches répétitives. Dans la release suivante, nous allons
faire le déploiement de nos application en utilisant le kubernetes.
47
Chapitre 4
RELEASE 2 : Conteneurisations et
orchestrations
Plan
1 Planification de la deuxiemme Release . . . . . . . . . . . . . . . . . . . . 49
2 Conception de la deuxiemme Release . . . . . . . . . . . . . . . . . . . . 49
3 Sprint5 : Déploiement des applications sur le cluster des apps . . . . . 50
4 Sprint6 : Déploiement de Gitlab sur le cluster des outils. . . . . . . . . 54
5 Sprint7 : Préparation des images Docker . . . . . . . . . . . . . . . . . . 59

Chapitre 4. RELEASE 2 : Conteneurisations et orchestrations
Dans cette section, nous allons se concentrer sur tout aspect de conteneurisation et d’orchestration
des applications et des outils. Tout d’abord, nous allons installer sur notre cluster d’application
l’application Odoo. Ensuite, nous allons installer sur notre cluster des outils notre fameux Gitlab sur
notre propre serveur en utilisant le kubernetes. Enfin, nous allons effectuer un petit pipeline pour
tester le bon fonctionnement de notre cluster Gitlab.
4.1 Planification de la deuxiemme Release
La deuxiemme Release contient essentiellement deux Sprints qui sont les suivants :
Tableau 4.1: Apercu des spints de la release 2

Num Sprint Titre sprint Description Durée
5 Déploiement de Déploiement de l’applicationOdoo avec 3 semaines
l’application sur le kubernetes sur lecluster crée
clusterdes apps
6 Déploiement de Gitlab Mise en place de Gitlab sur le clus-ter des outils 3 semaines
sur le cluster des outils. pour faire la pipeline
7 Mise en place de préparation de l’image docker et faire le build 2 semaines
pipeline de l’integration pour l’application Odoo
continue
4.2 Conception de la deuxiemme Release
Dans cette section, nous allons présenter le diagramme de cas d’utilisation de notre Release
selon les besoins fonctionnels que nous avons déjà fixés en décrivant les sprints. Il existe deux
principaux acteurs : l’Ingénieur DevOps et le Dévloppeur. Dans ce diagramme l’Ingénieur DevOps
aura plus de responsabilité qu’avant. Il va se concentrer sur le déploiement de l’application Odoo sur
le cluster des applications et le déploiement de l’application Gitlab sur le cluster des outils. Ces deux
cas d’utilisation necessite une authentification et ne peuvent être effectué que si notre infrastructure
existe. Ensuite ; le développeur est le responsable de la création et la préparation des images dockers.
49
Figure 4.1: Diagramme de Cas d’Utilisation de Release 2
Après avoir faire le cadre de notre release 2, nous allons commencer de prendre chaque sprint
et le décrire en détails en présentant à chaque fois son analyse conceptuelle et sa réalisation.
4.3 Sprint5 : Déploiement des applications sur le cluster des apps
4.3.1 Description
Durant ce sprint, nous allons essayer de faire le déploiement de notre application Odoo sur
notre cluster kubernetes crée. Tout d’abord, nous devons découvrir l’architecture de Odoo. Ensuite,
cette architecture va nous aider à comprendre comment créer nos manifestes kubernetes qui vont
contribuer au déploiement de kubernetes. Enfin, nous allons tester le bon fonctionnement de Odoo.
Dans cette partie, nous allons effectuer une petite analyse conceptuelle. Nous avons parlé
dans le chapitre 2 que les pods sont les plus petit elements dans le kubernetes. Si une application
contient plusieurs conteneurs, kubernetes essaye de les mettre en une même unité appelé pod. Ceci
50
est utile pour assurer une bonne gestion des conteneurs. Nous pouvons regrouper plusieurs pods qui
exécutent la même fonctionnalité dans un ensemble appelé service. Suivant cette démarche, nous
avons décomposer notre application de cette façon :
• Un namespace dont nous allons mettre notre application
• Deux services : un pour la base de donnée PostgresSQL et l’autre pour l’application
• Deux Déploiement : un pour la base de donnée de l’autre pour l’application
• Deux volumes persistants
• Deux volumes PVC ( Persistant Volume Claim) pour chacun des services.
• Un controlleur nginx ingress qui va laisser exposer les pods depuis le réseau externe.
Un volume persistant est un volume physique dans la machine qui stocke nos données persistant.
Un PVC représente une sorte de demande pour que la plateforme puisse créer un volume persistant
dans nos pods. Autrement dit, nous attachons les PVs au pods avec des PVC.
À chaque fois que nous voudrons modifier une action sur notre cluster (une fonctionnalité),
nous devons écrire un ensemble de fichiers YAML qui décrivent notre besoin et les valider dans notre
machine. Voilà une petite étude conceptuelle de ce que nous allons faire. La figure 4.2 montre la
décomposition de l’application Odoo sous formes des objets de kubernetes.
51
Figure 4.2: Déploiement de l’application avec kubernetes
4.3.3 Réalisation de déploiement de Odoo
Après avoir établi notre conception, il faut créer tous les fichier YAML nécessaires pour
assurer le bon fonctionnement de notre cluster d’application selon la conception que nous avons
effectué. Pour tester le bon fonctionnement de notre application, il faut vérifier que nos services
fonctionnent comme prévue :
Figure 4.3: Consulter les services de l’application
52
Ensuite, il faut vérifier que nos déploiements sont en bon état avec cette commande :
Figure 4.4: Consulter les déploiements de odoo
Puis, pour voir nos volumes persistants et qu’il sont bien attaché au PVC, il suffit d’exécuter
cette commande :
Figure 4.5: Consulter les volumes persistant de odoo
Le mot ’bound’ signifie que les volumes sont en train de bien enregistrer ce qui est prévue
d’être enregistrer.
Une fois que tous marche bien, nous pouvons voir notre application depuis le navigateur gràce
à notre Nginx Ingress Controller :
Figure 4.6: Page d’acceuil de odoo
Durant ce sprint, nous avons pu faire le déploiement de notre application sur notre cluster
d’application et en utilisant kubernetes.
53
4.4 Sprint6 : Déploiement de Gitlab sur le cluster des outils.
4.4.1 Description
Durant ce sprint, effectuer le déploiement de notre Gitlab sur notre cluster des outils. Ce
travail sera utile pour pouvoir effectuer le pipeline de l’intégration continue et du déploiement continu
par la suite. Pour ce fait, nous allons effectuer la décomposition de notre application Gitlab sous
forme de pods pour assurer son déploiement en utilisant kubernetes.
Dans cette section, nous allons se focaliser sur la conteneurisation et l’orchestration de nos
conteneurs dans le cluster des outils. Avant d’entamer la partie pratique, nous devons bien tracer la
façon avec laquelle nous devons déployer Gitlab en utilisant kubernetes.
Tout d’abord, le cluster contient un co-master et deux nœuds. Le co-master contient plusieurs
éléments :
Le co-worker1 et le worker2 communiquent avec le master via le kubelet. Un worker contient
un déploiement Gitlab qui est associé à un replicaSet. Il est associé à un gitlab secret qui lui le
responsable de récupération du mot de passe initiale du compte de l’administrateur ainsi que du
registration token généré et associé au gitlab runner. le déploiement de gitlab contient un conteneur
gitlab attaché à 3 volumes pour stocker tous en utilisant les PVs et les PVCs. Chacun des volumes
est associé à un PVC qui à sa place va faire une requête pour créer un volume physique persistant
pour stocker des données necessaires. Pour assurer le bon fonctionnement du pipeline de gitlab, il
faut que nous configurions les runneurs. Nous allons alors faire deux runneurs partagés un s’appelle
gitlab-runner-kubernetes et l’autre gitlab-runner-docker. chacun de ces deux runners est configuré
dans le fichier YAML en fixant les variables d’environement necessaires. Un Nginx Ingress Controller
rend gitlab accessible depuis le reseau externe. La figure suivante détaille mieux ce que nous allons
faire dans la partie pratique.
54
Figure 4.7: Étude conceptuelle de déploiement de Gitlab avec kubernetes
Pour les RBACs nous pouvons les présenter de cette façon :

Dans notre cas, nous allons crée un RBAC [16] qui permet aux ressources pods d’executer
quelques tâches pour pouvoir lancer notre pipeline dans les bonnes conditions.
55
Figure 4.8: RBAC du déploiement gitlab
4.4.3 Réalisation du déploiement de notre application Gitlab
Pour la réalisation de ce sprint, nous avons crée un ensemble de fichiers de configuration en

YAML pour décrire notre besoin :
Figure 4.9: Répertoire projet de déploiement de gitlab
56
Après avoir appliqué nos fichier YAML nous pouvons voir le résultat de nos déploiements
existant :
Figure 4.10: Les déploiements de gitlab
Nous poouvons aussi voir notre ingress qui rend notre déploiement gitlab accessible depuis
un réseau externe :
Figure 4.11: Ingress de gitlab
Pour voir nos volumes persistants, il suffit d’executer cette commande.
Figure 4.12: Volumes associé au déploiement gitlab
Maintenant, nous pouvons tester le succès de l’opération de création de mots de passe en utilisant
secret. Nous visitons la page du navigateur et nous saisons notre mot de passe initiale pour voir le
résultat de la capture 4.13
57
Figure 4.13: Page d’acceuil de gitlab
Pour lancer notre pipeline. il nous faut au minimum un gitlab runner actif. Nous avons
effectuer la configuration de deux runners un s’appelle gitlab-runner-kubernetes et l’autre gitlab-runner-docker.
Nous allons associer à chacun de nos runners un tag pour pouvoir les appeler dans notre pipeline
par la suite. Voilà nos runners partagé :
Figure 4.14: Runners partagés de notre Gitlab
Au cours de ce sprint, nous avons essayé de faire le déploiement du gitlab sur notre cluster
des outils en utilisant kubernetes.
58
4.5 Sprint7 : Préparation des images Docker
4.5.1 Description
Après avoir faire le déploiement de Gitlab, nous devons surement l’utiliser. Gitlab contient
un outil d’automatisation qui s’execute à chaque commit d’un fichier de notre répertoire Gitlab. Ceci
doit être élaborer dans une pipeline.
4.5.2.1 Diagramme de Cas d’Utilisation
Il faut tout d’abord dévoiler nos fonctionnalités avec un Diagramme de Cas d’Utilisation. Tout
d’abord, un développeur peut préparer les images de docker. Cependant, cette tâche nécessite ne peut
être effectué que s’il est authentifié. Tout d’abord, un développeur doit créer son fichier Dockerfile. Ce
fichier doit être préparer (etape de build) en utilisant un pipeline qui assurera l’intégration continue.
Ensuite, Un Développeur peut à tout moment consulter la liste des images docker ou bien télécharger
une de ces images.
59
Figure 4.15: Diagramme de cas d’utilisation du sprint 7
4.5.2.2 Diagramme de Séquence
Le diagramme de séquence va nous aider à lancer la réalisation du travail. Un développeur

fait un commit qui déclenchera automatiquement la pipeline de l’intégration continue. A ce stage
la, nous essayerons de faire le build de notre image. Après, nous allons la publier dans le registre du
GCP. Nous ne pouvons la publier sur le registre de GCP qu’avec la création d’un service account qui
permettra d’autoriser l’utilisation du registre de GCP. Une fois toute est bien vérifié, l’image doit
être publiée sur le registre du GCP.
60
4.5.3 Réalisation de la préparation des images docker
Avant de bien se lancer dans cette phase, nous allons crée notre dockerfile. Cependant, il est
primordiale de découvrir l’architecture technique de notre application Odoo comme illustré dans la
figure 4.15
Figure 4.17: Architecture de Odoo
Comprendre l’architecture de Odoo est l’une des étapes que nous devons évoquer. Elle est
principalement composée de trois parties. La première est le serveur odoo qui stocke les données sur
une bases de données PostgreSQL. La deuxiemme est le client qui est odoo mobile qui doit être sur
le terminal utilisateur. Le derrière est le serveur web qui permet une interaction utilisateur depuis
61
une interface. Après avoir comprendre cette architecture, nous somme prête pour construire notre
Dockerfile pour faire l’encapsulation de tous nos dépendances. Ensuite, un service account doit être
crée pour donner les permissions à gitlab d’accéder à notre google registry qui se touve dans le
GCP. Nous n’avons pas utiliser le même service account que nous l’avons utiliser pour la création
de l’infrastructure car les droits change au fur et à mesure de ce que nous allons faire.
Figure 4.18: Service Account pour accéder au container registry de Gitlab
Il faut dévoiler nos fonctionnalités avec un Diagramme de Cas d’utilisation. Tout d’abord,
un développeur peut préparer les images de docker. Cependant, cette tâche nécessite ne peut être
effectué que s’il est authentifié. Tout d’abord, un développeur doit créer son fichier Dockerfile. Ce
fichier doit être préparer (étape de build) en utilisant un pipeline qui assurera l’intégration continue.
Ensuite, Un Développeur peut à tout moment consulter la liste des images docker ou bien télécharger
une de ces images. La figure 4.19 montre la pipeline d’intégration continue. Après avoir terminé le
Figure 4.19: Résultat du pipeline
pipeline, nous pouvons remarquer sur le GCP un nouveau bucket qui s’ajoute et qui réfère à l’image
de Docker utilisé
62
Figure 4.20: Résultat d’ajout dans le registre de conteneurs de GCP
Durant ce sprint, nous avons pu faire la création d’un pipeline qui faire le build de notre
image docker et la mettre dans le registre de conteneurs du gcp.
Conclusion
Au cours de la release 2, nous avons fait le déploiement de notre application Odoo sur le
cluster d’application ainsi que notre applications Gitlab sur notre cluster des outils. Ensuite, nous
avons fait une petite pipeline pour assurer l’automatisation de l’intégration continue de l’application.
63
Conclusion générale
Au terme de ce projet, nous avons dressé un bilan complet de notre travail qui se situe dans le
cadre de notre projet de fin d’études. Il s’agit de concevoir et mettre en place une solution permettant
d’automatiser la création et la gestion de l’infrastructure de déploiement des applications critiques
de l’entreprise accueillante. Cette solution vise à améliorer la performance et l’efficience du processus
de livraison des nouvelles releases tout en assurant la qualité, l’agilité et en satisfaisant les attentes
des clients.
Pour ce fait, nous avons entamé, notre mémoire, par une étude préliminaire où nous présentons
RIF et nous introduisons notre mission d’automatisation. Par la suite, nous avons fixé le périmètre
et les objectifs de la mission. Cette étape nous a permis, par la suite, de tracer notre architecture
technique à partir de l’étude comparative. Des scripts d’automatisation ont été, également, effectués
afin d’assurer la non répétition des tâches répétitives. Par conséquent, nous avons pu déployer nos
applications choisies et faire notre pipeline de test.
Cette expérience à été bénéfique et bien fructueuse sur plusieurs plans. D’une part, elle nous
a permis de renforcer nos acquis tout au long de notre cursus à l’ISITCOM. D’autre part, ce projet
présente un grand apport pour approfondir nos connaissances en DevOps. Enfin, à travers ce stage,
nous avons eu de la chance d’améliorer nos aptitudes à communiquer et à travailler en collaboration
ce qui va nous aider sans doute à bien nous intégrer dans le milieu professionnel.
Comme perspectives de travail, nous proposons de développer plus la pipeline en ajoutant
des tests unitaires ainsi que des tests de qualité de code. Nous pouvons aussi intégrer la sécurité dans
notre pipeline en ajoutant des tests d’intrusion automatisés et de gestion des vulnérabilités. Il est
même possible d’assurer la surveillance continue en utilisant les outils nécessaires. Cette surveillance
nous servira à détecter et d’analyser les problèmes qui peuvent survenir en relation avec notre système
et nos services.
Ainsi, il est évident que notre travail peut être plus extensible et plus riche, mais faute de temps,
nous n’avons pas pu prévoir de telles perspectives.
64
bibliographie
[B1] Infrastructure as Code : Managing Servers in the Cloud | auteur : Kief Morris
[B2] The Terraform Book | Auteur : James Turnbull
65
Webographie
[1] Présentation générale de RIF[Accès le 20-Mai-2020],

adresse :https ://www.societe.com/societe/rassemblement-des-ingenieurs-francophones-838975357.htm
[2] Les artéfacts de Scrum[Accès le 25-Mai-2020],

adresse :https ://blog.myagilepartner.fr/index.php/2019/10/14/artefacts-scrum/
[3] Présentation DevOps[Accès le 26-Mai-2020],

adresse :https ://aws.amazon.com/fr/devops/what-is-devops/
[4] Cycle de vie de devops[Accès le 27-Mai-2020],

adresse :https ://dev.to/ashokisaac/devops-in-3-sentences-17c4
[5] Introduction au Cloud Computing [Accès le 2-Juin-2020],

adresse :https ://www.explainthatstuff.com/cloud-computing-introduction.html
[6] Modèles de déploiement de Cloud Computing [Accès le 3-Juin-2020],

adresse :https ://mycloudblog7.files.wordpress.com/2013/06/screen-shot-2015-06-09-at-2-13-05-pm1.pn
[7] Étude comparative entre Cloud publique et cloud privée [Accès le 3-Juin-2020],
adresse :https ://www.computerland.fr/difference-cloud-prive-public/
[8] Comparaison providers [Accès le 2-Juin-2020],

adresse : https ://www.computerworld.com/article/3429365/aws-vs-azure-vs-google-whats-the-best-clo
[9] Présentation de Gitlab[Accès le 5-Juin-2020],

adresse :https ://blog.eleven-labs.com/fr/introduction-gitlab-ci/
[10] Solution de virtualisation [Accès le 6-Juin-2020],

adresse :https ://docs.microsoft.com/en-us/virtualization/windowscontainers/about/containers-vs-vm
[11] Solution d’orchestration des conteneurs [Accès le 15-Juin-2020],

adresse :https ://phoenixnap.com/blog/kubernetes-vs-docker-swarm
66
Webographie
[12] Comprendre le concept des pods[Accès le 28-Juin-2020],

adresse :https ://kubernetes.io/docs/concepts/workloads/pods/
[13] Comprendre le concept de Déploiement en kubernetes[Accès le 2-Juillet-2020],

adresse :https ://kubernetes.io/docs/concepts/workloads/controllers/deployment/
[14] Comprendre le concept de service en kubernetes[Accès le 5-Juillet-2020],

adresse :https ://kubernetes.io/docs/concepts/services-networking/service/
[15] Comprendre le concept de Ingress[Accès le 28-Juin-2020],

adresse :https ://kubernetes.io/docs/concepts/services-networking/ingress/
[16] Document explicatif des RBACs[Accès le 10-Aout-2020],

adresse :https ://linkerd.io/2017/07/24/using-linkerd-kubernetes-rbac
67
Résumé
Afin de s’imposer dans le marché, les entreprises doivent adopter des processus et des démarches
plus agiles et alignés aux besoins de leurs clients. Les développements réalisés doivent répondre
aux spécifications exigées et déployer d’une façon plus rapide sur les différents environnements
des clients, tout en assurant une assurance de la qualité des livraisons.
Consciente de l’importance de l’automatisation pour remédier à ces challenges et optimiser l’ef-
ficience de ses processus internes de développement, l’entreprise RIF a pris la décision d’élaborer
une automatisation totale de son infrastructure ainsi du déploiement de ces applications. Ce
projet consiste à mettre en place une solution permettant l’automatisation de la création de
l’infrastructure et l’optimisation du cycle de vie des applications tout en assurant une meilleure
qualité et en respectant les délais prédéfinis
Mots clés : Devops, Docker, kubernetes, Conteneurisation, Infrastructure en tant que code, Automa-
tisation, Orchestration.
Abstract
In order to establish themselves in the market, companies must adopt processes and approaches
that are more agile and aligned with the needs of their customers. The developments must meet
the required specifications and deploy more quickly applications in different customer environ-
ments, while ensuring quality assurance of deliveries. Aware of the importance of automation to
overcome these challenges and optimize the efficiency of its internal development processes, the
RIF company has decided to develop total automation of its infrastructure and the deployment
of these applications. This project consists of setting up a solution allowing the automation of
the creation of the infrastructure and the optimization of the application life cycle while ensuring
better quality and respecting the predefined deadlines
Keywords : Devops, Docker, kubernetes, Containerization, Infrastructure as a code, Automation,

Orchestration.
administration@infcom.rnu : ¨¤rtk¯ d§rb 73 364 411 : HAf 73 371 571 : Ah TFwF Am 4011 1w.ª
GP1 4011 Hammam Sousse Tél :73 371 571 Fax : 73 364 411 Email : administration@infcom.rnu

TouziInesDEVOPSPFE2020 V1.6

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

TouziInesDEVOPSPFE2020 V1.6

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’Enseignement Supérieur

Institut Supérieur d’Informatique et des Techniques de

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National d’Ingénieur

Mise en place d’une solution DevOps

Encadrant académique : Mr. Bayram Triki Maître assistant

Réalisé au sein de la société RIF

Année Universitaire 2019 - 2020

Ministère de l’Enseignement Supérieur

Institut Supérieur d’Informatique et des Techniques de

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National d’Ingénieur

Mise en place d’une solution DevOps

Encadrant académique : Mr. Bayram Triki Maître assistant

Réalisé sein de la société RIF

Année Universitaire 2019 - 2020

Encadrant académique, Mr. Bayram Triki

Directeur technique de RIF , Mr. Ramzi Dridi

De plus profond de mon cœur, je dédie ce travail

A mon très cher père Hédi

A Ma sœur Sirine et son époux Hamed

A Mon frère Marwen

A mes adorables amis que je considère ma deuxième famille, Amina, Eya,

Slah, Ali,Wael, Zoubayer, Rami et Hatem

Votre fidèle Inès

Aux membres de jury pour avoir accepté d’évaluer mon travail.

1 Cadre générale du projet 3

3 RELEASE 1 : Automatisation de l’infrastructure de kubernetes 28

4 RELEASE 2 : Conteneurisations et orchestrations 48

1.1 Logo de RIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Valeur ajouté de l’agilité dans le processus du DevOps . . . . . . . . . . . . . . . . . 13

3.1 Diagramme de Cas d’Utilisation de Release 1 . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Diagramme de Cas d’Utilisation de Release 2 . . . . . . . . . . . . . . . . . . . . . . 50

1.1 Tableau des rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Étude comparative du modèle de déploiement . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Apercu des spints de la release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Apercu des spints de la release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

RIF RASSEMBLEMENT DES INGÉNIEURS FRANCOPHONES

CI Intégration Continue (en anglais Continuous Integration)

CD Déploiement Continue (en anglais Continuous Deployment)

OS Système d’exploitation ( en anglais Operating System)

PV Volume persistant(en anglais Persistent Volume)

PVC demande de volume persistant (en anglais Persistent Volume Claim)

GCP Plate-forme de Google Cloud ( en anglais Google Cloud Platform)

GCR Registre des conteneurs de Google ( en anglais Google Container Registry)

GCS Conteneur de Stockage de Google ( en anglais Google Container Storage)

IaaS Infrastructure En Tant que Code ( en anglais Infrastructure as a Service)

PaaS Plate-forme En Tant que Code ( en anglais Platform as a Service)

SaaS Logiciel En Tant que Service ( en anglais Software as a Service)

IaC Infrastructure En Tant que Code ( en anglais Infrastructure as Code)

K8s Kubernetes( en anglais Kubernetes)

SSH shell sécurisé ( en anglais Secure Shell)

UI Interface Utilisateur( en anglais User Interface)

SA Compte de Service( en anglais Service Account)

Dans un contexte de compétitivité accrues, les entreprises IT ne cessent pas d’innover et

Par ailleurs, la préparation de l’environnement de déploiement, quoiqu’elle soit une tâche

Consciente de l’importance de l’automatisation pour remédier à ces challenges et optimiser

prototype de la solution permettant l’automatisation de la création de l’infrastructure.

Cadre générale du projet

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