Soutenance mémoire
Mémoire de stage de fin d’études master professionnel en nouvelles technologies des télécommunications et réseaux
Technologie Docker
Définition
Docker est une solution de virtualisation légère pour Linux créée en 2013 et possédant une forte dynamique de développement et de déploiement.
Docker est une plateforme permettant de construire, déployer, et lancer des applications cloisonnées.
Contrairement à d’autres systèmes de virtualisation légère comme OpenVZ ou LXC qui ont des approches purement « virtualisation » d’un système, Docker se place dans un cadre applicatif.
L’objectif est de permettre aux développeurs et administrateurs de créer facilement des « Dockerfiles » décrivant un système : packages, fichiers de configuration, ports utilisés, etc.
Cette description permet ensuite à n’importe qui possédant Docker de construire le conteneur applicatif, assurant ainsi un environnement compatible.
La virtualisation légère de Docker se base sur les fonctionnalités fournies par le kernel Linux comme les cgroups et les kernel namespaces, permettant de garder des performances attendues d’un système de virtualisation légère.
Poids léger
Les conteneurs en cours d’exécution sur une seule machine partagent tous le même noyau du système d’exploitation afin qu’ils commencent instantanément et de faire une utilisation plus efficace de la RAM. Les images sont construites à partir de systèmes de fichiers en couches afin qu’ils puissent partager des fichiers communs, ce qui rend l’utilisation du disque et de l’image de téléchargements beaucoup plus efficace.
Plateforme
La plateforme Docker est composée de deux éléments :
Le démon Docker qui s’exécute en arrière-plan et qui s’occupe de gérer les conteneurs Le client Docker qui permet d’interagir avec le démon par l’intermédiaire d’un outil en ligne de commande
Etude comparative : Pour mettre en place le pipeline d’intégration continue, nous avons besoin d’un ensemble d’outils à savoir, un gestionnaire de version, un orchestrateur, un serveur de dépôt maven et un serveur de qualité de code.
Dans cette partie, nous procédons à une étude comparative entre les différents outils qui existent sur le marché.
Gestionnaire de version : Git vs SVN Git et SVN sont les deux outils de gestion de version les plus répandu sur le marché, cidessous un tableau comparatif entre ces deux outils ce qui permettra par la suite d’effectuer notre choix technique.
Aspect SVN Git Architecture Centralisé, uniquement le répertoire central a l’historique complet des changements. Les utilisateurs doivent communiquer via le réseau avec le répertoire central pour obtenir l’historique. Les backup sont gérés et maintenu indépendamment du SVN. Distribué, tous les développeurs qui vérifient le code à partir d’un dépôt / serveur central auront leur propre référentiel cloné installé sur leur machine. Ce qui permet les développeurs de pouvoir créer une nouvelle branche, de faire un « commit » sur un fichier et de revoir une version même en absence de connexion.
Failure
Si le répertoire central est endommagé, alors uniquement les données enregistrées dans le dernier backup sont récupérable.
La notion de « single point of failure » n’existe pas car il y a autant de copie du dossier qu’il y’en a d’utilisateur si ce n’est plus.
Contrôle d’accès Nécessité d’un « commit access » due au fait de la centralisation.
Non nécessite d’un « Commit access » puisque le système est distribué. Il faut juste décider de fusionner quoi à partir de quel utilisateur.
Stockage contenu
Stockage des métadonnées des fichiers sous forme de dossier caché .svn
Stockage de tout le contenu dans un dossier .git, c’est le dépôt du code cloné sur la machine client.
Les branches Les branches sont gérées comme étant un autre dossier dans le dépôt du code, elles ne sont pas historiées. Pour connaître s’il y a eu fusion entre des branches, il faut explicitement exécuter une commande. Cette façon de gérer les branches démultiplie les chances de créer des branches « orpheline». Une fois la fusion est faite nous ne pouvons plus savoir ce qui a été modifié.
La gestion des branches est assez simple, nous pouvons facilement naviguer entre les différentes branches d’un même répertoire de travail. Chaque répertoire de travail existant chez un utilisateur est considéré comme une branche. La fusion de la branche inclut les informations suivantes : auteur, heure, date, informations relatives à la branche et à la révision, les changements effectués par rapport à la version antécédente. la fusion suivante, commence automatiquement là où la dernière fusion a été faite.
Espace Le répertoire de travail contient deux copie de chaque fichier, un pour travailler avec et un caché dans le .svn, ce qui rend l’espace nécessaire relativement grand.
Taille du dépôt de code et répertoire de travail relativement petit (30X inférieur à celui de SVN). Ceci est due au fait que pour Git, le répertoire de travail nécessite seulement un fichier d’index de taille 100 bits pour chaque fichier.
Cette comparaison a été faîtes pour un but académique, le choix du gestionnaire du code source a été fait par l’entreprise.
Serveur d’orchestration : Jenkins vs Bamboo vs Travis
Jenkins, travis et bamboo sont des outils d’orchestration bien connu sur le marché, chacun d’entre eux présente ses avantages et ses inconvénients. Le tableau 2 permet de comparer entre ces outils. La comparaison se base sur l’aspect Open source du code, le nombre de plugins, la simplicité d’utilisation et l’interfaçage avec les différents outils de gestion de version.
L’étude comparative entre ces différents serveurs d’orchestration a dirigé notre choix vers Jenkins, qui, grâce à ses nombreux plugins, permet un interfaçage facile avec de nombreux outils dont nous avons besoin tel que Nexus et Sonar.
Serveur de gestion de dépôt maven : Nexus vs JFrog Artifactory
L’utilisation d’un gestionnaire de dépôt maven a plusieurs utilités, le dépôt peut servir d’un backup sur les applications dont les artefacts sont déployés sur ces serveurs, les artefacts peuvent être utilisé comme des bibliothèques et peuvent être importé par les différents développeurs sur d’autres applications.
Nexus et JFrog Artefactory sont les deux gestionnaires de dépôts maven les plus répandu sur le marché.Ci-dessous nous présentons la comparaison entre ces deux outils, notre comparaison est basée sur :
Le code (open source ou non) Installation à base de docker et dockerfile Taille du jar.
Sonarqube vs SonarLint Le serveur de qualité de code a plusieurs atouts pour n’importe quel projet, en effet, il fournit une analyse complète de la qualité d’une application en fournissant de nombreuses statistiques.
Ces données permettent ainsi d’évaluer la qualité du code, et d’en connaître l’évolution au cours du développement.Ci-dessous nous présentons la comparaison entre ces deux outils, notre comparaison est basée sur :
Le code (open source ou non) Installation à base de docker et dockerfile Langage supportés et l’existance ou non du tableau de bord.Après cette comparaison, nous avons choisi de travailler avec Sonarqube comme serveur de qualité de code.
La différence entre les conteneurs et les machines virtuelles
Les conteneurs ont des avantages d’isolement des ressources et de répartition similaire à des machines virtuelles, mais une approche architecturale différente leur permet d’être beaucoup plus portables et efficaces.
Contrairement aux machines virtuelles traditionnelles, un conteneur Docker n’inclut pas de système d’exploitation, s’appuyant sur les fonctionnalités du système d’exploitation fournies par l’infrastructure sous-jacente.
Machine virtuelle : Chaque machine virtuelle comprend l’application, les binaires et les bibliothèques nécessaires et tout un système d’exploitation invité – qui peuvent être des dizaines de GBs taille.
Conteneur : Les conteneurs comprennent l’application et toutes ses dépendances, mais partagent le noyau avec d’autres conteneurs. Ils fonctionnent comme un processus isolé dans l’espace utilisateur sur le système d’exploitation hôte.
Choix de solution de virtualisation : Vu ses points forts, sa légèreté, son portabilité et l’isolation qu’il offert, nous avons décidés de choisir docker comme solution de virtualisation pour mettre en place notre plateforme d’intégration continue.
Les scripts YAML et Groovy Dans notre projet, nous avons utilisés deux types de scripts, yaml et groovy
YAML
Pour le développement des scripts, nous avons utilisés le langage de sérialisation YAML qui fournit de puissants paramètres de configuration, sans avoir à apprendre un type de code plus complexe comme CSS, JavaScript et PHP.
YAML est l’acronyme de «Yet Another Markup Language», il se définit comme étant « un standard de sérialisation de données pour tous les langages, facile à utiliser pour les humains ».
Standard : car il n’y a pas d’approximation à avoir sur le contenu écrit en YAML. Sérialisation de données : consiste en la transformation d’une structure de données en un fichier texte. Human-friendly : une structure de données écrite en YAML est très simple à lire, facile à comprendre, et facile à éditer. Groovy
Groovy est le nom d’un langage de programmation orienté objet destiné à la plate-forme Java. Il constitue une alternative au langage Java pour cette plate-forme et est inspiré de Python, Ruby et Smalltalk.
Groovy utilise une syntaxe très proche de Java, avec des accolades, et est directement compilé, soit à la volée dynamiquement, soit classiquement avec un compilateur en bytecode.
Groovy s’intègre et est entièrement compatible avec la JVM étant donné que le bytecode est le même. Il peut donc :
utiliser les bibliothèques Java ; être utilisé dans des classes Java.
Groovy peut être comparé à BeanShell, l’objectif de faire un langage de scripting proche de java est le même, la mise en œuvre étant différente.
Conclusion Au cours de ce chapitre, nous avons présenté les concepts de base de notre projet, nous avons définis l’intégration continue, son fonctionnement et ses composants, la virtualisation avec ses solutions en se focalisant sur la technologie Docker, et enfin nous avons décrit nos choix concernant les outils de virtualisation ainsi que les types de scripts utilisés qui seront le noyau de la partie réalisation.
|
Guide du mémoire de fin d’études avec la catégorie les différents composants d’une plate-forme d’IC |
|
Étudiant en université, dans une école supérieur ou d’ingénieur, et que vous cherchez des ressources pédagogiques entièrement gratuites, il est jamais trop tard pour commencer à apprendre et consulter une liste des projets proposées cette année, vous trouverez ici des centaines de rapports pfe spécialement conçu pour vous aider à rédiger votre rapport de stage, vous prouvez les télécharger librement en divers formats (DOC, RAR, PDF).. Tout ce que vous devez faire est de télécharger le pfe et ouvrir le fichier PDF ou DOC. Ce rapport complet, pour aider les autres étudiants dans leurs propres travaux, est classé dans la catégorie configuration avancé de jenkins où vous pouvez trouver aussi quelques autres mémoires de fin d’études similaires.
|
Mots clés : Intégration continue, virtualisation, docker, DevOps
Table des matières
Introduction générale
Chapitre 1 : Contexte général du projet
1.1. Introduction
1.2. Présentation de l’entreprise
1.2.1. Historique
1.2.2. Vision et mission
1.2.3. Les valeurs
1.2.4. Les services
1.2.5. Les solutions
1.2.6. Les partenaires
1.3. Cadre du projet
1.3.1. Etude de l’existant
1.3.2. Limite de l’existant
1.3.3. Solutions proposées
1.3.4. Architecture générale de la solution
1.4. Conclusion
Chapitre 2 : État de l’art
2.1. Introduction
2.2. Intégration continue
2.2.1. Définition de l’intégration continue
2.2.2. Fonctionnement de l’IC
2.2.3. Les étapes de l’Intégration Continue
2.2.4. Les différents composants d’une plate-forme d’IC
2.2.5. Les avantages de l’intégration continue
2.3. La virtualisation
2.3.1. Principe
2.3.2. Intérêts
2.3.3. Catégories de virtualisation
2.3.4. Présentation de l’Hyperviseur
2.4. Solutions de virtualisation
2.5. Technologie Docker
2.6. Etude comparative
2.6.1. Gestionnaire de version : Git vs SVN
2.6.2. Serveur d’orchestration : Jenkins vs Bamboo vs Travis
2.6.3. Serveur de gestion de dépôt maven : Nexus vs JFrog Artifactory
2.6.4. Sonarqube vs SonarLint
2.6.5. La différence entre les conteneurs et les machines virtuelles
2.7. Choix de solution de virtualisation
2.8. Les scripts YAML et Groovy
2.9. Conclusion
Chapitre3 : Réalisation
3.1. Introduction
3.2. Réalisation technique et environnement
3.2.1. Environnement de travail
3.2.2. Première connexion au serveur :
3.2.3. Manipulation technique via docker et docker-compose
3.2.4. Configuration avancé de jenkins
3.3. Réalisation fonctionnelle
3.4. Conclusion
Conclusion générale
Liste des Références
Annexe
Télécharger le rapport complet
