Question

来自serverfault的交叉发布

由于我在此处发布了类似问题，因此我将从ServerFault（https://serverfault.com/questions/855120/multi-container-docker-on-aws-nginx-use-host-machine-etc-hosts-resolver）发布我的问题。我希望这   是允许的。

我在Amazon Elastic Beanstalk上有一个带有以下Dockerrun.aws.json文件的多容器泊坞窗环境：

{ 
    "AWSEBDockerrunVersion": 2, 
    "containerDefinitions": [ 
      { 
        "name": "web", 
        "memoryReservation": 256, 
        "image": "my/nginx/repo/image",  
        "portMappings": [ 
          { 
            "hostPort": 80, 
            "containerPort": 80 
          } 
        ], 
        "links": [ 
          "api" 
        ], 
        "essential": true 
      }, 
      { 
        "name": "api", 
        "memoryReservation": 256, 
        "image": "my-api/repo", 
        "essential": true, 
        "portMappings": [ 
          { 
            "hostPort": 3000, 
            "containerPort": 80 
          } 
        ]
      } 
    ] 
  }

最终，我希望nginx提供的节点应用程序能够解析来自链接容器的命名地址请求，因此在我的web图像（节点应用程序）中，我想向http://api/some/resource提出请求，让nginx将其解析为api容器。

现在，由于docker为指定的链接添加了api容器的主机条目，我希望nginx服务器解析来自主机etc/hosts文件的地址，但是正如我发现的那样，nginx使用它自己的解析器。在研究了这个问题后，我发现在非Elastic Beanstalk多容器解决方案和用户定义的网络中，解析器将由127.0.0.11上的docker提供，但是因为目前无法定义用户Dockerrun.aws.json中定义的网络，我一直在寻找不同的解决方案。 links可以在容器内解析，ping api确实有效，但是，nginx在那里做了自己的事情。

我已经阅读了dnsmasq，但是，我想在不安装此软件包的情况下运行，我甚至可以在这里选择吗？

Answer 1

这是一个服务发现主题，我不认为这个解决方案是正确的。

将links解析为App的IP是有效的;但是，它必须遵循起始顺序 - 首先是App，然后是Nginx。如果应用程序在Nginx启动后重新创建或缩放，则不会更改Nginx中的/etc/hosts。可以重新创建Nginx以更新/etc/hosts，但是与Nginx的所有连接都将断开连接。

由于您使用的是Amazon Elastic Beanstalk，我认为更好的解决方案是使用Consul（服务发现）+ Registrator（服务注册）+ Nginx（支持SRV，Plus或第三方）

就我个人而言，没有AEB，我做过类似的事情。我正在使用Docker Swarm（服务发现+服务注册）+ Nginx（带有修改后的HAproxy-SRV）

我希望这个答案可以帮助你做出决定。

AWS上的多容器泊坞窗 - Nginx使用主机/ etc / hosts解析程序

1 个答案: