最近项目上服务器磁盘满了,项目上小哥为了腾出来点空间,把docker的overlay2文件给删了部分,导致部分容器启动时候报错:
docker: Error response from daemon: open /var/lib/docker/overlay2/ffe5563b8c6a834b21dadb22106209d9fa1ab64ebe063e3ec040a05f1c: no such file or directory大体意思就是overlay2下面的这个文件没了
处理方式:
1、首先保证之前业务数据库有备份
2、把现在运行的容器关掉、删除
3、把相关镜像备份下，然后清理掉
4、按顺序重新导入新的镜像，然后重新启动容器并导入备份的数据问题根源在于docker的 Root Dir满了,这个默认路径在 /var/lib/docker
我们可以在部署docker时候修改这个默认路径,改成一个相对较大路径下
1、systemctl stop docker <br> 关闭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 <br> 设置开机启动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/var/lib/docker下的几个目录 及docker的几个id
1、 /var/lib/docker下目录结构为:
container
image
network
swarm
volumes
overlay2
...可以看到docker涉及到的一些概念容器、镜像、网络、挂载等都在这里有对应的目录,这是docker的存储目录
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、container目录:
container目录内部是启动容器的一些配置信息
hosts、hostname域名等信息;
config.v2.json配置文件,我们使用docker inspect 容器时候获取到的容器配置信息;
*-json.log容器产品日志文件
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算法计算得来的值,
两个优势 一个方便校验、一个方便共享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文件(就是启动容器之后 回显的文件)
6、Overlay2:
lower：底层文件系统。对于Docker来说，就是只读的镜像层；upper：上层文件系统。对于Docker来说，就是可读写的容器层；merged：作为统一视图的联合挂载点。对于Docker来说，就是用户视角下的文件系统；work：提供辅助功能。
最后说明下，回到最开头的问题，如果误删了文件导致docker容器无法启动，可以将磁盘上的/var/lib/docker目录重命名，然后重启docker服务，让docker重新拉取镜像，但如果以前的文件系统没有映射，会丢失文件，所以还是建议存储的内容一定要做好目录映射。
