Soutenance mémoire
Les sciences de l’information apportent beaucoup au domaine médical. Elles permettent d’effectuer de nombreux calculs et algorithmes sur de grandes bases de données. Cela permet à de nombreux projets d’avoir facilement accès à l’information. Avec l’arrivée d’internet puis, aujourd’hui, du big data, de nouveaux enjeux sont apparus [1] [2] [3]. L’un d’entre eux est de rendre accessible ladite information. Un autre est de fournir un environnement de calcul puissant aux chercheurs dans un contexte protégé. Lesdites données sont souvent soumises aux closes de confidentialités médicales.
Une difficulté qui apparaitra souvent lorsque l’on cherche à fournir un tel environnement à des chercheurs est le contexte d’exécution. Aujourd’hui, il existe des dizaines de langages de programmation fonctionnant tous sur des compilateurs différents, et possédant tous des centaines de versions différentes. Nous rencontrons un réel problème pour déplacer et déployer facilement un écosystème dans les puissants centres de calculs.
Docker est une application permettant l’encapsulation d’un environnement à l’intérieur d’une boîte appelée conteneur. Celui-ci pourra ensuite être déplacé ou exécuté de manière simple, indépendamment du système hôte [3].
Docker Engine
Docker est une plateforme open source permettant l’encapsulation de parties de logiciels dans un système indépendant du reste de l’ordinateur. Il sera donc possible d’y ajouter différents codes, librairies et logiciels sans pour autant modifier le système hôte. Cela fournit la garantie que l’exécution encapsulée dans Docker sera toujours la même, indépendamment de l’endroit où le conteneur sera exécuté [4].
Ce procédé est bien plus léger qu’une solution utilisant des machines virtuelles, puisqu’ici seuls les composants logiciels seront encapsulés. Un nouvel OS n’est pas nécessaire pour chaque application. Nous allons nous contenter d’encapsuler tous les composants nécessaires, et cela indépendamment les uns des autres.
Il est à noter que Docker étant basé sur des technologies Linux, Il ne fonctionne que sur cet OS. Il est cependant possible de l’exécuter sur d’autres systèmes d’opérations grâce à un mélange entre machine virtuelle et Docker . Au moment de la réalisation de ce travail, l’entreprise qui a créé Docker travaille activement sur une solution pour pouvoir l’utiliser sous Windows et OSX. Comme tout va très vite en ce moment dans ce domaine, et si le temps le permet, il sera peut-être possible d’essayer la beta du système sous Windows 10.
Le Docker Engine est le cœur de l’application. Il permet la création, l’exécution, et le lancement d’images Docker sur un système. Il s’agit donc de la pièce maîtresse du logiciel. Le contrôle de l’application se fait uniquement dans le terminal via des commandes personnalisées.
Avant de commencer à expliquer comment fonctionne Docker, il est important de comprendre la notion d’image et de conteneur. Une image est une « couche » contenant une configuration, ou un logiciel encapsulé. Les images sont organisées en pyramide, les unes sur les autres. Par exemple, si l’on veut créer une image d’un serveur Debian exécutant un serveur web, nous partirons de l’image Debian et y ajouterons une couche avec la version d’Apache désirée.
Pour définir une image, Docker se base sur un fichier de définition, appelé «Dockerfile ». Celui-ci doit contenir toutes les informations nécessaires pour la construction d’une nouvelle image. Lorsque nous construisons une image, nous effectuons un Docker build. Notons également que Git, la solution de gestions de versions, fait partie intégrante de Docker Engine. Il est donc très facile de partager ses images via un hub centralisé . Un conteneur se trouve au sommet de la pyramide des images. Il permet l’exécution de celles-ci. Là où une image n’est qu’une sorte de « modèle », le conteneur est un élément active. Il est d’ailleurs possible de lancer plusieurs conteneurs basés sur la même image. Quand on veut créer un conteneur, nous effectuons un Docker run. Notez que si une image prend en compte toutes les modifications écrites à l’intérieur, ce n’est pas le cas des conteneurs. Au moment de l’arrêt, le conteneur est supprimé. Il faut donc être prudent lors de l’exécution de systèmes de données. Tout doit être enregistré en dehors du conteneur ! Il n’est pas difficile d’organiser cette liaison grâce aux volumes.
Les volumes
Pour pallier au problème de la persistance des données dans un conteneur, il existe une solution : Les volumes. Ils permettent de traverser l’environnement encapsulé et de faire un lien vers l’hôte. Cela veut dire que le conteneur partagera un de ses dossiers avec l’hôte. Le système est assez proche d’un partage de fichier standard.
Les volumes se déclarent lors d’un « Docker run » avec l’argument v. Il faudra ensuite simplement lier un dossier de l’hôte physique avec celui provenant du conteneur. Leurs contenus seront ensuite toujours identiques.
conteneur et, dans notre cas, de lui fournir les informations nécessaires à ses calculs. Il est aussi possible de partager un même volume entre deux conteneurs pour leurs permettre de communiquer. Pour ce travail, les volumes seront une fonctionnalité clé. Ils permettront de rendre les données des bases internes disponible dans l’environnement encapsulé.
Docker Compose
Docker Compose est un outil qui permet de définir et d’exécuter une application multi-conteneur . Avec cette fonctionnalité, il sera possible de définir un fichier de composition qui permettra ensuite de lancer un environnement composé de plusieurs conteneurs. Compose permet également la prise en charge de diverses options entrées normalement dans le terminal. Il permet donc également de simplifier le lancement grâce à ce plan d’exécution. C’est un outil très pratique pour définir la manière dont un environnement doit s’exécuter et les relations entre les conteneurs.
Docker Remote API
Docker Engine comprend une API (web services) proche du standard REST nommée Docker Remote API . C’est elle qui permet la communication entre plusieurs applications exécutant Docker. C’est également elle qui va nous permettre de créer une interface de contrôle afin de maîtriser notre environnement encapsulé. Dans ce travail, Remote API va nous permettre de gérer la communication entre nos éléments. Il s’agit d’un élément standardisé très ouvert qui va nous laisser beaucoup de possibilités.
Registry Server
Dans une utilisation classique de Docker, les images sont stockées directement sur l’hôte depuis lequel l’image a été construite. Cela ne permet pas d’assurer la pérennité de l’image. Pour remédier à ce problème, la société Docker propose une intégration native à son Docker Hub. Il s’agit d’un serveur utilisant Git permettant de sauvegarder ou de partager facilement des images sur le cloud. Malheureusement, ces images, sauvegardées sur le Hub, serons stockées sur les serveurs appartenant à Docker. Nous perdrons donc une partie du contrôle de ces images, puisque nous ne savons pas où elles sont stockées physiquement. Cela peut poser un problème du point de vue de la confidentialité.
|
Table des matières
Introduction
2.1 Contexte et motivation
2.2 Objectifs
2.3 Résumé
3 Méthodes
3.1 Outils Docker
3.1.1 Docker Engine
3.1.2 Les volumes
3.1.3 Docker Compose
3.1.4 Docker Remote API
3.1.5 Registry Server
3.1.6 Docker Swarm
3.1.7 Docker Machine
3.2 Autres Outils
3.2.1 Virtualisation VMware
3.2.2 Jenkins avec plugin Docker
3.2.3 Apache http Server
3.2.4 Web service PHP
3.2.5 Nginx
3.2.6 Serveur Linux
3.2.7 Certificat Let’s Encrypt
4 Résultats
4.1 Prise en main des outils
4.1.1 Installation sous Windows 10
4.1.2 Docker Engine
4.1.3 Provisionnement en image
4.1.4 Conteneur avec un serveur web
4.2 Docker Remote API
4.2.1 Création d’un environnement de travail client – serveur
4.2.2 Initialisation de l’API
4.3 Registry privée
4.3.1 Création de la Registry
4.3.2 Pousser une image
4.3.3 Utiliser les images stockées
4.4 Recherche d’une méthode de contrôle
4.4.1 Plateforme de CI avec Jenkins : installation
4.4.2 Plateforme de CI avec Jenkins : utilisation
4.4.3 Plateforme de CI avec Jenkins : Gestion des utilisateurs
4.4.4 Plateforme de CI avec Jenkins : Synthèse
4.4.5 Shipyard
4.4.6 Web service en PHP
4.5 Comparaison des méthodes de contrôle
4.5.1 Complexité de Jenkins
4.5.2 Lacunes de Shipyard
4.5.3 Adaptabilité des services web
4.5.4 Synthèse
4.6 Déploiement
4.6.1 Installation de Docker
4.6.2 Registry sécurisée
4.6.3 Méthode de contrôle
4.7 Performances de Docker contre les VMs
4.8 Docker et le GPU computing
4.9 Recyclage des images
4.10 Sécurité de l’environnement
5 Conclusion
Télécharger le rapport complet
