By using AWS re:Post, you agree to the Terms of Use
/AWS Fargate/

Questions tagged with AWS Fargate

Sort by most recent
  • 1
  • 90 / page

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

Containers/services unable to communicate between them

I have created an ECS cluster that runs one service on Fargate with one task definition. The task definition runs two containers that are supposed to communicate with each other: - nginx (using `fastcgi_pass <hostname>:9000;`) - php-fpm I have tried running them in one task definition or in seperate services (with Service Discovery set with either A records or SRV records - I have tried all the options). Other info: - Public VPC with two public subnets - Security group that allows access from itself to port 9000 (the php-fpm port) - Load balancer connected to the nginx container on port 80 Here is one of the task definitions that I tried, in this case running the containers in the same task definition (nginx has `fastcgi_pass localhost:9000;`). I hope somebody can help me... It can't be this hard to do something so simple. Nothing seems to work. ``` { "ipcMode": null, "executionRoleArn": "arn:aws:iam::359816492978:role/ecsTaskExecutionRole", "containerDefinitions": [ { "dnsSearchDomains": null, "environmentFiles": null, "logConfiguration": { "logDriver": "awslogs", "secretOptions": null, "options": { "awslogs-group": "/ecs/v1-stage", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "ecs" } }, "entryPoint": null, "portMappings": [ { "hostPort": 80, "protocol": "tcp", "containerPort": 80 } ], "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": "359816492978.dkr.ecr.us-east-1.amazonaws.com/nginx", "startTimeout": null, "firelensConfiguration": null, "dependsOn": null, "disableNetworking": null, "interactive": null, "healthCheck": null, "essential": true, "links": [], "hostname": null, "extraHosts": null, "pseudoTerminal": null, "user": null, "readonlyRootFilesystem": null, "dockerLabels": null, "systemControls": null, "privileged": null, "name": "nginx" }, { "dnsSearchDomains": null, "environmentFiles": null, "logConfiguration": { "logDriver": "awslogs", "secretOptions": null, "options": { "awslogs-group": "/ecs/v1-stage", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "ecs" } }, "entryPoint": null, "portMappings": [ { "hostPort": 9000, "protocol": "tcp", "containerPort": 9000 } ], "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": "359816492978.dkr.ecr.us-east-1.amazonaws.com/php", "startTimeout": null, "firelensConfiguration": null, "dependsOn": null, "disableNetworking": null, "interactive": null, "healthCheck": null, "essential": true, "links": [], "hostname": null, "extraHosts": null, "pseudoTerminal": null, "user": null, "readonlyRootFilesystem": null, "dockerLabels": null, "systemControls": null, "privileged": null, "name": "php" } ], "placementConstraints": [], "memory": "1024", "taskRoleArn": "arn:aws:iam::359816492978:role/ecsTaskExecutionRole", "compatibilities": [ "EC2", "FARGATE" ], "taskDefinitionArn": "arn:aws:ecs:us-east-1:359816492978:task-definition/v1-stage:5", "family": "v1-stage", "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": "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": "com.amazonaws.ecs.capability.task-iam-role" }, { "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", "runtimePlatform": { "operatingSystemFamily": "LINUX", "cpuArchitecture": null }, "cpu": "512", "revision": 5, "status": "ACTIVE", "inferenceAccelerators": null, "proxyConfiguration": null, "volumes": [] } ```
1
answers
0
votes
7
views
asked a day ago

Unable to override taskRoleArn when running ECS task from Lambda

