Is is possible to output to CDK code?

[Hillsie]

I am looking to make some modifications to the stack that I have generated. I see that there is a way to add cdk overrides. Does this generate the Copilot into a CDK app that can be modified. It wasn't clear from the documentation.
I am looking to tweak the deployment I have and was hoping to output a CDK from a cloudformation or from copilot.
Thanks in advance.

[Lou1415926]

Hello @Hillsie 👋🏼 I will give a brief overview to the feature and hopefully that answers the questions!

# Without CDK override
$ copilot svc package --env test # Produces CFN template A.

# With CDK override
$ copilot svc override --tool cdk # Generates skeleton codes for a CDK app. You can think of this as similar to `cdk init`.
$ copilot svc package --env test 
# Copilot produces CFN template A
# It sees the `override/` folder so it feeds template A into the CDK app by writing template A into `.build/in.yml`
# The CDK app modifies individual resources in template A, thus producing template B

Therefore, what the CDK overrides feature does is to connect Copilot with CDK via. the template A that Copilot produces; what it doesn't do is to model Copilot as a CDK construct. The end product is a CloudFormation template, not a CDK app.

Does this generate the Copilot into a CDK app that can be modified.

The command copilot svc override --tool cdk does generates a CDK app. The app imports the CloudFormation template that Copilot would have produced without the CDK override (i.e. template A), and let you modify the individual resources in that template as L1 construct.

I am looking to tweak the deployment I have and was hoping to output a CDK from a cloudformation or from copilot.

I think you could take the skeleton CDK app generated from copilot svc override --tool cdk, write the Copilot template (the "template A") to .build/in.yml (this would have been handled in copilot svc package). This is a CDK app on its own, which means you could just modify the code and run cdk synth/ cdk deploy from this point, without any copilot commands. However there are a bunch of downsides, for example you'd been missing Copilot's declarative manifests, and you'd be working with low-level CDK codes as L1 constructs.

Hope this helps clarifying things! Please let me know though if I'm missing the question 👀

[Hillsie]

Thank you, @Lou1415926

[Lou1415926]

I have a quick follow-up question - hope you don't mind!

Were you looking to "eject" from Copilot to CDK? That is, to export an Copilot application into a CDK app, and then work with CDK from then on (i.e. just modify the CDK codes and run cdk deploy without having to interact with Copilot from this point)?

If this was what you were looking to do, I wonder if you'd like to interact with the Copilot services as L3 constructs or to interact with the resources as L2 constructs?

To elaborate - an L3 construct would be a "pattern" and would correspond to a service type in Copilot. For example, a Load-Balanced Web Service would be a L3 construct, and you will likely be able to configure the similar set of settings in the L3 construct as you can in a Load-Balanced Web Service's manifest. This offers roughly the similar level of abstraction as Copilot, but you'd be able to stay with CDK if you're already familiar with it, and potentially easier for you to hook your other CDK resources with your Copilot applications.

Whereas L2 constructs would correspond to individual AWS resources - which exposes configurations that you wouldn't have been able to in a service manifest. This is more flexible but loses the abstraction from the L3 patterns.

[Hillsie]

@Lou1415926 Ejecting would be a helpful feature. Level 3 or 2. The challenge is that to make Copilot stand up a solution assumptions need to be made. Some of the assumptions I'd want to tweaking to fit my use case.

[Lou1415926]

The challenge is that to make Copilot stand up a solution assumptions need to be made. Some of the assumptions I'd want to tweaking to fit my use case.

Can you give an example on the assumptions that you'd like to tweak? It's likely that L2 constructs would solve the issue better in this case, but I'm asking in order to validate what I understand from your use case 😄 !