>  기사  >  운영 및 유지보수  >  Docker가 지원하는 최초의 스토리지 엔진은 무엇입니까?

Docker가 지원하는 최초의 스토리지 엔진은 무엇입니까?

青灯夜游
青灯夜游원래의
2022-05-12 15:27:003161검색

AUFS는 Docker가 지원하는 최초의 스토리지 엔진입니다. AUFS는 Docker 초기에 사용된 스토리지 드라이버인 Union File System입니다. Docker 버전 18.06 및 Ubuntu 버전 14.04 이전에 권장되었으며 xfs 및 ext4 파일을 지원합니다.

Docker가 지원하는 최초의 스토리지 엔진은 무엇입니까?

이 튜토리얼의 운영 환경: linux7.3 시스템, docker20 버전, Dell G3 컴퓨터.

AUFS는 Docker가 지원하는 최초의 스토리지 엔진입니다.

Docker의 스토리지 엔진

Docker의 스토리지 엔진은 이렇게 설계되었지만 파일 시스템마다 다른 스토리지 드라이버로 구현됩니다. 다음으로 Docker의 스토리지 드라이버에 대해 이야기하겠습니다.

Docker에는 주로 다음과 같은 유형의 저장소 드라이버가 있습니다.

  • overlay2: 현재 버전에서 권장되는 저장소 드라이버이며 추가 종속성 및 구성 없이 우수한 성능을 얻을 수 있습니다. 버전 18.09 이후 오버레이 스토리지 드라이버를 교체했습니다. xfs, ext4 파일 시스템을 지원합니다.

  • aufs: Docker에서 사용하는 최초의 스토리지 드라이버로, Docker 18.06 버전 및 Ubuntu 14.04 버전 이전에 권장됩니다. xfs, ext4 파일 시스템을 지원합니다.

  • devicemapper: 이전 버전의 CentOS 및 RHEL 시스템에는 overlay2를 지원하지 않고 direct-lvm 지원이 필요하기 때문에 권장되는 스토리지 드라이버입니다.

  • btrfs: btrfs 파일 시스템에만 해당됩니다.

  • zfs: zfs 파일 시스템에만 해당됩니다.

  • vfs: 파일 시스템에 의존하지 않지만 성능이 매우 좋지 않아 주로 테스트용으로 사용됩니다.

overlay2, overlay, aufs의 레이어는 파일 기반이라는 점에 유의해야 합니다. 단일 파일의 쓰기 동시성이 높을 경우 대용량 메모리 지원이 필요하며 읽기-쓰기 레이어가 매우 커질 수 있습니다. 파일 하나 때문에. devicemapper, btrfs 및 zfs의 레이어는 블록 스토리지를 기반으로 하므로 단일 파일의 높은 동시성에 거의 영향을 미치지 않습니다. 그러나 btrfs와 zfs는 메모리 집약적입니다.

docker AUFS

AUFS는 Union File System입니다. 소위 UnionFS는 서로 다른 물리적 위치에 있는 디렉터리를 동일한 디렉터리에 병합하고 마운트하는 것입니다. UnionFS의 가장 중요한 애플리케이션 중 하나는 CD/DVD와 하드 디스크 디렉토리를 공동으로 마운트하는 것입니다. 그런 다음 이 읽기 전용 CD/DVD에 있는 파일을 수정할 수 있습니다(물론 수정된 파일은 디렉토리에 저장됩니다). 하드 드라이브에 있음).

AUFS는 Another UnionFS라고도 불렸고 나중에는 Alternative UnionFS라고 불렸습니다. 나중에는 충분히 지배적이지 않을 수도 있어서 Advance UnionFS라고 불렀습니다. 2006년 오카지마 준지로(Junjiro Okajima)가 개발한 AUFS는 초기 UnionFS 1.x를 완전히 다시 작성했습니다. 주요 목적은 안정성과 성능에 있었고 쓰기 가능한 분기와 같은 몇 가지 새로운 기능을 도입했습니다. AUFS는 사용 중인 UnionFS와 완벽하게 호환되며 이전 UnionFS보다 안정성과 성능이 훨씬 뛰어납니다. 나중에 UnionFS 2.x에서는 AUFS의 기능을 복사하기 시작했습니다. 하지만 그는 실제로 Linux 트렁크에 들어가지 못했습니다. 왜냐하면 Linus가 허락하지 않았기 때문입니다. 기본적으로는 코드의 양이 상대적으로 많고, (Union Mount의 경우 3,000줄, UnionFS의 경우 10,000줄에 불과) 작성이 형편없기 때문이었습니다. , 기타 평균 6,000 VFS에는 약 30,000줄의 코드가 있고 AUFS는 실제로 30,000줄의 코드가 있습니다.) 따라서 Okajima는 계속해서 코드 품질을 개선하고 계속 제출했으며 따라서 오늘날까지 계속해서 거부당했습니다. , AUFS는 Linux 트렁크에 들어갈 수 없습니다. (오늘 볼 수 있습니다. AUFS의 코드는 실제로 꽤 좋으며 OpenSSL보다 N배 더 좋습니다. Linus는 코드 품질에 대한 요구 사항이 매우 높거나 Linus는 AUFS를 좋아하지 않습니다.) .

다행히 Ubuntu 10.04, Debian6.0, Gentoo Live CD 등 많은 배포판에서 AUFS를 사용하므로 괜찮습니다.

자, 잡담을 모두 마친 후 예제를 살펴보겠습니다(환경: Ubuntu 14.04)

먼저 두 개의 디렉터리(과일 및 야채)를 만들고 이 두 디렉터리에 일부 파일을 넣습니다. 과일에는 사과, 토마토 및 야채가 포함됩니다. 당근과 토마토가 포함됩니다.

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

그런 다음 다음 명령을 입력합니다.

# 创建一个mount目录
$ mkdir mnt

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

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

./mnt 디렉터리에 apple, carrots, 토마토라는 세 개의 파일이 있는 것을 볼 수 있습니다. 과일 및 야채 디렉토리는 ./mnt 디렉토리로 통합됩니다.

파일 내용을 수정해 보겠습니다.

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

위의 예에서 ./mnt/apple의 내용이 변경되고 ./fruits/apple의 내용도 변경된 것을 볼 수 있습니다.

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

$ cat ./fruits/carrots
mnt_carrots

위의 예에서는 ./mnt/carrots의 파일 내용을 수정했지만 ./vegetables/carrots는 변경되지 않은 것을 볼 수 있습니다. 대신 ./fruits/carrots 디렉터리에 carrots 파일이 나타납니다. 그리고 그 내용은 ./mnt/carrots에 있는 내용입니다.

즉, mount aufs 명령에서는 야채와 과일의 디렉터리 권한을 참조하지 않았습니다. 기본적으로 명령줄의 첫 번째(가장 왼쪽) 디렉터리는 읽기 및 쓰기가 가능하며 이후의 모든 디렉터리는 읽기 및 쓰기가 가능합니다. 쓰기 가능합니다. (일반적으로 첫 번째 디렉터리는 쓰기 가능해야 하며 다음 디렉터리는 읽기 전용이어야 합니다.)

그래서 다음과 같이 aufs 마운트 권한을 지정하면 다른 효과를 볼 수 있습니다(위의 ./fruits/를 삭제하는 것을 기억하세요) 당근 파일 먼저):

$ 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搭建的分层镜像。

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视频教程

위 내용은 Docker가 지원하는 최초의 스토리지 엔진은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.