docker 存储管理

文章目录

docker 存储管理
- 容器存储方案
- - docker 容器存储解决方案
- docker 存储驱动
- - 基本概述
  - 存储驱动的选择原则
  - 主流的 docker 存储驱动
  - docker 版本支持的存储驱动
- overlay2 存储驱动
- - OverlayFS
  - overlay2 存储驱动要求
  - 配置 docker 使用 overlay2 驱动
- overlay2 存储驱动的工作机制
- - OverlayFS 的镜像分层与共享
  - overlay2 存储驱动的镜像层实现
  - 存储驱动实现的磁盘上的容器层
  - overlay2存储驱动的读写机制
- docker 存储挂载
- - 卷与存储驱动
  - 挂载类型
  - docker 卷的使用
  - docker 绑定挂载的使用
  - docker tmpfs挂载
  - docker 卷容器
  - 容器的数据共享

docker 存储管理

容器存储方案

docker 容器存储解决方案

存储驱动

由存储驱动实现的联合文件系统

外部挂载卷

以外部挂载卷为代表的持久化存储

docker 存储驱动

docker 镜像和容器的分层结构，就是由 docker 存储驱动来实现的

基本概述

存储驱动控制镜像和容器在 docker 主机上的存储和管理方式

联合文件系统

Union file systems （UnionFS），为Linux、FreeBSD、NetBSD 操作系统设计的，将其他文件系统合并到一个联合挂载点的文件系统，是 docker 重要的底层技术之一，可以通过创建层进行操作，轻巧和快速。

联合文件系统的多种变体

AUFS
Over;ayFS
Btrfs
BFS
DeviceMapper等

存储驱动

aufs
overlay
overlay2
devicemapper
btrfs
zfs
vfs等

联合文件系统实际是由存储驱动来实现的----》

存储驱动的选择原则

生产环境使用具有最佳整体性能和稳定性的存储驱动
内核支持多个存储驱动，存储驱动选择顺序在 docker 的源代码中定义
优先使用 linux 发行版默认的存储驱动，docker 在安装的时候会根据当前系统的配置选择默认的存储驱动，默认驱动有好的稳定性，已经在发行版上经过了严格的测试
个别存储驱动要求使用特定格式的底层文件系统
选择存储驱动要取决于工作负载的特征和所需的稳定性级别

主流的 docker 存储驱动

存储驱动类型	说明
overlay2	当前主流Linux发行版的首选存储驱动，不需要额外配置（ubuntu14.04不支持）
aufs	docker 18.06以前版本，aufs首选，只支持 ubuntu和debian，需要安装额外的包
devicemapper	以前centos和红帽推荐的存储驱动，现在不是了，性能有点问题
btrfs、zfs	依赖底层文件系统的正确配置，需要更多投入的维护和设置
vfs	用于测试，适合那些没有“写时拷贝”的文件系统，不过性能差，不推荐生产环境

docker 版本支持的存储驱动

基本建议的存储驱动都是 overlay2

底层文件系统

backing filesystem，就是/var/lib/docker （默认）所在的文件系统

存储驱动	支持的底层文件系统
overlay2、overlay	fstype=1的xfs和ext4
aufs	xfs ext4
devicemapper	direct-lvm
btrfs	btrfs
zfs	zfs
vfs	任何文件系统

检查当前存储驱动

docker info | grep "Storage Driver"

在这里插入图片描述

overlay2 存储驱动

OverlayFS

类似于 AUFS 的现代联合文件系统
比 AUFS 速度更快，实现更简单
Linux3.18版本开始，OverlayFS 进入 Linux 内核主线，内核模块中的名称从 overlayfs 变成了 overlay
docker 提供的存储驱动版本：最初的 overlay 和更高效稳定的 overlay2
OverlayFS 是 Linux 内核提供的联合文件系统，overlay 和 overlay2 是 docker 用来实现 OverlayFS 的存储驱动
overlay2 存储驱动在索引节点优化上更加高效，但是需要Linux内核4.0以上的版本（centos7.9内核好像是3.10吧？？）

overlay2 存储驱动要求

