UNIVERSITÉ NATIONAL DU VIETNAM, HA NOI INSTITUT FRANCOPHONE INTERNATIONAL Spécialité : Réseaux et Systèmes Communicants Wilkenson CHARLES L’AUTOMATISATION DU PROCESSUS D’INTEGRATION DE CODES, DES TESTS ET DU DEPLOIEMENT POUR UNE ARCHITECTURE EN MICROSERVICES. TỰ DỘNG HOA QUY TRINH TICH HỢP LẬP MÃ, KIỂM THỬ VA TRIỂN KHAI CHO KIẾN TRUC MICROSERVICE MEMOIRE DE FIN D’ETUDE DE MASTER 2 EN INFORMATIQUE Sous la direction de : Dr. Vo Ngoc Thieu & Dr. Nguyen Hong Quang Hanoi Novembre 2023 UNIVERSITÉ NATIONAL DU VIETNAM, HA NOI INSTITUT FRANCOPHONE INTERNATIONAL Spécialité : Réseaux et Systèmes Communicants Wilkenson CHARLES L’AUTOMATISATION DU PROCESSUS D’INTEGRATION DE CODES, DES TESTS ET DU DEPLOIEMENT POUR UNE ARCHITECTURE EN MICROSERVICES.
TỰ DỘNG HOA QUY TRINH TICH HỢP LẬP MÃ, KIỂM THỬ VA TRIỂN KHAI CHO KIẾN TRUC MICROSERVICE MEMOIRE DE FIN D’ETUDE DE MASTER 2 EN INFORMATIQUE Sous la direction de : Dr. Vo Ngoc Thieu & Dr. Nguyen Hong Quang Hanoi Novembre 2023 ATTESTATION SUR L’HONNEUR J’atteste sur l’honneur que ce mémoire a été réalisé par moi-même et que les données et les résultats qui y sont présentés sont exacts et n’ont jamais été publiés ailleurs. La source des informations citées dans ce mémoire a été bien précisée.
LỜI CAM ÐOAN Tôi cam đoan đây là công trình nghiên cứu của riêng tôi. Các số liệu, kết quả nêu trong Luận văn là trung thực và chưa từng được ai công bố trong bất kỳ công trình nào khác. Các thông tin trích dẫn trong Luận văn đã được chỉ rõ nguồn gốc. Signature de l’Etudiant CHARLES Wilkenson Remerciements La réalisation de ce mémoire de Master de recherche a été possible grâce au concours de plusieurs personnes à qui je voudrais témoigner toute ma gratitude.
Dans un premier temps, je voudrais exprimer toute ma reconnaissance aux directeurs de ce mémoire, Dr. Vo Ngoc Thieu et Dr. Nguyen Hong Quang pour leurs patiences, leurs disponibilités, leurs précieux conseils et leurs supervisions éclairées. L’enseignement de qualité dispensé par le Master « P23 RSC » a également su nourrir mes réflexions et a représenté une profonde satisfaction intellectuelle, merci donc aux enseignants-chercheurs.
Je désire aussi remercier les professeurs de l’IFI, qui m’ont fourni les outils nécessaires à la réussite de mes études universitaires. Je voudrais enfin exprimer ma gratitude à mes proches et les remercier de m'avoir soutenu et encouragé financièrement et mentalement. i Résumé Ce document vise à présenter le travail effectué par Charles Wilkenson, dans le contexte du mémoire de master « L’automatisation du processus d’intégration de codes, des tests et du déploiement pour une architecture en microservices » promu et coordonné par FSOFT. Le stage a commencé par une étude des concepts considérés comme essentiels pour une meilleure compréhension du projet en lui-même.
Cette étude a permis de poser une pierre angulaire sur laquelle le reste du stage s'est appuyé. Le reste du travail sera basé sur l'obtention d'une connaissance approfondie sur le fonctionnement des technologies "cloud-native", sur ce qu'est une architecture de microservices, des cultures de développement connues basées sur l'automatisation et de la manière dont elles peuvent être adoptées, et, enfin, comment l'observabilité des applications peut être obtenue lorsqu'elles sont en production. Ce modèle est couplé avec le pipeline CI/CD, qui constitue un pont entre cette infrastructure et les développeurs de logiciels, un pipeline qui automatise les tâches de construction (build), y compris les tests automatisés, l'analyse du code et la vérification des dépendances de manière cohérente et récurrente sans perte de qualité du logiciel. Avec cette base en place, ainsi que la culture de l'automatisation devenant d'automatisation au sein des équipes de développement, toutes les parties prenantes impliquées dans ce processus peuvent en récolter les fruits.
Mots clés : Cloud, Microservices, DevOps, Intégration continue, Déploiement continue ii Abstract The purpose of this document is to present the work carried out by Charles Wilkenson, in the context of his master's thesis "Automating the code integration, testing and deployment process for a microservices architecture", promoted and coordinated by FSOFT. The internship began with a study of the concepts considered essential for a better understanding of the project itself. This study laid the cornerstone on which the rest of the internship was based. The rest of the internship's work would be based on gaining an in-depth knowledge of how cloud-native technologies work, what a microservices architecture is, known automation-based development cultures and how they can be adopted, and, finally, how observability of applications can be achieved when they are in production.
This model is coupled with the CI/CD pipeline, which forms a bridge between this infrastructure and software developers, a pipeline that automates build tasks, including automated testing, code analysis and dependency checking, consistently and recurrently, without loss of software quality. With this foundation in place, and the culture of automation becoming automation within development teams, all stakeholders involved in the process can reap the rewards. Keywords : Cloud, Microservices, DevOps, Intégration continue, Déploiement continue iii Table des matières Chapitre 1 : Introduction générale.1 Présentation de l’entreprise FPT-SOFTWARE et l’équipe FHN.2 Contexte d’étude et problématique .3 Objectifs du stage. 3 Chapitre 2 : Définition et fonctionnement des termes essentiels pour une meilleur compréhension du sujet .1 Avantages du cloud computing.2 Différents types cloud computing.3 Différents services offerts par le cloud computing .1 Différentes façons dont les microservices communiquent .2 Types de communication des microservices .3 Comment les microservices communiquent-ils ? .4 Avantages de l'architecture microservices .4 Intégration Continue et Livraison Continue (CI/CD) .5 La stratégie de déploiement bleu-vert (blue-green deployment).
20 Chapitre 3 : Etat de l’art .1 Démarche de l’étude comparative des outils DevOps.1 Outils de gestion de code source .5 Comparaison et synthèse.2 Outils de provisionnement d'infrastructure .3 Comparaison et synthèse.3 Outils de gestion de configuration et d’automatisation .5 Comparaison et synthèse.4 Outils d'intégration continue .4 Comparaison et synthèse.5 Outils de gestion de monitoring .3 Comparaison et synthèse.6 Service tiers pour la sauvegarde des informations (Third Party Secret Keepers).3 Comparaison et synthèse.7 Synthèse et choix .8 Etude de l’existant .2 Critique de l’existant. 39 Chapitre 4 : Solution proposée .1 Configuration de notre environnement local .2 La structure du projet .3 Provisionnement de l'infrastructure .1 Gestion d’identités et d’accès (IAM) .2 Création d’une paire de clés EC2 .3 Configuration de l’interface en ligne de commande (AWS CLI).4 Mise en place de la distribution CloudFront .5 Création d’une base de données PostgreSQL dans RDS .5 Mise en place du pipeline CICD.1 La phase de construction (build) .2 La phase de test .3 La phase d’analyse .4 La phase d’alerte .5 La phase d’infrastructure .6 La phase de déploiement .7 Phase Smoke test .8 Phase de promotion .9 La phase de nettoyage .1 Création d’une nouvelle instance EC2 .2 Installation et configuration de Prometheus .3 Configuration des alertes .4 Téléchargement de Prometheus AlertManager .5 Configuration du service Systemd du gestionnaire d'alerte .6 Configurer le gestionnaire d'alertes avec SMTP .7 Création des règles Prometheus .8 Configuration de Prometheus. 76 Conclusion et perspectives. 79 vi Tables des figures Figure 1 : Cloud Computing.
4 Figure 2 : Différents services du cloud computing. 6 Figure 3 : Cloud Computing Infrastructure as a code. 8 Figure 4 : Comparaison entre l’architecture Monolithique celle des microservices. 9 Figure 5 : L’architecture de DevOps.
15 Figure 6 : Pipeline CICD. 16 Figure 7 : l’environnement bleu. 17 Figure 8 : l’environnement bleu. 18 Figure 9 : Déploiement bleu-vert.
19 Figure 10 : Architecture du pipeline initial. 38 Figure 11 : Architecture proposée. 41 Figure 12 : Eléments composants de notre infrastructure dans AWS. 42 Figure 13 : Structure du code source du projet.
49 Figure 14 : Connexion à notre instance EC2 en utilisant SSH. 51 Figure 15 : Connexion à notre instance EC2 en utilisant SSH. 52 Figure 16 : Configuration AWS CLI. 53 Figure 17 : Ajout de la paire de clés EC2 dans CircleCI.
54 Figure 18 : L’empreinte générée après l’ajout de la paire de clés EC2. 54 Figure 19 : Configuration automatique de la notification par courrier électronique. 57 Figure 20 : Echec de la tâche Ansible (build-backend). 57 Figure 21 : Exemple de notification par courriel suite à l’échec de la tâche (build-backend) 58 Figure 22 : Commande Ansible permettant de détruire l’environnement.
59 Figure 23 : Présentation de la tâche Ansible ‘configuration-infrastructure’. 61 Figure 24 : La commande Ansible ‘revert-migration’. 63 Figure 25 : Envoie le statut de la migration à un magasin clé-valeur tiers. 64 Figure 26 : Fichiers deploy-backend.yml et main.
66 Figure 27 : Pipeline d’intégration réussie. 69 Figure 28 : Fonctionnement de l’application. 72 Figure 30 : Temps de lecture du disque par seconde. 73 Figure 31: Quantité de mémoire disponible.
73 Figure 32 : Affichage de l’utilisation de l’unité centrale. 74 vii Figure 33 : Message d’alerte après l’arrêt de l’instance EC2 hébergeant le backend microservice. 77 viii Table des tableaux Tableau 1 : Symbologie. 21 Tableau 2 : Synthétisation de la comparaison des concurrents dans le domaine de gestion de codes sources.
25 Tableau 3 : Synthétise la comparaison des concurrents dans le domaine de provisionnement d’infrastructures. 28 Tableau 4 : Récapitulatif de comparaison des concurrents dans le domaine de gestionnaires de configuration. 32 Tableau 5 : Récapitulatif de comparaison des concurrents dans le domaine de gestionnaires de pipelines d’intégration. 34 Tableau 6 : Récapitulatif de comparaison des concurrents dans le domaine de la surveillance des applications.
36 Tableau 7 : Récapitulatif des choix. 38 Tableau 8 : Paramètres du serveur EC2. 71 ix Acronymes API – Application Programming Interface AWS – Amazon Web Services S3 – Simple Storage Service CD – Continuous Delivery CI – Continuous Integration HTTP – Hypertext Transfer Protocol HCL – HashiCorp Configuration Language IaaS – Infrastructure as a Service IaC – Infrastructure as Code IT – Information Technology JSON – JavaScript Object Notation PaaS – Platform as a Service SaaS – Software as a Service VCS – Version Control System YAML – Yet Another Markup Language SOAP – Simple Object Access Protocol REST – Representation State Transfert Protocol CORBA – Common Object Request Broker Architecture DSL – Domain-Specific Language x Organisation du manuscrit Lorsque vous éffectuez des travaux scientifiques, vous devez déterminer les objectifs et les résultats attendus ainsi que le plan de travail au début des travaux. Pour cela, il est nécessaire de définir le plan du document.
Fournir un schéma clair du travail effectué, l’état d’avancement est divisé en différents chapitres, comme suit : - Le premier chapitre fait l’introduction générale, présente l’entreprise d’accueil, présente le contexte de l’étude et motivation. - Le deuxième chapitre est consacré sur la spécification des technologies - Le troisième chapitre est consacré sur l’état de l’art, Etude comparative des outils DevOps. - Le quatrième chapitre présente la description de la solution proposée. - Le cinquième chapitre se concentre sur l’implémentation de la solution proposée.
- Et enfin la dernière partie va être consacrée pour la conclusion, la proposition des perspectives d’avenir. xi Chapitre 1 : Introduction générale L'avènement du Cloud Computing a entraîné d'énormes changements dans la façon dont les logiciels sont développés et distribués. Il n’est plus possible de patienter pendant six mois pour enfin livrer un logiciel. Une approche consiste à fréquemment publier de petites mises à jour associée à l'automatisation (entre autres pour les builds, la création de l'environnement et les tests) réduit le délai entre le développement et la publication, tout en rassurant sur la qualité du produit.
Pour y arriver il faut une parfaite collaboration entre les équipes de développement et d’exploitation deux équipes traditionnellement et dont les objectifs sont contradictoires. Les développeurs veulent être en mesure de publier rapidement de nouvelles fonctionnalités et des corrections de bugs afin de fournir de la valeur aux utilisateurs dès que possible.