【随手记录】关于docker存储overlay2相关问题
1、问题来源
最近项目上服务器磁盘满了,项目上小哥为了腾出来点空间,把docker的overlay2文件给删了部分,导致部分容器启动时候报错:
docker: Error response from daemon: open /var/lib/docker/overlay2/ffe5563b8c6a834b21dadb22106209d9fa1ab64ebe063e3ec040a05f1c: no such file or directory
大体意思就是overlay2下面的这个文件没了
处理方式:
1、首先保证之前业务数据库有备份 2、把现在运行的容器关掉、删除 3、把相关镜像备份下，然后清理掉 4、按顺序重新导入新的镜像，然后重新启动容器并导入备份的数据
2、问题根源
问题根源在于docker的 Root Dir满了,这个默认路径在 /var/lib/docker
我们可以在部署docker时候修改这个默认路径,改成一个相对较大路径下
1、systemctl stop docker
关闭docker 2、修改 /etc/docker/daemon.json配置文件 vi /etc/docker/daemon.json { "data-root": "/data/lib/docker" } 3、rsnyc -avz source dest -a包含子目录 同时同步元信息（比如修改时间、权限等） -v控制台输出信息 -z先压缩再传输 它可以在本地计算机与远程计算机之间，或者两个本地目录之间同步文件（但不支持两台远程计算机之间的同步） 没安装的可以用 yum install rsync安装或者用 cp mv等命令迁移 4、systemctl enable docker
设置开机启动docker 5、验证路径是否改变 docker info|grep 'Root Dir' 6、验证镜像是否存在 docker images
但是迁移到大磁盘治标不治本,需要找出来根本原因,我们去docker的Root Dir 输入命令
du -h --max-depth=1|sort -n
查看大文件路径,可以发现两个目录容易比较大 一个是container目录 一个是overlay2目录
对于overlay2目录,可以使用
docker system prune -a
清理磁盘，删除关闭的容器、无用的数据卷和网络，以及dangling镜像(即无tag的镜像),
-a 命令清理得更加彻底，可以将没有容器使用Docker镜像都删掉
对于container目录,基本是容器运行日志造成的,进入 container目录 输入命令 可以看到大文件，都是一些日志文件
du -h --max-depth=1|sort -n
对于日志
cat /dev/null > *-json.log清空日志
同时对于容器加启动限制
docker run ...... --log-opt max-size=10m --log-opt max-file=1
或者 修改/etc/docker/daemon.json配置文件
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3",
"labels": "production_status",
"env": "os,customer"
}
}
或者在启动的docker-compose.yml添加限制
logging:
options:
max-size: '12m'
max-file: '5'
driver: json-file
3、另外说明
/var/lib/docker下的几个目录 及docker的几个id
3.1、 /var/lib/docker下目录结构为:
container image network swarm volumes overlay2 ...
可以看到docker涉及到的一些概念容器、镜像、网络、挂载等都在这里有对应的目录,这是docker的存储目录
3.2、docker存储驱动:
现在docker支持很多种文件驱动类型,比如AUFS、OverlayFS，OverlayFS实现方式和AUFS类似，但是更快、且实现起来简单 ---> 说明文章
对于linux内核4.0及以上版本 或者红帽、centos 3.10.0-514版本可以使用overlay2存储驱动,其他低版本使用overlay(更推进 overlay2, 对于inode管理更好 效率更高)
我们可以通过修改配置文件 /etc/docker/daemon.json 来调整驱动类型
{
"storage-driver": "overlay2"
}
3.3、container目录:
container目录内部是启动容器的一些配置信息
hosts、hostname域名等信息;
config.v2.json配置文件,我们使用docker inspect 容器时候获取到的容器配置信息;
*-json.log容器产品日志文件
3.4、image目录:
distribution 目录
diffid-by-digest 保存了digest(layerID)->diffID的映射关系
v2metadata-by-diffid 保存了diffid -> (digest,repository)的映射关系
digest(layerID) 就是 pull 镜像时的 hash ID，拉取是 镜像层文件是压缩文件，压缩态
diffid 是 docker inspect 查看到的 镜像层 hash ID，此时 镜像层文件是解压缩的，解压缩态
因此虽说这两种 ID 都表示 镜像层 hash ID，但一个是压缩的，一个是解压缩的，所以 hash 运算后不一致
imagedb、layerdb 这俩都是元数据文件
imagedb可以看到镜像的元数据信息, cat下看到内部写着 dfffid
repositories.json 记录本地镜像列表, 镜像名称-版本:imageId
rootfs:
diffid: sha256 记录各层解压后经过sha256算法计算得来的值,
两个优势 一个方便校验、一个方便共享
3.5、layerdb目录
sha目录，内部记录ChainID
如果layer是最底层，没有任何父layer，那么diffID = chainID;
否则，chainID(n)=sha256sum(chainID(n-1)) diffID(n))
举个例子: 两层的 diffid diffid2 进行shasum256运算得出chainID
echo -n "sha256:5dacd731af1b0386ead06c8b1feff9f65d9e0bdfec032d2cd0bc03690698feda sha256:dd0338cdfab32cdddd6c30efe8c89d0229d9f939e2bb736fbb0a52f27c2b0ee9" | shasum -a 256
找到chainID之后，进去具体某个目录则看到 cache-id，指向具体真实的的overlay2文件
mounts
每启动一个容器,则在 layerdb下面会多一个 mounts文件(就是启动容器之后 回显的文件)
3.6、Overlay2:
- lower：底层文件系统。对于Docker来说，就是只读的镜像层；
- upper：上层文件系统。对于Docker来说，就是可读写的容器层；
- merged：作为统一视图的联合挂载点。对于Docker来说，就是用户视角下的文件系统；
- work：提供辅助功能。
