详解docker中容器devicemapper设备的挂载流程-低调大师

详解docker中容器devicemapper设备的挂载流程

2019-04-02 623

详解docker中容器devicemapper设备的挂载流程
事故起因
版本说明：本文中docker版本主要基于1.10版本，操作系统为centos7。devicemapper在文中缩写为dm。

某个用户的容器启动不起来，启动时候一直报错。通过docker log查看日志，可以看到报错信息如下

Timestamp: 2019-04-01 16:19:26.33690413 +0800 CST
Code: System error

Message: can't create pivot_root dir , error mkdir /export/docker/devicemapper/mnt/7a35b08cc8815ef439dfcc74fd375e2fbb618208674d6eff1ea5d0b61cc7ef1c/rootfs/.pivot_root492082001: no space left on device
对照docker源码，可以看到报错位置，就是在容器启动时候，docker会在容器中创建一个临时文件夹。而由于空间不足，因此导致报错，容器无法启动。

pivotDir, err := ioutil.TempDir(tmpDir, ".pivot_root")
if err != nil {

return fmt.Errorf("can't create pivot_root dir %s, error %v", pivotDir, err)

}
初步可以判断是由于用户将dm的根目录磁盘写满了导致。那么要解决这个问题，其实思路也就很简单，就是将容器的dm设备手动挂载起来，然后清理冗余文件后，再恢复。那么在docker中，是如何将容器的dm盘进行创建挂载的，笔者对此进行了一下梳理。

docker中容器的dm盘挂载原理
获取dm设备信息
这里我们假设要模拟的是f34cee76e36a容器的挂载。
首先进入到docker的存储目录，可以从image的层文件夹中根据容器的id，获取mount-id。
而后从devicemapper/metadata/文件夹中，根据mount-id，获取device_id。这里，该容器的device_id为34709。

[root@localhost docker]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f34cee76e36a xuxinkun/kubesql "kubesql-server" 3 weeks ago Exited (137) 3 hours ago kubesql-server
[root@localhost docker]# cat image/devicemapper/layerdb/mounts/f34cee76e36af13dbda34f78406ebe1c9a426d16e4eaae02055ace6b557b7539/mount-id
dad0ce9e1adcfe76df319443f429698eafa52dd6c6cb4fb8192f0846656f8824
[root@localhost docker]# cat devicemapper/metadata/dad0ce9e1adcfe76df319443f429698eafa52dd6c6cb4fb8192f0846656f8824
{"device_id":34709,"size":10737418240,"transaction_id":844170,"initialized":false,"deleted":false}
先看一下已经创建的dm设备列表和table。

[root@localhost docker]# dmsetup ls
cl-swap (253:1)
cl-root (253:0)
docker-253:2-3693860-e85dd79353abe6967cbc4f968934ae078d4d9da02010033b73a3df9659e4d547 (253:4)
cl-home (253:2)
docker-253:2-3693860-pool (253:3)
[root@localhost docker]# dmsetup table
cl-swap: 0 32899072 linear 8:2 2048
cl-root: 0 104857600 linear 8:2 1647560704
docker-253:2-3693860-e85dd79353abe6967cbc4f968934ae078d4d9da02010033b73a3df9659e4d547: 0 20971520 thin 253:3 34719
cl-home: 0 1614659584 linear 8:2 32901120
docker-253:2-3693860-pool: 0 167772160 thin-pool 7:1 7:0 128 32768 1 skip_block_zeroing
这其中主要要关注的是docker-253:2-3693860-pool，也就是253:3这个设备。后面的所有的docker容器的dm设备都是从这个pool中分出去的。
从table中可以看到一个已经创建好的，它的table是0 20971520 thin 253:3 34719。table的格式如下

logical_start_sector num_sectors target_type target_args
开始扇区扇区数设备类型设备参数
20971520的扇区数应与docker启动时为容器分配的容量相关。

其中，设备参数的34719即为容器对应的device_id。

创建dm设备
那么现在模拟容器挂载，首先创建一个dm设备。

[root@localhost docker]# dmsetup create docker-253:2-3693860-dad0ce9e1adcfe76df319443f429698eafa52dd6c6cb4fb8192f0846656f8824 --table "0 20971520 thin 253:3 34709"
然后可以查看下dm设备。

