Question

所以我一直面临着一个奇怪的问题，我不确定问题出在哪里。我正在使用docker-compose运行容器，并且以下nginx配置非常有效：

server {
  location / {
        proxy_pass http://container_name1:1337;
  }
}

container_name是我在docker-compose.yml文件中提供的服务的名称。它完美地解析为IP，并且可以正常工作。但是，当我将上面的文件更改为此：

upstream backend {
    least_conn;
    server container_name1:1337;
    server container_name2:1337;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

它完全停止工作，并且在错误日志中，我得到以下信息：

2020/03/17 13:16:03 [error] 8#8: *11 no live upstreams while connecting to upstream, client: xxxxxx, server: codedamn.com, request: "GET /HTTP/1.1", upstream: "http://backend/", host: "xxxxx"

那是为什么？在上游区块内时，nginx是否无法解析DNS？有人可以解决这个问题吗？

注意：这仅在生产（Ubuntu 16.04），本地（macOS Catalina）上发生，相同的配置可以正常工作。发现这一点后，我完全感到困惑。

更新1：，其工作原理如下：

upstream backend {
    least_conn;
    server container_name1:1337;
}

但不能使用一台以上的服务器。为什么？！

Answer 1

好的。弄清楚了。这是因为docker-compose随机创建了容器，nginx很快将容器标记为down（当有流量时，我将其部署在生产环境中）。应用容器还没有准备好，但是nginx已经准备好了，因此将它们标记为下来并停止转发任何流量。

现在，我没有同步docker-compose容器的创建顺序（正如我所发现的那样有点hacky），我通过写以下命令禁止了nginx自动将服务标记为关闭的失败尝试：

server app_inst1:1337 max_fails=0;

这可以让nginx仍然将流量转发到特定服务（并且我的docker配置为在崩溃时重新启动容器），

Nginx + Docker-与上游“在连接到上游时没有上游”，但与proxy_pass兼容

1 个答案: