Cloudformation-coverage-roadmap: AWS::CodeDeploy::DeploymentGroup-DeploymentType Support BLUE_GREEN for ECS/Fargate for CICD use cases and Codepipeline integration

[zzenonn]

1. Title -> AWS::CodeDeploy::DeploymentGroup-DeploymentType
2. Scope of request -> AWS::CodeDeploy::DeploymentGroup-DeploymentType supports BLUE_GREEN for Lambda but not for ECS/Fargate.
3. Expected behavior -> BlueGreen deployments for ECS/Fargate services.
4. Links to existing API doc (optional)

Announcement: https://aws.amazon.com/blogs/devops/use-aws-codedeploy-to-implement-blue-green-deployments-for-aws-fargate-and-amazon-ecs/
Announcement: https://aws.amazon.com/about-aws/whats-new/2020/05/aws-cloudformation-now-supports-blue-green-deployments-for-amazon-ecs/

1. Category tag (optional) -> Compute, Developer Tools
2. Any additional context (optional) -> Similar request as #37 however #37 was closed because of the announcement referenced above. The use case I want to reference is to explicitly have a BLUE_GREEN deployment type for ECS as a CodeDeploy::DeploymentGroup-DeploymentType to integrate with CICD (e.g. Codepipeline integration)

[sethstone]

I'm looking for the same capability as @zzenonn.

I'm able to build out all necessary resources for a BlueGreen ECS CICD pipeline using Cloudformation except I must create the Deployment Group using the CLI. I've attempted to derive the correct syntax from a working CLI command (see below), but when I try to run it as part of a stack deploy I get: "Encountered unsupported property BlueGreenDeploymentConfiguration".

 DeploymentGroup:
    Type: AWS::CodeDeploy::DeploymentGroup
    Properties: 
      ApplicationName: !Ref CodeDeployApplication
      AutoRollbackConfiguration: 
        Enabled: true
        Events:
          - DEPLOYMENT_FAILURE
      BlueGreenDeploymentConfiguration: 
        DeploymentReadyOption: 
          ActionOnTimeout: CONTINUE_DEPLOYMENT
          WaitTimeInMinutes: 0
        TerminateBlueInstancesOnDeploymentSuccess:
          Action: TERMINATE
          TerminationWaitTimeInMinutes: 5
      DeploymentConfigName: CodeDeployDefault.ECSAllAtOnce
      DeploymentGroupName: !Ref CodeDeployDeploymentGroupName
      DeploymentStyle: 
        DeploymentOption: WITH_TRAFFIC_CONTROL
        DeploymentType: BLUE_GREEN
      LoadBalancerInfo: 
        TargetGroupPairInfoList: 
          TargetGroups:
            - Name: !Sub ${ProjectPrefix}-tg1
            - Name: !Sub ${ProjectPrefix}-tg2
          ProdTrafficRoute: 
            ListenerArns: !Ref ALBProductionListener
      ServiceRoleArn: !GetAtt CodeDeployServiceRole.Arn
      ECSServices:
        - ServiceName: !Sub ${ProjectPrefix}-service
        - ClusterName: !Sub ${ProjectPrefix}-ecs-fargate-cluster

[hupe1980]

I created such a setup with custom resources and aws-cdk. The challenge was that the service had to be available when a DeploymentGroup was created, but that future control over updates to the taskdefinition should be done with CodeDeploy.

You can see an example here:
https://github.com/cloudcomponents/cdk-constructs/blob/master/examples/blue-green-container-deployment-example/src/blue-green-container-deployment-stack.ts

[cappellaiomatto]

Yep, I stumbled upon this. The accepted JSON via CLI cannot be converted to a working cloudformation template.
The (puzzling) error messages are either:
*) "Property LoadBalancerInfo cannot be specified"
or
*) "ec2TagFilters can not be specified"
Looking forward to a solution

[caJaeger]

Was sent by AWS support to add pressure to this open issue. This is very much needed.

[jtaylormayfield]

I am also looking at implementing a set of CodePipeline templates in CloudFormation that will require some manual process or extra scripting to accomplish this part of the automation. Please update this service.

[thomasstep]

I am also here to add pressure to this.

[benbridts]

The best way to add pressure is to use the 👍 on the original issue (and/or reach out to your TAM or Account Team if you have/know them).
That way it's actually measurable by AWS

[chathurilanchana]

Really looking forward for a solution to this issue. We share load balancer between multiple services, and use imports and nested stacks extensively. So we cant really get the benefits of Blue green cloudformation deploys with its current limitations.

[pablods90]

Hello,

This feature is really required. There are limitations in the current scenario, that make the solution not usable for relatively complex scenarios.

Also, there are two concerning issues:

• There are (apparently) random failures and inconsistencies when referencing parameters from the Task Definition or the Task set.
• Capacity Providers are not currently supported via CloudFormation for the Task Set resource. This is unfortunate, as the Capacity Provider Strategy parameter is present in the API call. This limits the option, as many use cases require using Capacity Providers.

Thanks!

[mbidewell]

Would like this as well. Unless I am misreading the documentation, its seems that, unlike an appspec CodeDeploy deployment which you specify the new details only, the CFN method requires the full specification of both the Blue and Green setups. This makes it far more complex than an Appspec deploy.

[yogeshjoshi]

There are couple of limitations, which preventing us to choose Blue Green for our ECS Stack.
We have LB Defined in Infra Package and shares between services. We would need Import Resources as it's basic to choose Cloudformation Implementation.

• Declaring output values or importing values from other stacks is not currently supported for templates defining blue/green ECS deployments.
• You cannot use the AWS::CodeDeploy::BlueGreen hook in a template that includes nested stack resources.
• You cannot use the AWS::CodeDeploy::BlueGreen hook in a nested stack.

Are there plans / work in progress to handle these use cases?

[rohits-spec]

Please use the following:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green.html

[yogeshjoshi]

@rohits-spec Document still says Importing values and importing from other stack is not supported and nested stack problem still persist.

We are following this problem from so many issues but always issue marked as closed, do you want to create new issue for same or should we reopen this.

[zzenonn]

@rohits-spec I wrote this issue referencing that exact feature. The feature closed #37 but I don't think it closes this one. Specifically, this covers several other use cases. If needed, we can create a new issue, but a lot of the feedback is documented here.

[rohits-spec]

Reopening this issue to address various usecases mentioned in this issue.

[Nestor10]

@rohits-spec noticed this is still listed as shipped in the coverage road map. Is this complete but waiting for release?