Integrate with AWS Cloud Development Kit (CDK)

[clareliguori]

Extend support on AWS Proton to enable defining infrastructure templates using CDK

[hoegertn]

Happy to help on this

[adamdottv]

Happy to help on this

Same!

[polothy]

Would be really slick if the Proton inputs were given to a CDK project and then cdk synth was called for you to generate the CloudFormation template. This way, instead of using CloudFormation + Jinja, you can just use NodeJS/Python/etc, whatever language your CDK project is built with. This would be super powerful and really easy to maintain over time.

Then of course, you can also make use of CDK constructs to share re-usable bits of your infrastructure across multiple Proton environments and services.

[clareliguori]

@polothy that matches with how I've been visualizing this for Proton -- as an alternative to Jinja, where CDK generates the CloudFormation template instead of Jinja (using cdk synth as you suggested). For example in your Proton infrastructure manifest, the engine could be something like aws-cdk instead of jinja: https://github.com/aws-samples/aws-proton-sample-templates/blob/main/loadbalanced-fargate-svc/service/infrastructure/manifest.yaml#L4

A couple areas I'd love to hear feedback and ideas from folks on further design:

1. What should packaging your CDK code and providing it to Proton in a template bundle look like? Especially wrt the CDK version your code was written for. Are you ok with providing the CDK construct library bits along with your compiled code in the compiled code, so that you can control the version and packaging?

2. How do you envision getting the inputs into your CDK code? For example, the below sample inputs for a Proton service instance using this sample template. Where do you want to read the inputs from? How do you want to parse the inputs / what format do you want the inputs in?

{
   "environment": {
      "ClusterName": "my-cluster",
      "ECSTaskExecutionRole": "my-execution-role",
      "VpcId": "vpc-123",
      "PublicSubnetOne": "subnet-abc",
      "PublicSubnetTwo": "subnet-def",
      "ContainerSecurityGroup": "sg-456"
   },
   "service_instance": {
      "desired_count": 2,
      "port": 80,
      "task_size": "medium",
      "unique_name": "frontend-dev"
   }
}

[polothy]

Great minds! Glad you were way ahead of me on this one!

For number 1, I don't mind the idea of bundling everything together (all the dependencies, etc). Could maybe also specify some commands to run, prior to synth, like npm install or pip install -r requirements.txt. Either way, would require specific runtimes (EG: having python 3.8 installed, etc) and specific versions of CDK. Unsure if you can specify some things in the infra manifest?

infrastructure:
  templates:
    - engine: aws-cdk@1.2.3
      runtimes: [python3.8,nodejs12.X]

I'd bet the CDK project leads would have great suggestions though. They have done similar things already with the CDK Pipelines construct where they need to synth CDK projects in CodeBuild.

For number 2, JSON is generally supported by a lot of languages without installing 3rd party package (IIRC), but neat thing here is that one could author a Proton CDK Construct that's just a library for reading this file or env variables and getting the inputs. Then we just add the library to our project and get a very nice UX for accessing these values:

cluster_name = proton.inputs.environment.get("ClusterName")
raw_env = proton.inputs.environment.all()

[hoegertn]

@clareliguori I would really love direct integration of CDK in Proton, but as a first and more general approach, I could think of having a Lambda, CodeBuild, StepFunction, etc integration for preparing the template. So Proton would send the input to some service and get a template as result. This could be Jinja, CDK, some fancy hand-written code, ...

[JohnPreston]

TLDR; Can I use just CFN templates without the schemas and manifest for Proton and have templates with CFN parameters?

To me when I look at the examples etc. it feels a lot like Proton aims to allow people to implement CFN Macros without having to create new Lambdas and publish them. With CFN macros, I could do everything that what I have seen so far Jinja would do. Macros do have the advantage to support all that Lambda supports, and more, if you then call out for boto etc.

Also as part of the examples I can see there is a always a schema. When using CDK/Troposphere or just CFN templates, I do not need the schemas etc, I just have CFN Parameters.

So I am really unsure why one would take the parameters out of the original templates, into a different file which even uses a different syntax format, to what benefit?

I was very excited to see proton coming out and will use it but it seems like a re-model/re-make of what CFN already provides all too well. We have implemented basically what Proton aims to do at work with native CFN and had no limitations with it.

Final note: the bundles are expected to be .tar.gz , which makes think, requires not only the templates but the schemas.

PS: Sorry if that is not the place but I could not find any more appropriate "issue thread"

[clareliguori]

