守护进程安全出问题时的排查顺序:从现象到根因

Docker · 3 分钟阅读· 278 次阅读

默认容器带 14 项左右 capabilities,多数应用只需要其中 2-3 项

正确的第一步是分类:起不来、连不上、跑得慢,三条路完全不同。

先说结论

先分三类,再由外向内查:网络、进程、配置、依赖、资源。

  • 先确认现象能复现,且能描述清楚
  • 由外向内:端口、进程、配置、依赖、资源
  • 读第一条错误,不是最后一条
  • 改一个变量,验证一次,别一次改五处
  • 留下记录:现象、假设、验证、结论

第一类:起不来

先看进程在不在,再看它为什么退出:默认容器带 14 项左右 capabilities,多数应用只需要其中 2-3 项。

  • 查看服务状态与最近日志(不是全部日志)
  • 确认端口是否被占用、权限是否足够
  • 确认配置文件语法(多数服务支持 test 模式)
  • 确认依赖的数据目录存在且可写

第二类:连不上

按「本机、网络、代理、应用」四层查:

层级 验证方式 典型原因
本机 本机 curl / telnet 端口 没监听、只听 127.0.0.1
网络 从另一台机器访问 防火墙、安全组、VLAN
代理 检查反代配置与证书 路径、超时、头部大小
应用 看访问日志与错误日志 鉴权、限流、连接池耗尽

第三类:跑得慢

--read-only 会让应用写临时文件失败,需要显式挂一个 tmpfs。

慢的问题先分清是「等」还是「算」:CPU 高是算,CPU 低但延迟高是等(IO、锁、网络)。

守护进程安全出问题时的排查顺序

这个服务的高频故障点

同类的坑基本集中在这些位置:

  • 开启 userns-remap 后容器内 root 映射到宿主 100000 起始的 UID,逃逸收益大减
  • 默认容器带 14 项左右 capabilities,多数应用只需要其中 2-3 项
  • --read-only 会让应用写临时文件失败,需要显式挂一个 tmpfs
  • seccomp 的默认配置已禁用 40 多个系统调用,改成 unconfined 等于全放开

别做的事

用 --privileged 解决权限问题,等于关掉所有隔离

把用户加进 docker 组当普通权限,实际给的是 root

一次改多个参数,会让下一次故障更难查。

把结论写下来

排查记录不是给别人看的,是给三个月后的自己看的。seccomp 的默认配置已禁用 40 多个系统调用,改成 unconfined 等于全放开。

排障能力不是知道更多命令,是知道先查什么。

评论 (3)

阿
阿哲

排查顺序那段直接抄进值班手册了。

K
Kevin

版本差异要强调,我照着做结果参数名全变了。

老
老吴

备份没验证过等于没有,这条我认。

发表评论

验证码

提交后需站长审核,通过后才会显示。