compose-cli
compose-cli copied to clipboard
Possibility to mark ECS containers as non essential
Description
Have the possibility to mark ECS containers as non essential
Currently all containers are marked as essential: https://github.com/docker/compose-cli/blob/79770d5803d1b475409aad187b11a2b63d79a037/ecs/convert.go#L122
Use case
I have a container that initialises (create, seed...) the database then exit. It works beautifully in localhost context (*), I would like the same behaviour when deployed to ECS
Unfortunately since all containers are marked as essential, ECS restarts the container in an infinite loop caused by "Essential container in task exited"
Proposed solution
Map restart: no to Essential: false in ECS ? see https://github.com/aws/amazon-ecs-cli/pull/62#issuecomment-244259521
Related issues
- https://github.com/docker/compose-cli/issues/2101
- https://github.com/aws/amazon-ecs-cli/pull/342
- https://github.com/aws/amazon-ecs-cli/issues/267#issuecomment-315484417
(*)
services:
front:
...
back:
...
depends_on:
database-init:
condition: service_completed_successfully
database-init:
...
command: ['npm', 'run', 'db:init']
depends_on:
database:
condition: service_healthy
database:
...
I have done this with ECS Compose-X by setting some deploy.labels which indicate family (so the two services defined in the compose file are joined in the same task definition) and you can then set an exit condition, i.e. for your init script, you could use SUCCESS. Because of the implication here that SUCCESS means the container runs, executes, and we expect return 0 before moving on to starting the next container, compose-x automatically understands that's not an essential container.
See https://docs.compose-x.io/syntax/compose_x/ecs.details/deploy.html#labels
There are plenty of other examples in the labs which highlight having primary containers, that have to be healthy, and others that do not.
Hope this helps :)
@JohnPreston I've been trying to figure out what you're hinting at, but I'm getting nowhere. Like @tkrotoff I too have a database migration that that exits.
With the standard docker compose (3.9) syntax, you just set the depends_on condition to service_completed_successfully. Are you saying that this has no effect on ECS, and there is some other mechanism that needs to be layered on top of this? i.e. so @tkrotoff's example would be changed to something like this:
services:
front:
...
back:
...
depends_on:
database-init:
condition: service_completed_successfully
deploy:
labels:
ecs.task.family: db-init
ecs.depends.condition: SUCCESS
database-init:
...
command: ['npm', 'run', 'db:init']
depends_on:
database:
condition: service_healthy
deploy:
labels:
ecs.task.family: db-init
database:
...
I can't quite figure out how this is supposed to work or what the underlying conceptual model is based on the docs you linked to.
Apologies @zuk The docs to the tool is a different one, not the ECS docker plugin extension which sadly does not support this.
Compose-X support most of the ECS plugin x- extensions, and much more.
Taking the exemple above you should have
services:
front:
...
back:
...
depends_on:
database-init
deploy:
labels:
ecs.task.family: backend # goes to task family backend
database-init:
...
command: ['npm', 'run', 'db:init']
depends_on:
database:
condition: service_healthy
deploy:
labels:
ecs.task.family: backend # goes to task family backend
ecs.depends.condition: SUCCESS # this container starts first and must return 0 for the next one to start
database:
...
The backend task & service definition (family) will deploy both containers together in order database-init then back
command to run to create the templates / deploy to AWS ECS
ecs-compose-x init
ecs-compose-x up -f docker-compose.yaml -p my-app-stack
The database service will be created before the service "backend" though considering that you need it up and running first
If you have a DB on AWS that uses RDS you can use the x-rds module to have compose-x create ingress rules and paramete/env vars to say simplify the integration