有蚊子的夜晚注定要失眠，那嗡嗡嗡的声音在耳边飞舞。
汝乃天骄,何不上九霄。
风言风语
容器也是为了服务而生，而且和虚拟机差不多是同一个级别的产品，而对于容器来说，优势在于持续交付和部署，相当方便。但是对于劣势来说，如果你每次需要零时进行bugfix，那么可能在下一次重拉镜像之后，所有的修改都失效了。
容器要做标准化，必须将日志的路径进行标准化，然后才有可能形成自动化。
无论是容器，还是虚拟机，其实都要对日志的路径进行标准化的定义，还有对磁盘空间也要进行标准化，还有用户也要进行标准化，这样才能自动化。
容器的磁盘空间满了，居然还能提供服务，虽然日志是写不进去的，但是如果一旦重启容器，那么就有可能造成服务无法启动。
可以看到，当磁盘空间占用为百分百的时候，服务依旧是可用的，emmm，这突破了我的思维结界。
日志没有写入。
重启的时候，是可以重启的，找一个mysql的容器重启试试。
从而得出结论：对于需要写入数据或者是有状态的容器来说，是需要磁盘空间足够的，如果磁盘容量不足，那么就会导致停止服务或者无法启动服务；对于非持久化或者是无状态的容器来说，如果磁盘容量不足，最多就是服务的日志无法写入，会丢失相关的日志，但是服务依旧正常。
那么容器在什么情况下会无法启动呢？
从经验来看，分为三种情况：
1 磁盘空间不足，这也是上面说的那种情况，因为需要用到存储空间。
2 内存不足，内存不足的时候容器无法启动，因为资源不足。
3 服务的内存不足导致服务无法启动，从而容器启动失败，例如java程序，如果容器分配的内存过少，那么就会导致服务无法启动，如果服务是entrypoint，那么就会导致容器启动失败。
在物理机或者虚拟机中运行容器的时候，其实和虚拟机一样，也会进行overcommiting，也就是超卖，无论对于cpu还是内存，都是一样的，从而在进行使用容器的时候，需要计算一下隔离的cpu，哪些cpu用来运行本机的进程，哪些cpu专门用来运行容器。
当发现有删除的文件还是被进程占用的时候，其实有的时候，并不是物理机或者虚拟机的问题，而是容器的问题，可能是容器的定时任务写的不对，从而导致删除的文件还继续被占用，这个时候，就只能重启容器解决了，但是关键的本质原因在于需要修改定时任务，不要删除进程当前使用的文件即可。
