Maison  >  Article  >  Opération et maintenance  >  Quel est le premier moteur de stockage pris en charge par Docker ?

Quel est le premier moteur de stockage pris en charge par Docker ?

青灯夜游
青灯夜游original
2022-05-12 15:27:003161parcourir

AUFS est le premier moteur de stockage pris en charge par Docker. AUFS est un système de fichiers Union, qui est un pilote de stockage au niveau des fichiers. C'était le pilote de stockage utilisé au début de Docker. Il était recommandé avant la version 18.06 de Docker et la version 14.04 d'Ubuntu.

Quel est le premier moteur de stockage pris en charge par Docker ?

L'environnement d'exploitation de ce tutoriel : système linux7.3, version docker20, ordinateur Dell G3.

AUFS est le premier moteur de stockage pris en charge par Docker.

Le moteur de stockage de Docker

Le moteur de stockage de Docker est conçu comme ceci, mais il est implémenté par différents pilotes de stockage pour différents systèmes de fichiers. Parlons ensuite du pilote de stockage de Docker.

Docker dispose principalement des types de pilotes de stockage suivants :

  • overlay2 : Il s'agit du pilote de stockage recommandé pour la version actuelle et peut atteindre d'excellentes performances sans dépendances ni configurations supplémentaires. Remplacement du pilote de stockage superposé après la version 18.09. Supporte xfs, système de fichiers ext4.

  • aufs : Le premier pilote de stockage utilisé par Docker, recommandé avant la version Docker 18.06 et la version Ubuntu 14.04. Supporte xfs, système de fichiers ext4.

  • devicemapper : Il s'agit du pilote de stockage recommandé pour les versions antérieures des systèmes CentOS et RHEL, car ils ne prennent pas en charge overlay2 et nécessitent une prise en charge directe de LVM.

  • btrfs : Pour le système de fichiers btrfs uniquement.

  • zfs : Uniquement pour les systèmes de fichiers zfs.

  • vfs : Ne dépend pas du système de fichiers, mais les performances sont extrêmement médiocres, principalement utilisées pour les tests.

Il convient de noter que les couches overlay2, overlay et aufs sont basées sur des fichiers. Lorsque la concurrence d'écriture d'un seul fichier est élevée, une prise en charge de grande mémoire est requise et la couche de lecture-écriture peut devenir très volumineuse. en raison d'un seul fichier. Les couches de devicemapper, btrfs et zfs sont basées sur le stockage par blocs, elles ont donc peu d'impact sur la simultanéité élevée d'un seul fichier. Mais les btrfs et zfs consomment beaucoup de mémoire.

docker AUFS

AUFS est un système de fichiers Union. Ce qu'on appelle UnionFS consiste à fusionner et à monter des répertoires situés dans différents emplacements physiques dans le même répertoire. L'une des applications les plus importantes d'UnionFS est de monter conjointement un CD/DVD et un répertoire du disque dur. Ensuite, vous pouvez modifier les fichiers sur ce CD/DVD en lecture seule (bien entendu, les fichiers modifiés sont stockés dans un répertoire). sur le disque dur).

