Docker 容器启动后就退出？一次华为云实验中的排查记录

本文基于 2026 年 10 月 13 日一次实际完成的华为云 KooLabs 实验及运行日志，由 AI 辅助整理。文中不包含实验账号、密码、公网地址等信息。Docker 18.09.9 是本次教学环境使用的旧版本，不是面向生产环境的版本建议。

1. 实验目标与实际环境

这次实践对应「轻松快速上手 Docker」实验，目标包括安装 Docker、拉取和加载镜像、运行容器，以及验证 Web 服务。

先核对实际环境，而不是直接照搬截图：

cat /etc/os-release
uname -m
docker version

本次分配的服务器为 Huawei Cloud EulerOS 2.0，x86_64。按照实验提供的安装包配置后，Docker 客户端和服务端版本均为 18.09.9。实验文字描述、截图与当前分配的镜像可能有差异，应以命令输出为准。

2. 镜像拉取成功，不等于应用已经可用

通过实验提供的镜像加速配置，成功拉取了 httpd:latest。还完成了实验提供的 CentOS 镜像归档导入、镜像列表检查与删除操作：

docker load -i centos.tar
docker images
docker rmi centos:7

随后创建名为 datahttpd 的容器，并将宿主机 80 端口映射到容器 80 端口。创建命令正常返回容器 ID，docker ps -a 短暂显示 Up，但 HTTP 请求没有成功。

docker ps -a
docker logs --tail 40 datahttpd
docker inspect --format '{{.State.Status}} | {{.State.ExitCode}}' datahttpd
curl -v --connect-timeout 5 http://127.0.0.1/

实际日志出现了关键错误：

(1)Operation not permitted: AH00480: ap_thread_create: unable to create worker thread
AH02324: A resource shortage or other unrecoverable failure was encountered

容器随后变为 exited，HTTP 请求从连接重置变为连接拒绝。值得注意的是，这次容器退出码为 0，所以只看退出码，也不足以判定服务健康。

这里没有进一步采集系统调用跟踪，因此不把原因直接断言为某一个 seccomp 规则。已确认的事实是：旧版 Docker 环境下，当前拉取的 httpd 镜像在创建工作线程时遇到 EPERM。 运行时、安全配置与镜像用户态的兼容性，是值得优先检查的方向。

3. 不扩大权限，先验证兼容镜像

这次没有直接添加 --privileged，而是拉取官方的 httpd:2.4-alpine 标签，在相同宿主机、端口和内容目录下重新测试。下面的删除命令仅针对前面创建、已经退出的实验容器：

docker pull httpd:2.4-alpine
docker rm datahttpd

mkdir -p /data
printf '%s\n' '<h1>Docker lab completed</h1>' > /data/index.html

docker run -d \
  --name datahttpd \
  -p 80:80 \
  -v /data:/usr/local/apache2/htdocs:ro \
  httpd:2.4-alpine

这里有两个细节：

• 挂载目标使用官方 httpd 镜像的默认站点目录 /usr/local/apache2/htdocs。如果挂到其他目录，却没有同步修改 Apache 配置，页面内容不会按预期变化。
• 静态内容采用只读挂载 :ro。用于展示页面时，没有必要让容器修改宿主机目录。

本次 Alpine 镜像保持运行，站点开始正常返回内容。这证明了该组合在本次实验中的可用性，但并不意味着只要换成 Alpine，就能解决所有线程创建或权限问题。

4. 用多项证据确认完成

docker ps -a
docker inspect --format '{{.State.Status}}' datahttpd
docker inspect --format '{{json .Mounts}}' datahttpd
curl --fail --show-error http://127.0.0.1/

本次验证结果包括：

1. 容器状态为 running；
2. 宿主机 80 端口映射至容器 80 端口；
3. 站点目录挂载的 RW 为 false；
4. 本机请求返回了预期的实验页面；
5. 从实验环境之外发起的 HTTP 请求返回 200，正文包含预期内容；
6. KooLabs 实验报告显示两项任务均「已完成」，总进度为 100%。

相比单独截图一个容器 ID，这些证据更能说明应用确实可用。

5. 实验结束后的处理

验证和保存记录后，通过 KooLabs 的「结束实验」入口退出，交由平台清理临时实验环境。不要使用个人云账号另行购买资源来替代已分配的实验资源，也不要把临时凭据写入博客、代码仓或长期保存的脚本。

对于长期使用的服务，优先采用仍受支持的 Docker Engine，按需求评估镜像版本和安全配置。镜像标签可能更新，严谨复现时还应记录镜像摘要、宿主机版本和运行参数。

小结

这次实践的关键收获不是多记几条 Docker 命令，而是建立完整的验证顺序：环境核对 → 镜像准备 → 容器状态 → 应用日志 → HTTP 验证 → 实验报告 → 资源清理。遇到启动后立即退出的问题，先看日志和实际响应，再决定是否更换镜像或升级运行时，避免盲目扩大权限。

实验来源：华为云 KooLabs「轻松快速上手 Docker」