La technologie de Docker

La technologie de Docker

Les avantages de la solution de conteneurs/docker

Dans le domaine du Web ainsi que dans le domaine de l’IT, l’utilisation de Docker possède plusieurs avantages. Les services IT fournissent de plus en plus de services orientés web, les conteneurs pourraient être un élément clef permettant la transitions des services IT vers le cloud.

Légèreté des conteneurs
Par opposition à un serveur virtuel sous Linux, le conteneur n’a besoin que de quelques centaines Mo de disques. De même l’empreinte mémoire est réduite, car nous n’avons que de la mémoire employée pour l’application (pas de couche OS). Il est ainsi avec démarrage plus rapide aussi le conteneur peut être facilement déplacé d’une machine à une autre.

Rapidité et facilité de déploiement des applications
Après avoir récupérer un template en une commande, et afin d’exécuter le conteneur il nous suffit une autre commande, celui-ci démarre en quelques secondes. Lors du démarrage, des paramètres peuvent être ajoutés en les transmettant au conteneur. Par exemple, la spécification de l’accès à la base de données ou d’autres paramètres d’automatisation.
L’idéal consiste à mettre en place une gestion de configuration, grâce à elle, les conteneurs deviennent autonomes. Ces conteneurs seront gérés comme un package logiciel. Cette facilité aide le développeur à provisionner les environnements qui sont déployés en production par exemple sans connaissance particulière d’infrastructures ou d’administration système.

Portabilité et multicloud
Il y a peu de formats d’enveloppes virtuelles qui soient nativement multi-Cloud. Il est toujours compliqué de récupérer sur sa ferme VMware son POC fait sur AWS, ou encore migrer sa machine virtuelle Open stack sur une Ressource Group Azure.

Les Facteurs et les concepts 

 Les facteurs
Code base • Un logiciel de suivi de version (git, mercurial, …) gère les code. • Une application = code source
Dependencies
• Préciser clairement toutes les dépendances. • Le système cible n’est pas censé inclure de programme pré-installé. • absence de dépendances implicites.
Config
• On considère une configuration, tout ce qui diffère d’un environnement à l’autre (dev, qualif, prod, autre site). • les élément de configuration doivent être passé par des variables d’environnement. • Aucune référence ne figure à la configuration dans le code.
Backing Services
• Il s’agit d’ une ressource externe au conteneur (base mysql, smtp, activemq, memcache, …). • L’accès à ces ressources se fait en paramètre. Pas de différence entre les services locaux et distants.
Build, release, run
• L’application et l’environnement sont recréés avant tout déploiement d’une nouvelle version. • On apporte aucune modification sur l’application déployée. • A chaque version déployée on accorde un numéro de version unique (timestamp, numero de commit, …).
Création de conteneurs (Build)
• Notion d’image qui permet une construction multicouche des conteneurs
• Il est possible de créer une nouvelle image tout en modifiant une image existante
Dépôts de conteneurs (Ship)
Search Rechercher d’images sur le Docker Hub
pull, push Récupérer / envoyer d’image depuis / sur un dépôt (par défaut le Docker Hub)• Plusieurs images officielles (gcc, python, ruby, java, golang, , haskell, centos, perl, , debian, fedora, ubuntu, …)
• Plusieurs images publiques d’utilisateurs ou d’organisations
• Versionnage des images
Build Génération automatisée d’images avec langage de script spécialisé dans un Docker file, exemple : FROM docker/whalesay:latest RUN apt-get -y update && apt-get install -y fortunes CMD /usr/games/fortune -a | cowsay
Commit Création d’une image à partir des modifications lors de l’exécution d’un conteneur
History Affichage de l’historique d’une image (couches avec possibilité de dépiler)
save, load, export, import
•Sauvegarde et rechargement d’images et de conteneurs
• Possibilité d’employer son propre dépôt avec Docker Registry, notamment disponible sous forme d’image Docker officielle.

Exécution et supervision de conteneurs (Run)

Daemon Lancer la partie serveur (démon) de l’architecture client/serveur de Docker
Run Lancer une commande dans un nouveau conteneur construit à partir d’une image
start, stop, restart, pause, unpause, kill
Contrôler l’exécution des conteneurs
ps, logs, top, stats Surveiller des conteneurs
• Plusieurs conteneurs se lient via des liens réseau
• Le partage et la persistance de données se font en utilisant de volumes pour
• Coordonner l’exécution de multiples conteneurs (Docker Compose) est possible
i. Processus
• L’application est effectuée dans l’environnement d’exécution en tant qu’un ou plusieurs processus. • Stockage de toutes les données dans une ressource externe (base de données). • Le non stockage local des variables de sessions utilisateurs.

Port binding
L’application donne un service qui écoute sur un port.

Concurency
• Possibilité de mettre à l’echelle chaque application. Pour répartir la charge, les conteneurs peuvent être lancés x fois. • Le programme dans le conteneur ne peut pas être lancé en tâche de fond.
• L’arrêt du conteneur suite à l’arrêt du programme.

Disposability • Le conteneur doit être à usage unique. • Il peut être lancé très rapidement. • Un arrêt inopportun ne doit pas détériorer les données.

Dev/prod parity
• dés qu’il finit la saisie du code le développeur doit pouvoir le déployer rapidement. • Le responsable du dévéloppement doit être plus proche du déploiement (DevOps).
• Maintenir la production et le développement aussi semblables que possible en utilisant les mêmes outils. Pour limiter les surprises en production, éviter de prendre des backends différents en prod et en dev (ex: base de données, …)

Logs
• Pour la visualisation et l’archivage à long terme, les applications doivent externaliser leurs journaux • Posibilité d’afficher les journaux dans la sortie standard de l’application, mais pas dans un fichier du conteneur. o. Admin process • Les commandes d’administration doivent être saisies dans un environnement semblables aux autres processus d’exploitation. • Mêmes variables d’environnement, même conteneur, mais en mode conversationnel

Table des matières

Introduction générale
Chapitre 1 : Etude de l’existant
Introduction
I. Présentation de la société Devercipe
II. Critique de l’existant
III. Solution proposée
Conclusion
Chapitre 2: Etat de l’art
Introduction
I. La technologie de Docker
II. Comparaison entre virtualisation classique et Docker
III. Les avantages de la solution de conteneurs/docker
IV. Les Facteurs et les concepts
Conclusion
Chapitre 3: Analyse et spécification de besoin
Introduction
I. Analyse de besoin
II. diagramme de cas d’utilisation
Conclusion
Chapitre 4 : Conception
Introduction
I. Description des diagrammes
II. Architecture MVC
Conclusion
Chapitre 5 : Réalisation
Introduction
I. Environnement de travail
II. Captures d’écran
Conclusion
Conclusion génerale

Télécharger le rapport complet