Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ECS Fargate Service: service not created because of alarm based rollback #26307

Closed
srshkmr opened this issue Jul 10, 2023 · 7 comments · Fixed by #26317
Closed

ECS Fargate Service: service not created because of alarm based rollback #26307

srshkmr opened this issue Jul 10, 2023 · 7 comments · Fixed by #26317
Labels
@aws-cdk/aws-ecs Related to Amazon Elastic Container bug This issue is a bug. p1

Comments

@srshkmr
Copy link
Contributor

srshkmr commented Jul 10, 2023

Describe the bug

During the deployment process with the same code which was working previously is returning the following error.

4:43:04 pm | CREATE_FAILED        | AWS::ECS::Service                               | xxxx
Resource handler returned message: "Invalid request provided: CreateService error: Alarm based rollback feature is only supported with ECS deployment controller. Update t
o ECS deployment controller and try again. (Service: AmazonECS; Status Code: 400; Error Code: InvalidParameterException; Request ID: xxx;
Proxy: null)" (RequestToken: xxx, HandlerErrorCode: InvalidRequest)

The following is my ECS deployment group

const ecsDeploymentGroup = new codeDeploy.EcsDeploymentGroup(this, 'ecsDeploymentGroup', {
      application: ecsApplication,
      deploymentGroupName: props.ECSTaskFamilyName,
      deploymentConfig,
      alarms: ecsServiceAlarms.alarms,
      service: ecsBlueGreenService.ecsService,
      blueGreenDeploymentConfig: {
        blueTargetGroup: ecsBlueGreenService.blueTargetGroup,
        greenTargetGroup: ecsBlueGreenService.greenTargetGroup,
        listener: ecsBlueGreenService.albProdListener,
        testListener: ecsBlueGreenService.albHttpsListener,
        terminationWaitTime: Duration.minutes(10),
      },
      autoRollback: {
        stoppedDeployment: true,
      }
    });

The application is deployed using Code deploy, So the deployment controller is set as CODE_DEPLOY

this.ecsService = new ecs.FargateService(this, 'FargateService', {
      cluster: props.cluster!,
      desiredCount: 1,
      taskDefinition,
      minHealthyPercent: 100,
      maxHealthyPercent: 200,
      enableExecuteCommand: true,
      deploymentController: {
        type: DeploymentControllerType.CODE_DEPLOY
      },
      healthCheckGracePeriod: Duration.seconds(60)
    });

Expected Behavior

ECS Cluster gets deployed successfully

Current Behavior

ECS creation failed

Reproduction Steps

Use the code in the bug description

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.87.0

Framework Version

No response

Node.js Version

v18.15.0

OS

MacOS 14.0

Language

Typescript

Language Version

5.1.6

Other information

No response

@srshkmr srshkmr added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Jul 10, 2023
@github-actions github-actions bot added the @aws-cdk/aws-ecs Related to Amazon Elastic Container label Jul 10, 2023
@peterwoodworth
Copy link
Contributor

During the deployment process with the same code which was working previously is returning the following error.

Could you share the difference in output between when this was working and when this was not? (i.e. cdk diff) - Additionally, when did this stop working, which version did you upgrade from to start encountering this error?

@peterwoodworth peterwoodworth added p1 response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. and removed needs-triage This issue or PR still needs to be triaged. labels Jul 10, 2023
@peterwoodworth
Copy link
Contributor

Though this just looks like the service rejecting the configuration given your deployment controller type, but I am pretty sure that auto rollback should be able to be selected for the codedeploy controller type

@github-actions github-actions bot removed the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label Jul 10, 2023
@jiem-ying
Copy link

jiem-ying commented Jul 11, 2023

Hi +1 to this issue.

Confirmed from ECS side that if using Code_Deploy type, the CreateService API would fail with Validation when "CODE_DEPLOY" and "DeploymentConfiguration.Alarm" combination detected:

