Task Definition IP Address

[MarkThielen]

Hey there,

thanks for putting this together, great work.

We are trying to run Vertx within a ECS environment testing with this Discovery Implementation. The Log files indicate that it works

1. Task Finds itself. (File Attached)
   TaskInformation20190502.txt

2. Scan and Retrieval of configured services within the cluster as expected. (File Attached)
   TaskScanResult20190502.txt

Does the response of 2) need to include the actual public IP address in order to connect ? The response that we are seeing does include the network bindings like this

"networkBindings": [ { "bindIP": "0.0.0.0", "containerPort": 5701, "hostPort": 5701, "protocol": "tcp" }, { "bindIP": "0.0.0.0", "containerPort": 8080, "hostPort": 33054, "protocol": "tcp" } ],

But no further information about the IP address of the task. Any ideas ?

Are you guys planning to take this further ? Would be interested to contribute

Thanks,
Mark

[MarkThielen]

Checking the code it seems like that it expected to have entries in the containers.networkInterfaces object which is empty in our case so I assume this is a configuration problem on our side as we have set task network mode to bridge and it only works with awsvpc.

[ls-urs-keller]

@MarkThielen True, we only tested on Fargate for now which is indeed AWSVPC. Feel free to make a PR.
The devs from Hazelcast have promised to add support Fargate+ECS in but not sure if it is already available.

[MarkThielen]

Thanks @urs-ikentoo-com,

checked where the hazelcast devs are and it seems it will still be some time, that is fine. I liked your guys implementation very much and have added regexps for cluster / service names as it matches our use case very well. I started a pull request let me know what you think.

Our use case comes from a Vertx framework perspective where we have encountered a couple of problems and could not find a clear solution. First of all the Hazelcast Discovery of ECS tasks and its IP addresses was a bit tricky until I found your solution. To make that work in different environments (dev, staging, prod) a way for defining cluster name regular expressions made sense for our setup as well as the service name regexp which lets us choose which services we want to discover in the cluster.

Added some comments and documentation to the readme.md file as well as some integration testing to see if and how the regexps work.

It is very likely that we will extend this until there is something official out there that we can review but the lightweight of this solution makes it very interesting.

Regards and thanks,
Mark

@MarkThielen True, we only tested on Fargate for now which is indeed AWSVPC. Feel free to make a PR.
The devs from Hazelcast have promised to add support Fargate+ECS in but not sure if it is already available.