【问题标题】:Docker load balance using NGINX proxy使用 NGINX 代理的 Docker 负载平衡
【发布时间】:2018-09-24 22:33:36
【问题描述】:

我正在尝试使用 nginx 和 docker 的本机 DNS 对 API 服务器进行负载平衡。

我希望 nginx 能够对所有可用服务器进行循环 API 调用。但即使我将 docker 的 DNS 服务器指定为解析器,nginx 也只会将请求转发到一台服务器。

docker-compose.yml 中的相关部分

proxy:
  restart: always
  build: ./src/nginx/.
  ports:
    - "8080:8080"
  links:
    - api:servers.api

nginx.conf

worker_processes 2;

events { worker_connections 1024; }

http {
    sendfile on;

    server {
        listen 8080;

        location / {
            resolver_timeout 30s;
            resolver 127.0.0.11 ipv6=off valid=10s;
            set $backend http://servers.api:80;
            proxy_pass          $backend;
            proxy_redirect      off;
        }
    }
}

如果我手动指定每个服务器,NGINX 循环负载均衡器就可以工作,我不想这样做,因为它不能自动扩展。

worker_processes 2;

events { worker_connections 1024; }

http{
    sendfile on;

    upstream api_servers{
        server project_api_1:80;
        server project_api_2:80;
        server project_api_3:80;
    }

    server{
        listen 8080;

        location / {
            proxy_pass          http://api_servers;
            proxy_redirect      off;
        }
    }
}

如何配置 nginx,使其能够检测添加的新容器并将它们包含在循环中?

【问题讨论】:

    标签: docker nginx


    【解决方案1】:

    在这种情况下,Docker 的 DNS 负责执行循环。不要在您的撰写中使用links 选项it's not necessary。看,我用的是这个例子:

    docker-compose.yml:

    version: '3'
      services:
        api:
          image: my-api-image
        client:
          image: ubuntu:latest
    

    所以我使用docker-compose up -d api 启动我的应用程序,然后扩展它:docker-compose scale api=10。现在,在客户端内部 (docker-compose run client bash):

    root@ce3857690292:/# dig api
    ...
    ;; QUESTION SECTION:
    ;api.               IN  A
    
    ;; ANSWER SECTION:
    api.            600 IN  A   172.19.0.6
    api.            600 IN  A   172.19.0.9
    api.            600 IN  A   172.19.0.7
    api.            600 IN  A   172.19.0.8
    api.            600 IN  A   172.19.0.11
    api.            600 IN  A   172.19.0.2
    api.            600 IN  A   172.19.0.10
    api.            600 IN  A   172.19.0.3
    api.            600 IN  A   172.19.0.5
    api.            600 IN  A   172.19.0.4
    

    使用 curl 你可以看到循环:

    root@1719c10f864a:/# curl -vI api
    * Rebuilt URL to: api/
    *   Trying 172.19.0.6...
    * Connected to api (172.19.0.6) port 80 (#0)
    ...
    root@1719c10f864a:/# curl -vI api
    * Rebuilt URL to: api/
    *   Trying 172.19.0.7...
    * Connected to api (172.19.0.7) port 80 (#0)
    ...
    root@1719c10f864a:/# curl -vI api
    * Rebuilt URL to: api/
    *   Trying 172.19.0.8...
    * Connected to api (172.19.0.8) port 80 (#0)
    

    在您的情况下,您需要用您的 nginx 替换我的 docker-compose 中的客户端服务,并将您的 api 用作上游(不带 links

    【讨论】:

    • 那么,在这种情况下,我根本不需要使用 nginx 来扩展(除非我需要 minimum_conn 或 ip_hash 负载平衡)? docker 应该能够做基本的循环负载平衡吗?
    • 这个“负载平衡”只对你的 docker 网络中的其他应用程序有效。我会考虑使用 nginx、ha 代理或(很可能)traefik:traefik.io
    【解决方案2】:

    我应该在 nginx 中使用 SERVICE 名称而不是 ALIAS 名称作为服务器名称。

    在 nginx 容器上运行 nslookup 显示:

    / # nslookup api
    nslookup: can't resolve '(null)': Name does not resolve
    
    Name:      api
    Address 1: 172.20.0.7 project_api_1.project_default
    Address 2: 172.20.0.5 project_api_3.project_default
    Address 3: 172.20.0.6 project_api_2.project_default
    
    / # nslookup servers.api
    nslookup: can't resolve '(null)': Name does not resolve
    
    Name:      servers.api
    Address 1: 172.20.0.7 project_api_1.project_default
    

    工作的 nginx.conf

    worker_processes 2;
    
    events { worker_connections 1024; }
    
    http {
        sendfile on;
    
        server {
            listen 8080;
    
            location / {
                resolver_timeout 30s;
                resolver 127.0.0.11 ipv6=off valid=10s;
                set $backend http://api:80;
                proxy_pass          $backend;
                proxy_redirect      off;
            }
        }
    }
    

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-11-19
      • 1970-01-01
      • 1970-01-01
      • 2022-01-10
      • 1970-01-01
      • 2021-03-11
      相关资源
      最近更新 更多