Que sont les pilotes de stockage Docker et lesquels devez-vous utiliser ? – CloudSavvy IT

Les pilotes de stockage Docker contrôlent la manière dont les images et les conteneurs sont stockés sur votre système de fichiers. C’est le mécanisme qui vous permet de créer des images, de démarrer des conteneurs et de modifier des calques inscriptibles. Voici les différences entre chaque pilote et les situations dans lesquelles ils doivent être utilisés.

A quoi servent les pilotes de stockage ?

Le pilote de stockage actif détermine comment Docker gère vos images et vos conteneurs. Les pilotes disponibles implémentent différentes stratégies de gestion des couches d’images. Ils auront des caractéristiques de performances uniques selon le scénario de stockage à portée de main.

Les pilotes de stockage sont intrinsèquement liés à la « couche inscriptible » d’un conteneur. Ce terme fait référence au niveau le plus élevé du système de fichiers d’un conteneur que vous pouvez modifier en exécutant des commandes, en écrivant des fichiers et en ajoutant des logiciels au moment de l’exécution.

Bien que les données de conteneur Docker persistantes doivent toujours être stockées dans des volumes, les modifications apportées au propre système de fichiers du conteneur sont souvent inévitables. Vous pouvez écrire des fichiers temporaires, stocker des variables d’environnement dans un fichier de configuration ou mettre en cache des données pour référence ultérieure.

Ces opérations entraînent toutes un écart du système de fichiers du conteneur en cours par rapport à celui défini par son image. Votre choix de pilote de stockage gère l’écart et applique la différence.

Que se passe-t-il lorsque vous démarrez un conteneur ?

Lorsqu’un nouveau conteneur démarre, Docker extrait d’abord les couches d’images créées en créant son Dockerfile. Les couches sont stockées sur votre machine hôte, vous n’avez donc pas besoin de récupérer l’image jusqu’à ce que vous souhaitiez récupérer les mises à jour. Dans le cadre du processus d’extraction, Docker identifiera et réutilisera les couches qu’il possède déjà, évitant ainsi les téléchargements redondants.

Une fois les calques d’image disponibles, Docker lancera le conteneur et ajoutera un calque supplémentaire par-dessus. Il s’agit de la couche inscriptible que le conteneur peut modifier. Toutes les couches inférieures sont immuables et dérivées de leurs définitions Dockerfile.

La couche inscriptible fonctionne bien avec peu de frais généraux lorsque vous ajoutez simplement des fichiers au système de fichiers d’un conteneur. Ils se retrouvent dans la couche inscriptible, en haut de la pile. Les modifications apportées aux fichiers existants sont cependant plus gênantes : ils existent dans des couches inférieures en lecture seule mais doivent maintenant être écrits.

L’approche de Docker consiste à « copier sur écriture », ce qui signifie que le fichier est copié hors de sa couche d’origine et dans la couche accessible en écriture au moment de la modification. Il s’agit d’une opération gourmande en E/S qui peut entraîner une dégradation des performances.

Les différents pilotes de stockage sont responsables de la mise en œuvre de la prise en charge de la copie sur écriture. Chaque pilote offre des compromis uniques entre les performances et l’efficacité d’utilisation du disque.

Pilotes de stockage disponibles

Docker utilise une architecture de pilote de stockage enfichable et fournit plusieurs options par défaut. Les pilotes de stockage n’affectent pas les images ou les conteneurs individuels – vous pouvez exécuter n’importe quelle image Docker quel que soit le pilote sélectionné.

Le pilote de stockage actif est un paramètre au niveau de l’exécution défini dans le fichier de configuration du démon Docker. Certains pilotes de stockage nécessitent un provisionnement spécial du système de fichiers avant de pouvoir les utiliser. Vous ajoutez ensuite le pilote de stockage sélectionné à /etc/docker/daemon.json:

{
    "storage-driver": "overlay2"
}

Vous pouvez vérifier votre pilote actuel en exécutant docker info | grep "Storage Driver". Sur la plupart des systèmes modernes, il sera par défaut overlay2.

Voici un aperçu des options parmi lesquelles vous pouvez choisir.

superposition2

Les overlay2 pilote est désormais la valeur par défaut sur toutes les distributions Linux activement prises en charge. Cela nécessite un ext4 ou xfs système de fichiers de sauvegarde.

overlay2 offre un bon équilibre entre performances et efficacité pour les opérations de copie sur écriture. Lorsqu’une copie sur écriture est nécessaire, le pilote parcourt les calques de l’image pour trouver le bon fichier, en commençant par le calque le plus élevé. Les résultats sont mis en cache pour accélérer le processus la prochaine fois.

