容器的文件系统

序言

很多时候都会焦虑，为什么会焦虑呢，因为变化的太快了？急于看到结果？基于事实去看的话，焦虑可能要少点儿，焦虑的时候多注意观察，慢慢积累沉淀。

留恋温柔乡，必是英雄冢，每一件事情总是存在两面性，要擅长取舍。

容器层

在使用容器的时候，有的时候会发现容器无法启动，有的时候会发现物理磁盘需要清理，所以需要了解容器的文件系统，查看容器使用的文件系统信息如下：

大部分的使用的存储驱动都是使用overlay2，使用这种文件系统的好处就是节省inode，而且内存的使用率比较高，多个容器能共用相同的库文件，从而可能出现物理机上大量的内存用于cache和buffer中。

在使用overlay2的时候，总共分为两层结构，一层是镜像层也就是lowerdir，一层是容器层，也就是可读写层，upperdir，由于在运行的时候，会进行挂载，从而又会创建一个层mergerdir，总体的架构图如下：

从上图可以看到对于容器来说，发生变化的文件都是在upperdir之中，而不变的部分都在lowerdir之中。

当容器的磁盘空间满了之后，那么容器是无法启动的，从而需要找到对应的目录，在物理机上直接进行删除文件，也就是删除upperdir之中文件，查找的路径如下：

当需要直接删除的时候，直接根据upperdir找到对应的日志目录，然后进行删除清理。

当容器是启动状态之后，其实容器的id和shm的id是相同的，而对于shm和merged目录是成对出现的，也可以根据这个方式来进行查找，但是如果一台主机上的容器数量有一百多个，那么就很难查找到了，从而还是使用inspect来的直接。

未启动容器和启动容器的最大区别就是，会生成一个merged的目录，将相关的文件显示在此处.

在进行查看文件的时候，需要注意的是如果是volume挂载到容器的，那么在mergeddir里面是无法找到的，必须要到volume里面的路径进行查找：

从上图可以看到，当直接在merge目录进行查找volume里面的文件的时候，是不存在的，而且在物理机上直接创建的文件会被volume里面的数据进行覆盖，和挂载的模式是一样。从而当需要清理volume的日志的时候，需要查找到volume的路径，然后写定时任务来进行清理。

在物理机上写定时任务是可以的，但是基本上不标准的，因为这些id随着容器的迁移等操作，是可能就不存在的，会出现大量错误的定时任务，所以标准的做法还是在容器内设置定时任务，而在物理机上清理，主要还是临时解决容器无法启动的问题。

在进行选择容器挂载目录的时候，一种是bind，一种是volume，bind的方式是由物理机控制，而volume则是由容器控制。

bind的方式主要是物理机上的文件系统，而主要是用来进行挂载独特的配置文件，例如nginx的nginx.conf，而volume则可以是程序数据，也可以是挂载的目录，而且在书写dockerfile的时候，直接使用指令VOLUME即可形成一个挂载目录。

在进行使用挂载的时候，有几个小细节需要注意，当不是绝对路径的时候，那么类型会变成volume类型；当使用绝对路径的时候，才会是bind类型，可以挂载文件，可以挂载目录，不存在的时候，会默认进行创建；当volume被使用的时候，就算是使用-f强制删除，也是无法删除的；对于指定来名字的test1的volume类型，必须手动进行删除，不能使用-v参数进行删除。

dockerfile文件的里面每个volume都会在容器中形成一个挂载点，这就是容器里磁盘分区的由来。

风言风语

运维总是涉及到运维侧和用户侧，运维侧主要是运维内部的服务，服务内部的原理，部署，监控，问题处理；而对于用户侧来说就是用户体验。

其实技术也是的，面对的人不同，从而关注的角度不同，随风而动。。。

任何形式的管理都是为了更好的提供服务，更好的提高处理问题的速度，给出更多的解决方案，如果管理单纯是为了管理，那就偏离了总体的目标。

最近发现我的聊天能力见长，感觉能胜天，因为每次都把天直接聊死。。。上次看见一女同事，我问几个月了。。。emmm，已绝交，哈哈哈