ECS DependsOn Condition Support

[SoundsSerious]

I'm using the docker-compose depends_on functionality with conditions for Healthy & Complete tasks.

Having read the Reference Documentation it appeared that there was full compatibility between ECS & Compose in this regard.

Digging into the source code it appears that only ECS: STARTED mode is supported. Any depends_on in compose will resolve to this.

Breezing through source code it looks like this might be relatively simple to implement. https://pkg.go.dev/github.com/compose-spec/compose-go/types

STARTED type is set here: https://github.com/docker/compose-cli/blob/69eda1fbe17ef227e6cc520b06cf370731a5a59f/ecs/local/compose.go#L127

Is this as simple as creating a mapping between ECS types and Compose Types?

[dgokcin]

I am also looking forward for this support. I am using nginx for routing traffic to other ecs services and my nginx frontend depends on 2 services(they need to be resolvable otherwise nginx does not start). Using depends on with the started option takes a lot of time. I would love to use another condition here which will speed up my deployment.

[JohnPreston]

Hello there. A bit of shameless input here, hoping that will help.

If you are keen on having the functionality work, it is supported in ECS Compose-X. Using the compose format and the deploy labels, you can even group services that are in compose within the same task definition along with others. The dependency of the containers with each other in the task definition is respected, as well as the dependency between different ECS Services. Also if you set healthcheck etc, it will automatically evaluate which services need to be started first and such. Very useful if you have a sidecar doing an init job before the main application starts, and so on.

depends_on is not that simple depending on whether you want all the services defined in compose to be their own service in ECS or if you want to group them in the same task definition.

Feedback most welcome.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.