Une introduction aux conteneurs, VM et Docker adaptée aux débutants

1*sGHbxxLdm87_n7tKQS3EUg
Reading Time: 13 minutes

Si vous êtes un programmeur ou un technicien, vous avez probablement déjà entendu parler de Docker: un outil utile pour emballer, expédier et exécuter des applications dans des «conteneurs». Ce serait difficile de ne pas le faire, avec toute l’attention qu’il mérite. ces jours-ci – des développeurs et des administrateurs système. Même les grands chiens comme Google, VMware et Amazon construisent des services pour le soutenir.

Peu importe que vous ayez ou non un cas d’utilisation immédiat pour Docker, je pense qu’il est important de comprendre certains des concepts fondamentaux autour de ce qu’est un «conteneur» et comment il se compare à une machine virtuelle (VM). Bien qu’Internet soit rempli d’excellents guides d’utilisation pour Docker, je n’ai pas trouvé beaucoup de guides conceptuels pour les débutants, en particulier sur la composition d’un conteneur. Donc, j’espère, ce post résoudra ce problème 🙂

Commençons par comprendre ce que sont les VM et les conteneurs.

Que sont les « conteneurs » et les « VM »?

Les conteneurs et les machines virtuelles ont des objectifs similaires: isoler une application et ses dépendances dans une unité autonome pouvant s’exécuter n’importe où.

De plus, les conteneurs et les machines virtuelles éliminent le besoin de matériel physique, permettant une utilisation plus efficace des ressources informatiques, à la fois en termes de consommation d’énergie et de rentabilité.

La principale différence entre les conteneurs et les VM réside dans leur approche architecturale. Regardons de plus près.

Machines virtuelles

Une VM est essentiellement une émulation d’un vrai ordinateur qui exécute des programmes comme un vrai ordinateur. Les machines virtuelles s’exécutent sur une machine physique en utilisant un « hyperviseur » . Un hyperviseur, à son tour, fonctionne sur une machine hôte ou sur « bare-metal » .

Débarrassons le jargon:

Un hyperviseur est une partie du logiciel, du micrologiciel ou du matériel sur lequel les machines virtuelles s’exécutent. Les hyperviseurs eux-mêmes fonctionnent sur des ordinateurs physiques, appelés « machine hôte » . La machine hôte fournit aux VM des ressources, y compris de la RAM et du CPU.Ces ressources sont réparties entre les machines virtuelles et peuvent être distribuées comme bon vous semble. Ainsi, si une machine virtuelle exécute une application plus gourmande en ressources, vous pouvez lui allouer plus de ressources que les autres machines virtuelles exécutées sur la même machine hôte.

La VM qui s’exécute sur la machine hôte (encore une fois, en utilisant un hyperviseur) est aussi souvent appelée « guest machine ». Cette machine contient à la fois l’application et tout ce dont elle a besoin pour exécuter cette application (binaires et bibliothèques). Il possède également sa propre pile matérielle virtualisée, y compris les cartes réseau virtualisées, le stockage et le processeur, ce qui signifie qu’il possède également son propre système d’exploitation invité. De l’intérieur, la machine invitée se comporte comme sa propre unité avec ses propres ressources dédiées. De l’extérieur, nous savons que c’est une VM – ressources de partage fournies par la machine hôte.

Comme mentionné ci-dessus, une machine invité peut fonctionner sur un hyperviseur hébergé ou un hyperviseur bare-metal . Il y a quelques différences importantes entre eux.

Tout d’abord, un hyperviseur de virtualisation hébergé s’exécute sur le système d’exploitation de la machine hôte. Par exemple, un ordinateur exécutant OSX peut avoir une machine virtuelle (par exemple VirtualBox ou VMware Workstation 8) installée au-dessus de ce système d’exploitation. La VM n’a pas d’accès direct au matériel, elle doit donc passer par le système d’exploitation hôte (dans notre cas, le Mac OSX).

L’avantage d’un hyperviseur hébergé est que le matériel sous-jacent est moins important. Le système d’exploitation de l’hôte est responsable des pilotes matériels au lieu de l’hyperviseur lui-même et est donc considéré comme ayant une plus grande compatibilité matérielle. D’autre part, cette couche supplémentaire entre le matériel et l’hyperviseur crée plus de ressources. la performance de la VM.

