Version du 6 février 2019 à 16:54

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 :

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.
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 :

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

- 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.

Stocker les informations sur les conteneurs qui tournent dans un fichier texte, paramétrer finement la configuration réseau.
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

Rocket (rkt) est un outil édité par CoreOS et est le concurrent de Docker. c'est un moteur de conteneur d'application développé pour les environnements de production modernes basés sur le cloud. Il présente une approche pod-native, un environnement d’exécution enfichable et une surface bien définie qui le rend idéal pour une intégration avec d’autres systèmes.

L'unité d'exécution principale de rkt est le "pod": un ensemble d'une ou plusieurs applications s'exécutant dans un contexte partagé (les pods de rkt sont synonymes du concept du système d'orchestration Kubernetes). Rkt permet aux utilisateurs d'appliquer différentes configurations (telles que les paramètres d'isolation) au niveau du pod et au niveau plus granulaire par application. L’architecture de rkt signifie que chaque pod s’exécute directement dans le modèle de processus Unix classique (c’est-à-dire qu’il n’ya pas de démon central), dans un environnement isolé et autonome. rkt implémente un format de conteneur standard moderne et ouvert, la spécification App Container (appc), mais peut également exécuter d'autres images de conteneur, telles que celles créées avec Docker.

Depuis son introduction par CoreOS en décembre 2014, le projet rkt a considérablement mûri et est largement utilisé. Il est disponible pour la plupart des principales distributions Linux et chaque version de rkt construit des packages rpm / deb autonomes que les utilisateurs peuvent installer. Ces packages sont également disponibles dans le référentiel Kubernetes pour permettre de tester l'intégration rkt + Kubernetes. rkt joue également un rôle central dans la manière dont Google Container Image et CoreOS Container Linux exécutent Kubernetes. Les éditeurs se concentrent sur la sécurité (le plus gros point faible de Docker), la compatibilité et une intégration aux standards. Le but étant de fournir les mêmes fonctionnalités que docker et être complémentaires.

Docker comparé à Rkt

Sécurité de l'image du conteneur :

L’un des avantages de Docker est qu’il existe un registre public à partir duquel tout le monde peut télécharger des images optimisées du serveur d’applications. Donc, si vous voulez un serveur Nginx optimisé pour une application Web Magento, vous en obtiendrez un du registre Docker. Cependant, il y a un danger caché à cela. Un attaquant peut remplacer une image de serveur par une autre infectée par un logiciel malveillant. Avant la version 1.8, Docker n’avait aucun moyen de vérifier l’authenticité d’une image de serveur. Mais dans la version 1.8, une nouvelle fonctionnalité appelée Docker Content Trust a été introduite pour signer et vérifier automatiquement la signature d'un éditeur. Dans rkt, la vérification de la signature est effectuée par défaut. Ainsi, dès qu'une image de serveur est téléchargée, elle est vérifiée avec la signature de l'éditeur pour voir si elle est falsifiée.

Prévention des attaques d'élévation de privilèges «root»

Docker s'exécute avec les privilèges de super-utilisateur «root» et crée de nouveaux conteneurs en tant que sous-processus. Le problème avec cela est qu'une vulnérabilité dans un conteneur ou un confinement médiocre peut donner à un attaquant un accès de niveau racine au serveur entier. Rkt a proposé une meilleure solution: les nouveaux conteneurs ne sont jamais créés à partir d'un processus root. De cette manière, même si une rupture de conteneur se produit, l'attaquant ne peut pas obtenir les privilèges root.

Flexibilité dans la publication ou le partage d'images

Lors du développement d'applications, il peut être nécessaire de partager des images de conteneur avec vos partenaires technologiques. Si vous souhaitez partager des conteneurs Docker, vous devez configurer un registre privé spécial sur vos serveurs ou l'héberger dans un compte payant Docker pour le partager avec vos partenaires. Pour rkt, vous n’avez besoin que de votre serveur Web. Rkt utilise le protocole HTTPS pour télécharger des images et utilise une méta-description sur le serveur Web pour pointer vers l'emplacement. C’est donc un serveur de moins à maintenir et plus facile à accéder pour les partenaires.

Taille de la base de code

Docker ajoute toutes ses fonctionnalités à un seul fichier programme monolithique, ce qui signifie que le nombre de lignes de code ne cesse d’augmenter à chaque nouvelle version. Et voici un problème de sécurité. Une seule vulnérabilité dans l'une des milliers de lignes de code peut compromettre l'intégralité du programme et donner essentiellement un accès root à un attaquant. Au contraire, rkt utilise a une architecture modulaire dans laquelle les fonctionnalités sont développées sous forme de fichiers binaires indépendants par différents fournisseurs. Le code de base est maintenu aussi petit que possible afin de réduire la surface d'attaque. Cela garantit que même si un sous-composant tel que etcd est compromis, les dommages seraient limités à ceux auxquels ce programme peut accéder.

Portabilité à d'autres systèmes de conteneurs

De nouveaux systèmes de conteneurs sortent tout le temps. Avec Docker, la migration vers une nouvelle technologie de conteneur peut poser problème, car elle utilise un format d’image propriétaire. En revanche, rkt utilise un format de conteneur open source appelé «appc». Ainsi, toute image de serveur créée à l'aide de rkt peut être facilement portée vers un autre système de conteneur à condition qu'elle suive le format ouvert «appc». En adhérant à un standard ouvert, rkt n’impose pas de verrouillage du fournisseur. Cela aide les propriétaires de système à migrer sans peine vers un autre système de conteneur mieux adapté à leurs besoins.

https://bobcares.com/blog/docker-vs-rkt-rocket/

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

Cahier des charges

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 ainsi qu'une machine virtuelle.

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
Analyse du projet	2	2	2	2	2	2	2	2	2	2	2
Etat de l'art 2	8
Création-configuration des conteneurs à la main		6	5	4
Script Shell
Gestion du stockage des informations des conteneurs
Paramétrage de la configuration réseau
MIse en application de l'application des tests

Prologue

Semaine 1

La première semaine a été dédiée à l'instauration de l'état de l'art des conteneurs. Et ce, afin de me familiariser et d'en apprendre un maximum sur le sujet, comprendre les subtilités de leur utilité ainsi que leurs évolution dans le temps.

Semaine 2

Durant cette semaine, il m'a été recommandé de réaliser des TP dédiés aux GIS sur la virtualisation et me familiariser avec les commandes permettant de créer des conteneurs à la main, ce que j'ai réussis à faire, une fois arrivée à la partie où il faut limiter/ restreindres les cpu, la mémoire, le nombre d'entrées/sortes ou encore l'interdiction d'accès à des périphériques, les commandes fonctionnaient mais il fallait tester si elles fonctionnent bien et qu'elles délimitent bien. Il a fallut trouver des idées pour tester la mémoire par exemple : allouer de la mémoire en boucle infinie et renvoyer le nombre de fois où ça a été fait afin de vérifier que ça respcte bien la taille donnée dans le cgroup. Cela ne fonctionnait point, et la compréhension des cgroups m'a prise plus de temps que prévu , ce qui m'a retardé...

Semaine 3

Semaine 4

Semaine 5

Semaine 6

Semaine 7

Semaine 8

Semaine 9

Semaine 10

Etat de l'art

Définition :

Un conteneur Linux est un processus ou un ensemble de processus isolés du reste du système. Tous les fichiers nécessaires à leur exécution sont fournis par une image distincte, ce qui signifie que les conteneurs Linux sont portables et fonctionnent de la même manière dans les environnements de développement, de test et de production. Ainsi, ils sont bien plus rapides que les pipelines de développement qui s'appuient sur la réplication d'environnements de test traditionnels.

L’utilité de la conteneurisation :

L'incidence de la virtualisation sur l'informatique moderne est profonde. Elle permet aux entreprises d'améliorer considérablement la rentabilité et la flexibilité des ressources informatiques. Mais la virtualisation a un coût, notamment au niveau de l'hyperviseur et des systèmes d'exploitation invités, qui requièrent chacun de la mémoire et de coûteuses licences. Il en résulte une augmentation de la taille de chaque machine virtuelle, ce qui limite le nombre de VM qu'un serveur peut héberger. La résurgence de la conteneurisation vise à virtualiser les applications sans trop alourdir le système. L'idée n'est pas nouvelle : depuis plusieurs années déjà, des systèmes d'exploitation tels que OpenVZ, FreeBSD, Solaris Containers et Linux-VServer prennent cette fonctionnalité en charge comme élément central de l'évolutivité Cloud. Mais c'est la récente introduction de plateformes ouvertes, telles que Docker, qui a remis sous les feux de la rampe la conteneurisation et son potentiel en matière d'applications distribuées évolutives.

Evolution :

La plupart des applications tournent sur des serveurs. Dans le passé, nous ne pouvions exécuter qu’une seule application par serveur. Le monde des systèmes ouverts de Windows et Linux n’avait pas les technologies pour exécuter en toute sécurité plusieurs applications sur un même serveur. Bien sûr, chaque fois que l’entreprise a besoin d’une nouvelle application, le service informatique allait acheter un nouveau serveur. Et la plupart du temps personne ne connaissait les exigences de performance de la nouvelle application! Cela signifie que le service informatique devait deviner lors du choix le modèle et la taille des serveurs à acheter. En conséquence, le service informatique a fait la seule chose à faire: acheter de gros serveurs rapides avec beaucoup de résilience. Après tout, la dernière chose que quelqu'un souhaitait, y compris l'entreprise, était des serveurs sous-alimentés. Les serveurs sous-alimentés peuvent être incapables de s'exécuter, transactions pouvant entraîner une perte de clients et de revenus. Alors, l’IT généralement achetait des serveurs plus gros que ce qui était réellement nécessaire. Cela a entraîné une énorme nombre de serveurs fonctionnant entre 5 et 10% de leur capacité potentielle. Un gaspillage tragique du capital et des ressources de l'entreprise!

Hello VMware !

Pour tout cela, VMware, Inc. a fait un cadeau au monde: la machine virtuelle (VM). Et presque du jour au lendemain, le monde s'est transformé en un endroit bien meilleur! Nous avons enfin acquis une technologie qui nous permettrait de gérer en toute sécurité plusieurs applications sur un seul serveur.

C'était un changeur de jeu! Il n’était plus nécessaire de se procurer un tout nouveau serveur surdimensionné à chaque fois que l'entreprise demandait une nouvelle application. Plus souvent qu'autrement ils pourraient exécuter de nouvelles applications sur les serveurs existants qui étaient assis avec de rechange capacité. Tout à coup, nous pourrions tirer d’énormes quantités de valeur des les actifs de l’entreprise, tels que les serveurs, entraînant un impact beaucoup plus important sur les activités de la société. VMwarts Même si les machines virtuelles sont géniales, elles ne sont pas parfaites! Le fait que chaque machine virtuelle nécessite son propre système d'exploitation dédié est un défaut majeur. Chaque OS consomme de la CPU, de la RAM et du stockage qui pourraient autrement être utilisés pour alimenter davantage les applications. Chaque système d'exploitation a besoin de correctifs et de surveillance. Et dans certains cas, chaque système d'exploitation nécessite une licence. Le modèle de machine virtuelle présente également d'autres défis. Les machines virtuelles sont lentes à démarrer et à la portabilité pas terrible - migrer et déplacer des charges de travail de machine virtuelle entre hyperviseurs et les plates-formes cloud est plus difficile qu'il ne le faut.

Bonjour les conteneurs!

Pendant longtemps, les grands acteurs du Web tels que Google utilisaient des conteneurs technologies pour remédier à ces faiblesses du modèle de VM. Dans le modèle de conteneur, le conteneur est à peu près analogue à la VM. Le principal La différence est que chaque conteneur n’a pas besoin d’un système d’exploitation complet. En fait, tous les conteneurs d’un même hôte partagent un même système d’exploitation. Cela libère énormément de quantités de ressources système telles que le processeur, la RAM et le stockage. Il réduit également les coûts de licence potentiels et réduit les frais généraux liés aux correctifs de système d’exploitation et autres entretien. Les conteneurs sont également rapides à démarrer et ultra-portables. Déplacement de charges de travail de conteneur depuis votre ordinateur portable vers le cloud, puis vers des ordinateurs virtuels.

1979: Unix V7 Au cours de l’histoire unix du développement des conteneurs d’Unix V7 en 1979, l’appel système chroot a été introduit, modifiant le répertoire racine d’un processus et de ses fils dans un nouvel emplacement du système de fichiers. Cette avancée a marqué le début de l'isolation des processus: la séparation de l'accès aux fichiers pour chaque processus. Chroot a été ajouté à BSD en 1982. Un programme exécuté dans un tel environnement ne peut pas accéder aux fichiers et aux commandes situés en dehors de cette arborescence de répertoires environnementaux. Cet environnement modifié est appelé une ” prison” chroot.

2000: JBS FreeBSD

Près de deux décennies plus tard, en 2000, quand un petit fournisseur d’hébergement en environnement partagé est venu dans l’historique upBSD des conteneurs avec les FreeBSD jails afin de séparer clairement ses services de ceux de ses clients pour des raisons de sécurité et de facilité d’administration. Les jails FreeBSD permettent aux administrateurs de partitionner un système informatique FreeBSD en plusieurs systèmes indépendants plus petits, appelés jails, avec la possibilité d'attribuer une adresse IP à chaque système et configuration.

2001: Linux VServer

Comme les jails FreeBSD, Linux VServer est un mécanisme jail qui permet de partitionner les ressources Linux Historique des conteneurs (systèmes de fichiers, adresses réseau, mémoire) sur un système informatique. Introduite en 2001, cette virtualisation de système d’exploitation est mise en œuvre en appliquant un correctif au noyau Linux. Des correctifs expérimentaux sont toujours disponibles, mais le dernier correctif stable a été publié en 2006.

2004: conteneurs Solaris

En 2004, la première version bêta publique de Solaris Containers, qui associe des contrôles des ressources système et une séparation des limites fournie par les zones, permettait de tirer parti de fonctionnalités telles que les instantanés et le clonage à partir de ZFS.

2005: Open VZ (Open Virtuzzo) Il s'agit d'une technologie de virtualisation au niveau du système d'exploitation pour l'historique de conteneursx de LinuopenVZ, qui utilise un noyau Linux corrigé pour la virtualisation, l'isolation, la gestion des ressources et les points de contrôle. Le code n'a pas été publié dans le noyau officiel de Linux.

2006: conteneurs de processus

Process Containers (lancé par Google en 2006) a été conçu pour limiter, comptabiliser et isoler l'utilisation des ressources (CPU, mémoire, E / S de disque, réseau) d'un ensemble de processus. Il a été renommé «Control Groups (cgroups)» un an plus tard et a finalement été fusionné avec le noyau Linux 2.6.24.

2008: LXC

Historique LXC des conteneurs

LXC (LinuX Containers) a été la première et la plus complète implémentation du gestionnaire de conteneurs Linux. Il a été implémenté en 2008 à l'aide des “space name” cgroups et Linux et fonctionne sur un seul noyau Linux sans nécessiter de correctifs.

Le noyau de Linux 2.6.24 intègre une prise en charge fondamentale de la conteneurisation pour assurer une virtualisation au niveau du système d'exploitation et permettre à un même hôte d'exécuter plusieurs instances Linux isolées, baptisées « conteneurs Linux », ou LXC (LinuX Containers). LXC repose sur la notion de groupes de contrôle Linux, les cgroups. Ici, chaque groupe de contrôle offre aux applications une isolation totale des ressources (notamment processeur, mémoire et accès E/S), et ce sans recourir à des machines virtuelles à part entière. Les conteneurs Linux proposent également une isolation complète de leur espace de noms. Les fonctions telles que les systèmes de fichiers, les ID réseau et les ID utilisateur, ainsi que tout autre élément généralement associé aux systèmes d'exploitation, peuvent donc être considérés comme « uniques » du point de vue de chaque conteneur.

2011: Warden

CloudFoundry a commencé Warden en 2011, en utilisant LXC dans le débuts et plus tard en le remplaçant par son histoire de fonderie owncloud de la mise en œuvre des conteneurs. Warden peut isoler des environnements sur n’importe quel système d’exploitation, s’exécutant en tant que démon et fournissant une API pour la gestion des conteneurs. Il a développé un modèle client-serveur pour gérer une collection de conteneurs sur plusieurs hôtes, et Warden inclut un service permettant de gérer les groupes de contrôle, les name space et le cycle de vie des processus.

2013: LMCTFY

LMCTFY a démarré en 2013 en tant que version à source ouverte de la pile de conteneurs de Google, fournissant des conteneurs d'applications Linux. Les applications peuvent être configurées en «conteneur», en créant et en gérant leurs propres sous-conteneurs. Le déploiement actif dans LMCTFY a été arrêté en 2015 après que Google ait commencé à contribuer à libcontainer, qui fait désormais partie des concepts LMCTFY de base, qui fait maintenant partie de la Open Container Foundation.

2013: Docker

Lorsque Docker est apparu en 2013, la popularité des conteneurs a explosé. Ce n’est pas une coïncidence: l’histoire croissante des conteneurs de docker a toujours été liée à l’utilisation de dockers et de conteneurs.

Tout comme Warden, Docker a également utilisé LXC à ses débuts et a par la suite remplacé ce gestionnaire de conteneurs par sa propre bibliothèque, libcontainer. Mais il ne fait aucun doute que Docker s’est séparé du pack en offrant un écosystème complet pour la gestion des conteneurs.

2016: l'importance de la sécurité des conteneurs est révélée

Avec l'adoption généralisée d'applications basées sur les conteneurs, les systèmes sont devenus plus complexes et les risques accrus, jetant ainsi les bases de la sécurité des conteneurs. Des vulnérabilités telles que sale COW ont contribué à cette réflexion. Cela a entraîné un changement dans la sécurité tout au long du cycle de vie du développement logiciel, ce qui en fait un élément clé de chaque étape du développement d'applications conteneur, également appelé DevSecOps. L'objectif est de construire des conteneurs sécurisés à partir de la base sans réduire les délais de commercialisation.

2017: Les outils de conteneur deviennent matures

Des centaines d'outils ont été développés pour faciliter la gestion des conteneurs. Alors que ces types d'outils existent depuis des années, 2017 est l'année où beaucoup d'entre eux ont gagné leurs galons. Il suffit de regarder Kubernetes; Depuis son adoption dans la Cloud Native Computing Foundation (CNCF) en 2016, VMWare, Azure, AWS et même Docker ont annoncé leur soutien, en plus de leurs infrastructures.

Alors que le marché continue de croître, certains outils ont permis de définir certaines fonctions de la communauté des conteneurs. Ceph et REX-Ray établissent des normes pour le stockage de conteneurs, tandis que Flannel connecte des millions de conteneurs dans des centres de données. Et dans CI / CD, Jenkins change complètement la façon dont nous construisons et déployons des applications.

Adoption de rkt et Containerd par la CNCF

L’écosystème de conteneurs est unique dans la mesure où il repose sur un effort et un engagement de la communauté vis-à-vis de projets open source. Le don de Docker du projet Containerd à la CNCF en 2017 est emblématique de ce concept, ainsi que l'adoption de CNCF du conteneur KRT (prononcé « fusée ») l'exécution dans le même temps. Cela a conduit à une plus grande collaboration entre les projets, à plus de choix pour les utilisateurs et à une communauté centrée sur l'amélioration de l'écosystème des conteneurs.

Kubernetes grandit

En 2017, le projet open-source a montré de grandes avancées pour devenir un k8s logo.pngtechnology plus mature. Kubernetes prend en charge des classes d'applications de plus en plus complexes, permettant ainsi la transition de l'entreprise vers le cloud hybride et les microservices. A DockerCon à Copenhague, Docker a annoncé qu'ils soutiendront le conteneur Kubernetes orchestrateur et Azure et AWS est tombé en ligne avec AKS (Azure Services Kubernetes) et EKS, un service Kubernetes pour rivaliser avec ECS propriétaire. Il s’agissait également du premier projet adopté par le CNCF et commandait une liste croissante de fournisseurs de services d’intégration de systèmes tiers. Kubernetes semble avoir un avenir prometteur en tant que plate-forme d'orchestration de facto Docker : un LXC augmenté Les plateformes de conteneurisation d'applications, telles que Docker, ne remplacent pas les conteneurs Linux. L'idée consiste à utiliser LXC comme base, puis à ajouter des capacités de niveau supérieur. Par exemple, une plate-forme comme Docker autorise la portabilité entre machines (qui exécutent aussi Docker) et permet ainsi à une application et à ses composants d'exister en tant qu'objet mobile unique. LXC seul permet la mobilité, mais la build est liée à la configuration du système. Donc la déplacer sur une autre machine peut introduire des différences susceptibles d'empêcher le conteneur de l'application de s'exécuter à l'identique (voire de s'exécuter tout court).

Docker a explosé sur scène en 2013, et cela a causé de l'excitation dans les cercles informatiques depuis. La technologie de conteneur d'application fournie par Docker promet de changer la façon dont les opérations informatiques sont réalisées de la même manière que la technologie de virtualisation quelques années auparavant.

Autres exemples, Docker propose des outils de génération automatisée de build. Ces outils aident les développeurs à passer plus facilement d'un code source à des applications conteneurisées, ou à utiliser des outils d'accompagnement, tels que Chef, Maven, Puppet et autres, afin d'automatiser ou de rationaliser le processus de build. La gestion des versions permet aux développeurs de suivre l'évolution des versions des conteneurs, de comprendre les différences, voire de revenir à des versions antérieures le cas échéant. Et sachant que tout conteneur peut servir d'image de base à un autre, il est d'autant plus facile de réutiliser des composants aisément partageables via un registre public (ou privé).

Aujourd’hui, Dave Bartoletti, analyste chez Forrester, pense que seulement 10% des entreprises utilisent actuellement des conteneurs en production, mais près d’un tiers sont en phase de test. Docker a généré 762 millions de dollars de revenus en 2016. Les conteneurs transformeront le monde de l’informatique car ils utilisent des systèmes d’exploitation partagés. Cette technologie permettrait à un data center ou à un fournisseur Cloud d’économiser des dizaines de millions de dollars par an, mais tout dépends bien sûr des risques qu’ils seraient prêt à prendre. Cependant, quelques préoccupations existent concernant l’assurance qu’auront les développeurs d’innover librement en utilisant des conteneurs. Les développeurs doivent pouvoir choisir les outils et les frameworks qu’ils souhaitent utiliser sans avoir à demander systématiquement la permission. L’utilisation d’un conteneur pourrait en effet étouffer la créativité d’un développeur…

@@ Ligne 163 : / Ligne 163 : @@
 |
 |-
-|Etat de l'art
+|Etat de l'art 2|| 8 || || || || || || || || || ||
 |-
-|Création-configuration des conteneurs à la main
+|Création-configuration des conteneurs à la main || ||6 || 5|| 4|| || || || || || ||
 |-
-|Script Shell
+|Script Shell||  || || || || || || || || || ||
 |-
-|Gestion du stockage des informations des conteneurs
+|Gestion du stockage des informations des conteneurs ||  || || || || || || || || || ||
 |-
-|Paramétrage de la configuration réseau
+|Paramétrage de la configuration réseau||  || || || || || | || || || ||
 |-
-|MIse en application de l'application des tests
+|MIse en application de l'application des tests||  || || || || || | || || || ||
 |}

IMA4 2018/2019 P30 : Différence entre versions