-
Notifications
You must be signed in to change notification settings - Fork 255
Pre-created cluster is not found #1084
Comments
Can you please check CloudFormation web UI when deploying with Makes me wonder if you get the deployment to run in the expected eu-west-1 region by |
should help to diagnose #1084 #1056 Signed-off-by: Nicolas De Loof <[email protected]>
According to CF event log, the first error is in WebService resource - "Resource creation cancelled". It fails almost immediately. Again, deploying WebService have ARN with a correct region 'arn:aws:ecs:eu-west-1:909329722030:service/monty-ecs-cluster/ecs-bug-1084-WebService-IrVAGUPSOd3X', nothing suspicious. Full logs:
|
Thanks for digging into this. Can you please confirm you checked CloudFormation deployment ran by I hardly can imagine how |
Please can you also check in the CloudFormation "model" UI that the uploaded template has the expected cluster ARN set for (failing) service? |
Checked the UI. Template (Stack -> Template tab) contains the same CloudFormation definition as Maybe the problem is with setting up docker context. I tried with the following variants:
All variants do not work. I think this bug can be related with #1056 |
should help to diagnose #1084 #1056 Signed-off-by: Nicolas De Loof <[email protected]>
I've also ran into this issue. I am also experiencing this weird discrepancy between CloudFormation and Docker compose. Taking the output from The reason the stack fails to create using To further this CloudFormation says in the events section The cluster is definitely there and this is not an issue with the generated CloudFormation template, is docker compose making a background request to check if the cluster exists while the CloudFormation is in the middle of running? (and this request subsequently fails for some reason) I've tried running this with --debug enabled as well but nothing seems to show up during the stack creation phase. AND to throw in some even more random stuff, when you run Hope this helps. TL;DR the CloudFormation template is fine, docker compose is manually telling CloudFormation to cancel the stack midway through |
compose up just invoke the cloudformation API to apply the converted cloudformation template, it does not query AWS API after this step. Also, "ClusterNotFoundException" is an AWS API error (as demonstrated by the Java-style of this error), so it seems there's a race condition happening on AWS-side applying CloudFormation template, where some resource require the cluster to be up but this one is not yet set. Can you please check the AWS web console and collect the list of Cloudformation events, so we know the first event to happend that would explain this deployment failure? |
Here is my output from the AWS cli, this is the most detailed logs that I can get. You can see at But why does setting this as a deamon work? What difference does |
running with -d we don't wath CloudFormation events to report deployment progress. |
I've also ran into this issue. [+] Running 8/10 Taking the output from docker compose convert and running it directly in CloudFormation works fine. |
Also running into this now, would be nice if this could be solved Running version 1.0.12 of the Compose CLI. usecase: I want to run the ecs apps on FARGATE_SPOT to save money. |
Also running into this issue:
Using |
I also ran into this issue. I have provided the existing ECS Cluster, VPC and Load balancer as input in the docker-compose. Ran the docker compose up command and the docker compose started creating CloudFormation Stack then the CFN stack creation failed. Upon checking the CloudTrail API calls, I noticed that DescribeServices API call made by docker cli failed with ClientException and the error 'Cluster not found.' From the DescribeServices API call, I observed that docker cli has passed the cluster as empty in the request parameters. Please find the below snippet.
It would be great if the docker cli can pass the cluster name as well in the DescribeServices API. However, I was able to deploy the docker compose to ECS in the us-east-1 region successfully. It might be possible that ECS is picking cluster name in the us-east-1. The issue could be from ECS Side as well. |
@SatyaHarish9 could you please use internal note: relevant code here https://github.com/docker/compose-cli/blob/main/ecs/cloudformation.go#L244 |
Hello @ndeloof I have used However, after docker cli initiating the CloudFormation Stack creation, it was trying to describe service using [] DescribeServices - Request Parameters - https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeServices.html#API_DescribeServices_RequestParameters From the above document, ECS assumes the default cluster if the cluster is not passed in request parameters. This parameter is required if the service or services described were launched in any cluster other than the default cluster. |
@ndeloof
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Reproduced original bug with the following changes:
Passing a detached flag However, it is not always appropriate to use detached mode - you should check the cluster and services status via API calls to ECS which is not why you want to use the cloud-abstract |
This issue has been automatically marked as not stale anymore due to the recent activity. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Tried with latest Docker version, still the same problem.
|
This issue has been automatically marked as not stale anymore due to the recent activity. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
The latest Docker 20.10 has the exact same problem:
|
2+ years this issue has been open with absolutely nothing being done about it. This was such a pressing issue for my team that we had to stop using this at all. I have no idea why the decision was made to add this as a feature, then not maintain it at all. This is also not the only issue like this, it seems anything related to the docker compose - aws/ecs is just left behind. |
This issue has been automatically marked as not stale anymore due to the recent activity. |
bumping this for attention. |
FYI I've opened a patch for this via #2269, but given the imminent EOL (#2258, docker/compose-ecs#7), it will (most likely) not be merged in this repository, so I've opened docker/compose-ecs#19 to track this issue, and docker/compose-ecs#20 to patch it in the new repo. |
Description
docker compose up fails with "ClusterNotFoundException: Cluster not found" when an ECS cluster is precreated.
Steps to reproduce the issue:
x-aws-*
variables. Check a simple compose file.docker compose --context myecs up -D
Describe the results you received:
Got the 'ClusterNotFoundException: Cluster not found.'
The output of
docker compose --context myecs up -D
:Additional facts:
Cluster definitely exists that can be verified by AWS GUI or
aws --profile aroot --region eu-west-1 ecs list-clusters
If a cluster was not pre-created, compose up succeeds.
It does not matter if ECS cluster was created by TerraForm or by GUI
Applying CloudFormation script created by convert succeeds, cluster is created:
So that means that a failing check was performed in the compose cli. Did not try to launch compose cli after applying CloudFormation though.
Describe the results you expected:
Expected that the app is up.
Additional information you deem important (e.g. issue happens only occasionally):
Output of
docker version
:Output of
docker context show
:You can also run
docker context inspect context-name
to give us more details but don't forget to remove sensitive content.Output of
docker info
:Additional environment details (AWS ECS, Azure ACI, local, etc.):
AWS profile is set up with all IAM permissions.
Resources are in eu-west-1.
AWS CLI version:
aws-cli/2.1.13 Python/3.9.1 Darwin/19.6.0 source/x86_64 prompt/off
The text was updated successfully, but these errors were encountered: