Reputation: 31
I am experimenting with AWS ECS. I am trying to find a best practice for allowing my containers to communicate with each other.
The simplest approach I have found is to use an application load balancer. This works, but I have to pass the DNS host of the ALB into my task definition / container as an environment variable.
Is this considered a best practice or is there a better way?
Upvotes: 1
Views: 3487
Reputation: 6063
First of all I assume that when you say "allowing my containers to communicate with each other" you mean separate ECS Services (comprised of n tasks) to communicate with each other?
To be clear: an ECS service is a collection of ECS tasks that scale in and out on a need basis (from 1 to n). An ECS task is a collection of pre-defined containers (from 1 to 10 IIRC). In most of the case you will have 1 container per task but you can have multiple sidecars (additional containers that are required for other reasons).
Inside a task containers can talk to each others via localhost
because they share the network namespace. The problem is how to make ECS services to talk to each other. Using an ELB in front of them it's one way to achieve this. The other (more practical way) to achieve it is to use Service Discovery
. If you enable it, all tasks in ECS service A will be able to resolve the name of ECS service B (WITHOUT YOU TO PASS ANY VARIABLE) and it will resolve to the tasks that belong to service B (by leveraging a mix of Route53 and CloudMap behind the scenes).
You can read more here.
If you want to explore an example of how you can use Service Discovery this may help.
Last but not least, if you are getting started with ECS my suggestion would be to use Copilot that hides a lot of the details and provide an easier to use interface to ECS: https://aws.github.io/copilot-cli/
Upvotes: 1