-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Applets: allow multi-applet stacks #341
Comments
Do we have applet support in the current release? Is it P0 for ext. beta/GA? |
We do have applet support in the current release. There are missing features such as #291. |
CDK constructs can represent robust and powerful cloud abstractions. Currently, the only way to consume these abstractions is by instantiating these constructs in code into a user's CDK stack and then deploying them either manually using cx toolkit or via a CI/CD pipeline. For certain use cases we would like to allow users to deploy CDK apps that are based on specific constructs without the need to consume these constructs in code, but rather use a simple declarative format such as a YAML file. CDK applets are JSON/YAML files that represent fully deployable stacks. |
Hi, we would like to make usage of the applet to describe different environment of deployment, e.g. to make declarative structure for 'dev|prod|integration' env for example. we would like to be able to do something like: Will you support such scenario? Thanks |
That is true, at the moment one applet corresponds to one stack. What would you prefer, and how would you use it? |
Hi, thanks for the fast respond. I assume the best way to describe 'our thoughts' will be using serverless-terminology. hope ok. We tend to think of constructs as our 'plugins', the building blocks that wraps basic logic/concepts. For example, apigw-access-with-cognito-authorizer, apigw-with-private-link, etc. And we wanted a declarative way that can be used by us or system engineer to describe our deployment. Not exactly serverles.yml ,but indeed some kind of format that will help us describe several constructs that builds a single stack. That is why we wanted to ask that each applet=stack, will allow several 'types' children to allow this. could it be useful for others too as you see it? Thanks in advance! |
Hi, small ping following the above. thanks in advance! |
Thanks for your response. At the moment, we're not planning to implement multi-construct applet stacks. I'm not opposed to it, but I think the gain wouldn't be large enough. There are no ways to combine constructs together (for example, reference an output of a construct as another construct's input). In the end, each construct in the stack would be standalone. At that point, what's the advantage of even combining them into the same stack? They might as well be deployed separately. Once we start allow referencing between applets, we're kind of rebuilding CloudFormation, and there's probably something better we could be doing instead. I will turn this issue into a feature request for that feature, but I can't make any promises on when it will be implemented. |
Highly appreciate the elaborated consideration of the issue. You explained well. Our thought was to be able to combine into simple small constructs what we refer to as 'best-practice/well-architecture small features', That could be as i mentioned above apigw-connected-with-waf-and-cloud-front, apigw-exposed-via-private-link, etc. Those joint building blocks (turned into constructs) could help build a full featured solution (single stack) that can later on enjoy the good-updates cloudformation supports. etc. However, i do realize it is not high necessity at the moment as we can still enjoy the cdk as is, with coding the above need. |
Formalize the concept of a cloud assembly to allow decoupling "synth" and "deploy". the main motivation is to allow "deploy" to run in a controlled environment without needing to execute the app for security purposes. `cdk synth` now produces a self-contained assembly in the output directory, which we call a "cloud assembly". this directory includes synthesized templates (similar to current behavior) but also a "manifest.json" file and the asset staging directories. `cdk deploy -a assembly-dir` will now skip synthesis and will directly deploy the assembly. To that end, we modified the behavior of asset staging such that all synth output always goes to the output directory, which is by default `cdk.out` (can be set with `--output`). if there's a single template, it is printed to stdout, otherwise the name of output directory is printed. This PR also includes multiple clean ups and deprecations of stale APIs and modules such as: - `cdk.AppProps` includes various new options. - An error is thrown if references between stacks that are not in the same app (mostly in test cases). - Added the token creation stack trace for errors emitted by tokens - Added `ConstructNode.root` which returns the tree root. **TESTING**: verified that all integration tests passed and added a few tests to verify zip and docker assets as well as cloud assemblies. See: https://github.com/awslabs/cdk-ops/pull/364 Closes #1893 Closes #2093 Closes #1954 Closes #2310 Related #2073 Closes #1245 Closes #341 Closes #956 Closes #233 BREAKING CHANGE: *IMPORTANT*: apps created with the CDK version 0.33.0 and above cannot be used with an older CLI version. - `--interactive` has been removed - `--numbered` has been removed - `--staging` is now a boolean flag that indicates whether assets should be copied to the `--output` directory or directly referenced (`--no-staging` is useful for e.g. local debugging with SAM CLI) - Assets (e.g. Lambda code assets) are now referenced relative to the output directory. - `SynthUtils.templateForStackName` has been removed (use `SynthUtils.synthesize(stack).template`). - `cxapi.SynthesizedStack` renamed to `cxapi.CloudFormationStackArtifact` with multiple API changes. - `cdk.App.run()` now returns a `cxapi.CloudAssembly` instead of `cdk.ISynthesisSession`. - `cdk.App.synthesizeStack` and `synthesizeStacks` has been removed. The `cxapi.CloudAssembly` object returned from `app.run()` can be used as an alternative to explore a synthesized assembly programmatically (resolves #2016). - `cdk.CfnElement.creationTimeStamp` may now return `undefined` if there is no stack trace captured. - `cdk.ISynthesizable.synthesize` now accepts a `cxapi.CloudAssemblyBuilder` instead of `ISynthesisSession`. - `cdk`: The concepts of a synthesis session and session stores have been removed (`cdk.FileSystemStore`, cdk.InMemoryStore`, `cdk.SynthesisSession`, `cdk.ISynthesisSession` and `cdk.SynthesisOptions`). - No more support for legacy manifests (`cdk.ManifestOptions` member `legacyManifest` has been removed) - All support for build/bundle manifest have been removed (`cxapi.BuildManifest`, `cxapi.BuildStep`, etc). - Multiple deprecations and breaking changes in the `cxapi` module (`cxapi.AppRuntime` has been renamed to `cxapi.RuntimeInfo`, `cxapi.SynthesizeResponse`, `cxapi.SynthesizedStack` has been removed) - The `@aws-cdk/applet-js` program is no longer available. Use [decdk](https://github.com/awslabs/aws-cdk/tree/master/packages/decdk) as an alternative.
Requested via email
The text was updated successfully, but these errors were encountered: