Aws-cdk: Blue Green ECS Deployment

[arvindshekar07]

Hi ,
I am referencing this video from the 2018 Re:Invent .https://www.youtube.com/watch?v=01ewawuL-IY.

1. I am struggling to get and blue green deployment setup where I have Infrastructure stack with fargate and another stack with multiple microservice on which run on fargate.

2. Can some examples be provided on how to do blue green deployment with ECR as an source?
   The confusing part here is how to pass the docker image tag, target and task to the cdk pipeline or as a cloudformtation template to support Blue/Green Deployment.

3. It makes sense if the stack name defaults to the TS class name but then what is the use of stack name when its being provided in the cloudformtation service.

4. How to access other stacks without having to do an TS way of logical inheritance?

5. Are there any examples where based on aws accounts i can put a specific VPC or provision differently ? I know there is a conditional function for TS but I didnt find a good way to write condition based on aws account .

6. Is there any examples on how to append the export functionality with the parameters provided to CFT at compile time? I get an TS error when I try to an optional variable to the export name @

[rix0rrr]

Blue/Green deployment for ECS is a supported feature, but I'm not sure it's available through CloudFormation yet, and we definitely don't have support for it in the CDK as of yet. You will have to set it up by hand for now.

It makes sense if the stack name defaults to the TS class name but then what is the use of stack name when its being provided in the cloudformtation service.

It's not the class name, it's the second parameter that you pass to stack:

new MyStack(app, "ThisIsTheName");

CloudFormation orients itself around the concept of "stacks" and stacks must have a name to identify them.

How to access other stacks without having to do an TS way of logical inheritance?

Classes (which you would combine through inheritance) give you a "kind of stack". You instantiate a class to get an object, which represents a real Stack. For example:

class MyStack extends cdk.Stack {
   // ...
}

// MyStack is not deployable yet. It might take parameters that we haven't filled in.
// To make it real, let's instantiate it:
new MyStack(app, 'Stack1', { flavor: 'banana' });
new MyStack(app, 'Stack2, { flavor: 'raspberry' });

// In fact, I can even instantiate multiple CloudFormation stacks from the same class!
// But they must have different names. 

This is a long way to say, once you have an object you can access attributes of it and pass those around, potentially as input arguments to another stack. It works just the same as in a regular programming language.

Here's an example of defining an S3 bucket in one stack, and using it in another:

https://github.com/awslabs/aws-cdk/blob/master/packages/%40aws-cdk/aws-s3/test/integ.bucket-sharing.lit.ts#L42

Are there any examples where based on aws accounts i can put a specific VPC or provision differently ?

I wouldn't recommend you put ifs with literal accounts in your source code. For example, it seems better to tag your VPC and use VpcNetwork.importFromContext with the tags member. But if you must:

class MyStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    if (this.requireAccountId() !== '12345678') {
      throw new Error('You must deploy this in account 12345678!');
    }
  }
}

Is there any examples on how to append the export functionality with the parameters provided to CFT at compile time? I get an TS error when I try to an optional variable to the export name @

I'm sorry, I do not understand the question. Could you explain a bit more?

[arvindshekar07]

@rix0rrr thanks for your quick response.

It's not the class name, it's the second parameter that you pass to stack:

new MyStack(app, "ThisIsTheName");

In my use case I have the same stack being used for UAT and PROD . In this case what would you suggest?

• Appending the "ThisIsTheName"?
• Or pass a variable as parameter?
  -Any other solution

if (this.requireAccountId()
In the code you mentioned how do you get requireAccountId?

class MyStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    if (this.requireAccountId() !== '12345678') {
      throw new Error('You must deploy this in account 12345678!');
    }
  }
}

Is there any examples on how to append the export functionality with the parameters provided to CFT at compile time? I get an TS error when I try to an optional variable to the export name @

I'm sorry, I do not understand the question. Could you explain a bit more?

I am sorry for the lack of explanation. Imagine a stack for UAT and PROD in the same account .
I have one stack say InfastructureStack that has all the long term resources mentioned (eg ALB,fargate S3 RDS ). I have another stack called the ServiceStack that tell what ECR task and service that needs to be created in fargate and port shift them all the request to the new ones.
Now if InfastructureStack is been referenced by the ServiceStack how would it distinguish between UAT and PROD .
The one solution I had was to check exported resources in the parent stack and see if I can append to the end with the environment information . But was not able to do that as parameter is an optional var and export function can not take name that are optional .

I am able to do the same process via clouldformation YML definition a which is kindof a Blue Green deployment .
This is an attempt to do this via CDK .

[SoManyHs]

Related: https://github.com/awslabs/aws-cdk/issues/2056

[skinny85]

Since this is a duplicate of #2056 , let's consolidate by closing this issue and moving the discussion to #2056.

[konstantinj]

https://aws.amazon.com/about-aws/whats-new/2020/05/aws-cloudformation-now-supports-blue-green-deployments-for-amazon-ecs/

reopen or new issue?

[piradeepk]

Reopened to track support for blue-green deployments

[MrArnoldPalmer]