I have a Lambda function that is supposed to pass its own permissions to the code running in an ECS task. It looks like this: ``` ecs_parameters = { "cluster": ..., "launchType": "FARGATE", "networkConfiguration": ..., "overrides": { "taskRoleArn": boto3.client("sts").get_caller_identity().get("Arn"), ... }, "platformVersion": "LATEST", "taskDefinition": f"my-task-definition-{STAGE}", } response = ecs.run_task(**ecs_parameters) ``` When I run this in Lambda, i get this error: ``` "errorMessage": "An error occurred (ClientException) when calling the RunTask operation: ECS was unable to assume the role 'arn:aws:sts::787364832896:assumed-role/my-lambda-role...' that was provided for this task. Please verify that the role being passed has the proper trust relationship and permissions and that your IAM user has permissions to pass this role." ``` If I change the task definition in ECS to use `my-lambda-role` as the task role, it works. It's specifically when I try to override the task role from Lambda that it breaks. The Lambda role has the `AWSLambdaBasicExecutionRole` policy and also an inline policy that grants it `ecs:runTask` and `iam:PassRole`. It has a trust relationship that looks like: ``` "Effect": "Allow", "Principal": { "Service": [ "ecs.amazonaws.com", "lambda.amazonaws.com", "ecs-tasks.amazonaws.com" ] }, "Action": "sts:AssumeRole" ``` The task definition has a policy that grants it `sts:AssumeRole` and `iam:PassRole`, and a trust relationship that looks like: ``` "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com", "AWS": "arn:aws:iam::account-ID:role/aws-service-role/ecs.amazonaws.com/AWSServiceRoleForECS" }, "Action": "sts:AssumeRole" ``` How do I allow the Lambda function to pass the role to ECS, and ECS to assume the role it's been given? P.S. - I know a lot of these permissions are overkill, so let me know if there are any I can get rid of :) Thanks!
2
answers
1
votes
18
views
asked 13 days ago

XGBoost Error: Allreduce failed - 100GB Dask Dataframe on AWS Fargate ECS cluster dies with 1T of memory.

Overview: I'm trying to run an XGboost model on a bunch of parquet files sitting in S3 using dask by setting up a fargate cluster and connecting it to a Dask cluster. Total dataframe size totals to about 140 GB of data. I scaled up a fargate cluster with properties: Workers: 40 Total threads: 160 Total memory: 1 TB So there should be enough data to hold the data tasks. Each worker has 9+ GB with 4 Threads. I do some very basic preprocessing and then I create a DaskDMatrix which does cause the task bytes per worker to get a little high, but never above the threshold where it would fail. Next I run xgb.dask.train which utilizes the xgboost package not the dask_ml.xgboost package. Very quickly, the workers die and I get the error `XGBoostError: rabit/internal/utils.h:90: Allreduce failed`. When I attempted this with a single file with only 17MB of data, I would still get this error but only a couple workers die. Does anyone know why this happens since I have double the memory of the dataframe? ``` X_train = X_train.to_dask_array() X_test = X_test.to_dask_array() y_train = y_train y_test = y_test ``` dtrain = xgb.dask.DaskDMatrix(client,X_train, y_train) output = xgb.dask.train( client, {"verbosity": 1, "tree_method": "hist", "objective": "reg:squarederror"}, dtrain, num_boost_round=100, evals=[(dtrain, "train")])`
1
answers
0
votes
6
views
asked 15 days ago

boto3 ecs.describe_task call returns task missing

