如何保障Docker容器内的Go Gin HTTP服务始终保持运行

你当前的配置下，只要容器内PID 1进程（也就是你编译好的Go HTTP服务程序）发生异常退出（包括代码panic、段错误、被系统OOM杀掉等非用户主动终止的情况），配置了restart: always的容器会自动触发重启，不需要额外引入保活工具。

restart: always的具体触发规则：

• 容器非用户主动执行docker stop/docker-compose stop终止的，无论退出码是多少，都会立即重启
• 即使用户主动停止过容器，当宿主机Docker服务重启、或整机重启后，该容器也会被自动拉起

不需要复杂的故障注入，两步即可完成验证：

1. 正常执行docker-compose up -d启动服务，确认接口可以正常访问
2. 模拟程序崩溃场景：
   • 先执行docker ps获取目标服务的容器ID或名称
   • 执行docker exec -it <容器ID/名称> kill 1，直接杀掉容器内PID为1的Go主进程，等价于服务异常崩溃
   • 立刻执行docker ps -a查看容器状态，会看到原容器退出后数秒内就会被重新拉起，新启动的容器STATUS字段会显示Up X seconds，容器ID与之前崩溃的容器保持一致
   • 也可以执行docker logs <容器ID/名称>查看日志，能看到服务崩溃前的输出，以及重启后程序重新初始化的日志，进一步确认重启生效。

注意不要用docker stop命令验证，该命令是用户主动触发的正常终止流程，不会立刻触发重启。你也可以临时在Gin代码里加一个测试接口，访问就主动触发panic，效果和kill进程完全一致。

你之前尝试Supervisord跑不通是非常普遍的情况，这种方案本身就违背了Docker单进程容器的设计原则，不推荐使用：

• 部署Supervisord后，容器PID 1进程会变成Supervisord而非你的Go服务。此时Go服务崩溃后，Supervisord虽然会在内部拉起进程，但Docker感知不到服务异常——因为Supervisord始终在运行，容器状态会一直显示为Up，你配置的restart: always规则完全失效，甚至出现服务已经不可用、但容器监控显示正常的假健康状态
• 额外引入Supervisord会增大镜像体积，还需要额外编写配置、处理日志转发、信号传递等问题，完全没有必要。

按推荐优先级从高到低排列：

方案1：原生重启策略 + 健康检查（零额外依赖，最推荐） #

你已经配置的restart: always只能感知进程直接退出的场景，覆盖不了程序死锁、Goroutine泄漏导致端口存活但请求卡死的异常。只需要补充Docker原生健康检查配置，就能实现全场景的异常自动重启，不需要安装任何额外组件。
在docker-compose.yml对应服务下添加如下配置：

services:
  your-go-backend:
    # 保留你原有配置
    restart: always
    ports:
      - "80:80"
    # 新增健康检查
    healthcheck:
      test: ["CMD", "wget", "--spider", "-q", "http://127.0.0.1:80/health"]
      interval: 5s # 每5秒探测一次
      timeout: 3s # 探测超时时间3秒
      retries: 3 # 连续3次探测失败判定为服务异常
      start_period: 10s # 服务启动后等待10秒再开始探测，避免启动慢导致误判

对应的Gin代码只需要加一个极简的健康检查路由即可：

r.GET("/health", func(c *gin.Context) {
    c.Status(http.StatusOK)
})

如果你的基础镜像没有带wget，也可以替换为curl命令，使用distroless等极简镜像的话，可以提前编译一个几KB的健康检查小程序放入镜像即可。

方案2：根据场景选择合适的原生重启策略 #

Docker原生提供了3种重启策略，你可以根据业务需求选择，不需要自行开发保活逻辑：

• restart: always：任何场景下都保持容器运行，适合核心不可中断的服务
• restart: unless-stopped：逻辑和always基本一致，区别是用户手动停止的容器，后续Docker服务重启、整机重启时不会被自动拉起，适合需要经常临时停机维护的服务
• restart: on-failure[:max-retries]：仅当容器退出码非0（也就是程序异常崩溃）时才重启，可以指定最大重启次数，比如on-failure:3表示崩溃后最多重启3次，避免程序存在致命bug时无限重启打满宿主机资源。

方案3：多进程场景使用Docker内置init #

如果后续你确实需要在容器内运行多个进程，不要部署Supervisord，直接在docker-compose配置中添加init: true即可，Docker会使用内置的tini轻量init进程作为PID 1，自动处理信号转发、僵尸进程回收，稳定性和资源占用远优于自行部署Supervisord。该方案对你当前单Go二进制的场景没有必要。

内容的提问来源于stack exchange，提问作者Fcoder