服务器容器运维零踩坑指南：新手看完也能直接上手

你是不是也遇过这种糟心事？本地跑的好好的项目，一上线到服务器就崩。重启好几次都没用，老板在群里疯狂@你要恢复时间。你满头汗查了俩小时，最后发现是容器依赖版本和本地不一致。很多刚接触容器运维的朋友，总觉得这东西很高深，要背一堆复杂命令。其实根本不用，今天给你讲的这些方法，全是我摸爬滚打5年攒的实招。不用懂复杂原理，照着做就能解决90%的日常问题，再也不用半夜爬起来修故障。

1、日常巡检：把问题掐灭在爆发前

运维的核心是防问题，不是等出了事再救火。每天花10分钟做巡检，能帮你省掉90%的加班时间。

1.1 每天3项基础检查，覆盖绝大多数隐患

你不用做太复杂的检查，就跑三个命令就行：

第一个查容器运行状态，输入命令：

``` docker ps -a ```

看STATUS列，但凡不是Up开头的，都要留意。如果不是你主动下线的业务，就赶紧查原因。

第二个查资源占用，输入命令：

``` docker stats --no-stream ```

看CPU和内存占比，超过80%的就提前扩容。举个例子，之前有个做电商的朋友，618前没查资源。直播当天容器内存爆了，卡了20分钟，少卖了十几万。

第三个查最近的报错日志，输入命令：

``` docker logs --tail 20 你的容器名 ```

搜error、warn这类关键词，有小报错提前改，别等炸了再处理。

1.2 巡检结果做分级标记，别漏事

查完的结果别随便存在记事本里就不管了，分三个等级标记：

• 红标：马上要处理的，比如容器已经挂了
• 黄标：3天内要处理的，比如内存占了75%
• 绿标：正常的，不用管

每周整理一次标记，就不会攒下一堆隐患。

2、故障应急：最快速度恢复业务，别死磕原因

真遇到故障了别慌，按这个步骤来，最多10分钟就能恢复业务。

2.1 先救业务，再查根因

很多新手遇到故障，第一反应是找为啥坏了。老板在后面催，业务停一分钟亏一分钟，你先恢复了再说。

第一步先重启容器，80%的小问题重启就能好：

``` docker restart 你的容器名 ```

要是重启没用，直接把流量切到备用容器。没有备用的，就用之前的正常镜像重新起一个。别犹豫，先让业务跑起来再说。

之前我遇到过容器日志打满崩了的情况，先切了流量，再慢慢清日志查问题。老板全程没发现，一点没影响业务。

2.2 留好两个快照，避免越修越坏

改配置或者上线前，一定要打两个快照，出了问题直接回滚，不会出大事故：

• 改配置前，给当前容器打镜像快照：docker commit 容器名 备份镜像名:版本号
• 上线新镜像前，别删旧镜像，留好上一个稳定版本

避坑提醒：别随便用latest标签的镜像。你根本不知道latest对应的是哪个版本，真要回滚都找不到对应版本，哭都没用。

3、日常优化：花10分钟设置，半年不用操心

有两个非常简单的优化设置，做了之后容器稳定性能提升一大截。

3.1 给容器加资源限制，避免一锅端

很多人跑容器不给资源限制，一个业务出问题，占满整个服务器的CPU内存，上面所有项目全崩。

你起容器的时候，加两个参数就行：

``` docker run --cpu-quota 50000 --memory 2g 你的镜像名 ```

这个意思是，这个容器最多用半个CPU，2G内存。你根据自己的业务调整数值就行。之前我帮朋友的小服务器加了这个限制，之前每个月崩3次，现在半年没出过问题。

3.2 开日志自动清理，不用手动删日志

很多人不知道，容器日志会越堆越多，几个月下来能占几十G硬盘，直接把服务器撑爆。

起容器的时候加日志参数，就能自动清理旧日志：

``` docker run --log-driver json-file --log-opt max-size=100m --log-opt max-file=3 你的镜像名 ```

意思是每个日志文件最多100M，最多存3个，满了自动删旧的，不用你手动清理。

这些方法全是我实战踩坑攒出来的，没有一句废话。你今天下班前，花15分钟就行。先给手上的所有容器跑一遍三个巡检命令，把有问题的标记出来。下次重启核心容器的时候，把资源限制和日志限制的参数加上。

不用一下全改，先做这两步，你下周要处理的故障至少少一半。真遇到拿不准的操作，记得先打快照再动，大不了回滚，绝对不会出大问题。