Une fois le fichier trouvé, il est copié dans la couche inscriptible du conteneur. La copie est alors modifiée avec les changements demandés par le conteneur. À partir de là, le conteneur ne voit que la nouvelle version copiée du fichier. L’original dans la couche d’image inférieure devient opaque pour le conteneur.

overlay2 fonctionne au niveau du fichier par opposition au niveau du bloc. Cela améliore les performances en maximisant l’efficacité d’utilisation de la mémoire, mais peut entraîner des couches inscriptibles plus grandes lorsque de nombreuses modifications sont apportées.

Les alternatives à ce pilote incluent aufs et les plus vieux overlay. Ni l’un ni l’autre n’est recommandé pour une utilisation sur les distributions Linux modernes où overlay2 est pris en charge.

btrfs et zfs

Ces deux pilotes fonctionnent au niveau du bloc et sont idéaux pour les opérations gourmandes en écriture. Ils nécessitent chacun leur système de fichiers de support respectif.

L’utilisation de ces pilotes entraîne votre /var/lib/docker répertoire étant stocké sur un btrfs ou zfs le volume. Chaque couche d’image a son propre répertoire dans le subvolumes dossier. L’espace est alloué aux répertoires à la demande selon les besoins, ce qui maintient l’utilisation du disque à un faible niveau jusqu’à ce que les opérations de copie sur écriture se produisent.

Les couches de base d’image sont stockées sous forme de sous-volumes sur le système de fichiers. D’autres couches deviennent des instantanés, ne contenant que les différences qu’elles introduisent. Les modifications de la couche inscriptible sont gérées au niveau du bloc, ajoutant un autre instantané économe en espace.

Vous pouvez créer des instantanés de sous-volumes et d’autres instantanés à tout moment. Ces instantanés continuent de partager des données inchangées, minimisant ainsi la consommation globale de stockage.

L’utilisation de l’un de ces pilotes peut vous offrir une meilleure expérience pour les conteneurs à forte intensité d’écriture. Si vous écrivez beaucoup de fichiers temporaires ou mettez en cache de nombreuses opérations sur le disque, btrfs ou zfs peut surpasser overlay2. Celui que vous devez utiliser dépend de votre système de fichiers de sauvegarde – généralement zfs est préféré comme alternative plus moderne à btrfs.

superpositions de fusibles

Ce pilote de stockage permet d’exécuter Docker en mode sans racine sur une machine qui ne prend pas en charge le overlay2 conducteur. Cependant, comme toutes les distributions Linux actuellement ciblées fonctionnent désormais avec overlay2, fuse-overlayfs n’est plus nécessaire ou recommandé.

Ce pilote fonctionne en implémentant un système de fichiers superposé à l’aide de FUSE. En tant que système de fichiers en espace utilisateur, il fonctionne en mode sans racine mais entraîne des pénalités de performances par rapport à un système de stockage au niveau du noyau.

vfs

Les vfs pilote est inclus à des fins de test uniquement et ne doit pas être utilisé en production. Les performances de ce pilote sont documentées comme médiocres.

vfs peut être utile dans certains scénarios particuliers car il n’utilise pas la copie sur écriture. Au lieu de cela, chaque couche obtient son propre répertoire sur disque. Lorsqu’un fichier doit se déplacer entre les couches, il est simplement copié dans un nouveau répertoire.

par conséquent vfs fonctionne avec tous les systèmes de fichiers et bénéficie de la simplicité et de la facilité d’inspection. Il souffre d’être intensif en E/S et enclin à provoquer une utilisation élevée du disque car chaque modification de fichier déclenche une copie complète de la couche source.

mappeur de périphérique

C’était autrefois le pilote recommandé pour CentOS et RHEL, mais il a perdu sa place pour overlay2 dans les versions plus récentes du noyau. Ce pilote nécessitait un direct-lvm système de fichiers de sauvegarde. devicemapper ne doit plus être utilisé – il est obsolète et sera entièrement supprimé à l’avenir.

Sommaire

Les pilotes de stockage de Docker sont utilisés pour gérer les couches d’images et la partie inscriptible du système de fichiers d’un conteneur. Bien que les modifications apportées aux systèmes de fichiers du conteneur soient perdues lorsque le conteneur s’arrête, elles doivent toujours être conservées pendant l’exécution du conteneur. C’est le pilote de stockage qui fournit ce mécanisme.

Chaque pilote possède un ensemble différent d’optimisations qui le rend plus ou moins adapté à différents scénarios. De nos jours overlay2 est le pilote par défaut et l’option recommandée pour la plupart des charges de travail, bien que des options alternatives telles que btrfs, zfs, et fuse-overlayfs ont des fonctionnalités plus avancées et peuvent être nécessaires dans certains cas.