Hi @JohnPreston, I have opened a separate issue to capture feedback for that request (using CFN parameters in Proton templates): https://github.com/aws/aws-proton-public-roadmap/issues/35

[rafavallina]

Hi everyone,

We are continuing to make progress in our support of CDK. One of the key areas where we are trying to find more data is what is the best way for Proton to "run" CDK. Different customers are using CDK in different ways and we want to make sure that Proton supports all of them.

@polothy you were mentioning that you would not mind passing the commands for Proton to run. We were thinking along the same lines. You could specify something like:

    runtimes:
      nodejs: 14
    run:
      - npm install
      - npm run build
      - npm cdk deploy

In your Proton manifest, and then Proton would execute these commands in order at the time of provisioning.

I'd love to get feedback on this approach. In particular, we have one question: How frequently do people in this thread need to access non-publicly accessible libraries when doing this? Depending on where the runtime for these commands happen, we'd need to be able to access any resource from the public internet.

Please leave a comment here with your take or if you want to get on a call!

[RichiCoder1]

@rafavallina At least personally, the local CDK script and synth step itself doesn't usually need access to anything private. If we want to test something private or seed something, we'll use a CDK Hook or Custom Resource to accomplish that. And most our private secrets are pulled via standard CloudFormation and AWS means.

[rafavallina]

Thank you @RichiCoder1! Do you us al public libraries, or do you have any private constructs as well?

[RichiCoder1]

Thank you @RichiCoder1! Do you us al public libraries, or do you have any private constructs as well?

Yup! We have a small collection of NPM-based construct and constant libraries we pull into about every CDK project now.

[markusl]

Thank you @RichiCoder1! Do you us al public libraries, or do you have any private constructs as well?

In our use case (a highly regulated and tightly secured industry) we proxy all public NPM packages and distribute our internal NPM packages through a custom NPM artifact repository. This means the build needs to run within a VPC that has the required VPN connectivity, and the build must use credentials for authentication.

[jmjava]

@markusl we do something similar and use CodeArtifact as the repo but we are in the process of setting up Artifactory in AWS so will be attempting to switch to that. We are doing Python CDK and the repo type is PYPI

[jmjava]

CDKPipeline has issues with using VPC lookups in the code base. You can get around that by having a prepopulated cdk.json checked in see: https://docs.aws.amazon.com/cdk/api/v1/python/aws_cdk.aws_ec2/Vpc.html#aws_cdk.aws_ec2.Vpc.from_lookup

this article has some workarounds I have not tried. We are still using the checked in cdk.json

https://levelup.gitconnected.com/aws-cdk-pipelines-real-world-tips-and-tricks-part-2-7a0d093a89a0

[rafavallina]

Thanks you all for (@RichiCoder1 @markusl @jmjava) your comments!

In general, at this point we are inclined to assume that customers will need to access libraries not available on the public Internet, so we will want to solve for that.

The way our current design would work is that Proton will rely on CodeBuild for this: we spin up a CodeBuild job in the customer account where we execute those commands as defined. Because the job is in the customer account, it can run in a VPC and access any private libraries if need be. As a customer, this means that you'd see new CodeBuild projects be created, all by Proton, that would run from time to time (whenever there is a Proton deployment)

Does this approach make sense? Any feedback on it?

[markusl]

@rafavallina Thanks for the quick response. It does make sense, yes. Please also note that there needs to be a mechanism to authenticate against the private NPM registry. For example, using NPM_TOKEN as described here https://docs.npmjs.com/docker-and-private-modules.

[sholtomaud]

Any updates on this issue?

Has Proton support in CDK landed? Pretty keen to start defining my Proton services and environments in CDK.

[rafavallina]

Hi @sholtomaud not shipped yet, no! We are still defining some parts of it. Would love to chat and hear more about the use case! Any chance you can reach out through your Account Team?

[rverma-dev]

Our organisation would also like to participate if there is a preview version of proton supporting cdk.

[tatcoo]

Hi @rverma-nsl - we don't have a preview but should have an update here soon

[huss-jay]

Would the CDK feature also happen to support Proton Components? As in, can CDK be an option as a source for the components?

[tatcoo]

Hi @huss-jay ! Proton components (which allows for developer-defined code to be executed in an account) will be excluded from the initial launch of CDK, but we’re eager to hear customer feedback about how their teams would use the two together (especially in the context of security policies and the permissions required to create components).

[tatcoo]

We just launched support for CDK through CodeBuild Provisioning for Proton. You can learn more here!