- Newest
- Most votes
- Most comments
If you run multiple containers in the same task that uses bridge networking, you can reference one container from the other by name by configuring the appropriate links
in the container definition.
For example, if you have a Task Definition with a container named main
and another called sidecar
, you can publish the IP address of sidecar
in the /etc/hosts
file of the main container like so:
"containerDefinitions": [
{
"name": "main",
"links": [
"sidecar"
],
...
},
{
"name": "sidecar",
...
}
]
In the main
container, you will see the IP published:
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.4 sidecar sidecar ecs-EcsBridgeContainerNameTestStackTaskDefBF06B5D6-6-sidecar-c2ad99be83f489e00c00
172.17.0.5 main
See also the ECS Task Definition documentation under "Network Settings".
Hello,
service discovery is not enabled by default, but you can configure it (it relies on Cloud Map internally). You can read more here: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html
Correct. But notice that bridge only works with SRV records (not A records) so you can't simply resolve database as you need to specify a port as well.
Well, SRV records contain port as well, so it's ust a question of proper usage of SRV records in application
Service discovery only allows SRV records in bridge mode. This makes it so that I would need special code to do lookups against the DNS name. Is that not true?
Oh, didn't see the previous comments on SRV records. So yeah, that makes things like startup/wait scripts not work very easily. i.e. you have to do special stuff. It also makes running in docker compose different, because in there the hostname = container-name mapping in DNS just works.
If you are using docker-compose locally, I would highly recommend to checkout ECS Compose-X (worth looking into the use-cases documented here). It will deal with IAM / Security groups etc between your ECS services and your other AWS resources. For service to service communication, you can link which service talks to another etc. You can automatically get the services registered in AWS CloudMap for service discovery, and it also has AppMesh support if you want to use service mesh on top of it for extra security/traceability etc. Now if you don't use compose syntax you can look into Copilot, although the supported use-cases is not as deep, but it does the job.
EDIT: not strictly an answer. More of a recommendation in case that were useful to have some ECS "specialized" tools to deal with your services configuration and deployment.
Thanks for the suggestion. I am using the AWS CDK which deals with all the permission issues that need to be taken care of. It also gives quick access to security group changes when necessary.
Relevant content
- asked 5 days ago
- Accepted Answerasked 4 months ago
- asked 4 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
Just a reminder: "The --link flag is a legacy feature of Docker"