How do you instruct AWS FARGATE to provision a t2.small via ECS CLI instead of the default micro?

Question

I am trialling AWS ECS for the first time. I've run through the tutorials and now I'm trying to deploy an existing Docker Compose suite which I've been using on Digital Ocean for some time.

I have four containers in my composition, an ExpressJS app, NGinx, MemcacheD, and a Python Flask API. These work OK on a Digital Ocean 1GB RAM host.

I've been following the guide and specs here: https://github.com/aws/amazon-ecs-cli#launching-an-aws-fargate-task and other general ECS CLI guides.

I've got ECS to make the cluster+service from the docker YAML (with a few tweaks), but when I try to UP the service, I get an error that the t2.micro EC2 which Fargate boots isn't big enough:

INFO[0016] (service CI) was unable to place a task because no container instance met all of its requirements. 
The closest matching (container-instance ...) has insufficient memory available. 
For more information, see the Troubleshooting section of the Amazon ECS Developer Guide.

So I'd like to force it to boot an t2.small (2GB RAM) or higher.

I see that you cannot directly tell Fargate to use a specific instant type from ECS - that setting is only for "EC2" direct, but I want to use Fargate to automate the instance management.

I have tried using the task_size memory parameter (which I believe to be the correct way of informing Fargate of your application's requirements?) but this doesn't affect the choice of EC2 instance type which Fargate boots - it still boots the default t2.micro.

I added this YML file with --ecs-params:

version: 1
task_definition:
  task_size:
    cpu_limit: 512
    mem_limit: 2GB

When I rebuild my cluster from scratch with this definition, I can see the 2GB is correctly configured under the taskDefinition page (console.aws.amazon.com/ecs/home#/taskDefinitions/...) - so the configuration is provided OK, but when I view the instance it's booted, it's still a t2.micro with 1GB RAM.

Am I misunderstanding the task_size.memory parameter?

EDIT:
I was mistaken in thinking the 2GB setting would influence the host instance size. This is not the case: ecs-cli up brings up the cluster and instance long before the docker-specified services are created by ecs-cli compose service up which reads those task params.

The task size parameter is per TASK which in Docker Compose terms are "services" (I think of them as containers plus exec params). So as I have four services, there will be four ECS tasks. To get the four tasks to fit inside a 1GB host therefore, task size should be 256MB (not 2GB!)

task_definition: task_size: cpu_limit: 512 mem_limit: 0.5GB

This now gets further creating the services, without the memory error. I don't quite understand why (as 0.5GB x 4 is still too big).

So while this has avoided the error, I still want to know how to create a larger instance when performing ecs-cli up with Fargate.

Answer 1

The short answer is "you don't have to".

The long answer is I was doing it wrong. Here's what was wrong and what I learned.

After working through tutorials, RTFMing and re-building my ECS configuration I found that I actually wasn't launching via Fargate. I had made a mistake during the initial configure command, so the default config was using EC2 launch type. When making the cluster it created an Autoscaling Group template with t2.micro in it, and then it was using this to launch the initial instance. I didn't think this was unusual, as I read that Fargate managed your EC2's for you, which I presumed was what was happening. No, this was "traditional" EC2 creation via a scaling template.

I figured out the mistake by viewing the config file. I noticed ecs-cli doesn't have any "view config" commands - they only write to the config, so it feels a bit mysterious when you are issuing later commands, especially as you are encouraged to set lots of defaults (presumably to simplify the CLI commands which get long and cumbersome).

less ~/.ecs/config 

version: v1
default: MY-TRIAL-CONFIG
clusters:
  MY-TRIAL-CONFIG:
    cluster: MY-TRIAL-CLUSTER
    region: ap-southeast-2
    default_launch_type: ""      <= this was the problem
  tutorial:
    cluster: tutorial
    region: ap-southeast-2
    default_launch_type: FARGATE

So I then tried the EC2-only parameter:

ecs-cli up --instance-type "t2.small" --capability-iam

and this changed the Autoscaling Group and indeed launched a t2.small. So I now know how to do it the EC2 way.

To do it properly as I had originally intended with Fargate, I needed default-launch-type FARGATE:

ecs-cli configure --cluster MY-TRIAL-CLUSTER --region ap-southeast-2 --default-launch-type FARGATE --config-name MY-TRIAL-CONFIG

Now the config looks like this:

less ~/.ecs/config 

version: v1
default: MY-TRIAL-CONFIG
clusters:
  MY-TRIAL-CONFIG:
    cluster: MY-TRIAL-CLUSTER
    region: ap-southeast-2
    default_launch_type: FARGATE
  tutorial:
    cluster: tutorial
    region: ap-southeast-2
    default_launch_type: FARGATE

After doing this, ecs-cli compose service up works very differently from the observed ECS launch flow.

1. it doesn't create any Autoscaling stuff
2. it doesn't launch any EC2 instances (I thought Fargate did, but managed it for you, but you don't get to see the container hosts)
3. It created a Cloudformation Stack instead (interestingly with a t2.micro EcsInstanceType parameter)
4. It's very clearly labelled on the Cluster home page: there's a row for EC2 launch types below the FARGATE row.

e.g.

MY-TRIAL-CLUSTER >
FARGATE
1          0             1
Services   Running tasks Pending tasks

EC2
0        0             0                                              0
Services Running tasks Pending tasks CPUUtilization MemoryUtilization Container instances

It's very clear now I see it. There are no instances for Fargate services.

You can also watch Fargate re-start the task-containers if they fail, either in the control panel, or with ecs-cli compose service ps and ecs-cli logs --task-id XXX --follow, to get a feel for the magic and how the Docker Compose features are being performed.