IMA4 2018/2019 P30

Présentation générale

Description

L'intitulé de mon projet est "Système minimal de gestion de conteneurs", il consiste à réaliser une solution logicielle permettant de créer, détruire, configurer et lister des conteneurs.

Un conteneur Linux est un ensemble de processus qui sont isolés du reste du système. Un conteneur s'exécute à partir d'une image distincte qui fournit tous les fichiers nécessaires à la prise en charge des processus qu'il contient :

• Les caractéristiques systèmes : taille mémoire maximale, nombre de CPUs utilisés, débit disque maximal etc.
• Une configuration réseau : liste de commutateurs virtuels de rattachement avec leurs adresses.

En fournissant une image qui contient toutes les dépendances d'une application, le conteneur assure donc la portabilité de l'application entre les divers environnements (développement, test puis production) ainsi que la scalabilité.

Les conteneurs sont une solution au problème de la façon dont les logiciels peuvent fonctionner de manière fiable lorsqu'ils sont déplacés d'un environnement informatique à l'autre. Cela pourrait être du portable du développeur à un environnement de test, d'un environnement de test à la production, et peut-être d'une machine physique dans un centre de données à une machine virtuelle dans un cloud privé ou public.

Conteneur

Les avantages majeurs de l'utilisation des conteneurs sont :

1. La taille : En effet un conteneur prend quelques dizaines de mégaoctets de taille, contrairement à une VM qui peut prendre plusieurs Gigabytes à cause de son système d'exploitation.Ce qui rend l'utilisation des conteneurs très populaire sur les serveurs qui peuvent en contenir plusieurs. Et dans le cloud où l'on paie ce qu'on consomme.
2. Le temps : Une application conteneurisée peut être démarrée instantanément et quand il est nécessaire peut disparaître libérant des ressources sur son hôte tandis que les machines virtuelles peuvent prendre plusieurs minutes pour démarrer leurs systèmes d'exploitation et commencer à exécuter les applications qu'ils hébergent.

- La modularité : Plutôt que d'exécuter une application complexe entière dans un seul conteneur, l'application peut être divisée en modules (tels que la base de données, l'interface avant de l'application, etc.) Les applications créées de cette manière sont plus faciles à gérer car chaque module est relativement simple et des modifications peuvent être apportées aux modules sans avoir à reconstruire l'application entière. Étant donné que les conteneurs sont si légers, les modules individuels (ou micro services) ne peuvent être instanciés que lorsqu'ils sont nécessaires et sont disponibles presque immédiatement. Avec une telle architecture, on suit la philosophie UNIX du “KISS”

• Les applications n’ont pas de dépendance système.
• Les mises à jours sont déployables facilement.
• La consommation de ressources est optimisés.

Les containers sont donc proches des machines virtuelles, mais présentent des avantages importants. Alors que la virtualisation consiste à exécuter de nombreux systèmes d’exploitation sur un seul et même système, les conteneurs se partagent le même noyau de système d’exploitation et isolent les processus de l’application du reste du système.

Plutôt que de virtualiser le hardware comme l’hyperviseur, le conteneur virtualise le système d’exploitation. Il est donc nettement plus efficient qu’un hyperviseur en termes de consommation des ressources système.

Concrètement, il est possible d’exécuter près de 4 à 6 fois plus d’instances d’applications avec un conteneur qu’avec des machines virtuelles comme Xen ou KVM sur le même hardware.

VM

Conteneur

Objectifs

Ce projet peut se découper en cinq grandes parties :

1. Commencer par faire un état de l'art afin de me forger des connaissances solides sur les conteneurs et leurs orchestration.
2. Créer, configurer et supprimer des conteneurs "à la main".
3. Créer un programme shell (qu'on lance dans le contexte d'un conteneur) qui permet d'automatiser la gestion des conteneurs, pour :

