关于docker:聊聊-Docker-的存储驱动-Overlay2

10次阅读

共计 5600 个字符,预计需要花费 14 分钟才能阅读完成。

大家好,我是张晋涛。

上周在我的交换群里有个小伙伴问到了 Overlay2 相干的问题,这篇就来介绍一下。

本节,我将为你介绍 Docker 当初举荐应用的存储驱动 Overlay2,在开始之前,你能够执行以下命令来查看 Docker 正在应用的存储驱动:

(MoeLove) ➜  ~ docker info --format '{{.Driver}}'                  
overlay2

如果你看到的后果也是 overlay2 阐明你的 Docker 曾经在应用 overlay2 存储驱动了。我在集体工作站上用的是 btrfs,这是因为自从 Fedora 33 开始,btrfs 就成为了 Fedora 默认的文件系统。不过服务器上就都是 overlay2 了。

你也可能会看到其余不同的后果,能够在启动 docker daemon 的时候,通过 --storage-driver 参数进行指定,也能够在 /etc/docker/daemon.json 文件中通过 storage-driver 字段进行配置。

目前对于 Docker 最新版本而言,你有以下几种存储驱动可供选择:

  • overlay2
  • fuse-overlayfs
  • btrfs
  • zfs
  • aufs
  • overlay
  • devicemapper
  • vfs

但它们对于你应用的文件系统之类的都有不同的要求,且实现形式也不尽相同。我以本节的重点 overlay2 存储驱动为例,它须要你应用 Linux 4.x 以上版本的内核,或者是对于 RHEL/CentOS 等须要应用 3.10.0-514 以上的内核(旧版本中存在一些兼容性问题,我在之前的文章中有提到过)。

同时,它反对你应用 ext4 的文件系统,或者减少了 ftype=1 的 xfs 文件系统。能够通过 docker info 进行失去文件系统相干的信息。

# 省略了局部输入
(MoeLove) ➜  ~ docker info                  
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true

存储驱动的作用

后面尽管曾经聊了如何设置和查看以后在用的存储驱动,但尚未介绍为何肯定要应用存储驱动,以及它的作用。

还记得我在之前的文章《万字长文:彻底搞懂容器镜像构建》中为你介绍的 Docker 如何存储镜像相干的内容吗,如果忘了能够回头温习一下。

Docker 将容器镜像做了分层存储,每个层相当于蕴含着一条 Dockerfile 的指令。而这些层在磁盘上的存储形式,以及在启动容器时,如何组织这些层,并提供可写层,便是存储驱动的次要作用了。

另外须要留神的是:不同的存储驱动实现不同,性能也有差别,同时应用不同的存储驱动也会导致占用的磁盘空间有所不同。

同时: 因为它们的实现不同,当你批改存储驱动后,可能会导致看不到原有的镜像,容器等,这是失常的,不用放心,切换回原先的驱动即可见。

OverlayFS

理解完后面的背景常识后,你也看到了我方才列出的可用存储驱动中有两个 overlayoverlay2,其实 overlay2 算是 overlay 的升级版,这两个存储驱动所用的都是 OverlayFS

overlay 驱动是在 2014 年 8 月份首次进入 Docker 的,而 overlay2 则是在 2016 年 6 月份被合并,并首次呈现在 Docker 1.12 中的。它的呈现是为了解决 overlay 存储驱动可能早层 inode 耗尽的问题。

简略介绍完 overlayoverlay2,咱们将重点回归到 OverlayFS 上。

咱们启动一个容器,以此为切入点来意识下 OverlayFS,留神: 以下内容应用 Linux 5.4 内核以及 Docker 20.10.21,不同环境下可能后果略有差别。

# 查看无在运行的容器和 overlay 挂载
(MoeLove) ➜  ~ mount |grep overlay
(MoeLove) ➜  ~ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

