1

This is an introductory guide by AWS on how to deploy microservices - based applications on ECS

Apparently (as also becomes evident from the documentation), a so called task definition should encompass all of your containers that make up you stack.

i.e. if your corresponding docker-compose.yml file was made of 5 services (in the docker compose context), these should all end up in the same ECS Task Definition (?).

From what I understand, this also serves the purpose of automated service discovery among the containers (as is the default behavior in docker-compose and docker swarm);

The problem lies in the fact that the scaling possibility when it comes to ECS is (besides EC2 instance) per ECS Service.

Does this mean that you cannot have container-level scaling ?

If I want a service scale, I would have to scale all of my containers within my so called stack?

pkaramol
  • 16,451
  • 43
  • 149
  • 324

2 Answers2

7

You do not need to have all containers in the same task definition. From the docs:

Your entire application stack does not need to exist on a single task definition, and in most cases it should not. Your application can span multiple task definitions by combining related containers into their own task definitions, each representing a single component.

Also, note that you are limited to 10 container definitions in a single task definition and it's perfectly fine to use just one container definition in each of your task definitions.

As for scaling, you can create a service for each task definition. This allows logically separate components in your stack to scale independently. For example, if you have 2 services, one for back-end api service and another for front-end nginx, you can create 2 separate task definitions for them, each service scaling independently.

Possible reasons to group your container definitions into a single task definition:

  • They have a single logical purpose or share a lifecycle(started and terminated together).
  • You want to scale them together.
  • You want the containers to share resources like data volumes.
  • The containers need to run on the same host instance and do things like communicate over localhost.

On the other hand, if the containers perform separate logical functions, scale independently, don't share a lifecycle or resources like volumes, you are probably better off using multiple task definitions/services.

There is also some documentation on application architecture for ECS here which explains this further.

user818510
  • 3,414
  • 26
  • 17
  • I agree with the approach you describe, that was the idea I got from going thru the docs myself also; the main issue is that service discovery is then a bit tricky (if I understand correctly it needs the creation of private hosted zones) and does not work out of the box like say in k8s, where if you define `serviceA` and `serviceB`, they can reach each other without any further config needed; – pkaramol Aug 30 '18 at 16:40
  • @pkaramol It does need a DNS namespace and hosted zone in Route 53. While not as seamless as kubernetes services, it's a lot better than before with the Route 53 Auto Naming API. – user818510 Aug 30 '18 at 17:28
0

Well, ECS only scale the task, no 1 of the container inside the task, if you want to scale a container inside the task you have to scale the task with all the containers. You have to create a task for each service. Remember, AWS think that you only want to run a task with a simple app, that consume database service from RDS and any service that it can consume it allocated in AWS infrastructure.

Miguel Conde
  • 813
  • 10
  • 22