Docker容器内如何正确重启FastAPI以触发容器自动重启

你配置的--reload参数是uvicorn的开发模式参数，开启后uvicorn会拆分出独立的主进程（负责重载监控）和业务子进程（跑实际应用代码）。你在数据库初始化逻辑中调用exit(1)仅会终止运行业务代码的子进程，主进程会将子进程退出判定为代码变更触发的正常重载事件，不会整体退出，因此无法触发docker配置的restart: always重启策略，你进程列表中状态为Z的defunct僵尸进程，就是被终止后未被主进程回收的业务子进程。

按推荐优先级排序：

• 生产环境直接移除--reload参数
  --reload仅用于本地开发时的代码热重载，生产环境开启没有任何收益还会带来额外性能开销和多进程问题。移除该参数后，uvicorn会以单进程模式运行业务代码，此时数据库初始化失败触发的exit(1)会直接让作为容器PID 1的uvicorn主进程以非0状态码退出，自动触发容器重启逻辑，不需要额外编写前置检测脚本。
  修正后的Dockerfile启动命令参考：

  CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
  

• 若开发环境必须保留--reload参数，修改异常退出逻辑终止主进程
  不要在业务代码中直接调用exit()，改为向PID为1的uvicorn主进程发送终止信号，确保整个容器进程组退出：

  import os
  import signal
  
  try:
      engine = create_engine(...)
      metadata.create_all(engine)
  except Exception as e:
      print(e)
      os.kill(1, signal.SIGTERM)
  

• 从编排层解决启动顺序问题，减少无意义重启
  你提到的前置数据库连通性检测逻辑，可以直接通过docker-compose的健康检查能力实现，不需要在应用镜像内额外写脚本：给数据库服务配置存活检测规则，再给web服务配置依赖条件，等数据库完全就绪后再启动web服务，从根源减少启动顺序导致的失败。
  配置参考：

  services:
    db:
      image: postgres:15 # 替换为你实际使用的数据库镜像
      restart: always
      healthcheck:
        test: ["CMD-SHELL", "pg_isready -U 你的数据库用户名"] # MySQL可替换为mysqladmin ping命令
        interval: 2s
        timeout: 2s
        retries: 10
    web:
      build: .
      restart: always
      depends_on:
        db:
          condition: service_healthy
  

  注意：该配置仅能解决开机/集群启动时的顺序问题，无法覆盖数据库运行中故障重启的场景，还是需要保留应用本身的异常退出或数据库连接重试逻辑。

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