Un environnement d’hyperviseur bare metal résout le problème de performances en s’installant sur le matériel de la machine hôte et en l’exécutant. Comme il s’interface directement avec le matériel sous-jacent, il n’a pas besoin d’un système d’exploitation hôte pour fonctionner. Dans ce cas, la première chose installée sur le serveur d’une machine hôte en tant que système d’exploitation sera l’hyperviseur. Contrairement à l’hyperviseur hébergé, un hyperviseur bare-metal possède ses propres pilotes de périphérique et interagit directement avec chaque composant pour toutes les tâches d’E / S, de traitement ou spécifiques au système d’exploitation. Cela se traduit par de meilleures performances, évolutivité et stabilité. Le compromis ici est que la compatibilité matérielle est limitée parce que l’hyperviseur peut seulement avoir autant de pilotes de périphériques intégrés.

Après tout ce discours sur les hyperviseurs, vous vous demandez peut-être pourquoi nous avons besoin de cette couche « hyperviseur » supplémentaire entre la machine virtuelle et la machine hôte.

Eh bien, puisque la machine virtuelle possède son propre système d’exploitation virtuel, l’hyperviseur joue un rôle essentiel en fournissant aux machines virtuelles une plate-forme pour gérer et exécuter ce système d’exploitation invité. Il permet aux ordinateurs hôtes de partager leurs ressources entre les machines virtuelles exécutées en tant qu’invités.

Diagramme de machine virtuelle

Comme vous pouvez le voir dans le diagramme, les machines virtuelles conditionnent le matériel virtuel, un noyau (c’est-à-dire un système d’exploitation) et un espace utilisateur pour chaque nouvelle machine virtuelle.

Récipient

Contrairement à une machine virtuelle qui fournit une virtualisation matérielle, un conteneur fournit une virtualisation au niveau du système d’exploitation en faisant abstraction de «l’espace utilisateur». Vous verrez ce que je veux dire que nous déballons le terme conteneur .

Dans tous les cas, les conteneurs ressemblent à une machine virtuelle. Par exemple, ils disposent d’un espace privé pour le traitement, peuvent exécuter des commandes en tant que root, avoir une interface réseau et une adresse IP privées, autoriser des routes personnalisées et des règles iptables, monter des systèmes de fichiers, etc.

La grande différence entre les conteneurs et les machines virtuelles réside dans le fait que les conteneurs * partagent * le noyau du système hôte avec d’autres conteneurs.

Diagramme de conteneur

Ce diagramme vous montre que les conteneurs ne contiennent que l’espace utilisateur, et non le noyau ou le matériel virtuel comme le fait une machine virtuelle. Chaque conteneur possède son propre espace utilisateur isolé pour permettre à plusieurs conteneurs de s’exécuter sur une machine hôte unique.Nous pouvons voir que toute l’architecture au niveau du système d’exploitation est partagée entre les conteneurs. Les seules parties qui sont créées à partir de zéro sont les bacs et les bibliothèques. C’est ce qui rend les conteneurs si légers.

Où Docker entre-t-il?

Docker est un projet open-source basé sur des conteneurs Linux. Il utilise des fonctionnalités du noyau Linux telles que les espaces de noms et les groupes de contrôle pour créer des conteneurs au-dessus d’un système d’exploitation.

Les conteneurs sont loin d’être neufs. Google utilise leur propre technologie de conteneur depuis des années. D’autres technologies de conteneur Linux incluent les zones Solaris, les prisons BSD et LXC, qui existent depuis de nombreuses années.

Alors pourquoi Docker gagne-t-il soudainement de la vapeur?

1. Facilité d’utilisation: Docker a rendu beaucoup plus facile pour quiconque – développeurs, administrateurs de systèmes, architectes et autres – de tirer parti des conteneurs afin de créer et de tester rapidement des applications portables. Il permet à n’importe qui d’empaqueter une application sur son ordinateur portable, qui à son tour peut fonctionner sans modification sur n’importe quel nuage public, nuage privé, ou même nu. Le mantra est: « construire une fois, courir n’importe où. »

2. Vitesse: Les conteneurs Docker sont très légers et rapides. Puisque les conteneurs ne sont que des environnements en bac à sable fonctionnant sur le noyau, ils prennent moins de ressources. Vous pouvez créer et exécuter un conteneur Docker en quelques secondes, par rapport aux machines virtuelles, ce qui peut prendre plus de temps car elles doivent démarrer un système d’exploitation virtuel complet à chaque fois.