存储驱动要求说明
Docker ERE 17.06 +
4.0或更高版本内核
RHEL或Centos 可使用3.10.0-514+
底层文件系统要求：ext4、xfs（仅限于启用d_type）

OverlayFS 文件系统通过 d_type 特性来确保文件的操作被正确处理，如果不支持 d_type的 overlay 或者 overlay2 存储驱动下使用 docker，docker 在操作文件上可能遇到一些错误

如何确定底层文件系统是否开启 d_type

在这里插入图片描述

配置 docker 使用 overlay2 驱动

大多数默认就是
显示的配置存储驱动方法：

{
  "registry-mirrors": ["https://xpd691zc.mirror.aliyuncs.com"],
  "insecure-registries":["https://192.168.1.236"],
  "storage-driver": "overlay2"
}

对于centos7系列

centos7 初始安装的内核时 3.x，官方基于该内核构建了 overlay 存储驱动，但是不能直接加载，到centos7.4版本才解决
centos7.4上安装的docker可以直接支持 overlay2存储驱动
centos7.4版本安装创建xfs文件系统的时候，默认没有启 d_type 支持的，需要额外注意

overlay2 存储驱动的工作机制

OverlayFS 的镜像分层与共享

不同层次的目录，对外统一呈现单个目录，2个目录被称为层，统一呈现的单个目录的联合进程被成为联合挂载（Union Mount）
OverlayFS 将底层目录称之为【lowerdir】，高层目录称之为【upperdir】，对外暴露统一视图的目录称为【merged】

在这里插入图片描述

镜像层与容器层有相似的文件时，容器层文件就会掩盖镜像层中相同的文件，然后合并显示

overlay与overlay2

最初的 overlay 仅仅适用2层模型工作，意味着多层镜像无法以多个 OverlayFS，当时的解决方法是采用硬链接的方案，比较废索引节点 node
两者存储驱动本质的区别在于镜像层之间共享数据的方法不同，overlay2 存储驱动通过每层的 lower 文件，而 overlay 存储驱动使用硬链接

overlay2 存储驱动的镜像层实现

多层镜像的分析

在这里插入图片描述

nginx镜像分层分析
在这里插入图片描述

最底层：3b93be9587d6276dc81265c5ab420878d27bddfb6343ea69656e5ad52ff14bfc
第一层：505637fc69befa54d1c0975e2cb99fb646ae1b04ccc6bdfe310b7576a2cceb6a
第二层：30ace3d17c2e4bd68261dc1fd3315f9278deef220a85f928435aaa9ce6ebc41c
第三层：27fda6ae190defa0beb127b7d8b29022dfc700ba2be1c0f9b196ff3fada49728
最顶层：62961b9285913b2fd2551c369f3401e1288b137037bc549ba15c3894135ee170

存储驱动实现的磁盘上的容器层

镜像层

在这里插入图片描述

容器层

docker run -it nginx /bin/bash

在这里插入图片描述

overlay2存储驱动的读写机制

读取文件

场景：

文件不存在于容器层，从镜像层读取，性能开销很小
文件存在于容器层，不在镜像层，直接从容器层读取
同时存在容器层和镜像层，读取镜像层中的文件版本，容器层中的文件将掩盖镜像中同名的文件

修改文件或目录

首次写入文件：容器层不存在，存储驱动执行一次【copy-on-write】将文件从镜像层（lowerdir）复制到容器层（upperdir），然后容器将更改部分写入容器中的该文件的一个新复制，这是一个文件级别的操作，即使这个文件非常大，但是只需要修改一个小部分，也是要复制整个文件，对容器的写入性能会带来影响，上述操作只在首次发生，后续的这个文件写操作只会针对已经复制到容器中的文件进行复制操作

删除文件和目录

容器中删除一个文件，会在容器层创建一个白化（whiteout）文件，在联合文件系统中，白化文件是指某一类占位符形态的特殊文件，可以删除属于自己的某些系统文件副本，但是无法删除镜像层的文件，因为镜像层是只读的，白化文件可以阻止容器读取到它。
容器中删除一个目录，和上述类似，会在容器层创建一个不透明（opaque）目录，能够有效阻止容器访问它

重命名目录