ruby-on-rails - 如何让 nginx 等待我的上游服务在 Docker Swarm 中启动？

Question

我将 nginx 代理服务和 Rails 应用服务部署到 docker swarm 中。 nginx 取决于我的 docker-compose 文件中的应用程序。

我的 nginx.conf 文件将流量定向到我的上游应用程序服务(在端口 3000 上公开)，如下所示(仅显示上游部分)。

upstream puma {
  server app:3000;
}

我的 docker-compose 文件如下所示:

version: '3.1'

services:

  app:
    image: my/rails-app:latest
    networks:
      - proxy

  web:
    image: my/nginx:1.11.9-alpine
    command: /bin/sh -c "nginx -g 'daemon off;'"
    ports:
      - "80:80"
    depends_on:
      - app
    networks:
      - proxy


networks:

  proxy:
    external: true

我的主机被设置为群管理器。

一切正常 - 没有任何问题。

但是，即使我的 docker-compose 文件中有一个 depends 部分 - 应用服务可能不完全(？)在 nginx 服务启动时已准备就绪，因此当上游服务配置部分尝试 DNS 解析“app:3000”时，似乎没有完全找到它。因此，当我访问我的网站时，我在 nginx 日志中发现以下错误消息:

2017/02/13 10:46:07 [error] 8#8: *6 connect() failed (111: Connection refused) while connecting to upstream, client: 10.255.0.3, server: www.mysite.com, request: "GET / HTTP/1.1", upstream: "http://127.0.53.53:3000/", host: "preprod.local"

如果我杀死正在运行 nginx 服务的 docker 容器，并且 swarm 稍后重新安排它并返回，如果我随后访问相同的 URL，它完全可以正常工作，并且请求已成功传递到上游到 app:3000 .

我怎样才能防止这种情况发生 - 启动时间有点超出，当 nginx 启动时，它还无法正确解析我的名为 app:3000 的 swarm 服务 - 相反，它试图通过流量到 IP 地址....

顺便说一句 - 如果我重新启动虚拟机，也会发生同样的情况 - 当 docker(在群模式下)再次启动服务时 - 我可能会遇到同样的问题。重启nginx容器即可解决问题。

Answer 1

我已经找到了一种方法来做到这一点 - 这是使用 Dockerfile 或 docker-compose 文件的 HEALTHCHECK 部分。

首先，在部署堆栈时，似乎 depends_on 选项并未真正使用

docker stack deploy -c docker-compose.yml mystack

如果服务任务无法正常启动或由于其他原因失败，集群模式下的 Docker 只会重新启动服务任务。所以depends_on选项并不是真的那么有用。

这就是我最终的解决方案，到目前为止效果很好:

version: '3.1'

services:

  app:
    image: my/rails-app:latest
    networks:
      - proxy

  web:
    image: my/nginx:1.11.9-alpine
    command: /bin/sh -c "nginx -g 'daemon off;'"
    ports:
      - "80:80"
    networks:
      - proxy
    healthcheck:
        test: ["CMD", "wget", "-qO-", "http://localhost/healthcheck"]
        interval: 5s
        timeout: 3s
        retries: 3

networks:

  proxy:
    external: true

所以我所做的是，从 nginx 服务器尝试访问我的 Rails 应用程序上的路由 - 我创建了一个名为/healthcheck 的路由，它返回状态代码 200。

因此，当我尝试访问它时，结果是失败(应用程序服务器尚未准备好)- nginx 将重新启动。希望当它再次启动时，应用程序服务器将可用，并且上游 app:3000 指令将执行正确的 DNS 解析。

因此，通过这种方式，我将(缺失的)depends_on 可以在群体模式下工作的行为“破解”在一起。