3. Hub Docker: les utilisateurs de Docker bénéficient également de l’écosystème de plus en plus riche de Docker Hub, que vous pouvez considérer comme un « app store pour les images Docker ». Docker Hub propose des dizaines de milliers d’images publiques créées par la communauté. pour utilisation. Il est incroyablement facile de rechercher des images qui répondent à vos besoins, prêtes à être retirées et utilisées avec peu ou pas de modifications.

4. Modularité et évolutivité: Docker facilite la répartition de la fonctionnalité de votre application dans des conteneurs individuels. Par exemple, vous pouvez avoir votre base de données Postgres en cours d’exécution dans un conteneur et votre serveur Redis dans un autre tandis que votre application Node.js est dans un autre. Avec Docker, il est plus facile de relier ces conteneurs entre eux pour créer votre application, ce qui facilite la mise à l’échelle ou la mise à jour des composants de manière indépendante à l’avenir.

Last but not least, qui n’aime pas la baleine Docker? 😉

Source: https://www.docker.com/docker-birthday

Concepts fondamentaux de Docker

Maintenant que nous avons une vue d’ensemble, passons en revue les parties fondamentales de Docker, pièce par pièce:

Docker Engine

Le moteur Docker est la couche sur laquelle Docker tourne. C’est une exécution légère et un outillage qui gère les conteneurs, les images, les builds et plus encore. Il fonctionne nativement sur les systèmes Linux et est composé de:

1. Un démon Docker qui s’exécute dans l’ordinateur hôte.
2. Un client Docker qui communique ensuite avec le démon Docker pour exécuter des commandes.
3. Une API REST pour interagir à distance avec le démon Docker.

Docker Client

Le client Docker est ce que vous, en tant qu’utilisateur final de Docker, communiquez avec. Pensez-y comme l’interface utilisateur de Docker. Par exemple, quand vous faites …

docker build gagieci/someImage .

vous communiquez avec le client Docker, qui communique ensuite vos instructions au démon Docker.

Docker Daemon

Le démon Docker est ce qui exécute réellement les commandes envoyées au client Docker – comme la construction, l’exécution et la distribution de vos conteneurs. Le démon Docker fonctionne sur la machine hôte, mais en tant qu’utilisateur, vous ne communiquez jamais directement avec le démon. Le client Docker peut également fonctionner sur la machine hôte, mais ce n’est pas obligatoire. Il peut fonctionner sur une machine différente et communiquer avec le démon Docker qui s’exécute sur la machine hôte.

Dockerfile

Un Dockerfile est l’endroit où vous écrivez les instructions pour construire une image Docker. Ces instructions peuvent être:

  • RUN apt-get y installe un paquet : pour installer un progiciel
  • EXPOSE 8000: exposer un port
  • ENV ANT_HOME / usr / local / apache-ant pour passer une variable d’environnement

et ainsi de suite. Une fois que vous avez configuré votre Dockerfile, vous pouvez utiliser la commande docker build pour créer une image à partir de celle-ci. Voici un exemple de Dockerfile:

Exemple de fichier Docker

Docker Image

Les images sont des modèles en lecture seule que vous construisez à partir d’un ensemble d’instructions écrites dans votre fichier Docker. Les images définissent à la fois ce que vous voulez que votre application empaquetée et ses dépendances ressemblent * et * les processus à exécuter lorsqu’elle est lancée.

L’image Docker est créée à l’aide d’un fichier Docker. Chaque instruction dans le Dockerfile ajoute une nouvelle « couche » à l’image, avec des couches représentant une partie du système de fichiers images qui ajoute ou remplace le calque situé en dessous. Les couches sont la clé de la structure légère mais puissante de Docker. Docker utilise un système de fichiers Union pour y parvenir:

Systèmes de fichiers Union

Docker utilise Union File Systems pour créer une image. Vous pouvez considérer un système de fichiers Union comme un système de fichiers empilable, ce qui signifie que les fichiers et les répertoires de systèmes de fichiers distincts (appelés branches) peuvent être superposés de manière transparente pour former un système de fichiers unique.