AUFS s'appelait également Another UnionFS, et plus tard, il s'appelait Alternative UnionFS. Plus tard, il n'est peut-être pas assez dominateur, c'est pourquoi il s'appelait Advance UnionFS. Développé par Junjiro Okajima en 2006, AUFS a complètement réécrit le premier UnionFS 1.x. Son objectif principal était la fiabilité et les performances, et il a introduit de nouvelles fonctionnalités, telles que l'équilibrage de charge en écriture. AUFS est entièrement compatible avec UnionFS utilisé et offre une bien meilleure stabilité et performances que le précédent UnionFS. Plus tard, UnionFS 2.x a commencé à copier les fonctions d'AUFS. Mais en réalité, il n'est pas entré dans le tronc Linux parce que Linus ne le laissait pas faire. Fondamentalement, c'était parce que la quantité de code était relativement importante et qu'elle était mal écrite (comparée à seulement 3 000 lignes de Union Mount et 10 000 lignes d'UnionFS). , et d'autres, qui ne comptaient en moyenne que 6 000 VFS et environ 30 000 lignes de code, et AUFS a en fait 30 000 lignes de code). Par conséquent, Okajima a continué à améliorer la qualité du code, a continué à se soumettre et a donc été constamment rejeté par Linus. jour, AUFS ne peut pas entrer dans le tronc Linux (aujourd'hui, vous pouvez voir que le code pour AUFS est en fait assez bon, N fois meilleur qu'OpenSSL. Soit Linus a des exigences très élevées en matière de qualité de code, soit Linus n'aime tout simplement pas AUFS).

Cependant, heureusement, de nombreuses distributions utilisent AUFS, telles que : Ubuntu 10.04, Debian6.0, Gentoo Live CD prend en charge AUFS, donc c'est OK.

D'accord, après tous ces potins, regardons un exemple (environnement : Ubuntu 14.04)

Tout d'abord, nous créons deux répertoires (fruits et légumes) et mettons quelques fichiers dans ces deux répertoires. Les fruits incluent les pommes et les tomates, et les légumes. inclure les carottes et les tomates.

$ tree
.
├── fruits
│   ├── apple
│   └── tomato
└── vegetables
    ├── carrots
    └── tomato

Ensuite, on entre la commande suivante :

# 创建一个mount目录
$ mkdir mnt

# 把水果目录和蔬菜目录union mount到 ./mnt目录中
$ sudo mount -t aufs -o dirs=./fruits:./vegetables none ./mnt

#  查看./mnt目录
$ tree ./mnt
./mnt
├── apple
├── carrots
└── tomato

On voit qu'il y a trois fichiers dans le répertoire ./mnt, pomme, carottes et tomates. Les répertoires de fruits et légumes sont regroupés dans le répertoire ./mnt.

Modifions le contenu du fichier :

$ echo mnt > ./mnt/apple
$ cat ./mnt/apple
mnt
$ cat ./fruits/apple
mnt

Dans l'exemple ci-dessus, nous pouvons voir que le contenu de ./mnt/apple a été modifié, et le contenu de ./fruits/apple a également été modifié.

$ echo mnt_carrots > ./mnt/carrots
$ cat ./vegetables/carrots 

$ cat ./fruits/carrots
mnt_carrots

Dans l'exemple ci-dessus, nous pouvons voir que nous avons modifié le contenu du fichier ./mnt/carrots, mais ./vegetables/carrots n'a pas changé. Au lieu de cela, le fichier carrots est apparu dans le répertoire de ./fruits/carrots, et son contenu C'est le contenu que nous avons dans ./mnt/carrots.

En d'autres termes, dans la commande mount aufs, nous n'avons pas fait référence aux autorisations de répertoire des légumes et des fruits. Par défaut, le premier répertoire (le plus à gauche) de la ligne de commande est lisible et inscriptible, et tous les répertoires suivants sont lisibles et accessibles en écriture. inscriptible. Il est en lecture seule. (D'une manière générale, le premier répertoire doit être accessible en écriture et les répertoires suivants doivent être en lecture seule)

Donc, si nous spécifions les autorisations pour monter aufs comme suit, vous trouverez différents effets (N'oubliez pas de supprimer ce qui précède ./fruits/ fichier carottes en premier) :

$ sudo mount -t aufs -o dirs=./fruits=rw:./vegetables=rw none ./mnt

$ echo "mnt_carrots" > ./mnt/carrots 

$ cat ./vegetables/carrots
mnt_carrots

$ cat ./fruits/carrots
cat: ./fruits/carrots: No such file or directory

现在,在这情况下,如果我们要修改./mnt/tomato这个文件,那么究竟是哪个文件会被改写?

$ echo "mnt_tomato" > ./mnt/tomato 

$ cat ./fruits/tomato
mnt_tomato

$ cat ./vegetables/tomato
I am a vegetable

可见,如果有重复的文件名,在mount命令行上,越往前的就优先级越高。

你可以用这个例子做一些各种各样的试验,我这里主要是给大家一个感性认识,就不展开试验下去了。

那么,这种UnionFS有什么用?

历史上,有一个叫Knoppix的Linux发行版,其主要用于Linux演示、光盘教学、系统急救,以及商业产品的演示,不需要硬盘安装,直接把CD/DVD上的image运行在一个可写的存储设备上(比如一个U盘上),其实,也就是把CD/DVD这个文件系统和USB这个可写的系统给联合mount起来,这样你对CD/DVD上的image做的任何改动都会在被应用在U盘上,于是乎,你可以对CD/DVD上的内容进行任意的修改,因为改动都在U盘上,所以你改不坏原来的东西。

我们可以再发挥一下想像力,你也可以把一个目录,比如你的源代码,作为一个只读的template,和另一个你的working directory给union在一起,然后你就可以做各种修改而不用害怕会把源代码改坏了。有点像一个ad hoc snapshot。

Docker把UnionFS的想像力发挥到了容器的镜像。你是否还记得我在介绍Linux Namespace上篇中用mount namespace和chroot山寨了一镜像。现在当你看过了这个UnionFS的技术后,你是不是就明白了,你完全可以用UnionFS这样的技术做出分层的镜像来。

下图来自Docker的官方文档Layer,其很好的展示了Docker用UnionFS搭建的分层镜像。

Quel est le premier moteur de stockage pris en charge par Docker ?

关于docker的分层镜像,除了aufs,docker还支持btrfs, devicemapper和vfs,你可以使用 -s 或 storage-driver= 选项来指定相关的镜像存储。在Ubuntu 14.04下,docker默认Ubuntu的 aufs(在CentOS7下,用的是devicemapper,关于devicemapper,我会以以后的文章中讲解)你可以在下面的目录中查看相关的每个层的镜像:

/var/lib/docker/aufs/diff/<id>

AUFS的一些特性

AUFS有所有Union FS的特性,把多个目录,合并成同一个目录,并可以为每个需要合并的目录指定相应的权限,实时的添加、删除、修改已经被mount好的目录。而且,他还能在多个可写的branch/dir间进行负载均衡。

上面的例子,我们已经看到AUFS的mount的示例了。下面我们来看一看被union的目录(分支)的相关权限:

  • rw表示可写可读read-write。

  • ro表示read-only,如果你不指权限,那么除了第一个外ro是默认值,对于ro分支,其永远不会收到写操作,也不会收到查找whiteout的操作。

  • rr表示real-read-only,与read-only不同的是,rr标记的是天生就是只读的分支,这样,AUFS可以提高性能,比如不再设置inotify来检查文件变动通知。

推荐学习:《docker视频教程

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn