Possibility to mark ECS containers as non essential

[tkrotoff]

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:
    ...

[JohnPreston]

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 :)

[zuk]

@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.

[JohnPreston]

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