Questions tagged with Amazon Elastic Container Service

Content language: English

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Bug Report: EventBridge Schedules Console does not set "launchType" for ECS RunTask, breaks Assign Public IP

**Issue Description:** When creating a schedule on the EventBridge Schedules Console that uses ECS RunTask, the schedule fails to include `launchType` in its `requestParameters` when it is set. This breaks the ability to set Assign Public IP with the error "Assign public IP is not supported for this launch type." Likely related to this issue: https://repost.aws/questions/QU7GVF66EhSjuLp04GafMKGQ/event-bridge-scheduler-fails-on-ecs-run-task-with-fargate-launch-type **Steps to Reproduce:** 1. Create a new schedule in the EventBridge Schedules console. 2. Choose ECS RunTask as the Target. 3. Under the RunTask config section, set Compute Options > Launch type to `FARGATE` 4. Set Configure Network Configuration > Auto-assign Public IP to `ENABLED` RunTask will fail with logs in CloudTrail similar to the following: ``` "errorCode": "InvalidParameterException", "errorMessage": "Assign public IP is not supported for this launch type.", "requestParameters": { "cluster": "arn:aws:ecs:XXXXX:XXXXX:cluster/XXXX", "count": 1, "enableECSManagedTags": true, "enableExecuteCommand": false, "networkConfiguration": { "awsvpcConfiguration": { "assignPublicIp": "ENABLED", "subnets": [ "subnet-XXXXX" ] } }, "overrides": {}, "placementConstraints": [], "placementStrategy": [], "platformVersion": "1.4.0", "startedBy": "chronos-schedule/XXXXX", "tags": [], "taskDefinition": "arn:aws:ecs:XXXXX:XXXXX:task-definition/XXXXX:X" }, ``` Notably, `launchType` is missing from `requestParameters` even through `assignPublicIp` was successfully set. **Workaround:** I was able to finish my desired test by [manually creating a schedule using the AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html). Then, I had no further issue implementing the request in the actual Lambda function being developed. However, this issue was an obstacle to testing and debugging.
0
answers
0
votes
5
views
asked a day ago

ECS Fargate and ALB failed the health check with timeout (Node.js app)

I have been trying for two days to run a Node.js application on ECS Fargate connected to a Load Balancer, but somehow it does not pass the health check. I use CDK to create the infrastructure and already use other applications with the same setup that work perfectly. The Dockerfile image works perfectly locally with docker-compose. I am not convinced that's a problem at the SG and infrastructure level, but I think more that it's application side, maybe you have an idea where to go to check. The application is not developed by me and uses Express as server with listener on port 9000. IMPORTANT: I created a small application to test with the same port and endpoint for heath check = it worked perfectly. (health check passed) I increased the ECS idle timeout etc. but nothing Looking at the Task Logs (see image), I see that the application returns a 200 status on the heath check endpoint, however if I try to call the load balancer from its address, the call goes to 504 timeout. I tried from an EC2 machine to connect to the task on the private IP-address: with telnet it seems to work, but if I curl on the health check endpoint, it goes to timeouts. Sometimes if I try to call the load balancer several times (perhaps while the task is starting), the application responds (i.e. I see that the endpoint is working), but immediately afterwards it goes into timeout Any idea? ![Enter image description here](/media/postImages/original/IMBRZWTodnTqu_cmYco5cULQ)
1
answers
0
votes
17
views
asked a day ago

Updating an ECS service automatically using the CLI via Lambda

I have a multi-container application that runs a service on ECS. The images are hosted on ECR, configuration files are pulled from a S3 bucket during container startup via script. The application sits behind a network loadbalancer with EIP. The loadbalancer is in a public subnet and reachable, the app itself is inside a private subnet. My ultimate goal is to automatically update the service when either a.) a new image is checked in or b.) a new configuration file is uploaded. I figured the best way to do this behind a network load balancer (which supports rolling update) is to use the AWS ECS CLi inside a lambda function that triggers upon update. If I did not misread the docs, the CLI should trigger a rolling update. To test the CLI, I tried: `aws ecs update-service --cluster mycluster --service myservice --force-new-deployment` However, this was not successful. A new task was created, but was stopped before deployment was finished with log message: > Essential container in task exited Parameters for the service are min. 100 % and max. 200 %. I also tried to set the lower bound of running tasks to 0 %. This resulted in the successful exit of the old task, but the new tasks failed to deploy with the same error. This makes me think that I probably configured something incorrectly. Questions: 1.) Is using a lambda function a smart choice here? Or is there a better way? 2.) How can I troubleshoot the failing rolling update? I appreciate any help! If you need more information, please let me know. Best regards, Sebastian
1
answers
0
votes
20
views
asked 7 days ago