docker線上環境踩坑

最近公司項目需要上線, 想到用docker部署啟動快又方便, 站在一個自學者的角度真的沒想到有這么多坑會踩到, 分享出來作為個人成長記錄, 也希望能幫到遇到同樣問題的人

1. docker配置漏洞導致服務器內存及cpu滿載

剛開始寫Dockerfile上傳jar包后打包成鏡像部署, 后來覺得麻煩就開放了2375端口通過idea遠程打包到服務器鏡像

1.1 修改docker配置文件, 開啟遠程訪問

vim /usr/lib/systemd/system/docker.service

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
#ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
#將ExecStart參數改成這樣后,打開雲服務器2375端口就可以通過idea遠程訪問了
ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2375 -H unix://var/run/docker.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always

1.2 端口被入侵! 服務器滿載

剛開通的幾天我覺得真的是太便利了, package一下鏡像就上去了, 還能在idea控制台直接運行, 部署跟測試真的是太方便了, 直到有一天早晨我打開遠程服務器連接......

當時的狀況差不多是這樣的

當時我就傻了, 這尼瑪怎么回事, top命令發現有一個進程占用了幾乎全部的cpu, kill之后立馬就自啟了, 而且還有很多curl命令在請求一個叫 letsupload的網站, 請求一些jpg格式的圖片, 我意識到我的服務器中毒了

1.3 解決挖礦病毒, 服務器恢復正常

立刻去雲控制台將2375端口關閉了, 通過尋找發現病毒叫bbb, 在/tmp目錄下, 但是提示沒有權限刪除, 不殺它就沒法刪除, 不刪除就沒法殺它, 好像陷入了一個死循環 , 一番努力發現有定時任務一直在下載啟動腳本

/var/spool/cron/crontabs/root
/var/spool/cron/root

直接rm -rf 刪除定時任務, 再kill果然成功了, cpu降下來了但是內存還是很高, 發現很多bash腳本在運行還在curl那些網址, 重啟服務器一切恢復正常

2. docker容器部署的springboot項目日期錯誤

2.1 通過Dockerfile 創建鏡像

經歷過病毒的入侵, 還是老老實實用Dockerfile手動創建鏡像吧, 現在沒時間弄docker CA證書配置, 以后每次開啟遠程一定先記得配置CA證書啊

FROM java:8
# 將當前目錄下的jar包復制到docker容器的/目錄下
ADD biz-1.0.0.jar /biz-1.0.0.jar
# 運行過程中創建一個mall-tiny-docker-file.jar文件
RUN bash -c 'touch /biz-1.0.0.jar'
# 聲明服務運行在8080端口
EXPOSE 8999
# 指定docker容器啟動時運行jar包
ENTRYPOINT ["java", "-jar","/biz-1.0.0.jar"]
# 指定維護者的名字
MAINTAINER nyf

一個很簡單的Dockerfile創建docker鏡像完成

2.2 創建並啟動容器

剛開始根據網上教程我是這樣啟動的

docker run -p 9991:8999 
--name zx-server1 
#此處用來關聯docker數據庫的
--link mysql-zx:db
#掛載宿主機時間到容器中
-v /etc/localtime:/etc/localtime 
#掛載日志文件
-v /logdata/zhongxian/logs:/var/logs 
-d --restart=always  biz:1.0.1

這樣平常使用起來一點問題都沒有, 你會發現查詢出來的時間也是對的, 數據庫插入后的時間也是對的, 以為萬事大吉了?

2.3 為什么導出表格時間不正確?

業務中有一個功能是需要導出記錄表格其中就有時間列, 上線后接到業務反饋說表格導出的時間不正確, 我立刻查看了宿主機的時間

date
2020年 04月 23日 星期四 17:34:32 CST

感覺沒毛病啊, 看了數據庫的時間, 都是對的啊, 難道是容器中的時間錯亂了?

進入容器查看時間, 居然是一致的, 哪個環節出現了問題呢

docker exec -it 16f44deacde2 /bin/bash
root@16f44deacde2:/# date
Thu Apr 23 17:36:06 CST 2020

經過分析數據庫時間是對的, 平時查詢時間也是對的, 說明在導出的過程中出現了偏差, 后來發現居然是jvm的鍋, 它不從/etc/localtime讀時間, 跑到/etc/timezone去讀時區, 但是我沒有掛載啊, 時區不對正好差八個小時

docker run -p 9991:8999 
--name zx-server1 
#此處用來關聯docker數據庫的
--link mysql-zx:db
#掛載宿主機時間到容器中
-v /etc/localtime:/etc/localtime 
#掛載宿主機時區文件
-v /etc/timezone:/etc/timezone
#掛載日志文件
-v /logdata/zhongxian/logs:/var/logs 
-d --restart=always  biz:1.0.1

如果發現你的服務器沒有時區文件,自己創建一個文件內容如下

Asia/shanghai

3. 線上服務不能訪問, 磁盤滿了?

某一天傍晚時分正准備下班, 突然接到一個電話服務不可用了! 嚇的我趕緊docker ps 一下, 服務都好好的呢, 於是就刪除所有容器重新啟動了docker容器, 就恢復正常了, 我以為一切都過去了, 又加了一會班臨走之前點了一下navicat, 連不上數據庫了, 我一看磁盤居然全滿了(剛開始實施硬盤很小)

應該不至於啊,這才存多少數據怎么可能磁盤滿了, 看一眼docker什么情況

#查看docker系統狀態
du -sh /var/lib/docker
28.7G    /var/lib/docker

怎么會這么大, 原來是我沒有對容器日志的大小做限制, 日志在無限的增長, 六個容器一直在寫日志

#編輯配置文件加上下面兩行配置
vim /etc/docker/daemon.json

{
  "log-driver":"json-file",
  "log-opts": {"max-size":"500m", "max-file":"3"}
}

max-size=500m，意味着一個容器日志大小上限是500M, max-file=3，意味着一個容器有三個日志，1,2,3各500M。

通過幾天的運行, 沒有再出現硬盤爆滿的情況了, 真的是用一項新的技術之前需要提前准備好各種意外情況, 還是經驗不夠豐富, 需要繼續磨練