{
  ...
  "DeploymentController": {
    "Type": "CODE_DEPLOY"
  },
  ...
  "DeploymentConfiguration": {
    "Alarms": {
      "AlarmNames": [],
      "Enable": "false",
      "Rollback": "false"
    },
    ...
  },
 ...
}

And as ECS is designed that the DeploymentConfiguration.Alarm can only used by default controller AKA "ECS deployment controller". https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-alarm-failure.html

I understand this new change is from this release #25840

Given it is ECS service API limitation, the L2 construct should have a judgement that if "DeploymentController.Type" is "CODE_DEPLOY", do not explicitly specify the DeploymentConfiguration.Alarms.

Currently the workaround is using Escape Hatches then override deletion:
CfnService.addPropertyDeletionOverride('DeploymentConfiguration.Alarms');

Let me know if you need more clarifications.

@srshkmr
Copy link
Contributor Author

srshkmr commented Jul 11, 2023

Could you share the difference in output between when this was working and when this was not? (i.e. cdk diff) - Additionally, when did this stop working, which version did you upgrade from to start encountering this error?

I upgraded from 2.81.0 to 2.87.0, That's when this issue started occuring, Weird thing is even after downgrading the CDK version to 2.81 I am getting the same error. It was working fine on Thursday last week

@tam0ri
Copy link
Contributor

tam0ri commented Jul 11, 2023

When deploymentAlarms property is defined explicitly, CDK checks deploymentController is ECS or not.

if (props.deploymentAlarms
&& deploymentController
&& deploymentController.type !== DeploymentControllerType.ECS) {
throw new Error('Deployment alarms requires the ECS deployment controller.');
}

On the other hand, currently CDK never validates deploymentController property for the default alarms settings.

} else if (this.deploymentAlarmsAvailableInRegion()) {
this.deploymentAlarms = {
alarmNames: [],
enable: false,
rollback: false,
};
}

I just submitted PR to fix this.

@peterwoodworth
Copy link
Contributor

Thanks a bunch @tam0ri!

@mergify mergify bot closed this as completed in #26317 Jul 12, 2023
mergify bot pushed a commit that referenced this issue Jul 12, 2023
… CODE_DEPLOY and EXTERNAL deployment controller (#26317)

From #25840, ECS L2 construct sets the default configuration for the `CfnService.deploymentConfiguration.alarms` property to:
```
alarmNames: [],
rollback: false,
enable: false,
```

However, alarm based rollback feature is only supported for ECS services that use the rolling update (ECS) deployment controller.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-alarm-failure.html

Due to this limitation, when deploymentController is set to CODE_DEPLOY or EXTERNAL, creation for the service will fail by conflict with `deploymentConfiguration.alarms` property.

This PR solves the issue by skipping to set default configuration for the `CfnService.deploymentConfiguration.alarms` property for CODE_DEPLOY and EXTERNAL deployment controller.

Closes #26307

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

bmoffatt pushed a commit to bmoffatt/aws-cdk that referenced this issue Jul 29, 2023
… CODE_DEPLOY and EXTERNAL deployment controller (aws#26317)

From aws#25840, ECS L2 construct sets the default configuration for the `CfnService.deploymentConfiguration.alarms` property to:
```
alarmNames: [],
rollback: false,
enable: false,
```

However, alarm based rollback feature is only supported for ECS services that use the rolling update (ECS) deployment controller.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-alarm-failure.html

Due to this limitation, when deploymentController is set to CODE_DEPLOY or EXTERNAL, creation for the service will fail by conflict with `deploymentConfiguration.alarms` property.

This PR solves the issue by skipping to set default configuration for the `CfnService.deploymentConfiguration.alarms` property for CODE_DEPLOY and EXTERNAL deployment controller.

Closes aws#26307

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-ecs Related to Amazon Elastic Container bug This issue is a bug. p1
Projects
None yet
4 participants