aws / amazon-ecs-cli Goto Github PK

If I specify a security group I created myself in a region like this:

ecs-cli up --keypair us-oregon --capability-iam --size 1 --instance-type t2.small --azs us-west-2a,us-west-2b --security-group my-custom-group

my cluster creation never completes. Using the Cloudformation UI I can see that the process got stuck at this stage:

22:32:58 UTC-0800 CREATE_IN_PROGRESS AWS::AutoScaling::AutoScalingGroup EcsInstanceAsg Resource creation Initiated

In most compose files you have a command as the following

hello_world:
    image: busybox
    ports: 
        - "80:80"
    command: echo hi

This works fine with docker-compose.

The only way I've been able to represent that with ecs-cli compose is via the following awkward construct:

hello_world:
    image: busybox
    ports: 
        - "80:80"
    command:
        - echo
        - hi

ecs-cli compose doesn't appear to provide any way to run a complex command-line on a single container through the 'ecs-cli compose run' functionality. With 'docker-compose run' all the arguments after the container name are supplied to the (one) container to override the normal command run - from the documentation for that:

docker-compose run --no-deps SERVICE COMMAND [ARGS...].

whereas ecs-cli compose run --help allows just a single argument per container:

compose run - ecs-cli compose run [containerName] [command] [containerName] [command] ...

If you try to quote the command to supply it as a single string, for example something like:

ecs-cli compose run container '/bin/echo test'

then it tries to run a file named '/bin/echo test' on the container rather than passing that string to a shell to run. I don't see any solution other than to completely place all such commands into a file in the docker image or a mounted volume that can then be called as a single string.

When I try and run ecs-cli compose with a docker compose file I get the following error:

WARN[0000] Skipping unsupported YAML option... option name=hostname

The following works fine with docker-compose up

web:
    image: nginx
    ports: 
        - "80:80"
    mem_limit: 50M

When using ecs-cli compose up I get the following error repeated 3 times:
FATA[0000] Unable to create and read ECS Compose Project error=strconv.ParseInt: parsing "50M": invalid syntax

You can work around this by using

web:
    image: nginx
    ports: 
        - "80:80"
    mem_limit: 52428800

instead.

It looks like ecs-cli configure always writes aws_access_key_id and aws_secret_access_key to ~/.ecs/config. This is terrible practice, as it creates another spot where credentials can be leaked to malware or attackers. It also makes using short-lived credentials annoyingly difficult.

It seems the workaround is to delete the properties and rely on ENV variables.

The standard aws cli authentication mechanisms should be used, namely ~/.aws/config and ~/.aws/credentials. If credentials can't be found by the standard credential discovery mechanism for aws cli tools, ecs-cli should fail with "Can't find credentials".

The latest ECS CLI v0.1.0 (*cbdc2d5) creates a cluster with AMIs that doesn't support ECR. The official documentation states, and I quote:

You can use your Amazon ECR images with Amazon ECS, but you need to satisfy some prerequisites:

• Your container instances must be using at least version 1.7.0 of the Amazon ECS container agent. The latest version of the Amazon ECS-optimized AMI supports Amazon ECR images in task definitions. For more information, including the latest Amazon ECS-optimized AMI IDs, see Amazon ECS Container Agent Versions.

The AMI currently used for the instance is the Amazon ECS-Optimized Amazon Linux AMI 2015.03.g which carries v1.4.0 of the ECS Container Agent. See below (as per the docs):

This results in an attribute error when running the task definition on the containers:

$ ecs-cli compose --file ecs-compose.yml up
INFO[0001] Using ECS task definition                     TaskDefinition=ecscompose-elk-server:23
INFO[0001] Couldn't run containers                       reason=ATTRIBUTE

This problem only exists with images from ECR and not official or namespaces images on Docker Hub.

Sources

• Amazon ECR Repositories
• Amazon ECS-optimized AMI Container Agent Versions

Created a cluster running on two instances like specified in the examples.

This is my compose file (docker-compose-prod.yml):

web:
    image: nathanleclaire/laraveldocker_web
    links:
     - db
     - redis
     - beanstalkd
    ports:
     - "80:80"
    volumes:
     - /var/lib/lightning/mysql:/var/lib/lightning/mysql
