1、24 个常见的 Docker 疑难杂症处理技巧(一)

喜欢ヅ旅行 2024-02-18 11:29 12阅读 0赞

1Docker 迁移存储目录
默认情况系统会将 Docker 容器存放在 /var/lib/docker 目录下

[问题起因] 今天通过监控系统,发现公司其中一台服务器的磁盘快慢,随即上去看了下,发现 /var/lib/docker 这个目录特别大。由上述原因,我们都知道,在 /var/lib/docker 中存储的都是相关于容器的存储,所以也不能随便的将其删除掉。
那就准备迁移 docker 的存储目录吧,或者对 /var 设备进行扩容来达到相同的目的。更多关于 dockerd 的详细参数,请点击查看 官方文档 地址。
但是需要注意的一点就是,尽量不要用软链, 因为一些 docker 容器编排系统不支持这样做,比如我们所熟知的 k8s 就在内。

  1. # 发现容器启动不了了
  2. ERRORcannot create temporary directory!
  3. # 查看系统存储情况
  4. $ du -h --max-depth=1

[解决方法 1] 添加软链接

  1. # 1.停止docker服务
  2. $ sudo systemctl stop docker
  3. # 2.开始迁移目录
  4. $ sudo mv /var/lib/docker /data/
  5. # 3.添加软链接
  6. $ sudo ln -s /data/docker /var/lib/docker
  7. # 4.启动docker服务
  8. $ sudo systemctl start docker

[解决方法 2] 改动 docker 配置文件

  1. # [方式一] 改动docker启动配置文件
  2. $ sudo vim /lib/systemd/system/docker.service
  3. ExecStart=/usr/bin/dockerd --graph=/data/docker/
  4. # [方式二] 改动docker启动配置文件
  5. $ sudo vim /etc/docker/daemon.json
  6. {
  7. "live-restore": true,
  8. "graph": [ "/data/docker/" ]
  9. }

[操作注意事项] 在迁移 docker 目录的时候注意使用的命令,要么使用 mv 命令直接移动,要么使用 cp 命令复制文件,但是需要注意同时复制文件权限和对应属性,不然在使用的时候可能会存在权限问题。如果容器中,也是使用 root 用户,则不会存在该问题,但是也是需要按照正确的操作来迁移目录。

  1. # 使用mv命令
  2. $ sudo mv /var/lib/docker /data/docker
  3. # 使用cp命令
  4. $ sudo cp -arv /data/docker /data2/docker

下图中,就是因为启动的容器使用的是普通用户运行进程的,且在运行当中需要使用 /tmp 目录,结果提示没有权限。在我们导入容器镜像的时候,其实是会将容器启动时需要的各个目录的权限和属性都赋予了。如果我们直接是 cp 命令单纯复制文件内容的话,就会出现属性不一致的情况,同时还会有一定的安全问题。

在这里插入图片描述
2Docker 设备空间不足
Increase Docker container size from default 10GB on rhel7.

[问题起因一] 容器在导入或者启动的时候,如果提示磁盘空间不足的,那么多半是真的因为物理磁盘空间真的有问题导致的。如下所示,我们可以看到 / 分区确实满了。

  1. # 查看物理磁盘空间
  2. $ df -Th
  3. Filesystem Size Used Avail Use% Mounted on
  4. /dev/vda1 40G 40G 0G 100% /
  5. tmpfs 7.8G 0 7.8G 0% /dev/shm
  6. /dev/vdb1 493G 289G 179G 62% /mnt

如果发现真的是物理磁盘空间满了的话,就需要查看到底是什么占据了如此大的空间,导致因为容器没有空间无法启动。其中,docker 自带的命令就是一个很好的能够帮助我们发现问题的工具。

  1. # 查看基本信息
  2. # 硬件驱动使用的是devicemapper,空间池为docker-252
  3. # 磁盘可用容量仅剩16.78MB,可用供我们使用
  4. $ docker info
  5. Containers: 1
  6. Images: 28
  7. Storage Driver: devicemapper
  8. Pool Name: docker-252:1-787932-pool
  9. Pool Blocksize: 65.54 kB
  10. Backing Filesystem: extfs
  11. Data file: /dev/loop0
  12. Metadata file: /dev/loop1
  13. Data Space Used: 1.225 GB
  14. Data Space Total: 107.4 GB
  15. Data Space Available: 16.78 MB
  16. Metadata Space Used: 2.073 MB
  17. Metadata Space Total: 2.147 GB

[解决方法] 通过查看信息,我们知道正是因为 docker 可用的磁盘空间不足,所以导致启动的时候没有足够的空间进行加载启动镜像。解决的方法也很简单,第一就是清理无效数据文件释放磁盘空间(清除日志),第二就是修改 docker 数据的存放路径(大分区)。

  1. # 显示哪些容器目录具有最大的日志文件
  2. $ du -d1 -h /var/lib/docker/containers | sort -h
  3. # 清除您选择的容器日志文件的内容
  4. $ cat /dev/null > /var/lib/docker/containers/container_id/container_log_name