[root@localhost docker]# dmsetup ls
cl-swap (253:1)
cl-root (253:0)
docker-253:2-3693860-dad0ce9e1adcfe76df319443f429698eafa52dd6c6cb4fb8192f0846656f8824 (253:5)
docker-253:2-3693860-e85dd79353abe6967cbc4f968934ae078d4d9da02010033b73a3df9659e4d547 (253:4)
cl-home (253:2)

[root@localhost tmp]# ls /dev/dm-*
/dev/dm-0 /dev/dm-1 /dev/dm-2 /dev/dm-3 /dev/dm-4 /dev/dm-5
可以看到，新增了一个dm-5的设备。

当然，也可以在/dev/mapper下查看

挂载dm设备
现在将/dev/dm-5设备挂载到自己创建了/tmp/test目录下。

[root@localhost docker]# mount /dev/dm-5 /tmp/test
[root@localhost docker]# ll /tmp/test/
total 4
-rw------- 1 root root 64 Mar 11 15:40 id
drwxr-xr-x 16 root root 274 Apr 2 09:54 rootfs
[root@localhost docker]# ll /tmp/test/rootfs/
total 16
-rw-r--r-- 1 root root 12076 Dec 5 09:37 anaconda-post.log
lrwxrwxrwx 1 root root 7 Dec 5 09:36 bin -> usr/bin
drwxr-xr-x 4 root root 43 Mar 11 17:50 dev
drwxr-xr-x 48 root root 4096 Mar 11 17:50 etc
drwxr-xr-x 3 root root 21 Mar 11 17:38 home
lrwxrwxrwx 1 root root 7 Dec 5 09:36 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Dec 5 09:36 lib64 -> usr/lib64
drwxr-xr-x 2 root root 6 Apr 11 2018 media
drwxr-xr-x 2 root root 6 Apr 11 2018 mnt
drwxr-xr-x 2 root root 6 Apr 11 2018 opt
drwxr-xr-x 2 root root 6 Dec 5 09:36 proc
dr-xr-x--- 4 root root 140 Mar 11 17:37 root
drwxr-xr-x 12 root root 163 Mar 11 17:50 run
lrwxrwxrwx 1 root root 8 Dec 5 09:36 sbin -> usr/sbin
drwxr-xr-x 2 root root 6 Apr 11 2018 srv
drwxr-xr-x 2 root root 6 Dec 5 09:36 sys
drwxrwxrwt 7 root root 132 Mar 11 17:38 tmp
drwxr-xr-x 13 root root 155 Dec 5 09:36 usr
drwxr-xr-x 18 root root 238 Dec 5 09:36 var
可以在目录下看到rootfs文件夹，该文件夹下即为容器的所有文件。而后找出冗余文件删除即可。

卸载移除设备
最后清理恢复，卸载目录，移除dm设备。

[root@localhost docker]# umount /tmp/test
[root@localhost docker]# dmsetup remove docker-253:2-3693860-e85dd79353abe6967cbc4f968934ae078d4d9da02010033b73a3df9659e4d547
重启容器后，恢复正常。至此，该问题得以修复。

以上是手动进行容器dm设备的创建挂载流程。其实在docker中，也基本上是这样来进行操作的。具体代码可以参考graphdriver下的devmapper中的相关流程。代码这里就不再一一走读了。

docker中mnt挂载点不可见的问题
在这里顺带还解释下docker挂载的一个疑惑，就是docker中dm设备最终都会mount到devicemapper/mnt/{mount-id}/目录下。

但是在/proc/mounts下并不可见。这是因为docker daemon单独创建了一个mount的namespace。