I'm trying to use a boto3 ECS waiter to wait on a Fargate ECS task to complete. The vast majority of the time the waiter works as expected (waits for the task to reach the STOPPED status). However, sporadically the waiter will return a failure because a task is marked as missing. However, I can find the task itself in the cluster and cloudwatch logs for the task. When I first encountered this, I switched to using boto3 [`ecs.describe_tasks`](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ecs.html#ECS.Client.describe_tasks) method to see if I could get more information about what was happening. When the above situation occurs, descirbe_tasks returns something like: ``` {'tasks': [], 'failures': [\{'arn': 'arn:aws:ecs:us-west-2:21234567891011:task/something-something/dsfsadfasdhfasjklhdfkdsajhf', 'reason': 'MISSING'}], 'ResponseMetadata': \{'RequestId': sdkfjaskdjfhaskdjfhasd', 'HTTPStatusCode': 200, 'HTTPHeaders': {'x-amzn-requestid': 'sdkjfhsdkajhfksadhkjsadf', 'content-type': 'application/x-amz-json-1.1', 'content-length': '145', 'date': 'Fri, 06 May 2022 08:36:11 GMT'}, 'RetryAttempts': 0}} ``` I've looked at the [AWS Docs ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/api_failures_messages.html) and the none of the scenarios outlined for `reason: MISSING` apply in my circumstance. I'm passing my cluster name as an argument to the call as well. Since this happens intermittently its difficult to troubleshoot. What does the MISSING status mean? What are the reasons why an API call to check on task status would return missing when the task exists?
1
answers
0
votes
9
views
asked 18 days ago

Container cannot bind to port 80 running as non-root user on ECS Fargate

I have an image that binds to port 80 as a **non-root** user. I can run it locally (macOS Monterey, Docker Desktop 4.7.1) absolutely fine. When I try and run it as part of an ECS service on Fargate it fails as so: **Failed to bind to 0.0.0.0/0.0.0.0:80** **caused by SocketException: Permission denied** Fargate means I have to run the task in network mode `awsvpc` - not sure if that's related? Any views on what I'm doing wrong? The [best practices document](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/bestpracticesguide.pdf) suggests that I should be running as non-root (p.83) and that under awsvpc it's reasonable to expose port 80 (diagram on p.23). FWIW here's a mildly cut down version the JSON from my task definition: ``` { "taskDefinitionArn": "arn:aws:ecs:us-east-1:<ID>:task-definition/mything:2", "containerDefinitions": [ { "name": "mything", "image": "mything:latest", "cpu": 0, "memory": 1024, "portMappings": [ { "containerPort": 80, "hostPort": 80, "protocol": "tcp" } ], "essential": true, "environment": [] } ], "family": "mything", "executionRoleArn": "arn:aws:iam::<ID>:role/ecsTaskExecutionRole", "networkMode": "awsvpc", "revision": 2, "volumes": [], "status": "ACTIVE", "requiresAttributes": [ { "name": "com.amazonaws.ecs.capability.logging-driver.awslogs" }, { "name": "ecs.capability.execution-role-awslogs" }, { "name": "com.amazonaws.ecs.capability.ecr-auth" }, { "name": "com.amazonaws.ecs.capability.docker-remote-api.1.19" }, { "name": "ecs.capability.execution-role-ecr-pull" }, { "name": "com.amazonaws.ecs.capability.docker-remote-api.1.18" }, { "name": "ecs.capability.task-eni" } ], "placementConstraints": [], "compatibilities": [ "EC2", "FARGATE" ], "runtimePlatform": { "operatingSystemFamily": "LINUX" }, "requiresCompatibilities": [ "FARGATE" ], "cpu": "256", "memory": "1024", "tags": [] } ```
2
answers
0
votes
78
views
asked a month ago

Fargate timeout problem

Hi. I've got an unexpected error, I guess it's about timeout. Task takes time quite long. generally less than 1minute. There is no problem when it finish before 1 minute. But sometimes task takes more than 1 minute. Error occurs when it takes more than 1minute. Please see below. ``` [ec2-user@ip-000-00-0-00 ~]$ curl --location --request POST 'userid.ap-northeast-2.elb.amazonaws.com:port/service' -d "video.mp4" -o output.json -v Note: Unnecessary use of -X or --request, POST is already inferred. % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 172.31.74.35:5000... * Connected to loadbalancer.ap-northeast-2.elb.amazonaws.com (000.00.00.00) port 0000 (#0) > POST /service HTTP/1.1 > Host: userid.ap-northeast-2.elb.amazonaws.com:port > User-Agent: curl/7.79.1 > Accept: */* > Content-Length: 37 > Content-Type: application/x-www-form-urlencoded > } [37 bytes data] 100 37 0 0 0 37 0 0 --:--:-- 0:00:59 --:--:-- 0* Mark bundle as not supporting multiuse < HTTP/1.1 500 Internal Server Error < Date: Tue, 19 Apr 2022 01:45:23 GMT < Content-Type: application/octet-stream < Content-Length: 0 < Connection: keep-alive < Server: Python/3.7 aiohttp/3.7.4.post0 < 100 37 0 0 0 37 0 0 --:--:-- 0:01:00 --:--:-- 0 * Connection #0 to host loadbalancer.ap-northeast-2.elb.amazonaws.com left intactm left intact ``` With curl verbose option, I get 500 Internal Server Error at 0:00:59. How can I finish my task which takes more than 1minutes? I've tried - increasing Health check grace period for **ECS Service** - increasing idle timeout of **Load Balancer** - increasing timeout and interval of **Target group** - curl options (like keep-alive, max-time) My EC2 Instance - type : t2.micro - Amazon Linux My Service - Service type : REPLICA - Launch type : FARGATE My task in service - Network mode : awsvpc - Compatibilities : EC2, FARGATE - Requries compatibilities : FARGATE - EFS mounted - Docker Appreciate,
1
answers
0
votes
26
views
asked a month ago

ECS Exec error TargetNotConnectedException

I'm getting this error when I try to connect to my Fargate ECS container using ECS Exec feature: ``` An error occurred (TargetNotConnectedException) when calling the ExecuteCommand operation: The execute command failed due to an internal error. Try again later. ``` The task's role was missing the SSM permissions, I added them, but the error persists. Below is the output of the [amazon-ecs-exec-checker](https://github.com/aws-containers/amazon-ecs-exec-checker) tool: ``` Prerequisites for check-ecs-exec.sh v0.7 ------------------------------------------------------------- jq | OK (/usr/bin/jq) AWS CLI | OK (/usr/local/bin/aws) ------------------------------------------------------------- Prerequisites for the AWS CLI to use ECS Exec ------------------------------------------------------------- AWS CLI Version | OK (aws-cli/2.2.1 Python/3.8.8 Linux/5.13.0-39-generic exe/x86_64.ubuntu.20 prompt/off) Session Manager Plugin | OK (1.2.295.0) ------------------------------------------------------------- Checks on ECS task and other resources ------------------------------------------------------------- Region : us-west-2 Cluster: removed Task : removed ------------------------------------------------------------- Cluster Configuration | Audit Logging Not Configured Can I ExecuteCommand? | arn:aws:iam::removed ecs:ExecuteCommand: allowed ssm:StartSession denied?: allowed Task Status | RUNNING Launch Type | Fargate Platform Version | 1.4.0 Exec Enabled for Task | OK Container-Level Checks | ---------- Managed Agent Status ---------- 1. RUNNING for "api-staging" ---------- Init Process Enabled (api-staging:14) ---------- 1. Enabled - "api-staging" ---------- Read-Only Root Filesystem (api-staging:14) ---------- 1. Disabled - "api-staging" Task Role Permissions | arn:aws:iam::removed ssmmessages:CreateControlChannel: allowed ssmmessages:CreateDataChannel: allowed ssmmessages:OpenControlChannel: allowed ssmmessages:OpenDataChannel: allowed VPC Endpoints | Found existing endpoints for vpc-removed: - com.amazonaws.us-west-2.s3 SSM PrivateLink "com.amazonaws.us-west-2.ssmmessages" not found. You must ensure your task has proper outbound internet connectivity. Environment Variables | (api-staging:14) 1. container "api-staging" - AWS_ACCESS_KEY: not defined - AWS_ACCESS_KEY_ID: defined - AWS_SECRET_ACCESS_KEY: defined ``` The output has only green and yellow markers, no red ones, which means Exec should work. But it doesn't. Any ideas why?
1
answers
0
votes
25
views
asked a month ago

How do I set up an AWS Amplify project to query an existing AWS AppSync API?

Hi, I am new to AWS Amplify and would like guidance on how to send a query to an ***existing*** GraphQL API on AWS AppSync. I am unsure how to start as a lot of Amplify coverage creates a *new* AppSync API using the Amplify CLI. ## Objectives * Set up a Node.js project to work with an existing AWS AppSync API, using AWS Amplify as the GraphQL client. * Send a single query to an existing AWS AppSync API. The query lists game results from a DynamoDB table and is called `listGames` in my GraphQL schema. * I need to repeat the query in order to fetch all available database records that satisfy the query. This would mean adding results to an array/object until the `nextToken` is `null` (i.e. no more records can be found for the query). ## Context * This application is deployed in an Amazon ECS container using AWS Fargate. * The ECS service is fronted by an Application Load Balancer (ALB). * A leader board web page fetches game results through a `POST` request to the ALB's DNS name / URL and adds them to a HTML table. ## Notes * For now, API key is my authentication method. I would soon like to switch to a task IAM role in ECS. * The ECS deployment described in 'Context' is working but it sends `POST` requests without AWS libraries. It is my understanding that I would need to use an AWS library in order to use an IAM role for AppSync authentication (used as a [task IAM role in ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)). Please correct me if I am mistaken. I would greatly appreciate any help you can give me. Thank you for your time!
1
answers
1
votes
12
views
asked 2 months ago

Set cpu and memory requirements for a Fargate AWS Batch job from an AWS Cloudwatch event

I am trying to automate Fargate AWS Batch jobs by means of AWS Cloudwatch Events. So far, so good. I am trying to run the same job definition with different configurations. I am able to set the batch job as a cloudwatch event target. I have learned how to use the Constant (JSON text) configuration to set a parameter of the job. Thus, I can set the name parameter successfully and the job runs. However, I am not able to also set the memory and cpu settings in the Cloudwatch event. I would like to use a larger machine for a a bigger port such as Singapore, without changing the job definition. After all, at the moment it still uses the default vpcu and memory settings of the job definition. ``` { "Parameters": {"name":"wilhelmshaven"}, "ContainerOverrides": { "Command": ["upload_to_day.py", "-port_name","Ref::name"], "resourceRequirements": [ {"type": "MEMORY", "value": "4096"}, {"type": "VCPU", "value": "2"} ] } } ``` Does any one know how to set the Constant (JSON text) configuration or input transformer correctly? Edit: If I try the same thing using the AWS CLI, I can achieve what I would like to do. ``` aws batch submit-job \ --job-name "run-wilhelmshaven" \ --job-queue "arn:aws:batch:eu-central-1:123666072061:job-queue/upload-raw-to-day-vtexplorer" \ --job-definition "arn:aws:batch:eu-central-1:123666072061:job-definition/upload-to-day:2" \ --container-overrides '{"command": ["upload_to_day.py", "-port_name","wilhelmshaven"], "resourceRequirements": [{"value": "2", "type": "VCPU"}, {"value": "4096", "type": "MEMORY"}]}' ```
1
answers
0
votes
5
views
asked 2 months ago

Step Function manage/trigger Fargate task container override storage size?

Hi, We successfully trigger fargate task through step function, Something like below: * Is there anyway to define the ephemeral storage size, cpu and memory within the container override section below? * Now, when we create fargate task, we set desire_count=0, min_count=0 and we have 0 instance always on (which is good, we don't want to always on instance). But how will max_count be treated? When we have more than max_count of concurrent step function running, will some step just hanged and waiting for the finishment of certain fargate task? Or throwing error? Thank you , in advance. "UncompressGranuleECS": { "Parameters": { "LaunchType": "FARGATE", "Cluster": "${module.cluster.ecs_cluster_name}", "TaskDefinition": "${local.fargateTaskARN}", "NetworkConfiguration": { "AwsvpcConfiguration": { "Subnets": ${jsonencode(var.subnet_ids)}, "AssignPublicIp": "DISABLED" } }, "Overrides": { "ContainerOverrides": [ { "Name":"dyen-cumulus-uncompress_granule-fargate", "Command": ["java", "-Xms7500M", "-Xmx7500M", "-jar", "/home/dockeruser/build/libs/my-jarfile.jar"], "Environment":[ { "Name":"region", "Value":"us-west-2" }, { "Name":"TASK_TOKEN", "Value.$":"$$.Task.Token" }, { "Name":"CMA_MESSAGE", "Value":"myjson:[]" } ] } ] } }, "Type": "Task", "HeartbeatSeconds": 1800, "Resource": "arn:aws:states:::ecs:runTask.waitForTaskToken", "Retry": [ { "ErrorEquals": [ "States.ALL" ], "IntervalSeconds": 10, "MaxAttempts": 0 } ], "Catch": [ { "ErrorEquals": [ "States.ALL" ], "ResultPath": "$.exception", "Next": "failureStep" } ], "Next": "MissingStep" },
2
answers
0
votes
7
views
asked 3 months ago

Step functions pass input into Fargate instance :

by looking at this AWS document: https://docs.aws.amazon.com/step-functions/latest/dg/sample-project-container-task-notification.html step functions can totally instantiate/manage fargate or ECS Task. Speaking about fargate * the example put fargate as first step. suppose fargate is the 2nd step, can we get the output message from first step (larger than 8K) into fargate task through either .sync or .waitForTaskToken model? Instead of passing input parameters through fargate containerOverride's command or commands? * If above is possible, does the code inside fargate suppose to do something like : GetActivityTaskResult getActivityTaskResult = client.getActivityTask(new GetActivityTaskRequest().withActivityArn(stringActivityArn)); String taskToken = getActivityTaskResult.getTaskToken(); String taskInput = getActivityTaskResult.getInput(); * In this step function instantiate fargate model (.sync or .waitForTaskToken), does fargate instances gets created each time when step functions "calls" it? That is, we actually would like to set desire_count and min count both to zero and forget about scaling alarms or metrics. If above is true, does it respect the max_count? I guess cost-wise, it is fine with us because how many concurrent fargate running does not matter anymore. Cost is based on usage. * is ECS or fargate able to return output values to the calling step function? that is, using sendSucess or some other api to send output back to step function for next step to use (become the input of next step)?
1
answers
0
votes
62
views
asked 3 months ago

HTTP API GW + API VPC Link + Cloudmap + Fargate - How does it load balance

I am using an infrastructure setup as described in the title. This setup is also somewhat shown in this picture: https://d2908q01vomqb2.cloudfront.net/1b6453892473a467d07372d45eb05abc2031647a/2021/02/04/5-CloudMap-example.png In the official AWS blog here: https://aws.amazon.com/blogs/compute/configuring-private-integrations-with-amazon-api-gateway-http-apis/ the following is stated about using such setup: > As AWS Cloud Map provides client-side service discovery, you can replace the load balancer with a service registry. Now, connections are routed directly to backend resources, instead of being proxied. This involves fewer components, making deployments safer and with less management, and reducing complexity. My question is simple: What load balancing algorithm does HTTP API GW use when distributing traffic to resources (the Fargate tasks) registered in a service registry? Is it round-robin just as it is with ALB? Only thing I was able to find is this: > For integrations with AWS Cloud Map, API Gateway uses DiscoverInstances to identify resources. You can use query parameters to target specific resources. The registered resources' attributes must include IP addresses and ports. API Gateway distributes requests across healthy resources that are returned from DiscoverInstances. https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-private.html#http-api-develop-integrations-private-Cloud-Map
2
answers
0
votes
30
views
asked 3 months ago

Overriding Hostname on ECS Fargate

Hello, I am setting up a Yellowfin [deployment](https://wiki.yellowfinbi.com/display/yfcurrent/Install+in+a+Container) using their stock app-only [image](https://hub.docker.com/r/yellowfinbi/yellowfin-app-only) on ECS Fargate. I was able to set up a test cluster for my team to experiment with. Yellowfin requires a license to use their software. To issue a license, Yellowfin needs to know the hostname of the underlying platform it runs on. Yellowfin can provide wildcard licenses that match on a standard prefix or suffix. Currently, we are using a development license that matches on the default hostname that our test environment's Fargate task is assigned. The default hostname seems to be of the form <32-character alphanumeric string>-<10-digit number> where the former is the running task's ID and the latter is an ID of some other related AWS resource (the task definition? the cluster?) that I could not identify. Although this 10-digit number stays constant if new tasks are run, it does not seem like a good strategy to base the real Yellowfin license off of it. I would like to override the hostname of a Fargate task when launching the container to include a common prefix (e.g., "myorg-yfbi-") to make it simple to request a wildcard license for actual use. If possible, I would like to avoid building my own image or migrating to use another AWS service. Is there a standard way to override the hostname for a Fargate service by solely updating the task definition? Would overriding the entrypoint be a viable option? Is there another way to set hostname in Fargate that I am not aware of? Thank you for any guidance you can provide. Happy to provide more information if it helps.
1
answers
0
votes
32
views
asked 3 months ago

CDK v1: Deploy RDS SQL Server and use credential in a connection string for fargate docker instance

I have been trying to find an answer in documentation, github, here and the old forums, but I fail to find the answer to my question. In my CDK v1 (python) I create a RDS instance of SQL Server and set credentials with aws_rds.Cerednetials.from_generated_secret(), but when I later on want to provide environment/sercrets values to the docker container I want to run in fargate I have the following environment variable that I need to be set: DB_CONNECTION_STRING, which has the following syntax: Server=<somehost.aws.com>,144;Database=<databasename>; User Id=<databaseuser>;Password=<databasepassword> All the examples I have seen uses multiple variables like DB_USER/DB_PASS/DB_HOST and then you can easily set those with help of secret_value, but there is no example on generating a connection string. How do you solve this? I took a look at aws glue, but it didn't feel like the right optionand I'm not too keen on making a dockerfile to try to pull the official docker image and then create a kind of a wrapper to have environment/sercret variables and then a script that builds up the connection string and sets it before calling the start script for the application (this has other downsides). The reason why I'm not using the CDK v2 is that the current version seems to be broken when you create a new project in WSL (seems to think it's pure ms-windows and fails to create a number of files needed). Thanks in advance for any reply.
1
answers
0
votes
13
views
asked 4 months ago

AWS NLB sends 120 byte of unknown TCP Keep-alive packet to clients

We have an IoT device that connects to our MQTT broker behind the NLB. We are keeping the connection between IoT device and broker by utilising MQTT Keep Alive time and brokers heartbeat intervals. Our IoT device sleeps most of the time. It wakes up in the following situations. Whenever it wants to send PINQREST(every 340s -MQTT Keep Alive time) sends it to the broker. Other microservices publish some data, and brokers send that information to IoT devices. Our objective is to sleep the IoT device as much as possible and maintain the connection to save the battery. ***Problem: ***Normally, this particular IoT device sleeps most of the time. Our objective is to keep it sleeping as much as possible while maintaining a connection between IoT Device and the MQTT broker. The problem is that IoT Device continuously wakes up every 20s whenever the broker sends some downstream data to the IoT device. This usually happens whenever IoT Device receives downstream data from a broker. Based on our vendor's packet analysis, we found that NLB sends 120 bytes of TCP Keep-alive packets to IoT devices every 20s right after the broker publishes some downstream data. This is entirely sent by NLB and not by the broker. ***Only happen in TLS : ***We found that this happens if we use TLS(8883) in NLB and terminate the TLS in NLB. If we remove the TLS, add the listener on a non-secure port (1883), and forward the traffic to Target's non-secure port, things are working as expected, and there are no 20s wake-up or keep-alive packet sent by NLB every 20s. We also tested the same setup with CLB in an SSL port. It works without any problem and does not send a keep-alive to the client (IoT device). We have removed the TLS and opened the non-secure port as a temporary workaround. Why does NLB send keep-alive packets every 20s if we use TLS ? is this an intended behaviour of NLB? Any idea how we could resolve it? ***The overview of the cloud setup: *** * MQTT broker runs in ECS Fargate * Multi-AZ * Broker in a private subnet NLB is in between * Client (IoT device) and Target(MQTT Broker) * NLB idle time keep resetting by two things * Keep alive time sent by Client(IoT device) every * 340s Heartbeat time published by Target (MQTT Broker)every 340s Connection remains open NLB offload the TLS in port 8883 and forward the traffic to target port 1883
1
answers
0
votes
35
views
asked 4 months ago

ECS Fargate Windows documentation unclear

Hey there! I've been attempting to use ECS Fargate with Windows containers and am running into some unclear documentation. It seems in the documentation, platform version 1.0.0 is the latest given to Windows, and 1.4.0 is the latest given to Linux containers. Now, there are certain task definition's that are supposedly available to Windows according to the documentation but turn out not to be. I'll list this here in the hopes that this could be cleared up by the ECS Fargate team. 1. ephemeralStorage - Here it's shown the ephemeralStorage is able to adjusted on Windows Fargate https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-storage.html and here https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-ephemeralstorage.html, however in the API doc it says this is not available for Windows https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html I believe that 1.0.0 does not actually support this as I've been trying to run a large unreal engine docker image (151gb uncompressed) and keep getting "CannotPullContainer: failed to extract layer" errors. 2. environmentFiles - At these docs https://docs.aws.amazon.com/AmazonECS/latest/developerguide/taskdef-envfiles.html it is shown that the environmentFiles field should work for Windows 1.0.0 but whenever I try to include this field in my Windows task I get a PlatformTaskDefinitionIncompatibilityException which makes me suspect it is not actually implemented. You can follow this issue I made here https://github.com/aws/containers-roadmap/issues/1626 I suspect there are probably more discrepancies between the documentation and the implementation for Windows Fargate, and I suspect not many people are running Windows containers on Fargate, but I do feel this should be rectified! I'll continue adding to this list if anything more comes up. I'm going to attempt to instead run a cluster on an EC2 instance and hopefully the process will be a bit smoother.
1
answers
0
votes
10
views
asked 4 months ago

InvalidParameterValue Error in docker compose deploy

I am trying to deploy two docker containers via docker compose to ECS. This already worked before. Now I'm getting the following error: > **DatabasemongoService TaskFailedToStart: Unexpected EC2 error while attempting to tag the network interface: InvalidParameterValue** I tried deleting all resources in my account and recreating a default VPC which the docker compose uses to deploy. I tried tagging the network interface via the management web UI, which worked without troubles. I found this Documentation about EC2 Error Codes: https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html > **InvalidParameterValue**: A value specified in a parameter is not valid, is unsupported, or cannot be used. Ensure that you specify a resource by using its full ID. The returned message provides an explanation of the error value. I don't get any output besides the error above to put my search on a new trail. Also there is this entry talking about the error: > InvalidNetworkInterface.InUse: The specified interface is currently in use and cannot be deleted or attached to another instance. Ensure that you have detached the network interface first. If a network interface is in use, you may also receive the **InvalidParameterValue** error. As the compose CLI handles creation and deletion of network interfaces automatically, I assume this is not the problem. Below is my docker-compose.yaml file. I start it via `docker compose --env-file=./config/.env.development up` in the ecs context. ``` version: '3' services: feathers: image: xxx build: context: ./app args: - BUILD_MODE=${MODE_ENV:-development} working_dir: /app container_name: 'feather-container' ports: - ${BE_PORT}:${BE_PORT} environment: - MODE=${MODE_ENV:-development} depends_on: - database-mongo networks: - backend env_file: - ./config/.env.${MODE_ENV} database-mongo: image: yyy build: context: ./database container_name: 'mongo-container' command: mongod --port ${MONGO_PORT} --bind_ip_all environment: - MONGO_INITDB_DATABASE=${MONGO_DATABASE} - MONGO_INITDB_ROOT_USERNAME=${MONGO_USERNAME} - MONGO_INITDB_ROOT_PASSWORD=${MONGO_PASSWORD} ports: - ${MONGO_PORT}:${MONGO_PORT} volumes: - mongo-data:/data networks: - backend networks: backend: name: be-network volumes: mongo-data: ``` Any help, idea, or point in the right direction is very appreciated!
0
answers
0
votes
12
views
asked 5 months ago
  • 1
  • 90 / page