How to deploy Netfilex Eureka Server and Eureka Client with docker Network on AWS ECS cluster

Question

I am migrating my spring cloud eureka application to AWS ECS and currently having some trouble doing so.

I have an ECS cluster on AWS in which two EC2 services was created

1. Eureka-server
2. Eureka-client

each service has a Task running on it.

QUESTION:

how do i establish a "docker network" amongst these two services such that i can register my eureka-client to the eureka-server's registry? Having them in the same cluster doesn't seem to do the trick.

locally i am able to establish a "docker network" to achieve this task. is it possible to have a "docker network" on AWS?

Answer 1

The problem here lies on the way how ECS clusters work. If you go to your dashboard and check out your task definition, you'll see an ip address which AWS assigns to the resource automatically.

In Eureka's case, you need to somehow obtain this ip address while deploying your eureka client apps and use it to register to your eureka-server. But of course your task definitions gets destroyed and recreated again somehow so you easily lose it.

I've done this before and there are couple of ways to achieve this. Here is one of the ways:

1. For the EC2 instances that you intend to spread ECS tasks as eureka-server or registry, you need to assign Elastic IP Addresses so you always know where to connect to in terms of a host ip address.
2. You also need to tag them properly so you can refer them in the next step.
3. Then switching back to ECS, when deploying your eureka-server tasks, inside your task definition configuration, there's an argument as placement_constraint This will allow you to add a tag to your tasks so you can place those in the instances you assigned elastic ip addresses in the previous steps.
4. Now if this is all good and you deployed everything, you should be able to refer your eureka-client apps to that ip and have them registered.

I know this looks dirty and kind of complicated but the thing is Netflix OSS project for Eureka has missing parts which I believe is their proprietary implementation for their internal use and they don't want to share.

Another and probably a cooler way of doing this is using a Route53 domain or alias record for your instances so instead of using an elastic ip, you can also refer them using a DNS.