# 启动一个容器
(MoeLove) ➜  ~ docker run --rm -d alpine sleep 99999                         
caa9517ce0d799602735a30aaaaf123c07e07ff6e44c5a4b07e776af85780abe
(MoeLove) ➜  ~ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
caa9517ce0d7        alpine              "sleep 99999"       23 seconds ago      Up 22 seconds                           hopeful_dubinsky

# 查看 overlay 挂载
(MoeLove) ➜  ~ mount |grep overlay                  
overlay on /var/lib/docker/overlay2/f4356a8f14342008fc298bf3d313b863d10f30ef447a3b2f51ea9ece0dec09db/merged type overlay (rw,relatime,seclabel,lowerdir=/var/lib/docker/overlay2/l/5OO3RLRXHJPEH3IFEXNCTO4PY5:/var/lib/docker/overlay2/l/UVA7IR67ZZTN2BNTKCZ7T6HUWU,upperdir=/var/lib/docker/overlay2/f4356a8f14342008fc298bf3d313b863d10f30ef447a3b2f51ea9ece0dec09db/diff,workdir=/var/lib/docker/overlay2/f4356a8f14342008fc298bf3d313b863d10f30ef447a3b2f51ea9ece0dec09db/work)

能够看到,在启动容器后,零碎上多了一个 OverlayFS (overlay) 的挂载。留神看其中的几个内容:

  • 挂载点在:/var/lib/docker/overlay2/f4356a8f14342008fc298bf3d313b863d10f30ef447a3b2f51ea9ece0dec09db/merged

    (MoeLove) ➜  ~ sudo ls /var/lib/docker/overlay2/f4356a8f14342008fc298bf3d313b863d10f30ef447a3b2f51ea9ece0dec09db/merged
    bin  dev  etc  home  lib  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

    其中的内容,看着很相熟,是咱们所启动容器根目录中的内容。为了验证这一说法,我在容器中新写一个文件:

    (MoeLove) ➜  ~ docker exec -it $(docker ps -ql) sh
    / # echo 'Hello Docker' > moelove-info

    再次查看此挂载点中的内容:

    (MoeLove) ➜  ~ sudo ls  /var/lib/docker/overlay2/22be5e4dc4541a60aa4f6de628c3938e7fdc9c4b117277274cd911c46166986b/merged
    bin  dev  moelove-info  etc  home  lib  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
    (MoeLove) ➜  ~ sudo cat /var/lib/docker/overlay2/f4356a8f14342008fc298bf3d313b863d10f30ef447a3b2f51ea9ece0dec09db/merged/moelove-info
    Hello Docker

    能够看到方才写的内容曾经在这个挂载点的目录中了。

  • lowerdir: 这是是咱们 mount 中指定的目录。

    这个 lowerdir 中蕴含两个目录,这是应用了内核对 OverlayFS multi layer 个性的反对,咱们别离查看下其中内容:

    (MoeLove) ➜  ~ sudo ls -a /var/lib/docker/overlay2/l/5OO3RLRXHJPEH3IFEXNCTO4PY5
    .  ..  dev  .dockerenv  etc
    (MoeLove) ➜  ~ sudo ls -a /var/lib/docker/overlay2/l/UVA7IR67ZZTN2BNTKCZ7T6HUWU
    .  ..  bin  dev  etc  home  lib  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

    这两个目录,是不是看着很相熟?

    是的,它们就是咱们所启动容器根目录中的大部分内容。为什么说是大部分内容呢?当咱们查看其中的内容时,你也会发现它们的内容也并不残缺。比方咱们方才新写入的 moelove-info 文件,或者当咱们查看 etc 目录下的文件,你也会发现其中都只是惯例零碎 /etc 目录下的局部内容。

    (MoeLove) ➜  ~ sudo ls /var/lib/docker/overlay2/l/5OO3RLRXHJPEH3IFEXNCTO4PY5/etc   
    hostname  hosts  mtab  resolv.conf
    (MoeLove) ➜  ~ sudo ls /var/lib/docker/overlay2/l/UVA7IR67ZZTN2BNTKCZ7T6HUWU/etc 
    alpine-release  fstab     init.d       modprobe.d      mtab        passwd     protocols  shells       udhcpd.conf
    apk             group     inittab      modules         network     periodic   securetty  ssl
    conf.d          hostname  issue        modules-load.d  opt         profile    services   sysctl.conf
    crontabs        hosts     logrotate.d  motd            os-release  profile.d  shadow     sysctl.d
  • upperdir 是另一个重要的目录,咱们来看看其中的内容

    (MoeLove) ➜  ~ sudo ls -a /var/lib/docker/overlay2/f4356a8f14342008fc298bf3d313b863d10f30ef447a3b2f51ea9ece0dec09db/diff  
    .  ..  moelove-info  root

    咱们发现这个目录中蕴含着方才创立的 moelove-info 文件。同时,其中也蕴含一个 root 目录,这个目录便是咱们默认应用的 root 用户的家目录。

    如果去查看其中的内容,也会发现方才咱们执行命令的历史记录。

  • workdir 这个目录和 upperdir 在同一个父目录下,查看其内容发现外面只有一个 work 目录

    (MoeLove) ➜  ~ sudo ls -a /var/lib/docker/overlay2/f4356a8f14342008fc298bf3d313b863d10f30ef447a3b2f51ea9ece0dec09db/work
    .  ..  work

