闲聊容器的日志

序言

     有蚊子的夜晚注定要失眠，那嗡嗡嗡的声音在耳边飞舞。

     汝乃天骄,何不上九霄。

风言风语

    容器也是为了服务而生，而且和虚拟机差不多是同一个级别的产品，而对于容器来说，优势在于持续交付和部署，相当方便。但是对于劣势来说，如果你每次需要零时进行bugfix，那么可能在下一次重拉镜像之后，所有的修改都失效了。

    容器要做标准化，必须将日志的路径进行标准化，然后才有可能形成自动化。

    无论是容器，还是虚拟机，其实都要对日志的路径进行标准化的定义，还有对磁盘空间也要进行标准化，还有用户也要进行标准化，这样才能自动化。

    

    容器的磁盘空间满了，居然还能提供服务，虽然日志是写不进去的，但是如果一旦重启容器，那么就有可能造成服务无法启动。

    

    可以看到，当磁盘空间占用为百分百的时候，服务依旧是可用的，emmm，这突破了我的思维结界。

    

    日志没有写入。

    

    重启的时候，是可以重启的，找一个mysql的容器重启试试。

    从而得出结论：对于需要写入数据或者是有状态的容器来说，是需要磁盘空间足够的，如果磁盘容量不足，那么就会导致停止服务或者无法启动服务；对于非持久化或者是无状态的容器来说，如果磁盘容量不足，最多就是服务的日志无法写入，会丢失相关的日志，但是服务依旧正常。

    那么容器在什么情况下会无法启动呢？

    从经验来看，分为三种情况：

    1 磁盘空间不足，这也是上面说的那种情况，因为需要用到存储空间。

    2 内存不足，内存不足的时候容器无法启动，因为资源不足。

    3 服务的内存不足导致服务无法启动，从而容器启动失败，例如java程序，如果容器分配的内存过少，那么就会导致服务无法启动，如果服务是entrypoint，那么就会导致容器启动失败。

    在物理机或者虚拟机中运行容器的时候，其实和虚拟机一样，也会进行overcommiting，也就是超卖，无论对于cpu还是内存，都是一样的，从而在进行使用容器的时候，需要计算一下隔离的cpu，哪些cpu用来运行本机的进程，哪些cpu专门用来运行容器。

    当发现有删除的文件还是被进程占用的时候，其实有的时候，并不是物理机或者虚拟机的问题，而是容器的问题，可能是容器的定时任务写的不对，从而导致删除的文件还继续被占用，这个时候，就只能重启容器解决了，但是关键的本质原因在于需要修改定时任务，不要删除进程当前使用的文件即可。

    总是忘记去查进程，哎哟，我这该死的脑子。。。

    听说你们都在谈论996，那么我也谈谈996。

    其实996总体上来说，并没有什么错，错就在两个问题，一个是是否值得，二个是钱是否给足了。

    

    其实你要是为自己干活，就算是007又如何？你依旧会不断的追寻；如果你是被迫去做事，就算每天上班一个小时，那么你依旧会觉得是上坟。

    

    人心这个东西，在金钱面前，一文不值，就像可爱在性感面前一文不值，大部分人追求的都是短期目标，因为这样最真实刺激，而对于长期目标来说，遥遥无期。

    

    努力不能解决很多问题，但是不努力也是万万不能的，就像如梦出醒，不撞墙，并不会回头，不去试试，你怎么知道成不成。

    我一直在思考一个问题，为什么我这么努力，如今还是一坨屎？？？

    

    选择比努力更重要，有的时候瞎了眼，就要承担瞎眼的后果。越努力越幸运？迷失了方向，越努力只会越来越偏离航线，且行且珍惜。