CODEWITHSUNDEEP
amazon-web-servicesaws-cdkaws-codepipeline
Max
Max

Reputation: 115

Deploying infra changes into existing stack through CDK CodePipelines

How to migrate an existing stack with resources defined in the CDK to Code Pipelines without recreating the old stack/resources?

I have a stack that is deployed through cdk deploy from Github Actions. I'm trying to migrate the CD part of the pipeline to the CodePipeline. However, if I put the exiting cdk.Stack definition to the cdk.Stage it will delete the old stack (That's my assumption). How would you handle that? I know there is a way to expose resources from the stack, but this implies I need to keep this stack up and running which doesn't make any sense.

Upvotes: 4

Views: 1549

Answers (1)

fedonev
fedonev

Reputation: 25669

You want the pipeline to update an existing stack without replacing stateful resources1. For the stage-deploy to work as intended, (a) your existing stack must have explicit (non-default) resource names for the resources you want to keep, (b) the new stage stack must have constructs that hardcode those existing resource names and (c) the new stack's constructs must avoid other replacement behaviours2 on the stateful resources.

Point "a" means you are out of luck if you let CDK (technically, CloudFormation) set default resource names on the existing resources. A change from default naming to an explicit name triggers replacement behaviour, even if the new explicit name matches the existing generated name. The stage deploy will fail.

If you get this far, all that's left is give the stage-deployed stack the same name as the existing stack. When the pipeline executes, CloudFormation will perform a stack update.

Not a requirement, but as a safety measure you should ensure that stateful resources have a cdk.RemovalPolicy.RETAIN removalPolicy set and backups made. Retained resources will be orphaned outside the stack on replace or delete actions, not destroyed if things go sideways.

(1) Replacing means destroy and recreate. You aren't worried about stateless resources like (empty) queues and lambdas, which can be safely be replaced, but rather any stateful resources like databases.

(2) Changes to stack resources result in either update or replacement behaviour. Most changes are updates, which cause at most a short service interruption. The CloudFormation docs for each resource lists the update behaviour for each attribute, but at a minimum, changes to resource names (e.g. a CDK DynamoDB table's tableName) result in replacement.

Upvotes: 1

Related Questions