docker线上环境踩坑

小爷有点狂 2020-04-23

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控制台直接运行, 部署跟测试真的是太方便了, 直到有一天早晨我打开远程服务器连接......

当时的状况差不多是这样的

docker线上环境踩坑

当时我就傻了, 这尼玛怎么回事, 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
:/# 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。

通过几天的运行, 没有再出现硬盘爆满的情况了, 真的是用一项新的技术之前需要提前准备好各种意外情况, 还是经验不够丰富, 需要继续磨练

相关推荐