[问题起因二] 显然我遇到的不是上一种情况,而是在启动容器的时候,容器启动之后不久就显示是 unhealthy 的状态,通过如下日志发现,原来是复制配置文件启动的时候,提示磁盘空间不足。
后面发现是因为 CentOS7 的系统使用的 docker 容器默认的创建大小就是 10G 而已,然而我们使用的容器却超过了这个限制,导致无法启动时提示空间不足。

  1. 2023-11-13 11:11:15,816 INFO spawned: 'app-demo' with pid 835
  2. 2023-11-13 11:11:16,268 INFO exited: app (exit status 1; not expected)
  3. 2023-11-13 11:11:17,270 INFO gave up: app entered FATAL state, too many start retries too quickly
  4. cp: cannot create regular file '/etc/supervisor/conf.d/grpc-app-demo.conf': No space left on device
  5. cp: cannot create regular file '/etc/supervisor/conf.d/grpc-app-demo.conf': No space left on device
  6. cp: cannot create regular file '/etc/supervisor/conf.d/grpc-app-demo.conf': No space left on device
  7. cp: cannot create regular file '/etc/supervisor/conf.d/grpc-app-demo.conf': No space left on device

[解决方法 1] 改动 docker 启动配置文件

  1. # /etc/docker/daemon.json
  2. {
  3. "live-restore": true,
  4. "storage-opt": [ "dm.basesize=20G" ]
  5. }

[解决方法 2] 改动 systemctl 的 docker 启动文件

  1. # 1.stop the docker service
  2. $ sudo systemctl stop docker
  3. # 2.rm exised container
  4. $ sudo rm -rf /var/lib/docker
  5. # 2.edit your docker service file
  6. $ sudo vim /usr/lib/systemd/system/docker.service
  7. # 3.find the execution line
  8. ExecStart=/usr/bin/dockerd
  9. and change it to:
  10. ExecStart=/usr/bin/dockerd --storage-opt dm.basesize=20G
  11. # 4.start docker service again
  12. $ sudo systemctl start docker
  13. # 5.reload daemon
  14. $ sudo systemctl daemon-reload

[问题起因三] 还有一种情况也会让容器无法启动,并提示磁盘空间不足,但是使用命令查看发现并不是因为物理磁盘真的不足导致的。而是,因为对于分区的 inode 节点数满了导致的。

  1. # 报错信息
  2. No space left on device

[解决方法] 因为 ext3 文件系统使用 inode table 存储 inode 信息,而 xfs 文件系统使用 B+ tree 来进行存储。考虑到性能问题,默认情况下这个 B+ tree 只会使用前 1TB 空间,当这 1TB 空间被写满后,就会导致无法写入 inode 信息,报磁盘空间不足的错误。我们可以在 mount 时,指定 inode64 即可将这个 B+ tree 使用的空间扩展到整个文件系统。

  1. # 查看系统的inode节点使用情况
  2. $ sudo df -i
  3. # 尝试重新挂载
  4. $ sudo mount -o remount -o noatime,nodiratime,inode64,nobarrier /dev/vda1

[补充知识] 文件储存在硬盘上,硬盘的最小存储单位叫做 扇区(Sector)。每个扇区储存 512 字节(相当于0.5KB)。操作系统读取硬盘的时候,不会一个个扇区地读取,这样效率太低,而是一次性连续读取多个扇区,即一次性读取一个块(block)。这种由多个扇区组成的块,是文件存取的最小单位。块的大小,最常见的是4KB,即连续八个 sector 组成一个 block 块。文件数据都储存在块中,那么很显然,我们还必须找到一个地方储存文件的元信息,比如文件的创建者、文件的创建日期、文件的大小等等。这种储存文件元信息的区域就叫做索引节点(inode)。每一个文件都有对应的 inode,里面包含了除了文件名以外的所有文件信息。
inode 也会消耗硬盘空间,所以硬盘格式化的时候,操作系统自动将硬盘分成两个区域。一个是数据区,存放文件数据;另一个是 inode 区(inode table),存放 inode 所包含的信息。每个 inode 节点的大小,一般是 128 字节或 256 字节。inode 节点的总数,在格式化时就给定,一般是每1KB或每2KB就设置一个 inode 节点。

  1. # 每个节点信息的内容
  2. $ stat check_port_live.sh
  3. File: check_port_live.sh
  4. Size: 225 Blocks: 8 IO Block: 4096 regular file
  5. Device: 822h/2082d Inode: 99621663 Links: 1
  6. Access: (0755/-rwxr-xr-x) Uid: ( 1006/ escape) Gid: ( 1006/ escape)
  7. Access: 2019-07-29 14:59:59.498076903 +0800
  8. Modify: 2019-07-29 14:59:59.498076903 +0800
  9. Change: 2019-07-29 23:20:27.834866649 +0800
  10. Birth: -
  11. # 磁盘的inode使用情况
  12. $ df -i
  13. Filesystem Inodes IUsed IFree IUse% Mounted on
  14. udev 16478355 801 16477554 1% /dev
  15. tmpfs 16487639 2521 16485118 1% /run
  16. /dev/sdc2 244162560 4788436 239374124 2% /
  17. tmpfs 16487639 5 16487634 1% /dev/shm

