当elasticsearch在容器中时,覆盖`tcp.publish_port`会中断聚类

时间:2016-06-06 23:07:07

标签: elasticsearch docker elasticsearch-plugin

我尝试运行一个elasticsearch集群,每个es节点都在自己的容器中运行。这些容器使用ECS部署在可能正在运行其他不相关容器的多台计算机上。为避免端口冲突,容器公开的每个端口都会分配一个随机值。这些随机端口在所有正在运行的相同类型的容器中是一致的。换句话说,所有正在运行的es-node容器都将端口9300映射到相同的随机数。

这是我使用的配置:

network:
  host: 0.0.0.0

plugin:
  mandatory: cloud-aws

cluster:
  name: ${ES_CLUSTER_NAME}

discovery:
  type: ec2
  ec2:
    groups: ${ES_SECURITY_GROUP}
    any_group: false
  zen.ping.multicast.enabled: false

transport:
  tcp.port: 9300
  publish_port: ${_INSTANCE_PORT_TRANSPORT}

cloud.aws:
  access_key: ${AWS_ACCESS_KEY}
  secret_key: ${AWS_SECRET_KEY}
  region: ${AWS_REGION}

在这种情况下,_INSTANCE_PORT_TRANSPORT是9300绑定到主机上的端口。我已经确认上面使用的所有环境变量都已正确设置。我还通过命令行arg将network.publish_host设置为主机的本地IP。

当我强制_INSTANCE_PORT_TRANSPORT(并且反过来transport.publish_port)为9300时,一切都运行良好,但只要它被赋予随机值,节点就不能再连接到每个节点其他。我使用logger.discovery=TRACE看到了这样的错误:

ConnectTransportException[[][10.0.xxx.xxx:9300] connect_timeout[30s]]; nested: ConnectException[Connection refused: /10.0.xxx.xxx:9300];
    at org.elasticsearch.transport.netty.NettyTransport.connectToChannelsLight(NettyTransport.java:952)
    at org.elasticsearch.transport.netty.NettyTransport.connectToNode(NettyTransport.java:916)
    at org.elasticsearch.transport.netty.NettyTransport.connectToNodeLight(NettyTransport.java:888)
    at org.elasticsearch.transport.TransportService.connectToNodeLight(TransportService.java:267)
    at org.elasticsearch.discovery.zen.ping.unicast.UnicastZenPing$3.run(UnicastZenPing.java:395)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

似乎节点绑定的端口与尝试连接到其他节点时ping的端口相同。有没有办法让它们与众不同?如果不是,那么transport.publish_port是什么意思?

1 个答案:

答案 0 :(得分:2)

discovery-ec2插件的工作方式是使用AWS EC2 API收集IP地址列表,并将此列表用作单播节点列表。

但它不会从正在运行的集群中收集任何信息。显然该节点尚未连接! 所以它对其他节点的publish_port一无所知。

它只是添加了一个IP地址。就这样。 Elasticsearch然后是is using the default port,即9300。

所以IMO无法在短时间内解决这个问题。

但我们可以想象添加一个与Google Compute Engine已实现的功能接近的新功能。我们使用特定的元数据从GCE API获取此端口。

我们可以为Azure和EC2做同样的事情。您想要open an issue,以便跟踪工作吗?