db:
    image: mysql
    environment:
        MYSQL_ROOT_PASSWORD: password
    volumes:
     - /var/lib/mysql
redis:
    image: redis
beanstalkd:
    image: nathanleclaire/laraveldocker_beanstalkd

When I run:

$ ecs-cli compose -f docker-compose-prod.yml up
ERRO[0000] Error registering task definition             error=ClientException: host.sourcePath should not be blank.
        status code: 400, request id: b7a2c30b-6e0f-11e5-a4a1-6b2efea4c01d family=0x820c5e110
ERRO[0000] Create task definition failed                 error=ClientException: host.sourcePath should not be blank.
        status code: 400, request id: b7a2c30b-6e0f-11e5-a4a1-6b2efea4c01d
FATA[0000] ClientException: host.sourcePath should not be blank.
        status code: 400, request id: b7a2c30b-6e0f-11e5-a4a1-6b2efea4c01d

Seems that sourcePath is not getting set as it should be in the task definition.

WARN[0000] Skipping unsupported YAML option... option name=privileged

This option is critical so that containers can mount volumes backed by EBS: aws/amazon-ecs-agent#68

Trying to ecs-cli up I encountered an issue:

$ ecs-cli up --keypair my-key --capability-iam --size 2
INFO[0000] Created cluster                               cluster=nates-cluster
INFO[0000] Waiting for your cluster resources to be created
INFO[0001] Cloudformation stack status                   stackStatus=CREATE_IN_PROGRESS
ERRO[0031] Failure event                                 reason= resourceType=AWS::CloudFormation::Stack
ERRO[0031] Error executing 'up': Cloudformation failure waiting for 'CREATE_COMPLETE'. State is 'ROLLBACK_COMPLETE'