3Docker 缺共享链接库
Docker 命令需要对/tmp 目录下面有访问权限

[问题起因] 给系统安装完 compose 之后,查看版本的时候,提示缺少一个名为 libz.so.1 的共享链接库。第一反应就是,是不是系统少安装那个软件包导致的。随即,搜索了一下,将相关的依赖包都给安装了,却还是提示同样的问题。

  1. # 提示错误信息
  2. $ docker-compose --version
  3. error while loading shared libraries: libz.so.1: failed to map segment from shared object: Operation not permitted

[解决方法] 后来发现,是因为系统中 docker 没有对 /tmp 目录的访问权限导致,需要重新将其挂载一次,就可以解决了。

  1. # 重新挂载
  2. $ sudo mount /tmp -o remount,exec

4Docker 容器文件损坏
对 dockerd 的配置有可能会影响到系统稳定

[问题起因] 容器文件损坏,经常会导致容器无法操作。正常的 docker 命令已经无法操控这台容器了,无法关闭、重启、删除。正巧,前天就需要这个的问题,主要的原因是因为重新对 docker 的默认容器进行了重新的分配限制导致的。

  1. # 操作容器遇到类似的错误
  2. b'devicemapper: Error running deviceCreate (CreateSnapDeviceRaw) dm_task_run failed'

[解决方法] 可以通过以下操作将容器删除/重建。

  1. # 1.关闭docker
  2. $ sudo systemctl stop docker
  3. # 2.删除容器文件
  4. $ sudo rm -rf /var/lib/docker/containers
  5. # 3.重新整理容器元数据
  6. $ sudo thin_check /var/lib/docker/devicemapper/devicemapper/metadata
  7. $ sudo thin_check --clear-needs-check-flag /var/lib/docker/devicemapper/devicemapper/metadata
  8. # 4.重启docker
  9. $ sudo systemctl start docker

5Docker 容器优雅重启
不停止服务器上面运行的容器,重启 dockerd 服务是多么好的一件事

[问题起因] 默认情况下,当 Docker 守护程序终止时,它会关闭正在运行的容器。从 Docker-ce 1.12 开始,可以在配置文件中添加 live-restore 参数,以便在守护程序变得不可用时容器保持运行。需要注意的是 Windows 平台暂时还是不支持该参数的配置。

  1. # Keep containers alive during daemon downtime
  2. $ sudo vim /etc/docker/daemon.yaml
  3. {
  4. "live-restore": true
  5. }
  6. # 在守护进程停机期间保持容器存活
  7. $ sudo dockerd --live-restore
  8. # 只能使用reload重载
  9. # 相当于发送SIGHUP信号量给dockerd守护进程
  10. $ sudo systemctl reload docker
  11. # 但是对应网络的设置需要restart才能生效
  12. $ sudo systemctl restart docker

[解决方法] 可以通过以下操作将容器删除/重建。

  1. # /etc/docker/daemon.yaml
  2. {
  3. "registry-mirrors": ["https://vec0xydj.mirror.aliyuncs.com"], # 配置获取官方镜像的仓库地址
  4. "experimental": true, # 启用实验功能
  5. "default-runtime": "nvidia", # 容器的默认OCI运行时(默认为runc)
  6. "live-restore": true, # 重启dockerd服务的时候容易不终止
  7. "runtimes": {
  8. # 配置容器运行时
  9. "nvidia": {
  10. "path": "/usr/bin/nvidia-container-runtime",
  11. "runtimeArgs": []
  12. }
  13. },
  14. "default-address-pools": [ # 配置容器使用的子网地址池
  15. {
  16. "scope": "local",
  17. "base":"172.17.0.0/12",
  18. "size":24
  19. }
  20. ]
  21. }
  22. $ vim /etc/docker/daemon.json
  23. {
  24. "default-address-pools" : [
  25. {
  26. "base" : "172.240.0.0/16",
  27. "size" : 24
  28. }
  29. ]
  30. }

6Docker 容器无法删除
找不到对应容器进程是最吓人的

[问题起因] 今天遇到 docker 容器无法停止/终止/删除,以为这个容器可能又出现了 dockerd 守护进程托管的情况,但是通过 ps -ef 无法查到对应的运行进程。哎,后来开始开始查 supervisor 以及 Dockerfile 中的进程,都没有。这种情况的可能原因是容器启动之后,主机因任何原因重新启动并且没有优雅地终止容器。剩下的文件现在阻止你重新生成旧名称的新容器,因为系统认为旧容器仍然存在。

  1. # 删除容器
  2. $ sudo docker rm -f f8e8c3..
  3. Error response from daemon: Conflict, cannot remove the default name of the container

[解决方法] 找到 /var/lib/docker/containers/ 下的对应容器的文件夹,将其删除,然后重启一下 dockerd 即可。我们会发现,之前无法删除的容器没有了。

  1. # 删除容器文件
  2. $ sudo rm -rf /var/lib/docker/containers/f8e8c3...65720
  3. # 重启服务
  4. $ sudo systemctl restart docker.service

发表评论

表情:
评论列表 (有 0 条评论,12人围观)

还没有评论,来说两句吧...

相关阅读