容器管理需分阶段精准控制：创建（docker create）与运行（docker run）分离；运行时通过exec、pause、stats、logs动态干预；停止用stop配合--time，清理先stop再rm；监控依赖inspect、Prometheus/cAdvisor及健康检查。
容器创建与启动的精细化控制
创建容器不等于立刻运行，区分 docker create 和 docker run 是精准管理的第一步。前者只生成容器实例但保持 created 状态，适合预配置复杂参数后再统一启动；后者一步到位，适用于快速验证或简单服务。
常用预配置项包括：
- -v /host/conf:/etc/nginx/conf.d：挂载配置目录，避免镜像内硬编码
- --restart=unless-stopped：确保宿主机重启后容器自动恢复（但不会在手动 stop 后自启）
- --cpus=1.5 -m 1g：限制资源，防止单个容器挤占系统关键资源
- --network my-overlay：接入自定义网络，替代默认 bridge，提升跨容器通信安全性和可控性
运行中容器的动态干预策略
容器不是“启动就放任”，运行时干预能显著提升稳定性与可观测性。
例如临时诊断问题时：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 用 docker exec -it myapp sh 进入容器调试，比重启更轻量
- 执行 docker pause myapp 可冻结全部进程，保留内存现场，适用于紧急止血或性能压测暂停点
- 配合 docker stats myapp 实时观察 CPU、内存、网络 IO，发现隐性瓶颈
- 对日志量大的服务，用 docker logs --tail 100 -f myapp 流式查看最新日志，避免全量拉取卡顿
停止、清理与异常恢复的健壮方案
停止不是简单 kill，清理不是盲目 rm。优雅退出和容错设计才是生产级实践的核心。
- docker stop 默认发送 SIGTERM，等待 10 秒后发 SIGKILL；如应用需更长清理时间，加 --time=30
- 强制删除运行中容器用 docker rm -f，但应避免在 CI/CD 流水线中无条件使用，建议先 stop 再 rm
- 批量清理已退出容器：docker rm $(docker ps -q -f status=exited)
- 为防意外崩溃，启动时指定 --restart=on-failure:3，失败最多重试 3 次，比 always 更可控
状态追踪与自动化生命周期监控
人工查 docker ps 不可持续。把容器状态纳入可观测体系，才能实现主动运维。
- 用 docker inspect myapp --format='{{.State.Status}}' 提取结构化状态，供脚本或监控系统消费
- 结合 Prometheus + cAdvisor，采集容器 CPU、内存、重启次数、uptime 等指标，设置 running != 1 或 restarts > 0 的告警
- 记录容器启动时间戳：docker inspect myapp --format='{{.State.StartedAt}}'，辅助判断是否长期未更新
- 对关键服务，编写健康检查脚本定期调用 curl -f http://localhost:8080/health 并联动容器 restart
