docker线上环境踩坑
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 :/# 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。
通过几天的运行, 没有再出现硬盘爆满的情况了, 真的是用一项新的技术之前需要提前准备好各种意外情况, 还是经验不够丰富, 需要继续磨练