[root@localhost tmp]# ll /proc/1/ns/mnt
lrwxrwxrwx 1 root root 0 Mar 19 19:03 /proc/1/ns/mnt -> mnt:[4026531840]
[root@localhost tmp]# ps -fe|grep docker
root 845 23449 0 17:04 pts/1 00:00:00 grep --color=auto docker
root 23121 1 0 09:09 ? 00:00:38 /usr/bin/docker-current daemon --selinux-enabled --log-driver=journald -H tcp://127.0.0.1:5050 -H unix:///var/run/docker.sock -g /home/docker --storage-opt dm.blkdiscard=false --storage-opt dm.mountopt=nodiscard --storage-opt dm.loopdatasize=80G --storage-opt dm.loopmetadatasize=4G
[root@localhost tmp]# ll /proc/23121/ns/mnt
lrwxrwxrwx 1 root root 0 Apr 2 10:25 /proc/23121/ns/mnt -> mnt:[4026532450]
23121为docker daemon的进程id。可以通过查看该进程的mounts即可看到相应的挂载信息。

[root@localhost tmp]# cat /proc/23121/mounts|grep mnt
/dev/mapper/docker-253:2-3693860-e85dd79353abe6967cbc4f968934ae078d4d9da02010033b73a3df9659e4d547 /home/docker/devicemapper/mnt/e85dd79353abe6967cbc4f968934ae078d4d9da02010033b73a3df9659e4d547 xfs rw,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
当然，也可以通过nsenter切入到docker daemon进程的mount ns下进行查看。

[root@localhost tmp]# nsenter -t 23121 -m mount -l|grep mnt
/dev/mapper/docker-253:2-3693860-e85dd79353abe6967cbc4f968934ae078d4d9da02010033b73a3df9659e4d547 on /home/docker/devicemapper/mnt/e85dd79353abe6967cbc4f968934ae078d4d9da02010033b73a3df9659e4d547 type xfs (rw,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota)
作者：xuxinkun
出处：xinkun的博客
链接：https://www.cnblogs.com/xuxinkun/

微信关注我们

原文链接：https://yq.aliyun.com/articles/696581

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

分享丨提升 DockerCon 大会体验的4大方法

出品丨Docker公司（ID：docker-cn）编译丨小东每周一、三、五，与您不见不散！ DockerCon 2019 即将登陆旧金山，我们会根据您提出的反馈，来提升您的 DockerCon 体验。如果您还没有预定座位，那么现在就浏览 https://www.docker.com/dockercon 进行注册吧！每次会议结束后，我们的团队都会仔细整理您提出的所有反馈以及建议并及时做出适当的调整，以确保 DockerCon 大会仍然是您的难忘体验。在这里，我要向参与填写活动调查问卷的每一个人表示由衷的感谢！我们知道填写活动调查问卷看起来很乏味，但我们很感激您反馈。考虑到这一点，我们想分享一些您即将在旧金山大会上看到的新变化：基于角色的内容：今年，您可以找到关于如何使用 Docker 开发人员和 IT 基础设施以及运维团队的专门教程。这些教程由 Docker 船长、客户和 Docker 解决方案架构师所领导，他们将分享在容器中构建和运行应用程序的经验和最佳实践。而且，为了让这种体验更好，我们还为与会者开发了一款新的移动应用程序，届时我们将可以听到您的声音。一个全球性的 Docke...

2019-04-03

624

Docker 是 Golang 编写的，自 2013 年推出以来，受到越来越多的开发者的关注。如果你关注最新的技术发展，那么你一定听说过 Docker。不管是云服务还是微服务（Microservices），越来越多的厂商都开始基于 Docker 作为基础设施自动化的工具。那么什么是 Docker？Docker怎么学？今天我们有幸邀请到了《深入浅出Docker》译者李瑞丰老师，来听听他的所思所想。异步社区：可以介绍一下自己吗？目前正在做哪些事情？李瑞丰：我在2012年毕业于山东大学计算机科学与技术专业，同年7月加入英孚泰克，负责公司教育、气象等领域的多个项目开发。2015年加入浪潮信息，参与了虚拟化平台项目的建设，负责其中虚拟化存储相关工作。2017年加入美团外卖，负责门店相关业务的研发工作。长期关注新兴技术方向，对CI/CD保持极大的热情。异步社区：是什么原因开始翻译《深入浅出Docker》一书的？您是如何评价这本书的？李瑞丰：之前在浪潮时，参与研发的产品就属于虚拟化 & 云平台方向，所以一直也对相关领域的技术长期保持关注。但是网上的资料良莠不齐，学习的时候也遇到了...

2019-04-03

602

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。