看完以上的介绍,想必你曾经发现了它们之间的局部分割,在此之前,咱们在额定看一个目录,那就是 upperdirworkdir 以及挂载点独特的父目录:

(MoeLove) ➜  ~ sudo ls  /var/lib/docker/overlay2/f4356a8f14342008fc298bf3d313b863d10f30ef447a3b2f51ea9ece0dec09db 
diff  link  lower  merged  work

你会发现这个目录下的内容就比拟直观了。咱们方才曾经看了其中 diffmergedwork 目录的内容了,当初看看 lower 中的内容吧:

(MoeLove) ➜  ~ sudo cat /var/lib/docker/overlay2/f4356a8f14342008fc298bf3d313b863d10f30ef447a3b2f51ea9ece0dec09db/lower
l/5OO3RLRXHJPEH3IFEXNCTO4PY5:l/UVA7IR67ZZTN2BNTKCZ7T6HUWU

咱们发现,lower 文件中的内容是以 : 分隔的两个 lowerdir 的目录名称。

至此,咱们能够失去以下论断:

  • lower 是根底层,能够蕴含多个 lowerdir
  • diff 是可写层,即挂载时的 upperdir,在容器内变更的文件都在这一层存储;
  • merged 是最终的合并后果,即容器给咱们出现进去的后果;

Overlay2

通过后面对 Docker 启动容器后挂载的 OverlayFS 的介绍后,Overlay2 的工作流程想必你也就比较清楚了。

将镜像各层作为 lower 根底层,同时减少 diff 这个可写层,通过 OverlayFS 的工作机制,最终将 merged 作为容器内的文件目录展现给用户。

你可能会有疑难,如果只是这样简略的组织,会不会有什么限度呢?答案是必定的,当然有限度,咱们能够通过 Overlay2 的代码来看

// daemon/graphdriver/overlay2/overlay.go#L442
func (d *Driver) getLower(parent string) (string, error) {
// 省略局部内容
    if len(lowers) > maxDepth {return "", errors.New("max depth exceeded")
    }
}

能够看到其对 lower 的深度有硬编码的限度,以后硬编码的限度是 128。如果你在应用的过程中遇到这个谬误,那示意你超过了最大深度限度,你就须要找些方法来缩小层级了。

总结

本节,我为你介绍了 OverlayFS 及 Overlay2 存储驱动相干的内容。通过理论启动容器生成的相干目录来介绍 overlay2 的工作流程,想必通过这种形式能更易了解。


欢送订阅我的文章公众号【MoeLove】

正文完
 0