Docker-GitHub Actions Runner 项目中 Docker 服务启动问题深度解析

问题背景

在容器化环境中使用 myoung34/docker-github-actions-runner 项目时，用户报告了一个典型问题：尽管日志显示 Docker 服务已成功启动，但实际运行 GitHub Actions 工作流时仍会报错。这种情况在 ECS Fargate 环境和普通 Ubuntu 服务器上都有出现，但根本原因和解决方案各不相同。

ECS Fargate 环境的问题分析

在 AWS ECS Fargate 环境中，用户尝试通过定义挂载点和临时卷来共享 Docker 套接字：

mount_points = [
  {
    source_volume  = "docker-sock"
    container_path = "/var/run/docker.sock"
  }
]

然而，Fargate 的一个根本限制在于它不支持 Docker-in-Docker (DinD) 模式。这是因为 Fargate 本身就是基于容器化的服务，其设计架构不允许在容器内部再运行 Docker 守护进程。这是 AWS 容器服务的固有特性，目前没有可行的解决方案。

普通服务器环境的问题诊断

在 Ubuntu 服务器环境下，使用 Sysbox 运行时和 Docker Compose 部署时，用户遇到了更微妙的问题：

1. 首次启动容器时一切正常
2. 容器重启后，虽然日志显示 Docker 服务已启动，但实际无法使用
3. 检查发现存在残留的 Docker PID 文件

深入日志分析显示关键错误信息：

failed to start daemon: process with PID 165 is still running

这表明系统在重启时未能正确清理前一个 Docker 守护进程的 PID 文件，导致新实例无法启动。

解决方案探索

对于普通服务器环境，我们找到了两种解决方案：

方案一：入口脚本清理

通过自定义入口脚本，在容器启动时主动清理残留的 PID 文件：

entrypoint:
  - sh
  - -c
  - |
    if [ -f /var/run/docker.pid ]; then
      pid=$(cat /var/run/docker.pid)
      kill -TERM "$pid" || true
      rm -f /var/run/docker.pid
    fi
    exec /entrypoint.sh ./bin/Runner.Listener run --startuptype service

方案二：使用 tmpfs 挂载

更优雅的解决方案是利用 tmpfs 挂载 /var/run 目录：

tmpsf:
  - /var/run

这种方法确保每次容器重启时，/var/run 目录都会被清空，自然解决了 PID 文件残留问题。

技术原理深入

这些问题的本质在于 Linux 进程管理和容器生命周期的交互：

1. PID 文件机制：传统服务使用 PID 文件防止多实例运行，但在容器环境中可能造成冲突
2. 容器重启语义：容器"重启"实际上是先停止后新建，而非传统意义上的进程重启
3. 文件系统持久性：默认情况下，容器内部文件系统变化在重启后会保留

理解这些底层机制有助于我们设计更健壮的容器化解决方案。

最佳实践建议

1. 在 Fargate 等受限环境，避免使用需要 Docker-in-Docker 的工作流
2. 对于自托管环境，优先考虑 tmpfs 方案处理临时文件
3. 在 CI/CD 流水线设计中，考虑使用无状态、幂等的任务设计
4. 监控容器日志中类似 "PID still running" 的警告信息

通过这些问题分析和解决方案，我们可以更深入地理解容器化 CI/CD 环境中的常见陷阱，并建立更可靠的基础设施部署策略。