spec: cdk package

[eladb]

Following up on this comment, this issue is an initial spec for a new CLI command called (for now) cdk package.

Similarly to the cloudformation package and sam package commands, the new cdk package STACK will:

1. Build local assets (docker images, zip directories) defined in a cloud assembly,
2. Upload them to S3/ECR and
3. Upload the CloudFormation template for that stack to S3, with the asset CloudFormation parameters default values set to point to the publish locations.
4. It will then return an S3 URL (presigned?) that is a self-contained template that can be deployed to the environment with no additional information required. Another interesting benefit of the self-contained template is that it represents a "point in time", which can be easily rolled back if needed.

Currently this process is performed by cdk deploy. Decoupling package from deploy is required in order to mitigate risks related to running docker build in an environment that has administrative privileges, and also to allow using of native cloudformation APIs for deployments, instead of requiring to run a container with cdk deploy. This addresses users's concern around costs and constraints the administrative IAM role in remote accounts to the cloudformation service principal).

Similar to the approach we took with cdk synth (which produces a cloud assembly as an output), cdk deploy will automatically invoke cdk package but it will also be possible to invoke them independently (similar to cdk synth). We can decide that if --app points to an s3:// url, cdk deploy will treat it as a ready-to-deploy template.

The eventual flow will be:

[cdk synth] => cdk.out(cloud-assembly) => [cdk package] => s3://template-url => [cdk deploy] => stack

[j]

I was just about to create an issue asking how to do a sam package equivalent.

Currently in CI, we do a sam package and push the CF packaged template to S3 and use that template to deploy/promote stages to various AWS accounts.

Also, currently with sam we have to build ourselves because their build system is kinda broken for advanced node.js apps (typescript, etc). So if CDK can support any type of build system, having it build would be cool, otherwise, we still want to be able to build deployables ourselves.

[jewelsjacobs]

Hi @eladb!

Like @j mentioned, advanced node.js apps can require some non CF operations (typescript compiling, webpack building, etc). It's only after these operations occur that there's a nice compiled directory to use s3 deployment with.

Would I be able incorporate non CF commands into the package stage?

I guess I could always build my entire web source code as a local asset and then include a cdk template with codebuild that includes those commands in a buildspec.

That's not much different than what I'm doing now in my pipeline.

I suppose non CF operation support is a bit much :)

Thanks!

[eladb]

@jewelsjacobs since we are trying to be agnostic to programming languages/framework/build tools, our approach is that if you want something to be available during synthesis it needs to be there before you run cdk synth.

So in the case of building websites, your approach is what we expect people to do: run some pre-synth commands that will produce the website (either in .zip format or just a "dist" directory) and then during synth, reference this artifact and let the CDK do it's work to package it and deploy it.

Does that make sense?

[jewelsjacobs]

Thanks for your thoughtful response @eladb.

Makes perfect sense!

[joshrp]

I really like the idea and it seems abstract enough to apply to any asset needing to be built and prepared prior to releasing.

Is there any plan in place for implementing this? Is it planned for V2 or earlier?

[eladb]

This is currently superseded by #3437