容器的文件系统

序言

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


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

容器层

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

容器的文件系统

    大部分的使用的存储驱动都是使用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,已绝交,哈哈哈


上一篇:Centos7下GlusterFS分布式存储集群环境部署记录


下一篇:ServerSAN系统元数据管理设计