1. • Lancer une instance.
   • Lister les instances en cours d'exécution (identifiant, nom de l'image d'origine, temps d'exécution) tout en mettant à jour le fichier des instances (s'il le faut).
   • Arrêter une instance, détruire ses ressources réseau tout en conservant son image disque dans un état stable ainsi que ses caractéristiques.
   • Suppression d'une instance avec la destruction de son image disque et ses caractéristiques.
2. Stocker les informations sur les conteneurs qui tournent dans un fichier texte, paramétrer finement la configuration réseau.
3. Mettre en place une application de test : une architecture de ferme de serveurs Web privée avec un accès par mandataire inverse. Les serveurs Web et le mandataire inverse seront des conteneurs.

Analyse du projet

Positionnement par rapport à l'existant

Lorsqu'on parle aujourd'hui de gestion de conteneurs on parle systématiquement de la solution Docker. Mon automatisation de cette gestion ne pourra bien évidemment jamais concurrencer Docker. Le but ici, est de réussir à reproduire un système de gestion minimal ressemblant à Docker en plus simple et de parvenir à le maîtriser.

Analyse du premier concurrent

Docker Enterprise Edition est sans doute la solution de gestion de conteneurs commerciale la plus connue. Il fournit une plate-forme intégrée, testée et certifiée pour les applications exécutées sur les systèmes d'exploitation Linux ou Windows et les fournisseurs de cloud. L’écosystème de Docker est riche et complet, cela va de la gestion de conteneurs, à l’orchestration (Docker Swarm ou son concurrent Google Kubernetes) tout en passant par la gestion du réseau, de l’intégration du cloud avec Docker machine, des application multi conteneurs avec Docker Compose.

Aujourd’hui, selon les créateurs de Docker, plus de 3,5 millions d’applications ont été containérisées en utilisant cette technologie, et plus de 37 milliards d’applications containérisées ont été téléchargées.

De même, d’après le système de monitoring cloud DataDog, 18,8% des utilisateurs avaient adopté la plateforme en 2017. De son côté, RightScale estime que l’adoption de la plateforme dans l’industrie du Cloud a augmenté de 35% en 2017 à 49% en 2018. Des géants comme Oracle et Microsoft l’ont adopté, au même titre que presque toutes les entreprises du Cloud.

Analyse du second concurrent

LXC est un système de virtualisation, utilisant l'isolation comme méthode de cloisonnement au niveau du système d'exploitation. Il est utilisé pour faire fonctionner des environnements Linux isolés les uns des autres dans des conteneurs partageant le même noyau et une plus ou moins grande partie du système hôte. Le conteneur apporte une virtualisation de l'environnement d'exécution (processeur, mémoire vive, réseau, système de fichier…) et non pas de la machine. LXC repose sur les fonctionnalités des cgroups du noyau Linux disponibles depuis sa version 2.6.24. Il repose également sur d'autres fonctionnalités de cloisonnement comme le cloisonnement des espaces de nommage du noyau, permettant d'éviter à un système de connaître les ressources utilisées par le système hôte ou un autre conteneur. Docker était un gestionnaire de conteneurs initialement basé sur LXC.

Scénario d'usage du produit ou du concept envisagé

Toto est un développeur pas très à la mode, il ne connaît pas Docker! Il a de modestes connaissances en système et il essaye de développer une application. Il travaille sur un ordinateur portable ayant une configuration spécifique, avec des librairies et paquets spécifiques.

Les collègues développeurs de Toto travaillent sur des machines présentant des configurations légèrement différentes.

L'application que Toto développe repose sur cette configuration et dépend de librairies et de paquets avec une version particulière.

En parallèle, l'entreprise de Toto dispose d'environnements de test et de production qui ont leurs propres systèmes d’exploitation avec une version particulière ainsi que leurs propres paquets et librairies. Toto souhaite émuler ces environnements autant que possible localement, mais sans avoir à payer les coûts liés à la recréation des environnements de serveur. Comment faire pour que son application en développement puisse fonctionner dans ces environnements, passer l'assurance qualité et être déployée sans prise de tête, sans réécriture et sans correctifs ?

La réponse est simple : il lui suffit d'utiliser des conteneurs. Le conteneur qui accueille son application contient toutes les configurations et librairies nécessaires. Il peut ainsi le déplacer entre les environnements de développement, de test et de production, sans aucun effet secondaire. La crise est évitée,Toto pourra continuer à travailler et ne se fera pas licencié, il travaillera plus efficacement, apportera un gain de temps et d’argent à son entreprise et ne se cassera plus la tête à considérer le système présent sur les environnements de production et de tests. De plus, il utilisera le système de gestion de conteneurs que je lui réserve !

Les conteneurs Linux peuvent aussi être utilisés pour résoudre des problèmes liés à des situations qui nécessitent un haut niveau de portabilité, de configurabilité et d'isolation. Quelle que soit l'infrastructure (sur site, dans le cloud ou hybride), les conteneurs répondent à la demande.

Réponse à la question difficile

La question difficile qui m'a été posée était mes avantages par rapport à mon premier concurrent : Docker, c'est à dire pourquoi utiliserait-on un système léger de gestion de conteneurs plutôt que Docker.

Pour répondre à cette question, il faut comprendre comment Docker fonctionne : Docker est un logiciel modulaire qui comprend plusieurs couches. L'une de ses couches est le docker deamon (dockerd), le deamon est codé afin d'exposer une API REST. Ainsi, il est bind sur des sockets au sein de la machine.

L'autre inconvénient de Docker c'est qu'il va manipuler les Iptables (https://docs.docker.com/network/iptables/) afin de pouvoir gérer le réseau des conteneurs, cela peut venir perturber les configurations réseaux déjà présentes sur la machine. Mon système n'utilisera que les commutateurs logiciels (bridges linux) standards. Ainsi, il n'y aura aucune altération du routage des paquets au sein de la machine.

De plus je n'utiliserai pas de gestion sophistiquée des images à base de système de fichiers à couche. Avant de lancer un conteneur le système de fichiers (un fichier lui-même) est copié, et le conteneur est démarré sur cette copie.

Préparation du projet

Choix techniques : matériel et logiciel

Ce projet est purement informatique, il ne nécessite aucun matériel. Par contre au moment où je ferai l'infrastructure avec les conteneurs, j'aurai besoin d'un serveur.

Liste des tâches à effectuer

- État de l’art de la conteneurisation.

- Créer, configurer et supprimer des conteneurs "à la main".

- Créer un script shell pour: Lancer une instance, lister les instances en cours d'exécution, les arrêter ou encore les supprimer.

- Stocker les informations des conteneurs.

- Paramétrer la configuration réseau.

- Mettre en place une application de tests avec des conteneurs (infrastructure ferme serveurs web avec accès par mandataire inverse).

Calendrier prévisionnel

Le projet étant à rendre au mois de Mai, prenant en compte une marge d'erreurs et d'améliorations éventuelles, le calendrier prévisionnel optimal que je me suis fixée se trouve sur le diagramme de Gantt suivant :

Réalisation du Projet

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S7	Heures S8	Heures S9	Heures S10	Total
Analyse du projet	0