閒聊容器的日誌

序言

     有蚊子的夜晚註定要失眠，那嗡嗡嗡的聲音在耳邊飛舞。

     汝乃天驕,何不上九霄。

風言風語

    容器也是爲了服務而生，並且和虛擬機差很少是同一個級別的產品，而對於容器來講，優點在於持續交付和部署，至關方便。可是對於劣勢來講，若是你每次須要零時進行bugfix，那麼可能在下一次重拉鏡像以後，全部的修改都失效了。

    容器要作標準化，必須將日誌的路徑進行標準化，而後纔有可能造成自動化。

    不管是容器，仍是虛擬機，其實都要對日誌的路徑進行標準化的定義，還有對磁盤空間也要進行標準化，還有用戶也要進行標準化，這樣才能自動化。

    

    容器的磁盤空間滿了，竟然還能提供服務，雖然日誌是寫不進去的，可是若是一旦重啓容器，那麼就有可能形成服務沒法啓動。

    

    能夠看到，當磁盤空間佔用爲百分百的時候，服務依舊是可用的，emmm，這突破了個人思惟結界。

    

    日誌沒有寫入。

    

    重啓的時候，是能夠重啓的，找一個mysql的容器重啓試試。

    從而得出結論：對於須要寫入數據或者是有狀態的容器來講，是須要磁盤空間足夠的，若是磁盤容量不足，那麼就會致使中止服務或者沒法啓動服務；對於非持久化或者是無狀態的容器來講，若是磁盤容量不足，最多就是服務的日誌沒法寫入，會丟失相關的日誌，可是服務依舊正常。

    那麼容器在什麼狀況下會沒法啓動呢？

    從經驗來看，分爲三種狀況：

    1 磁盤空間不足，這也是上面說的那種狀況，由於須要用到存儲空間。

    2 內存不足，內存不足的時候容器沒法啓動，由於資源不足。

    3 服務的內存不足致使服務沒法啓動，從而容器啓動失敗，例如java程序，若是容器分配的內存過少，那麼就會致使服務沒法啓動，若是服務是entrypoint，那麼就會致使容器啓動失敗。

    在物理機或者虛擬機中運行容器的時候，其實和虛擬機同樣，也會進行overcommiting，也就是超賣，不管對於cpu仍是內存，都是同樣的，從而在進行使用容器的時候，須要計算一下隔離的cpu，哪些cpu用來運行本機的進程，哪些cpu專門用來運行容器。

    當發現有刪除的文件仍是被進程佔用的時候，其實有的時候，並非物理機或者虛擬機的問題，而是容器的問題，多是容器的定時任務寫的不對，從而致使刪除的文件還繼續被佔用，這個時候，就只能重啓容器解決了，可是關鍵的本質緣由在於須要修改定時任務，不要刪除進程當前使用的文件便可。

    老是忘記去查進程，哎喲，我這該死的腦子。。。

    據說大家都在談論996，那麼我也談談996。

    其實996整體上來講，並無什麼錯，錯就在兩個問題，一個是是否值得，二個是錢是否給足了。

    

    其實你要是爲本身幹活，就算是007又如何？你依舊會不斷的追尋；若是你是被迫去作事，就算天天上班一個小時，那麼你依舊會以爲是上墳。

    

    人心這個東西，在金錢面前，一文不值，就像可愛在性感面前一文不值，大部分人追求的都是短時間目標，由於這樣最真實刺激，而對於長期目標來講，遙遙無期。

    

    努力不能解決不少問題，可是不努力也是萬萬不能的，就像如夢出醒，不撞牆，並不會回頭，不去試試，你怎麼知道成不成。

    我一直在思考一個問題，爲何我這麼努力，現在仍是一坨？？？

    

    選擇比努力更重要，有的時候瞎了眼，就要承擔瞎眼的後果。越努力越幸運？迷失了方向，越努力只會愈來愈偏離航線，且行且珍惜。