The open source version of the Amazon ECS developer guide. You can submit feedback & requests for changes by submitting issues in this repo or by making proposed changes & submitting a pull request.
License: Other
This repository is archived, read-only, and no longer updated. For more information, read the announcement on the AWS News Blog.
You can find up-to-date AWS technical documentation on the AWS Documentation website, where you can also submit feedback and suggestions for improvement.
Please share your experience! If you've hit a problem and solved it, I’d love to hear from you. I am also interested in any tips or tricks you’ve learned along the way.
Submit a pull request (instructions here) or send me a note via the Comments below. If your suggestion is likely to help others, I'll add it to the Amazon ECS Developer Guide.
Thank you for your time. I look forward to hearing from you!
Can the AWS Cloud Map documentation be published to GitHub? This question is a bit misplaced, but I couldn't find a better place for it. (I've requested the same in the AWS Cloud Map console, though.)
I'd like to contribute documentation enhancements surrounding SRV records, related to aws/containers-roadmap#448
Happy new year 2021, dear reader!
In the getting started page, the following line is incomplete / missing the intended word & hyperlink:
To learn about the developer tools available for using Amazon ECS, see .
There should be a word & hyperlink after see, above.
This page (end especially the script at the bottom of the page) is for amazon linux but not for amazon linux 2. Please update this page so every works with amazon linux 2
amazon-ecs-developer-guide/doc_source/ecs-ami-storage-config.md
You can modify this value at launch time to increase or decrease the available storage on your container instance.
It isn't possible to decrease the storage to less than the snapshot size.
I think there might be a potential typo in the doc cmd-ecs-cli-compose-ecsparams.md
docker_volumes:
- name: string
scope: string
autoprovision: ### Feel like this should be boolean.
driver: string
driver_opts: boolean ### Instead this has become boolean.
string: string
labels:
string: stringFor reference I saw this document which mentions autoprovision to be boolean and driver_opts as string.
If this is probably a typo, I'm more than happy to send in a PR for the fix.
On this page https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html the list of supported AMIs contains "Amazon ECS-optimized Windows Server 2004 Core AMI", but on this page https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_Windows.html the list doesn't contain it, only older ones like 1909 and 2019.
The paragraph:
"Before you can use IAM roles for tasks, Amazon ECS needs permission to make calls to the AWS APIs on your behalf. These permissions are provided by the Amazon ECS Task Role."
https://github.com/awsdocs/amazon-ecs-developer-guide/blob/master/doc_source/task_IAM_role.md
Reads like a circular dependency. It should be rewritten or removed altogether.
Hello,
I have followed below documentation to explore service discovery in ECS services and when I made desired count to 2 for one ECS service, I am getting RESOURCE:ENI error for 2nd task. 1st task is up and running properly.
https://github.com/awsdocs/amazon-ecs-developer-guide/blob/master/doc_source/service-discovery.md
I am just wondering how service discovery works if I am planning to run hundreds of ECS services with multiple tasks for each on bunch of EC2 servers.
I went through below documentation and it says there is limit on number of ENIs attached to server.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html
Please advise if this is not the correct way to get above question answered. Thank you.
The document says that:
"Service Auto Scaling is not currently available in the ECS console in the following regions:
China (Beijing) | cn-north-1"
However, Service Auto Scaling is actually available in the ECS console in BJS.
See the attached file for the screenshot of the console:
First off, thank you for supporting PrivateLink! It makes ECS far more attractive to security-sensitive organizations like mine.
But one thing that struck me is that PrivateLink policies are supported on the ecs endpoint, but not on the ecs-agent and ecs-telemetry endpoints. The documentation just says I need all three, but doesn't really explain when and why (e.g., do I need all three for Fargate or just for traditional ECS?)
Unfortunately if I need all three endpoints in my VPC, then it makes me very uneasy to not have policy support on the latter two. I realize they're (probably deliberately) undocumented, but many security-conscious organizations are concerned about exfiltration risks from private VPCs that are not connected to the internet. Policy support on the ecs endpoint gives us the power to control exfiltration on that one, but the other two are sort of "wide open" to the world and make me very uneasy. It's possible that they're somehow restricted internally to only allow telemetry within my account but since they're undocumented it's hard to know.
tl;dr: could you explain a bit of how the ecs-agent and ecs-telemetry endpoints work from an exfiltration standpoint? PrivateLink's primary driver (as I understand it) is exfiltration-conscious offline VPCs so it seems relevant to the ECS PrivateLink documentation
In this page of the documentation, it would be nice to have concrete examples on how to set up your containers so to execute the bootstrap script when a container starts.
Looking at the following docs, the nofile hard limit default is stated to be 1048576.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html#fargate-resource-limits
This limit conflicts with the following doc (states hard limit default is 4096):
https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html
Running ulimit -a -H via ecs exec in a container with no ulimit parameters in the task definition shows 4096.
AWS Documentation states that AWS Fargate supports mounting Host Volumes - which is not supported [1] . From my understanding, Fargate Supports mounting other Docker Volumes by using the 'volumesFrom' property. But doesn't inherently support Bind Mounts.
There are multiple citations of this error - which need to be corrected.
Citation 1: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html
Citation 2: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bind-mounts.html
Reference:
[1] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-storage.html
According the public documentation, there is no depends_on parameter.
But, as you can see on the AWS CLI repository, it exists.
Can you please update the public documentation with the latest ecs-params.yml parameters?
Thanks in advance
The code snippet which contains task definition where two containers are sharing a single volume is NOT separated by a comma. I tried to contact someone via AWS forums but not responsive at all.
For tasks hosted on Amazon EC2, how do you specify the GPUs that should be allocated for the task/container?
Hi team,
I wanted to suggest that the considerations could be bolstered to include a note that for resolution to be successful the Amazon Provided DNS must be used for resolution of the DNS names.
But also enableDnsHostnames, and not just enableDnsSupport must be true on the VPC configuration for custom Private hosted zones to be resolvable - as covered here:
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support
The service documentation (service_definition_parameters.md) seems to be missing information about the serviceRegistries attribute.
This attribute instructs ECS to register an instance with a servicediscovery service whenever a task is created or destroyed. The tutorial about service discovery (service-discovery.md) does contain this attribute and it is actually working.
Hi,
I have followed multiple links online around ECS service having multiple Target groups but I cannot seem to get this working. I have also noticed when using the AWS Web Interface that it is not possible to add multiple target groups to a service and only allows one.
Can anyone explain this? Would be greatly appreciated, as I can only seem to be able to serve one port behind a load balancer for the same service.
Hi,
I've been going through the example of setting up a codepipeline that deploys to fargate.
Reading through the tutorial there is a detail missing or unclear.
During the build phase, we create an imagedefinitions.json file, but it's not clear how to reference it during the codepipeline stage. E.g. where is that artifact and how will codepipeline know that ?
Thanks
As per ECS User guide,
Fargate Platform version as per platform_versions.html documentation refers 1.4.0 as LATEST version.
However, when launching a Fargate task for ECS, LATEST refers to 1.3.0.
Raising this issue to fix wording in documentation.
As it mentions tags are case-sensitive and says "Don't use the aws: " . Someone might believe that "AWS:" or "Aws:" are allowed, which is not the case.
The note:
"The default expiration time for the generated IAM role credentials is 6 hours."
As per above statement, It looks like that there is a way for the users to change (increase/decrease) the frequency of auto rotation of ECS role credentials from 6 hours. If there is a way for the end users to change, then it is not documented anywhere as per my understanding.
Otherwise, we should add a note that this value can not be changed.
It would be an improvement if /doc_source/http_proxy_config.md would address ECS anywhere. I'm not sure if it does not because ECS anywhere only recently went GA, or if there is a better location for ECS anywhere documentation.
The documentation for setting NO_PROXY in /etc/systemd/system/docker.service.d/http-proxy.conf
has
Environment="NO_PROXY=169.254.169.254"
but cloudwatch on ECS anywhere does not work for me unless I have
Environment="NO_PROXY=169.254.169.254,169.254.170.2"
Can this be updated?
I was working on setting up ECS anywhere on RHEL 7. The installation script does not install/configure docker on RHEL, so I was looking for documentation on proxy settings, and landed at /doc_source/http_proxy_config.md (among other places).
Using settings on that page, I was able to get the agent up and connected to AWS and run a sample task. However, when trying to integrate cloudwatch into the ECS task definition, I was encountering an odd error.
Jun 14 18:45:48 xxxxx dockerd: time="2021-06-14T18:45:48.948385798-05:00" level=error msg="Failed to create log stream" errorCode=CredentialsEndpointError logGroupName=/ecs/hello-world-ecsanywhere logStreamName=ecs/ecsanywhere/8c735d0cca854d90bd7271bf8a852a9b message="failed to load credentials" origError=": "
Since this is my first experience with AWS / docker / cloudwatch / etc., the error meant nothing to me, but I have had enough history with proxies to wonder if that was the cause. Next I turned on docker debug logging in hopes it would give me more details, but unfortunately nothing more about "origError":
Jun 14 18:45:48 xxxxx dockerd: time="2021-06-14T18:45:48.939616967-05:00" level=debug msg="Trying to get credentials from awslogs-credentials-endpoint"
Jun 14 18:45:48 xxxxx dockerd: time="2021-06-14T18:45:48.939657400-05:00" level=debug msg="Created awslogs client" region=us-east-2
Jun 14 18:45:48 xxxxx dockerd: time="2021-06-14T18:45:48.948385798-05:00" level=error msg="Failed to create log stream" errorCode=CredentialsEndpointError logGroupName=/ecs/hello-world-ecsanywhere logStreamName=ecs/ecsanywhere/8c735d0cca854d90bd7271bf8a852a9b message="failed to load credentials" origError=": "
Luckily, the debug statement led me to here: https://github.com/moby/moby/blob/master/daemon/logger/awslogs/cloudwatchlogs.go#L368, where I found the hardcoded credentials endpoint in the same file: https://github.com/moby/moby/blob/master/daemon/logger/awslogs/cloudwatchlogs.go#L65
After adding that to NO_PROXY, cloudwatch started to work.
Definitely a roundabout way to get where I was trying to go, so if the documentation can be fixed that would be great.
(In hindsight, I see the "/etc/sysconfig/docker" configuration has NO_PROXY as I needed it, but the "/etc/systemd/system/docker.service.d/http-proxy.conf" config does not...ouch)
Additionally, if the error or debug messages would have
That would have helped tremendously. If you feel it's worthwhile to provide that feedback to developers please do (or let me know where the best place to file an issue would be, and I can do it.) Thank you.
Hello, Im having trouble understanding the "Installing the Amazon ECS CLI" guide. Im trying to install it on Windows machine. However, when I run this command in Powersheel as administrator:
gpg --keyserver hkp://keys.gnupg.net --recv BCE9D9A42D51784F
My ouput is the following:
gpg: requesting key 2D51784F from hkp server keys.gnupg.net
gpg: key 2D51784F: "Amazon ECS <[email protected]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
But for the follwing command:
gpg --import <public_key_filename>
I cannot find any public_key_file_Name to use in the import statement. I have also try creating it and place in the same directory (I copy paste the content that is the guide into a file and save it as .gpg, and then I place the file in the same directory). However, when I try to import it, the following message pops up:
My command: gpg --import aws-ecs-cli-gpg.gpg
Output:
gpg: can't open `aws-ecs-cli-gpg.gpg': No such file or directory
gpg: Total number processed: 0
But I dont know why it says that there is no such file or directory, when I cann clearly see the file in the explorer.
Can anyone help me please? I have been stuck with this over the past days.
The following doc is missing the definition of resourceRequirements attributes.
I also can't find it's purpose from the AWS web interface.
Expectation:
Below is the sample task definition JSON generated from the AWS console.
{
"ipcMode": null,
"executionRoleArn": "arn:aws:iam::XXXXXXXXXXXX:role/sample-service-ecs-task-exec",
"containerDefinitions": [
{
"dnsSearchDomains": null,
"environmentFiles": null,
"logConfiguration": {
"logDriver": "awslogs",
"secretOptions": null,
"options": {
"awslogs-group": "/ecs/sample-service/app",
"awslogs-region": "eu-central-1",
"awslogs-stream-prefix": "ecs"
}
},
"entryPoint": null,
"portMappings": [
{
"hostPort": 80,
"protocol": "tcp",
"containerPort": 80
}
],
"command": [],
"linuxParameters": null,
"cpu": 0,
"environment": [
{
"name": "APACHE_ACCESS_LOG_LEVEL",
"value": "error"
},
],
"resourceRequirements": null,
"ulimits": null,
"dnsServers": null,
"mountPoints": [
{
"readOnly": false,
"containerPath": "/var/www/html/var",
"sourceVolume": "shared-vol-var"
}
],
"workingDirectory": null,
"secrets": null,
"dockerSecurityOptions": null,
"memory": null,
"memoryReservation": null,
"volumesFrom": [],
"stopTimeout": null,
"image": "XXXXXXXXXXXX.dkr.ecr.eu-central-1.amazonaws.com/sample:211558953",
"startTimeout": null,
"firelensConfiguration": null,
"dependsOn": null,
"disableNetworking": null,
"interactive": null,
"healthCheck": null,
"essential": true,
"links": null,
"hostname": null,
"extraHosts": null,
"pseudoTerminal": null,
"user": null,
"readonlyRootFilesystem": null,
"dockerLabels": null,
"systemControls": null,
"privileged": null,
"name": "shop"
},
{
"dnsSearchDomains": null,
"environmentFiles": null,
"logConfiguration": {
"logDriver": "awslogs",
"secretOptions": null,
"options": {
"awslogs-group": "/ecs/sample-service",
"awslogs-region": "eu-central-1",
"awslogs-stream-prefix": "ecs"
}
},
"entryPoint": null,
"portMappings": [],
"command": null,
"linuxParameters": null,
"cpu": 0,
"environment": [],
"resourceRequirements": null,
"ulimits": null,
"dnsServers": null,
"mountPoints": [],
"workingDirectory": null,
"secrets": null,
"dockerSecurityOptions": null,
"memory": null,
"memoryReservation": null,
"volumesFrom": [],
"stopTimeout": null,
"image": "hello-world:latest",
"startTimeout": null,
"firelensConfiguration": null,
"dependsOn": null,
"disableNetworking": null,
"interactive": null,
"healthCheck": null,
"essential": false,
"links": null,
"hostname": null,
"extraHosts": null,
"pseudoTerminal": null,
"user": null,
"readonlyRootFilesystem": null,
"dockerLabels": null,
"systemControls": null,
"privileged": null,
"name": "hello"
}
],
"placementConstraints": [],
"memory": "1024",
"taskRoleArn": "arn:aws:iam::XXXXXXXXXXXX:role/sample-service-ecs-task",
"compatibilities": [
"EC2",
"FARGATE"
],
"taskDefinitionArn": "arn:aws:ecs:eu-central-1:XXXXXXXXXXXX:task-definition/sample-service:9",
"family": "sample-service",
"requiresAttributes": [
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.logging-driver.awslogs"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.execution-role-awslogs"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.efsAuth"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.ecr-auth"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.19"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.efs"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.task-iam-role"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.25"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.execution-role-ecr-pull"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.18"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.task-eni"
}
],
"pidMode": null,
"requiresCompatibilities": [
"FARGATE"
],
"networkMode": "awsvpc",
"cpu": "512",
"revision": 9,
"status": "ACTIVE",
"inferenceAccelerators": null,
"proxyConfiguration": null,
"volumes": [
{
"fsxWindowsFileServerVolumeConfiguration": null,
"efsVolumeConfiguration": {
"transitEncryptionPort": null,
"fileSystemId": "fs-e4ed97bc",
"authorizationConfig": {
"iam": "DISABLED",
"accessPointId": "fsap-0b4df69a36f1f54ca"
},
"transitEncryption": "ENABLED",
"rootDirectory": "/"
},
"name": "shared-vol-var",
"host": null,
"dockerVolumeConfiguration": null
}
]
}At https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html#amazonelasticcontainerservice-container-instance we can see the resource-type documented as:
arn:${Partition}:ecs:${Region}:${Account}:container-instance/${ClusterName}/${ContainerInstanceId}
At https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security_iam_id-based-policy-examples.html#IAM_container_instance_policies there is an example which looks like this:
arn:aws:ecs::<aws_account_id>:container-instance/<container_instance_UUID>
I tried the first version with the ListTask action and did not get it to work. I solved it by using the wildcard * as resource and a condition for the cluster. I guess the Service Authorization Reference is wrong. In the past I also had problems with RunTask and its resources statement which I could not resolve. Maybe there was some kind of rework in the past which did not make it to the Service Authorization Reference?
Tried for ECS It is not listing service quotas for the specified AWS service (ECS) in my AWS Account....
➜ ~ aws service-quotas list-service-quotas --service-code ecs
{
"Quotas": []
}
➜ ~
Checking list all default service quotas for the specified AWS service - Able to see
➜ ~ aws service-quotas list-aws-default-service-quotas --service-code ecs --region eu-west-1 --query "Quotas[*].{ServiceName:ServiceName,QuotaName:QuotaName,QuotaCode:QuotaCode,Value:Value}" --output table
-------------------------------------------------------------------------------------------------------------------------------------------------------
| ListAWSDefaultServiceQuotas |
+------------+---------------------------------------------------------------------------+-------------------------------------------------+----------+
| QuotaCode | QuotaName | ServiceName | Value |
+------------+---------------------------------------------------------------------------+-------------------------------------------------+----------+
| L-21C621EB| Clusters per account | Amazon Elastic Container Service (Amazon ECS) | 10000.0 |
| L-86C34207| Container instances per cluster | Amazon Elastic Container Service (Amazon ECS) | 2000.0 |
| L-08804B4B| Public IP addresses for tasks using the Fargate launch type | Amazon Elastic Container Service (Amazon ECS) | 100.0 |
| L-9EF96962| Services per cluster | Amazon Elastic Container Service (Amazon ECS) | 1000.0 |
| L-92E49DE3| Tasks using the EC2 launch type per service (the desired count) | Amazon Elastic Container Service (Amazon ECS) | 1000.0 |
| L-A6B4929D| Tasks using the Fargate Spot capacity provider, per Region, per account | Amazon Elastic Container Service (Amazon ECS) | 250.0 |
| L-46458851| Tasks using the Fargate launch type, per Region, per account | Amazon Elastic Container Service (Amazon ECS) | 100.0 |
+------------+---------------------------------------------------------------------------+-------------------------------------------------+----------+
I've AWS CLI version
➜ ~ aws --version
aws-cli/1.18.64 Python/3.7.4 Linux/4.14.138-114.102.amzn2.x86_64 botocore/1.16.14
Could you please confirm list-service-quotas is blank...
Any Suggestions here please ?
Hello team,
In this page of documention currently customer have visibility for target metric value and actual metric data points in cloudwatch ..but they don't have any clear data point which states when would scale-in occur.
ECS tasks scale in process is vaguely mentioned in considerations link... can we please add a new example scale in action...which clearly mentions the scopes of target metric value setup my customer, actual metric data points in cloudwatch and data points when customer should expect the scale in action to occur.
It is not possible to get instance metadata from a task started with ECS, the container is unable to access the metadata from the host.
Invoke-WebRequest http://169.254.169.254/latest/meta-data/instance-id -UseBasicParsing
I just launched a new spot fleet request with the latest AMI ami-02507631a9f7bc956 for my ECS cluster.
I found that the storage configuration of this AMI no longer matches the documentation:
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-ami-storage-config.html states that:
Amazon ECS-optimized Amazon Linux AMIs from version 2015.09.d and later launch with an 8-GiB volume for the operating system that is attached at /dev/xvda and mounted as the root of the file system. There is an additional 22-GiB volume that is attached at /dev/xvdcz that Docker uses for image and metadata storage.
And that:
You can increase these default volume sizes by changing the block device mapping settings for your instances when you launch them; however, you cannot specify a smaller volume size than the default.
When creating the Spot Fleet Request via the web console I found that /dev/xvdcz is not an available volume device, although /dev/xvdbz is available.
After the EC2 instance was created I found that vgs is no longer installed in the base O.S. and that docker is using a different Storage Driver (devicemapper changed to overlay2).
This is the way "docker info" reported the storage in previous AMI ami-0bf2fb355727b7faf:
$sudo docker info
...
Server Version: 18.06.1-ce
Storage Driver: devicemapper
Pool Name: docker-docker--pool
Pool Blocksize: 524.3kB
Base Device Size: 10.74GB
Backing Filesystem: ext4
Udev Sync Supported: true
Data Space Used: 3.503GB
Data Space Total: 42.42GB
Data Space Available: 38.92GB
Metadata Space Used: 6.701MB
Metadata Space Total: 46.14MB
Metadata Space Available: 39.44MB
Thin Pool Minimum Free Space: 4.242GB
Deferred Removal Enabled: true
Deferred Deletion Enabled: true
Deferred Deleted Device Count: 0
Library Version: 1.02.135-RHEL7 (2016-11-16)
Logging Driver: json-file
Cgroup Driver: cgroupfs
...
And this is how is now:
$ sudo docker info
...
Server Version: 18.06.1-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
...
What's the correct process to extend the size of the docker partition for image and metadata storage in the new AMI?
We also use the extra volume /dev/xvdcz to add encryption to our container storage. What's the recommended approach now?
Documentation outlining the environment variables available within a Fargate hosted environment that are preset by AWS. For example, there is the following page for Lambda:
While following tutorial steps to create FSx with ECS.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tutorial-wfsx-volumes.html#wfsx-create-instance
Encountered error below when carrying out step 6.
Step 6: Paste the following sample task definition JSON into the text area (replacing the pre-populated JSON there) and choose Save.
Looking at the bind-mount documentation, I've seen this example: To mount volumes from another container using volumesFrom.
This example will work well with EC2 launch type. But, for Fargate 1.4, the containers will not be able to see the files written by the other container.
In order to do so, both containers should use the same volume instead of one of them (in case of 2 containers) uses the volumes_from directive.
I was able to reproduce the issue and put it working fine after modify my task definition to use the same volumes for both containers instead of use the volumesFrom.
Let me know if you have any questions.
Change this to a feature request, as toggling the Managed Instance/Managed Termination flags to Disable then Enable seemed to then allow for the the update to TargetCapacity.
If a capacity provider update fails, need to provide details as to the problem. The current updateStatusReason: referencing a client exception and documentation that does not exist, is not helpful at all...e.g.
"updateStatus": "UPDATE_FAILED",
"updateStatusReason": "The capacity provider can't be updated right now due to a client exception. See the documentation for possible causes or wait and try again.",
(this is an autoScalingGroupProvider cp).
Reason should provide a greater level of detail as to the cause, not reference 'the documentation'
Please share your example task definitions! If you have a useful or interesting task definition example that you feel other users could benefit from, let us know.
Submit a pull request (instructions here) or send me a note via the Comments below. If your suggestion is likely to help others, I'll add it to the list of example task definitions here in the Amazon ECS Developer Guide.
Thank you for your time. I look forward to hearing from you!
Hi there!
I have had an issue in the past where I have attempted to register a task definition, but it got rejected because it was over the size limit. I looked up the ECS service limits here and was able to identify that there's a 32 KiB limit.
However, what do I need to calculate that number? Is there an AWS CLI command that I can use?
The closest thing to this that I attempted to do is to use the AWS CLI command as follows:
aws ecs describe-task-definition --task-definition <TASK_DEFINITION_NAME> > definition.json
And then check the size of it using ls -ahl. However, this results in a file size that's bigger than 32 kb.
Add the option "non-blocking" and "max-buffer-size" as an "Available awslogs Log Driver Options".
Please find here the further information about this option:
Allow awslogs to use non-blocking mode
Configure the delivery mode of log messages from container to log driver
Base on the AWS container road map's member mentioned, currently T2 and T3 instance type is not supported due to technical constraints .
aws/containers-roadmap#7 (comment)
As currently document, it seems will misleading customer. Because customer only see the notice "The c5n, m5n, m5dn, r5n, and r5dn instance types are not supported.".
I expected that we can add the t2 and t3 on this unsupported notice in order to make customer more clarify.
If you look here:
StopTimeout
Time duration to wait before the container is forcefully killed if it doesn't exit normally on its own.
It doesn't tell us the units, I assume milliseconds, but it's pretty unclear, also for startTimeout.
When trying to add a cross account parameter into a task definition, ECS errors out with
The Systems Manager parameter ARN has a different account ID than the current account. The current account ID is ********* and the ARN account ID is ***********. Cross-account access for ARNs is not currently supported.
However, the documentation does not make it clear that Cross-account access via ARNs is not supported in the documentation.
This should be listed as a consideration to make this clear.
When try to run it as below ecs-cli compose --file docker-compose.yml up --create-log-groups --ecs-profile ec2-ecs-tutorial --aws-profile pprofile
it fails with below logs
WARN[0000] Skipping unsupported YAML option for service... option name="network_mode" service name=restcomm
WARN[0000] Skipping unsupported YAML option for service... option name=restart service name=restcomm
INFO[0001] Using ECS task definition TaskDefinition="root:10"
WARN[0001] Failed to create log group tutorial-rc in us-west-2: The specified log group already exists
ERRO[0001] Error running tasks error="InvalidParameterException: No Container Instances were found in your cluster.\n\tstatus code: 400, request id: 1bc1cad8-05b3-11e8-93c3-3f478d00f51d" task definition="arn:aws:ecs:us-west-2:966021346097:task-definition/root:10"
FATA[0001] InvalidParameterException: No Container Instances were found in your cluster.
status code: 400, request id: 1bc1cad8-05b3-11e8-93c3-3f478d00f51d
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data-tutorial.html
The above page is missing the ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true as part of EC2 bootstrap. Without this step we are getting the following error
STOPPED (Fetching secret data from AWS Secrets Manager in region us-east-1: secret arn:aws:secretsmanager:us-east-1:㊙️secretname-1aBCDe: RequestError: send request failed caused by: Post https://secretsmanager.us-east-1.amazonaws.com/: dial tcp: lookup secretsmanager.us-east-1.amazonaws.com on 10.7.166.253:53: no such host)
we are able to pull secrets successfully by adding ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true to bootstrap.
I noticed the documentation for subscribing to the ECS optimized AMI updates was deleted 11 days ago and is now found under windows ami section.
/doc_source/ECS-AMI-SubscribeTopic.md
1114647#diff-6c7023cf1cbe5e3fd7cab63759b1980ced42646344daaade4393ea7023cf267f
Is there another option for being notified of ecs optimized linux 2 ami updates?
Predictive Scaling for ECS EC2 seems to be good, I would like to request a feature to get it for ECS Fargate as well.
Hello, this is a suggest update for "Creating an IAM role and policy for your tasks" section of our public documentation IAM roles for tasks,
It is recommended that you use the aws:SourceAccount or aws:SourceArn condition keys to scope the permissions further to prevent the confused deputy security issue. These condition keys can be specified in the trust relationship or in the IAM policy associated with the role
With aws:SourceArn we can lock down the IAM role to all ECS tasks within the account to assume it. For example,
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ecs-tasks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:ecs:*:1234567890:task/*"
}
}
}
]
}
However, it is not yet supported to lock down the IAM role to only allow tasks from specific cluster.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ecs-tasks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:ecs:*:1234567890:task/my-cluster-name/*"
}
}
}
]
}
To set proper expectation, can we add following lines to clarify the scope of current supported usage for aws:SourceArn?
Suggest line to add:
Using `aws:SourceArn` condition key to lock down IAM role to cluster level is not supported currently.
Feel free to reach out to xuyiruan at amazon dot com if you need any further info. thanks.
In the page of Task Definition Parameters, there are two confusion statements I would request a further explanation or clarify.
Line 196
Agent versions <= 1.1.0: Null and zero CPU values are passed to Docker as 0, which Docker then converts to 1,024 CPU shares. CPU values of 1 are passed to Docker as 1, which the Linux kernel converts to 2 CPU shares.
Here the document says:
Does that means when user set the value to 0 and 1(or larger), the conversion will be done by Docker and Linux kernel respectively? Or, the second one should be "Docker" as well?
Line 197
Agent versions >= 1.2.0: Null, zero, and CPU values of 1 are passed to Docker as 2.
Dose the unit of 2 is CPU shares?
in this page https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_storage I do not see any information on firelensConfiguration parameter
{
"essential": true,
"image": "amazon/aws-for-fluent-bit:latest",
"name": "log_router",
"firelensConfiguration": {
"type": "fluentbit",
"options": {
"enable-ecs-log-metadata": "true"
}
},
"memory": 128
}
One example shows cat <<'EOF' >> /etc/ecs/ecs.config which should be cat <<'EOF' >> /etc/ecs/ecs.config. Would like to fix it to avoid reader miss configuration.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.