feat: new synthesizer separates assets out per CDK application

[kaizencc]

This PR introduces a new synthesizer inside the module app-staging-synthesizer-alpha. This new synthesizer produces staging resources alongside the CDK application and assets will be stored there. It removes the need for running cdk bootstrap before deploying a CDK app in a new account/region. Under the new synthesizer, assets between different CDK applications will be separated which means they can be cleaned up and lifecycle controlled independently.

To get started, add the following to your CDK application:

const app = new App({
  defaultStackSynthesizer: AppStagingSynthesizer.defaultResources({
    appId: 'my-app-id', // put a unique id here
  }),
});

The new format of staging resources will look something like this:

┌─────────────────────────────┐┌───────────────────────────────────────┐┌───────────────────────────────────────┐
│                             ││                                       ││                                       │
│      ┌───────────────┐      ││             ┌──────────────┐          ││             ┌──────────────┐          │
│      │Bootstrap Stack│      ││             │  CDK App 1   │          ││             │  CDK App 2   │          │
│      └───────────────┘      ││             └──────────────┘          ││             └──────────────┘          │
│                             ││┌──────────────────┐                   ││┌──────────────────┐                   │
│                             │││ ┌──────────────┐ │                   │││ ┌──────────────┐ │                   │
│                             │││ │Staging Stack │ │                   │││ │Staging Stack │ │                   │
│                             │││ └──────────────┘ │                   │││ └──────────────┘ │                   │
│                             │││                  │                   │││                  │                   │
│                             │││                  │                   │││                  │                   │
│                             │││┌────────────────┐│     ┌────────────┐│││┌────────────────┐│     ┌────────────┐│
│                             ││││  IAM Role for  ││ ┌───│  S3 Asset  │││││  IAM Role for  ││ ┌───│  S3 Asset  ││
│                             ││││File Publishing ││ │   └────────────┘││││File Publishing ││ │   └────────────┘│
│                             │││└────────────────┘│ │                 ││││  IAM Role for  ││ │                 │
│                             │││                  │ │                 ││││Image Publishing││ │                 │
│┌───────────────────────────┐│││                  │ │                 │││└────────────────┘│ │                 │
││IAM Role for CFN execution ││││                  │ │                 │││                  │ │                 │
││    IAM Role for lookup    ││││                  │ │                 │││                  │ │                 │
││  IAM Role for deployment  ││││┌────────────────┐│ │                 │││┌────────────────┐│ │                 │
│└───────────────────────────┘││││ S3 Bucket for  ││ │                 ││││ S3 Bucket for  ││ │                 │
│                             ││││ Staging Assets │◀─┘                 ││││ Staging Assets │◀─┘                 │
│                             │││└────────────────┘│                   │││└────────────────┘│      ┌───────────┐│
│                             │││                  │                   │││                  │  ┌───│ ECR Asset ││
│                             │││                  │                   │││┌────────────────┐│  │   └───────────┘│
│                             │││                  │                   ││││ ECR Repository ││  │                │
│                             │││                  │                   ││││  for Staging   │◀──┘                │
│                             │││                  │                   ││││     Assets     ││                   │
│                             │││                  │                   │││└────────────────┘│                   │
│                             │││                  │                   │││                  │                   │
│                             │││                  │                   │││                  │                   │
│                             │││                  │                   │││                  │                   │
│                             │││                  │                   │││                  │                   │
│                             │││                  │                   │││                  │                   │
│                             ││└──────────────────┘                   ││└──────────────────┘                   │
└─────────────────────────────┘└───────────────────────────────────────┘└───────────────────────────────────────┘

This feature is heavily experimental and the API may break in the future. It does not work with CDK Pipelines yet.

Depended on #25536.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[rix0rrr]

TODO: lifecycle rules?

[rix0rrr]

These don't need to be exposed on the interface, right?

[rix0rrr]

I would expect an application name parameter here as well

[rix0rrr]

Is this one that's going to be created or reused? Maybe call it existingFileAssetPublishingRoleName ?

[rix0rrr]

This name is going to conflict with the default bootstrapped roles :).

I think we pick a prefix that contains the app name and base the rest off of it. And come to think of it, ${AccountId} only needs to be in the bucket name, not in any of the role names.

[rix0rrr]

The construct ID doesn't have to be its actual name. It could just be a symbolic identifier like "FileRole". Think of it as a variable name.

[rix0rrr]

Check the current assume role policies. I think the correct assumer here will be:

• The Deploy Role if the user chooses a Deploy Role (should be a parameter to the stack synthesizer)
• The current account root if not

[rix0rrr]

Perhaps this needs to be configurable?

[rix0rrr]

You need special placeholders instead of tokens, to pass to the asset manifest. I think it's the literal string ${AWS::Region}, etc.

[rix0rrr]

Some final nitpicks on the README and naming, sorry :P and then let's ship it!

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 93dad51
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[RichiCoder1]

Howdy! Probably not the best place to ask, but will there be a version of this where you can still share Buckets, but the rest is independent? At least two of our accounts are already close to bucket limit and it's not hard to hit depending on your usage.