So looks like starting with the L2s we can add an option to TaskDefinition to enable/blue green. We can do this by outputting the hook and transform detailed in the docs here https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green.html

Some experimentation may be required to get this working properly with a nice API. It could constitute a new "pattern". I haven't seen a lot of examples of using the L1s to achieve this but it should be possible.

[MrArnoldPalmer]

The "considerations" section of the user guide has some details that look like they are going to complicate implementation.

• You cannot include updates to resources that trigger green deployments and updates to other resources in the same stack update, as discussed in Resource Updates that Trigger ECS Blue/Green Deployments.
• Parameters whose values are obfuscated by CloudFormation cannot be updated by the CodeDeploy service during a green deployment, and will lead to an error and stack update failure. These include:
  
  
  
  • Parameters defined with the NoEcho attribute.
  
  
  • Parameters that use dynamic references to retrieve their values from external services. For more information, see Using Dynamic References to Specify Template Values.
  
  
• Declaring output values or importing values from other stacks is not currently supported for templates defining blue/green ECS deployments.
• Importing existing resources is not currently supported for templates defining blue/green ECS deployments.

[MrArnoldPalmer]

As mentioned by @shamhub in #6605 there is a construct out there supporting this that may provide some guidance for implementation.

https://www.npmjs.com/package/@cloudcomponents/cdk-blue-green-container-deployment

[CONJAUMCGCG]

What is the status of Blue Green ECS Deployment for AWS CDK?

[tsykora-verimatrix]

+1

it would be great to see support for blue/green deployments in ECS/Fargate in CDK since it's available in CloudFormation already (since 19th May)

[MrArnoldPalmer]

We are investigating how to integrate this in CDK and provide an idiomatic experience. This is not a trivial task because of the limitations of the feature in cloudformation as mentioned above.

We are considering a number of options including custom resources and/or magically splitting out blue/green resources into their own stack and somehow hiding the limitations around export/import mechanics.

I would encourage anyone who really wants to leverage this feature now to check out third party construct libraries, e.g. https://www.npmjs.com/package/@cloudcomponents/cdk-blue-green-container-deployment

An RFC is likely required to flesh out the design of an implementation that could be included in the core library.

[jpSimkins]

I spent the last 2 weeks trying to get this to work. I did find that npm package but I really didn't want to use Lambdas for this as I don't need them when I manually set this up. So glad I found this ticket :heart:

I will use the npm package above to get this working and will refactor once this is properly supported by the CDK. I am just glad to see I wasn't incompetent in this. I thought I was just missing something but glad to see it's not me.

Looking forward to the update and support of Fargate Blue/Green deployments in the CDK.

Is there any ETA for this? (next 6 months, over a year) Just wondering as using the npm package will suffice for now, it's not ideal.

[clareliguori]

The "considerations" section of the user guide has some details that look like they are going to complicate implementation.

• You cannot include updates to resources that trigger green deployments and updates to other resources in the same stack update, as discussed in Resource Updates that Trigger ECS Blue/Green Deployments.

• Parameters whose values are obfuscated by CloudFormation cannot be updated by the CodeDeploy service during a green deployment, and will lead to an error and stack update failure. These include:

  • Parameters defined with the NoEcho attribute.
  • Parameters that use dynamic references to retrieve their values from external services. For more information, see Using Dynamic References to Specify Template Values.
• Declaring output values or importing values from other stacks is not currently supported for templates defining blue/green ECS deployments.
• Importing existing resources is not currently supported for templates defining blue/green ECS deployments.

Hey @MrArnoldPalmer I'm not understanding why these restrictions/considerations should prevent CDK from adding support for the new Hooks section?

Ideally, I think we should unblock customers as soon as possible to be able to generate templates for blue-green deployments with the Hooks section, even at the "L1" level, and even if that template may later fail to deploy if the stack author doesn't take into account these considerations. The considerations listed are likely to change/loosen over time if the backend implementation changes, so I'm not sure it's the right thing to build that logic into the CDK anyway and become out of date.

[skinny85]

On a related note, we recently added support for Hooks on the L1 level in #10143.

[clareliguori]

Oh awesome, thanks @skinny85!

[MrArnoldPalmer]

@clareliguori I think investigation needs to be done in order to see how these restrictions are going to impact a higher level abstraction for this in CDK. Writing a naive construct would run into these issues because users can transparently use imports/exports between stacks and dynamic references etc.

With the hooks support available we will work on getting an example of L1 usage for users to reference in order to guide users in the interim.

[srethira]

@MrArnoldPalmer Is there any timeline for example L1 usage?

[CONJAUMCGCG]

@skinny85 @MrArnoldPalmer will this change allow us to create Amazon ECS(Blue/Green) action in Code Pipeline?
Currently we are not able to create ecsDeploymentApplication and ecsDeploymentGroup for blue/green deployments, which required by Amazon ECS(Blue/Green).
As I understand from above we will have to use Cloudformation Action Provider to deploy Blue Green template instead of having standard ECS(Blue/Green)

[martavoi]

Any updates so far?