ECS on EC2 bidirectional communication between two containers in the same task

Question

I'm trying to configure ECS task on EC2 instance. Network mode in task definition is Bridge

My task has two containers inside, that should communicate with each other. eg ContainerA makes requests to ContainerB and ContainerB makes requests to ContainerA.

Everything works well when I use docker-compose, containers can communicate by their names. But when I deploy on ECS those containers don't see each other. Partly I can fix this problem using Links in the task definition, however, it works only in one direction, I mean if set links for both containers I receive such error message during creation task definition:

Unable to create a new revision of Task Definition web-app:12 Container links should not have a cycle

It would be great to hear any thoughts, what did I miss and if it's actually possible. Honestly, I thought that containers inside one task should communicate automatically by container names, especially when they are under the same Bridge.network.

I know that there is a feature Service Discovery that allow communication between to services by names, but still, I would prefer to have one service and task with two containers inside.

Thank you for any help.

ContainerA.NETWORK SETTINGS

Answer 1

If both containers are defined in the same task definition they are available via localhost :

For instance, if ContainerA is listening on port 8081 and ContainerB is listening on port 8082, they can simply reach each other by:

localhost:8081
localhost:8082

Side note: same concept as in Kube.netes pod with two containers - they are accessible via localhost

EDIT : that's relevant for awsvpc .network mode as you can see in the documentation :

containers that belong to the same task can communicate over the localhost interface

Answer 2

docker-compose uses not a bridge , but user-defined.network by default. That's by addressing by service name works:

By default Compose sets up a single.network for your app. Each container for a service joins the default.network and is both reachable by other containers on that.network, and discoverable by them at a hostname identical to the container name.

https://docs.docker.com/compose.networking/

ECS EC2 uses links by default, which are deprecated by Docker and not cannot have cycles, as you've found out.

Unfortunately user-defined.networks are not supported by AWS despite a long-standing issue: https://github.com/aws/containers-roadmap/issues/184

That's what I've figured out so far. I guess the only option left is to use the awsvpc .network mode which allows containers to communicate via localhost (which I find rather awkward):

This means that all containers in a task are addressable by the IP addresses of the elastic.network interface, and they can communicate with each other over the localhost interface.

https://aws.amazon.com/blogs/compute/under-the-hood-task.networking-for-amazon-ecs/