Le contenu des répertoires qui ont le même chemin dans les branches superposées est vu comme un seul répertoire fusionné, ce qui évite d’avoir à créer des copies séparées de chaque couche. Au lieu de cela, ils peuvent tous être donnés des pointeurs vers la même ressource; Lorsque certaines couches doivent être modifiées, cela crée une copie et modifie une copie locale, laissant l’original inchangé. C’est ainsi que les systèmes de fichiers peuvent * apparaître * inscriptibles sans permettre les écritures. (En d’autres termes, un système de « copie sur écriture ».)

Les systèmes en couches offrent deux avantages principaux:

1. Sans duplication: les calques permettent d’éviter la duplication d’un ensemble complet de fichiers chaque fois que vous utilisez une image pour créer et exécuter un nouveau conteneur, ce qui rend l’instanciation des conteneurs docker très rapide et bon marché.
2. Ségrégation de couche: effectuer une modification est beaucoup plus rapide – lorsque vous changez une image, Docker ne fait que propager les mises à jour vers la couche qui a été modifiée.

Volumes

Les volumes sont la partie « données » d’un conteneur, initialisée lors de la création d’un conteneur. Les volumes vous permettent de conserver et de partager les données d’un conteneur. Les volumes de données sont distincts du système de fichiers Union par défaut et existent en tant que répertoires et fichiers normaux sur le système de fichiers hôte. Ainsi, même si vous détruisez, mettez à jour ou reconstruisez votre conteneur, les volumes de données resteront intacts. Lorsque vous voulez mettre à jour un volume, vous le modifiez directement. (En prime, les volumes de données peuvent être partagés et réutilisés entre plusieurs conteneurs, ce qui est plutôt intéressant.)

Docker Containers

Un conteneur Docker, comme indiqué ci-dessus, enveloppe le logiciel d’une application dans une boîte invisible contenant tout ce que l’application doit exécuter. Cela inclut le système d’exploitation, le code d’application, l’exécution, les outils système, les bibliothèques système, etc. Les conteneurs Docker sont construits à partir d’images Docker. Les images étant en lecture seule, Docker ajoute un système de fichiers en lecture-écriture sur le système de fichiers en lecture seule de l’image pour créer un conteneur.

Source: Docker 

De plus, en créant le conteneur, Docker crée une interface réseau afin que le conteneur puisse communiquer avec l’hôte local, attache une adresse IP disponible au conteneur et exécute le processus que vous avez spécifié pour exécuter votre application lors de la définition de l’image.

Une fois que vous avez créé un conteneur, vous pouvez l’exécuter dans n’importe quel environnement sans avoir à apporter de modifications.

Double-cliquer sur « conteneurs »

Phew! C’est beaucoup de pièces mobiles. Une chose qui m’a toujours intrigué, c’est comment un conteneur est réellement implémenté, d’autant plus qu’il n’y a pas de limite d’infrastructure abstraite autour d’un conteneur. Après beaucoup de lecture, tout a un sens alors voici ma tentative de vous l’expliquer! 🙂

Le terme «conteneur» est vraiment juste un concept abstrait pour décrire comment quelques caractéristiques différentes fonctionnent ensemble pour visualiser un «conteneur». Courons à travers eux très vite:

1) Espaces de noms

Les espaces de noms fournissent aux conteneurs leur propre vue du système Linux sous-jacent, limitant ce que le conteneur peut voir et accéder. Lorsque vous exécutez un conteneur, Docker crée des espaces de noms que le conteneur spécifique utilisera.

Docker utilise plusieurs types d’espaces de noms dans un noyau, par exemple:

une. NET: Fournit un conteneur avec sa propre vue de la pile réseau du système (par exemple, ses propres périphériques réseau, adresses IP, tables de routage IP, répertoire / proc / net, numéros de ports, etc.).
b. PID: PID signifie Process ID. Si vous avez déjà exécuté ps aux dans la ligne de commande pour vérifier quels processus sont en cours d’exécution sur votre système, vous avez vu une colonne nommée « PID ». L’espace de noms PID donne aux conteneurs leur propre vue d’ensemble des processus qu’ils peuvent voir et interagir, y compris un init indépendant (PID 1), qui est « l’ancêtre de tous les processus ».
c. MNT: Donne à un conteneur sa propre vue des « montages » sur le système .Ainsi, les processus des différents espaces de noms de montage ont des vues différentes de la hiérarchie du système de fichiers.
ré. UTS: UTS signifie UNIX Timesharing System. Il permet à un processus d’identifier les identifiants système (ie nom d’hôte, nom de domaine, etc.).UTS permet aux conteneurs d’avoir leur propre nom d’hôte et nom de domaine NIS indépendant des autres conteneurs et du système hôte.
e. IPC: IPC signifie InterProcess Communication. L’espace de noms IPC est responsable de l’isolation des ressources IPC entre les processus s’exécutant à l’intérieur de chaque conteneur.
F. USER: cet espace de noms est utilisé pour isoler les utilisateurs dans chaque conteneur. Il fonctionne en permettant aux conteneurs d’avoir une vue différente des plages uid (ID utilisateur) et gid (ID groupe), par rapport au système hôte. Par conséquent, l’UID et le GID d’un processus peuvent être différents à l’intérieur et à l’extérieur d’un espace de noms utilisateur, ce qui permet également à un processus d’avoir un utilisateur non privilégié en dehors d’un conteneur sans sacrifier les privilèges root.

Docker utilise ces espaces de noms ensemble pour isoler et commencer la création d’un conteneur. La fonctionnalité suivante est appelée groupes de contrôle.

2) Groupes de contrôle

Les groupes de contrôle (également appelés cgroups) sont une fonctionnalité de noyau Linux qui isole, hiérarchise et comptabilise l’utilisation des ressources (processeur, mémoire, E / S disque, réseau, etc.) d’un ensemble de processus. En ce sens, un groupe de contrôle s’assure que les conteneurs Docker n’utilisent que les ressources dont ils ont besoin et, si nécessaire, définit des limites aux ressources qu’un conteneur * peut * utiliser. Les groupes de contrôle s’assurent également qu’un seul conteneur n’épuise pas l’une de ces ressources et réduit l’ensemble du système.

Enfin, les systèmes de fichiers union sont une autre fonctionnalité utilisée par Docker:

3) Système de fichiers Union isolé:

Décrit ci-dessus dans la section Docker Images 🙂

C’est vraiment tout ce qu’il ya à un conteneur Docker (bien sûr, le diable est dans les détails de mise en œuvre – comme la façon de gérer les interactions entre les différents composants).

L’avenir de Docker: Docker et VM vont coexister

Bien que Docker gagne certainement beaucoup de vapeur, je ne crois pas que cela devienne une réelle menace pour les machines virtuelles. Les conteneurs continueront à gagner du terrain, mais il existe de nombreux cas d’utilisation où les machines virtuelles sont encore mieux adaptées.

Par exemple, si vous devez exécuter plusieurs applications sur plusieurs serveurs, il est probablement judicieux d’utiliser des machines virtuelles. D’un autre côté, si vous avez besoin d’exécuter de nombreuses * copies * d’une seule application, Docker offre des avantages convaincants.

De plus, bien que les conteneurs vous permettent de diviser votre application en plusieurs parties discrètes fonctionnelles pour créer une séparation des préoccupations, cela signifie également qu’il y a un nombre croissant de pièces à gérer, ce qui peut devenir difficile.

La sécurité a également été un sujet de préoccupation avec les conteneurs Docker – puisque les conteneurs partagent le même noyau, la barrière entre les conteneurs est plus mince. Alors qu’une machine virtuelle complète ne peut émettre que des hypercalls à l’hyperviseur hôte, un conteneur Docker peut effectuer des appels système au noyau hôte, ce qui crée une plus grande surface d’attaque. Lorsque la sécurité est particulièrement importante, les développeurs sont susceptibles de choisir des machines virtuelles, qui sont isolées par un matériel abstrait, ce qui rend beaucoup plus difficile d’interférer les unes avec les autres.

Bien sûr, des problèmes tels que la sécurité et la gestion vont certainement évoluer au fur et à mesure que les conteneurs seront plus exposés à la production et à un examen plus approfondi de la part des utilisateurs. Pour l’instant, le débat sur les conteneurs vs VM est vraiment mieux pour les gens qui vivent et respirent tous les jours!

Conclusion

J’espère que vous êtes maintenant équipé des connaissances dont vous avez besoin pour en savoir plus sur Docker et peut-être même l’utiliser dans un projet un jour.

Comme toujours, envoyez-moi un mot dans les commentaires si j’ai fait des erreurs ou peut être utile de toute façon! 🙂

Poster un Commentaire

avatar

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

  Subscribe  
Me notifier des