I have no idea what this CloudFormation error means. I think this is related to not specifying a valid key pair (I accidentally used my-key like the tutorial instead of the one I'd created for the service), but some more helpful messages would be nice.

I used to use variables substitution in my docker-compose file, but it seems that ecs-cli doesn't recognise them:

db:
  image: "postgres:${POSTGRES_VERSION}"

I'd like to use it with my CI tool in order to apply different variable for different stages.

With latest version I got:

ERRO[0000] Error registering task definition error=ClientException: Container.image contains invalid characters.
status code: 400, request id: ******* family=0xc20808e2c0
ERRO[0000] Create task definition failed error=ClientException: Container.image contains invalid characters.
status code: 400, request id: ********

Ref: https://docs.docker.com/compose/compose-file/#variable-substitution

Thanks,
Giorgio

Docker-compose enabled variable substitution from shell environment now.

web:
    image: "myimage: ${GIT_COMMIT_HASH}"
    ports: 
        - '80:80'
...

It will be awesome if ecs-cli support this too. Or maybe this involves the issue with docker version running on ecs instance?

A dirty build is denoted by a * by the hash in the --version output. The version generation code has the assumption that ECS_RELEASE will be set to create a clean build, but the build code doesn't fulfill that assumption.
A new release target could/should be added that does a fresh clone in a container and sets that flag, or the version-gen logic should be revisited.

This issue is cosmetic only; it affects version v0.1.0.

Ran into problems where I created a task in one AWS account. Switched to a different AWS account and kept getting cache hits.

Additionally deleting tasks doesn't refresh the cache and it just keeps hitting the cache as well. Solution turned out to be rm -rf ~/.cache which I don't think is acceptable.

... but the doc indicates it will handle this. When you go through this tutorial you fail a few times as you find out what permissions are required. It shouldn't require deleting a stack (with no instances running) to re-run the up command.

single quotes are valid around strings in YAML and often useful for avoiding escaping quotes.
The following task definition works with docker-compose but results in wrong behavior with ecs-cli compose.

web:
    image: nginx
    ports: 
        - '80:80'

Running ecs-cli compose up results in the following error:
ERRO[0000] Unable to open ECS Compose Project error=Could not convert port into integer in portmappings: strconv.ParseInt: parsing "80'": invalid syntax

This can also lead to incorrect behavior at runtime, such as with extraneous quotes in commands.

ECS has an easy way to set up Private Registry Authentication through User Data but the ECS CLI still doesn't support it (see #16 )

The credential resolution for the ecs-cli was recently streamlined in #50, however, there is not sufficient testing around verifying the order of AWS credential resolution. Adding tests to ensure the different credential providers are being used was a bit more involved, so I've added some 'skipped' placeholder tests[1] to actually verify that specified credential providers are functioning as intended. These tests need to be implemented.

[1] juanrhenals@aa82236#diff-a4838a1da48f1c19e5fcf8a4b572b856R92

Can I forward gpu devices to docker with compose file. The option is not thr in UI. Any comments on this will be appreciated.

Thx

It would be nice to have an ecs resources subcommand which reported on the infrastructure used by the cluster the ECS CLI is configured to use (instance IPs/instance hostnames/instance IDs ...)

Use case:

Once you create your cluster with ecs up and deploy some containers, you may want to access the instances (e.g. ssh) or the services offered by the containers in the instances (e.g. a web server).

You need the instance hostnames/IPs to access them. They can be obtained manually through the AWS Console (or automatically through the general AWS CLI since ecs configure provides the cluster name) but it's a hassle and an extra dependency.

When I try the following Compose file with ECS CLI:

redis:
  image: redis
  ports:
  - 10000:6379

I get the following error:

ERRO[0000] Unable to open ECS Compose Project            error=Unable to unmarshal compose config. Error: interface conversion: yaml.Node is yaml.Map, not yaml.List
FATA[0000] Unable to create and read ECS Compose Project  error=Unable to unmarshal compose config. Error: interface conversion: yaml.Node is yaml.Map, not yaml.List

Adding two spaces in front of the - fixes the issue. The original Compose file is valid YAML, though.

Trying to launch a docker-compose file that works locally with compose, and I get the following errors:

ecs-cli compose --file docker-compose.yml up
ERRO[0000] Error registering task definition             error=ClientException: Family contains invalid characters.
    status code: 400, request id: 81108bb6-840b-11e5-a881-4de8415be30c family=0xc208036440
ERRO[0000] Create task definition failed                 error=ClientException: Family contains invalid characters.
    status code: 400, request id: 81108bb6-840b-11e5-a881-4de8415be30c
FATA[0000] ClientException: Family contains invalid characters.
    status code: 400, request id: 81108bb6-840b-11e5-a881-4de8415be30c

Its unclear to me what "Family" its referring to

ecs-cli has been wonderful. For me, it's missing the ability to create services with load balancers. As a workaround, I define tasks with ecs-cli and use aws-cli (http://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) to create the service with the load balancer.

AmazonEC2ContainerServiceforEC2Role may be too restrictive for certain cases.

In our (http://weave.works) particular case, we need to be able to obtain the IPs of the instances which are part of current the autoscaling group.

For context, see https://github.com/weaveworks/guides/blob/d1039713f6b65c21c59dac309e1b3ae962c478bb/aws-ecs/data/weave-ecs-policy.json#L16-L17 and https://github.com/weaveworks/integrations/blob/0cf225a9daa1c439b2e52a08198582775bb2f121/aws/ecs/packer/to-upload/peers.sh#L18-L27

Running ecs-cli compose up with the following file:

privileged_example:
    image: busybox
    privileged: true
    command:
        - sh
        - "-c"
        - "hostname changed; hostname"

Results in the output of:
WARN[0000] Skipping unsupported YAML option... option name=privileged
and the container running incorrectly.

This command ecs-cli configure -p profile -c cluster fails to copy the existing envs from ~/.aws/credentials (with 'profile' being fully populated). Here's a cat of ~/.ecs/config after configured.

[ecs]
cluster = cluster
aws_profile = profile
region = 
aws_access_key_id = 
aws_secret_access_key = 

Is'nt the cli supposed to copy the remaining envs from ~/.aws/credentials?

Of course I can copy the envs manually, but am I missing something that's obvious?

$ ecs-cli configure --region us-east-1 --cluster arriba
INFO[0000] Saved ECS CLI configuration for cluster (arriba) 
$ ecs-cli up --port 22 --keypair arriba --capability-iam --size 1 --instance-type t2.micro
INFO[0001] Created cluster                               cluster=arriba
INFO[0002] Waiting for your cluster resources to be created 
INFO[0002] Cloudformation stack status                   stackStatus=CREATE_IN_PROGRESS
INFO[0063] Cloudformation stack status                   stackStatus=ROLLBACK_IN_PROGRESS
ERRO[0094] Failure event                                 reason=route table rtb-5d58c639 and network gateway igw-626e6107 belong to different networks resourceType=AWS::EC2::Route
ERRO[0094] Error executing 'up': Cloudformation failure waiting for 'CREATE_COMPLETE'. State is 'ROLLBACK_COMPLETE' 

Destroying the cluster and recreating it made it work, so it may be a timing problem in Cloud Formation.

We (at http://weave.works) would like to have a new flag in ecs up for providing User Data so that we can customize the EC2 instances of the cluster.

Context:

In order to be able to deploy an ECS cluster talking to Weave Scope as a cloud service we need to add custom User Data to the EC2 instances.

We (at http://weave.works) would love to use the ECS CLI but we provide our own ECS AMI and there's currently no way to specify a custom AMI when creating the cluster with ecs up.

Below is my docker-compose.yml file that I'm running when using ecs-cli compose up

hello_world:
  image: busybox
  cpu_shares: 100
  mem_limit: 256288000
  command: 
    - echo hi

Regardless of what command I use, I always get the same error:

System error: exec: \"echo hi\": executable file not found in $PATH"

Using ecs-cli to setup a cluster, I get an error for unsupported instance type for 'm4.xlarge' or 'm4.2xlarge':

$ ecs-cli --version
ecs-cli version 0.1.0 (*UNKNOWN)
$ ecs-cli up   --keypair *snip*   --capability-iam   --size 1   --vpc *snip*  --subnets *snip*  --azs us-east-1a   --instance-type m4.xlarge
INFO[0000] Created cluster                               cluster=opsviz-dev
ERRO[0000] Error executing 'up': ValidationError: Parameter EcsInstanceType failed to satisfy constraint: must be a valid EC2 instance type.
    status code: 400, request id: a90c31b7-badf-11e5-a984-97970441ee29

While I couldn't find what ImageID the cloudformation template uses, according to the documentation on setting up an ECS instance, ECS would use the following ami for us-east-1 region: ami-2b3b6041 (http://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_container_instance.html)

If I use that AMI to create the instance itself, it indicates support for the m4.* instance classes.

c4.2xlarge works fine via ecs-cli

Are various instance types not supported? If so, is this documented somewhere?

Also, sidenote: Is the ECS cloudformation template available somewhere?

As we know, YAML is a superset of JSON. Anywhere you can use a YAML array you should be able to also use a JSON array. This doesn't work. For example:

web:
    image: nginx
    ports: ["80:80"]

This works fine with docker-compose but with ecs-cli compose I get the following error:
ERRO[0000] Unable to convert yaml to service configs error=Error parsing: node is not of type list ["80:80"]

This can be worked around with the folowing:

web:
    image: nginx
    ports:
        - "80:80"
        - "443:443"

I have multiple data-only containers that shall provide persistent data to multiple other containers. It is quite easy to set everything up. But when pushing it with ecs-cli compose up and than check what happened with ps it prompts:
ExitCode: 0

I assume that the problem is that data-only containers do not keep running. Could this be the problem?

Run this:

ecs-cli up --keypair my-key-pair --capability-iam --size 2 --instance-type t2.medium

and I get this:

ERRO[0000] Error executing 'up': ParameterValue and UsePreviousValue not set for parameter key 'EcsCluster'

I have tried adding the creds directly to the .ecs/config file as well. However this should work?!:

(default)jessesanford@JesseMacbook ~/workspace/stn_proxymail_docker (master)$ ecs-cli configure --region us-east-1 -p ~/.aws/credentials --cluster proxymail                                                                                                            [2.2.3]
INFO[0000] Saved ECS CLI configuration for cluster (proxymail)
(default)jessesanford@JesseMacbook ~/workspace/stn_proxymail_docker (master)$ ecs-cli compose --file docker-compose.yml up                                                                                                                                              [2.2.3]
ERRO[0120] Unable to create an instance of ECSParams given the cli context  error=NoCredentialProviders: no valid providers in chain
FATA[0120] Unable to create and read ECS Compose Project  error=NoCredentialProviders: no valid providers in chain
(default)jessesanford@JesseMacbook ~/workspace/stn_proxymail_docker (master)$ cat ~/.ecs/config                                                                                                                                                                         [2.2.3]
[ecs]
cluster = proxymail
aws_profile = /Users/jessesanford/.aws/credentials
region = us-east-1
aws_access_key_id =
aws_secret_access_key =

Any ideas? I checked the access key is correct in iam on this account.

ECS CLI uses go-gypsy, which only supports a limited subset of YAML.

This causes a few issues:

• #3 (arrays specified as [1,2,3] don't work)
• #4 (single quotes around strings don't work)
• #12 multi-line arrays only work if there is extra indentation

Switching to e.g. http://gopkg.in/yaml.v2 (used by Compose) should address those issues.

It would be useful to be able to create a compose.yml file from an existing task definition. We already have task definitions but do not have compose files for them.

If my docker-compose.yml specifies an env var without a value, docker compose uses the shell you're running in to grab that value and pass it along. This is useful for not source controlling things like API tokens. E.g.

hubot:
  image: danehammer/the_dude
  links:
    - redis
  environment:
    - "REDIS_URL=redis://redis:6379"
    - "HUBOT_SLACK_TOKEN"

This allows me to export the token as a var locally when I go to run the compose up command. Works correctly with docker compose, does not work with ecs-cli compose.

docker-compose expose the -f switch to load one or more docker-compose override files. Is there something similar for ecs-cli?

For instance:

$ ecs-cli up --keypair my-key --capability-iam --size 2

Would simply hang indefinitely for me and did not print an error message indicating what was wrong. Turns out I had configured my credentials / profile incorrectly. I could not really effectively debug this because there's no --verbose / --debug type flag as far as I can tell.

convert_task_definition.go#L79 already has the comment // TODO, read env file

This already works:

app:
  environment:
    - A=1
    - B=2

But this doesn't:

app:
  env_file: ~/.env

Where ~/.env contains:

A=1
B=2

Documentation: docker-compose.yml reference

Hi,

The ecs-cli compose create and up commands seem to have a bug whereby they check if a task definition exists in the default region instead of the region configured for the ecs cli config file: ~/.ecs/config. This seems to happen if you try and change the configured AWS region using the same compose file and cluster name.

I found this issue by performing the following:

1. Ran the following command to setup the ecs cli: ecs-cli configure --region eu-west-1 --cluster jenkins
2. Setup the ECS cluster instances with the command: ecs-cli up --keypair <keypair> --capability-iam --size 2 --instance-type t2.medium
3. Deployed the compose file with the command: ecs-cli compose --file jenkins-master.yml up
4. Changed the region by running the command: ecs-cli configure --region us-east-1 --cluster jenkins
5. Setup the ECS cluster instances with the command: ecs-cli up --keypair <keypair> --capability-iam --size 2 --instance-type t2.medium
6. Ran the command to create the ECS task: ecs-cli compose --file jenkins-master.yml up

The output I got was the following:

INFO[0000] Using ECS task definition TaskDefinition=ecscompose-jenkins-ecs:1
ERRO[0000] Error running tasks error=InvalidParameterException: Invalid Region in ARN
status code: 400, request id: 3d8a1cb2-848b-11e5-83d9-b34077ba1855 task definition=arn:aws:ecs:eu-west-1:934676248949:task-definition/ecscompose-jenkins-ecs:1
FATA[0000] InvalidParameterException: Invalid Region in ARN
status code: 400, request id: 3d8a1cb2-848b-11e5-83d9-b34077ba1855

If I run the create command: ecs-cli compose create --file jenkins-master.yml it does not check the task definition in the target region, only the default region.

Output:
INFO[0000] Using ECS task definition TaskDefinition=ecscompose-jenkins-ecs:1

Also, if the task definition is deregistered in the default region it still gives the same message and will not create a new task definition in the configured region.

/ecs-cli-darwin-amd64-latest up --capability-iam
ERRO[0000] Error executing 'up': Parameter not found

'up' command when invoked without --keypair is giving error message which is not showing the parameter that is missing.

./ecs-cli-darwin-amd64-latest up --help
NAME:
   up - Create the ECS Cluster (if it does not already exist) and the AWS resources required to set up the cluster.

USAGE:
   command up [command options] [arguments...]

OPTIONS:
   --keypair        Specify the name of an existing Amazon EC2 key pair to enable SSH access to the EC2 instances in your cluster.
   --capability-iam Acknowledge that this command may create IAM resources.
   --size       [Optional] Specify the number of instances to register to the cluster. The default is 1.
   --azs        [Optional] Specify a comma-separated list of 2 VPC availability zones in which to create subnets (these AZs must be in the 'available' status). This option is recommended if you do not specify a VPC ID with the --vpc option. WARNING: Leaving this option blank can result in failure to launch container instances if an unavailable AZ is chosen at random.
   --security-group     [Optional] Specify an existing security group to associate it with container instances. Defaults to creating a new one.
   --cidr       [Optional] Specify a CIDR/IP range for the security group to use for container instances in your cluster. Defaults to 0.0.0.0/0 if --security-group is not specified
   --port       [Optional] Specify a port to open on a new security group that is created for your container instances if an existing security group is not specified with the --security-group option. Defaults to port 80.
   --subnets        [Optional] Specify a comma-separated list of existing VPC Subnet IDs in which to launch your container instances. This option is required if you specify a VPC with the --vpc option.
   --vpc        [Optional] Specify the ID of an existing VPC in which to launch your container instances. If you specify a VPC ID, you must specify a list of existing subnets in that VPC with the --subnets option. If you do not specify a VPC ID, a new VPC is created with two subnets.
   --instance-type  [Optional] Specify the EC2 instance type for your container instances.

The configuration file currently uses only one section (ecs).

It would be very useful if several sections could be used, one per cluster, with the ability to switch between them, e.g.:

$ cat ~/.ecs/config
[ecs]
cluster = default-cluster
aws_profile = 
region = eu-west-1
aws_access_key_id = MYKEYID
aws_secret_access_key = mySecretKey

[test]
cluster = another-cluster
aws_profile =
region = us-east-1
aws_access_key_id = MYKEYID
aws_secret_access_key = mySecretKey

$ ecs-cli -c test ps

When Im calling ecs-cli up with vpc and subnets parameters it gives me error:
ERRO[0192] Failure event reason=The availability zones of the specified subnets and the AutoScalingGroup do not match resourceType=AWS::AutoScaling::AutoScalingGroup

same as here http://serverfault.com/questions/732220/docker-project-on-aws-ecs

What is the purpose of this prefix?

I think it clutters things in the UI and adds an unnecessary ecscompose-service to all services? Can this be something that is toggled off via command line?

When attempting to run ecs-cli ps, consistently seeing a nil pointer error.

Output:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0xe0 pc=0xe3698]

goroutine 1 [running]:
github.com/aws/amazon-ecs-cli/ecs-cli/modules/compose/ecs.getContainersForTasks(0x8820d2f260, 0x820f98480, 0x820e8e000, 0x95, 0xa0, 0x0, 0x0, 0x0, 0x0, 0x0)
/private/tmp/amazon-ecs-cli20151017-49504-1xj8wtw/amazon-ecs-cli-0.1.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/modules/compose/ecs/entity.go:194 +0x498
github.com/aws/amazon-ecs-cli/ecs-cli/modules/compose/ecs.collectContainers(0x8820d2f260, 0x820f98480, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
/private/tmp/amazon-ecs-cli20151017-49504-1xj8wtw/amazon-ecs-cli-0.1.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/modules/compose/ecs/entity.go:112 +0x101
github.com/aws/amazon-ecs-cli/ecs-cli/modules/compose/ecs.info(0x8820d2f260, 0x820f98480, 0x8820d2f200, 0x0, 0x0, 0x0, 0x0, 0x0)
/private/tmp/amazon-ecs-cli20151017-49504-1xj8wtw/amazon-ecs-cli-0.1.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/modules/compose/ecs/entity.go:97 +0x67
github.com/aws/amazon-ecs-cli/ecs-cli/modules/compose/ecs.(_Task).Info(0x820f98480, 0x8820d2f200, 0x0, 0x0, 0x0, 0x0, 0x0)
/private/tmp/amazon-ecs-cli20151017-49504-1xj8wtw/amazon-ecs-cli-0.1.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/modules/compose/ecs/task.go:95 +0x7b
github.com/aws/amazon-ecs-cli/ecs-cli/modules/command.clusterPS(0x820bd01e0, 0x8820cf0b50, 0x820b4bd40, 0x8820cf0aa0, 0x820b45980, 0x0, 0x0, 0x0, 0x0, 0x0)
/private/tmp/amazon-ecs-cli20151017-49504-1xj8wtw/amazon-ecs-cli-0.1.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/modules/command/cluster_app.go:264 +0x244
github.com/aws/amazon-ecs-cli/ecs-cli/modules/command.ClusterPS(0x820bd01e0)
/private/tmp/amazon-ecs-cli20151017-49504-1xj8wtw/amazon-ecs-cli-0.1.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/modules/command/cluster_app.go:103 +0x2ac
github.com/codegangsta/cli.Command.Run(0x6a7550, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7987e0, 0x37, 0x0, ...)
/private/tmp/amazon-ecs-cli20151017-49504-1xj8wtw/amazon-ecs-cli-0.1.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/vendor/src/github.com/codegangsta/cli/command.go:127 +0x1052
github.com/codegangsta/cli.(_App).Run(0x820bcc400, 0x820b44260, 0x2, 0x2, 0x0, 0x0)
/private/tmp/amazon-ecs-cli20151017-49504-1xj8wtw/amazon-ecs-cli-0.1.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/vendor/src/github.com/codegangsta/cli/app.go:159 +0xc2f
main.main()
/private/tmp/amazon-ecs-cli20151017-49504-1xj8wtw/amazon-ecs-cli-0.1.0/src/github.com/aws/amazon-ecs-cli/ecs-cli/main.go:43 +0x96c

goroutine 15 [IO wait]:
net.runtime_pollWait(0x8820cf1f48, 0x72, 0x820b4a160)
/usr/local/Cellar/go/1.5.1/libexec/src/runtime/netpoll.go:157 +0x60
net.(_pollDesc).Wait(0x820c48140, 0x72, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/net/fd_poll_runtime.go:73 +0x3a
net.(_pollDesc).WaitRead(0x820c48140, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/net/fd_poll_runtime.go:78 +0x36
net.(_netFD).Read(0x820c480e0, 0x820c94000, 0x8000, 0x8000, 0x0, 0x8820cec050, 0x820b4a160)
/usr/local/Cellar/go/1.5.1/libexec/src/net/fd_unix.go:232 +0x23a
net.(_conn).Read(0x820c4a010, 0x820c94000, 0x8000, 0x8000, 0x0, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/net/net.go:172 +0xe4
crypto/tls.(_block).readFromUntil(0x820c464e0, 0x8820d2c2b0, 0x820c4a010, 0x5, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/crypto/tls/conn.go:455 +0xcc
crypto/tls.(_Conn).readRecord(0x820c5a000, 0x7f9517, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/crypto/tls/conn.go:540 +0x2d1
crypto/tls.(_Conn).Read(0x820c5a000, 0x820b53000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/crypto/tls/conn.go:901 +0x167
net/http.noteEOFReader.Read(0x8820cfbc48, 0x820c5a000, 0x820bf23c8, 0x820b53000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/net/http/transport.go:1370 +0x67
net/http.(_noteEOFReader).Read(0x820fd9fe0, 0x820b53000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
:126 +0xd0
bufio.(_Reader).fill(0x820def020)
/usr/local/Cellar/go/1.5.1/libexec/src/bufio/bufio.go:97 +0x1e9
bufio.(_Reader).Peek(0x820def020, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/bufio/bufio.go:132 +0xcc
net/http.(_persistConn).readLoop(0x820bf2370)
/usr/local/Cellar/go/1.5.1/libexec/src/net/http/transport.go:876 +0xf7
created by net/http.(_Transport).dialConn
/usr/local/Cellar/go/1.5.1/libexec/src/net/http/transport.go:685 +0xc78

goroutine 16 [select]:
net/http.(_persistConn).writeLoop(0x820bf2370)
/usr/local/Cellar/go/1.5.1/libexec/src/net/http/transport.go:1009 +0x40c
created by net/http.(_Transport).dialConn
/usr/local/Cellar/go/1.5.1/libexec/src/net/http/transport.go:686 +0xc9d

goroutine 24 [IO wait]:
net.runtime_pollWait(0x8820cf1dc8, 0x72, 0x820b4a160)
/usr/local/Cellar/go/1.5.1/libexec/src/runtime/netpoll.go:157 +0x60
net.(_pollDesc).Wait(0x820d8f3a0, 0x72, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/net/fd_poll_runtime.go:73 +0x3a
net.(_pollDesc).WaitRead(0x820d8f3a0, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/net/fd_poll_runtime.go:78 +0x36
net.(_netFD).Read(0x820d8f340, 0x820f71000, 0x800, 0x800, 0x0, 0x8820cec050, 0x820b4a160)
/usr/local/Cellar/go/1.5.1/libexec/src/net/fd_unix.go:232 +0x23a
net.(_conn).Read(0x820b64088, 0x820f71000, 0x800, 0x800, 0x0, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/net/net.go:172 +0xe4
crypto/tls.(_block).readFromUntil(0x8210bd5f0, 0x8820d2c2b0, 0x820b64088, 0x5, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/crypto/tls/conn.go:455 +0xcc
crypto/tls.(_Conn).readRecord(0x820c5a2c0, 0x7f9517, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/crypto/tls/conn.go:540 +0x2d1
crypto/tls.(_Conn).Read(0x820c5a2c0, 0x8210d4000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/crypto/tls/conn.go:901 +0x167
net/http.noteEOFReader.Read(0x8820cfbc48, 0x820c5a2c0, 0x820eb6058, 0x8210d4000, 0x1000, 0x1000, 0x82101ed00, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/net/http/transport.go:1370 +0x67
net/http.(_noteEOFReader).Read(0x820f439e0, 0x8210d4000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
:126 +0xd0
bufio.(_Reader).fill(0x8210bfaa0)
/usr/local/Cellar/go/1.5.1/libexec/src/bufio/bufio.go:97 +0x1e9
bufio.(_Reader).Peek(0x8210bfaa0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/local/Cellar/go/1.5.1/libexec/src/bufio/bufio.go:132 +0xcc
net/http.(_persistConn).readLoop(0x820eb6000)
/usr/local/Cellar/go/1.5.1/libexec/src/net/http/transport.go:876 +0xf7
created by net/http.(_Transport).dialConn
/usr/local/Cellar/go/1.5.1/libexec/src/net/http/transport.go:685 +0xc78

goroutine 25 [select]:
net/http.(_persistConn).writeLoop(0x820eb6000)
/usr/local/Cellar/go/1.5.1/libexec/src/net/http/transport.go:1009 +0x40c
created by net/http.(_Transport).dialConn
/usr/local/Cellar/go/1.5.1/libexec/src/net/http/transport.go:686 +0xc9d

After issue in #9, I tried to ecs-cli down. But, I got an error indicating that the --force flag is required. If it's required, why make it a flag? ;D

This is an option in the web UI, but not in ecs-cli compose service

Currently, the AMI in the ecs-cli is 2015.03.b, which is the ECS Agent 1.1.0

ECR requires that the ECS Agent 1.7.0 or greater, so we should update for the latest AMI of 2015.03.g.
http://docs.aws.amazon.com/AmazonECS/latest/developerguide/container_agent_versions.html

Upgrading this will allow ECR images to be used with clusters created by the ecs-cli.