Reputation: 1
property of ECS container definition is used for container dependencies
Links property of docker compose provides service dependencies.
We are mapping a docker compose file to ECS task definition.
Conceptually, Is the purpose of links
property in docker compose similar to DependsOn
property of ECS container definition?
Upvotes: 0
Views: 1226
Reputation: 159040
links:
was an important part of the first-generation Docker networking setup. Once Docker introduced the docker network
series of commands and Docker Compose set up a private network by default, it became much less important, and there's not really any reason to use it at all in modern Docker.
Compose has its own depends_on:
option. If service a
depends_on: [b]
, then when a
starts up (maybe because you explicitly docker-compose up a
, or maybe just as an ordering constraint) the b
container is guaranteed to exist. If b
is a database or some other service that takes a while to start up, it's not guaranteed to be functional, but for instance b
will be a valid host name from a
's point of view.
Within a single ECS task, one container can dependsOn
others. This is similar to the Compose depends_on:
setting, but it has an additional condition
parameter that can support a couple of different lifecycles. Of note, one container can wait for another to be "condition": "HEALTHY"
, a check that in Docker Compose requires the waiting container to manually check on its own (ofter with a helper script like wait-for-it.sh
); it can also wait for another container to "condition": "COMPLETE"
if one container just does setup for another.
If you're porting a Docker Compose file to an ECS task, I'd start by trying to replace links:
with depends_on:
, which shouldn't cause much functional change; translating this to ECS, the semantics of that are very similar to "dependsOn": [{"condition": "START"}]
.
Upvotes: 1