docker 存储管理

文章目录

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

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

shell 复制代码

{
  "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镜像分层分析

shell 复制代码

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

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

镜像层

容器层

docker run -it nginx /bin/bash

overlay2存储驱动的读写机制

读取文件

场景：

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

修改文件或目录

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

删除文件和目录

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

重命名目录

只有源和目的路径都位于顶层才能对目录进行重命名，否则返回错误（cross-device link not permitted）

docker 存储挂载

卷与存储驱动

容器层的数据所存在的问题

在容器的生命周期内存在，随着容器的死亡还被删除，不会持久保存
主机其他进程要访问容器中的数据，难度较高
容器的可写层与主机紧密耦合，无法轻松将数据转移到其他地方
写入容器的可写层还需要存储驱动来管理文件系统，性能不如卷

存储卷

又称数据卷
本质就是主机上的文件或者目录，能够直接被挂载到容器的文件系统中
对数据卷的读写操作会绕过存储驱动，以主机的速度运行
任意数量的数据卷都可以装入容器
多个容器可以共享一个或多个卷

挂载类型

不管挂载类型，数据并没有什么不同，这些数据在容器的文件系统中，都会显示目录或文件

卷

存储在主机文件系统中，默认/var/lib/docker/volumes 目录中，由 docker 管理，非 docker 进程不能修改
是 dockers 中持久保存容器应用数据的最佳方式
也支持卷驱动，这些卷驱动可以让用户将数据存储到远程主机或云上

绑定挂载

存储到主机上的任意位置
绑定挂载性能较高，依赖于具有特定目录结构的主机文件系统
绑定挂载也允许访问敏感文件
适合的场景：主机与容器共享配置文件等

tmpfs

仅限于运行 Linux 操作系统的 Docker 主机使用，只存储在主机的内存中，不会被写入主机的文件系统中，不能持久化保存容器的数据
如果容器产生了非持久化状态数据，可以考虑使用这个来挂载

docker 卷的使用

卷的创建

显示创建：docker volume create

卷的优势

更易备份和迁移
可以通过 docker 命令和 API 进行管理
卷在 Linux 容器和 Windows 容器中都可以工作
多个容器之间共享更安全
卷驱动支持远程主机和云端，加密卷内容等，拓展其他功能都可以
新卷的内容可以由容器预填充

使用

--mount：键值对，逗号隔开的用法，比-v的语法更加冗长，顺序不重要，

-v：卷的名称:容器中被挂载的文件或目录的路径（绝对路径）:<ro等可选项>

如果卷不是空白的呢？

如果卷是空白的呢，上面其实已经看过效果

删除卷

删除所有：docker volume prune

删除卷：docker volume rm xxxx

docker 绑定挂载的使用

特性

绑定挂载功能有效
绑定挂载性能高
容器的移植性被限制，更多的需要配置操作
系统安全产生影响

使用

--mount 选项	说明
type	挂载的类型
src	主机上的绝对路径
target	容器内的路径
readonly	只读
bind-propagation	绑定传播
consistency	一致性

上述操作也可以用于文件挂载
挂载主机上不存在的目录或者文件

docker tmpfs挂载

tmpfs：临时文件系统，基于内存的文件系统，速度非常快

不会持久化到磁盘

容器的生命周期内存在

特性

挂载是临时的
存储在主机内存中，内存不够，就存交换空间中
容器停止，tmpfs 将被移除
不能容器共享
只适合linux平台

~这个就不去细看了，等需要用到的场景再学习一下即可~

docker 卷容器

Volume Container 数据卷容器，是一种特殊的容器，专门用来将卷提供给其他容器挂载，通过 --volumes-from 选项基于卷容器创建一个新的容器，并挂载君容器提供的卷

通过卷容器实现容器之间的数据共享

容器要共享数据，先创建卷容器，再让其他容器挂载卷容器来共享

使用

感觉这个用途不大

容器的数据共享

容器与主机共享数据

绑定挂载和卷都可以
docker cp 可以在容器与主机之间复制数据

容器之间共享数据

绑定挂载和卷都可以