Skip to content
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

Environment defaults and support for relocatable templates #2866

Closed
eladb opened this issue Jun 13, 2019 · 0 comments · Fixed by #2922 or MechanicalRock/tech-radar#14 · May be fixed by MechanicalRock/cdk-constructs#5, MechanicalRock/cdk-constructs#6 or MechanicalRock/cdk-constructs#7
Labels
feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged.

Comments

@eladb
Copy link
Contributor

eladb commented Jun 13, 2019

[Only using “region” here, but same applies for account].

  • stack.region will resolve to: env.region || Aws.region
  • Any code that requires a concrete region will check Token.isUndefined(stack.region), either fall back and return a "relocatable" result (e.g. use Fn::GetAZs) or emit a metadata error and return dummy values for tests.
  • If stack.region is not a concrete value, assembly manifest will indicate any-region in the stack's environment spec (aws://1287239487234/any-region). Same for account.
  • If cdk deploy sees any-region in a stack's environment spec, it will use the default region as configured in the CLI. If a region is not configured for some reason, an error will be reported.
  • Remove Context.getDefaultRegion(). It shouldn't be accessed directly.

User guide and documentation should guide users who wish to synthesize "relocatable" (account/region-agnostic) templates to simply set env: { account: Aws.account, region: Aws.region } when they define their stack. This will result in the above behavior to kick in.

@eladb eladb added the feature-request A feature should be added or improved. label Jun 13, 2019
eladb pushed a commit that referenced this issue Jun 13, 2019
The PR #2728 caused a regression on how the framework behaves when a
stack's environment (account and/or region) are not specified.

The behavior is: if account and/or region are not specified at the stack
level (or set to Aws.accountId and Aws.region, respectively), the cloud
assembly manifest of this stack will have an environment specification
based on the defaults passed in from the CLI.

This is a temporary solution which fixes #2853 but doesn't fully implement
the behavior we eventually want (which is documented in #2866).
@eladb eladb changed the title Environment defaults Environment defaults and support for relocatable templates Jun 13, 2019
shivlaks pushed a commit that referenced this issue Jun 13, 2019
…ed (#2867)

The PR #2728 caused a regression on how the framework behaves when a
stack's environment (account and/or region) are not specified.

The behavior is: if account and/or region are not specified at the stack
level (or set to Aws.accountId and Aws.region, respectively), the cloud
assembly manifest of this stack will have an environment specification
based on the defaults passed in from the CLI.

This is a temporary solution which fixes #2853 but doesn't fully implement
the behavior we eventually want (which is documented in #2866).
@NGL321 NGL321 added the needs-triage This issue or PR still needs to be triaged. label Jun 17, 2019
eladb pushed a commit that referenced this issue Jun 19, 2019
Formalize the simple use case for synthesizing cloudformation templates that
are not pre-associated with a specific AWS account/region.

When a CDK stack is defined without an explicit `env` configuration, or if `env.account`
and/or `env.region` are set to `Aws.accountId`/`Aws.region`, the stack is said to be
"environment-agnostic". This means that when a template is synthesized, we will use
the CloudFormation intrinsics `AWS::AccountId` and `AWS::Region` instead of concrete
account/region.

The cloud assembly manifest for such stacks will indicate `aws://unknown-account/unknown-region`
to represent that this stack is environment-agnostic, and tooling should rely on external
configuration to determine the deployment environment.

Environment-agnostic stacks have limitations. For example, their resources cannot be referenced
across accounts or regions, and context providers such as SSM, AZs, VPC and Route53 lookup
cannot be used since they won't know which environment to query.

To faciliate the env-agnostic use case at the AWS Construct Library level,
this change removes any dependency on concrete environment specification. Namely:

- The AZ provider, which is now accessible through `stack.availabilityZones` will fall
  back to use `[ Fn::GetAZs[0], Fn::GetAZs[1] ]` in case the stack is env-agnostic. This is
  a safe fallback since all AWS regions have at least two AZs.
- The use of the SSM context provider by the EC2 and ECS libraries to retrieve AMIs was
  replaced by deploy-time resolution of SSM parameters, so no fallback is required.

See list of breaking API changes below.

Added a few static methods to `ssm.StringParameter` to make it easier to reference values directly:
* `valueFromLookup` will read a value during synthesis using the SSM context provider.
* `valueForStringParameter` will return a deploy-time resolved value.
* `valueForSecureStringParameter` will return a deploy-time resolved secure string value.

Fixes #2866

BREAKING CHANGE: `ContextProvider` is no longer designed to be extended. Use `ContextProvider.getValue` and `ContextProvider.getKey` as utilities.
* **core:** `Context.getSsmParameter` has been removed. Use `ssm.StringParameter.valueFromLookup`
* **core:** `Context.getAvailabilityZones` has been removed. Use `stack.availabilityZones`
* **core:** `Context.getDefaultAccount` and `getDefaultRegion` have been removed an no longer available.
* **route52:** `HostedZoneProvider` has been removed. Use `HostedZone.fromLookup`.
* **ec2:** `VpcNetworkProvider` has been removed. Use `Vpc.fromLookup`.
* **ec2:** `ec2.MachineImage` will now resolve AMIs from SSM during deployment.
* **ecs:** `ecs.EcsOptimizedAmi` will now resolve AMis from SSM during deployment.
eladb pushed a commit that referenced this issue Jun 19, 2019
Formalize the simple use case for synthesizing cloudformation templates that are not pre-associated with a specific AWS account/region.

When a CDK stack is defined without an explicit `env` configuration, or if `env.account` and/or `env.region` are set to `Aws.accountId`/`Aws.region`, the stack is said to be "environment-agnostic". This means that when a template is synthesized, we will use the CloudFormation intrinsics `AWS::AccountId` and `AWS::Region` instead of concrete account/region.

The cloud assembly manifest for such stacks will indicate `aws://unknown-account/unknown region` to represent that this stack is environment-agnostic, and tooling should rely on external configuration to determine the deployment environment.

Environment-agnostic stacks have limitations. For example, their resources cannot be referenced across accounts or regions, and context providers such as SSM, AZs, VPC and Route53 lookup cannot be used since they won't know which environment to query.

To faciliate the env-agnostic use case at the AWS Construct Library level, this change removes any dependency on concrete environment specification. Namely:

- The AZ provider, which is now accessible through `stack.availabilityZones` will fall back to use `[ Fn::GetAZs[0], Fn::GetAZs[1] ]` in case the stack is env-agnostic. This is a safe fallback since all AWS regions have at least two AZs.
- The use of the SSM context provider by the EC2 and ECS libraries to retrieve AMIs was replaced by deploy-time resolution of SSM parameters, so no fallback is required.

See list of breaking API changes below.

Added a few static methods to `ssm.StringParameter` to make it easier to reference values directly:
* `valueFromLookup` will read a value during synthesis using the SSM context provider.
* `valueForStringParameter` will return a deploy-time resolved value.
* `valueForSecureStringParameter` will return a deploy-time resolved secure string value.

Fixes #2866

BREAKING CHANGE: `ContextProvider` is no longer designed to be extended. Use `ContextProvider.getValue` and `ContextProvider.getKey` as utilities.
* **core:** `Context.getSsmParameter` has been removed. Use `ssm.StringParameter.valueFromLookup`
* **core:** `Context.getAvailabilityZones` has been removed. Use `stack.availabilityZones`
* **core:** `Context.getDefaultAccount` and `getDefaultRegion` have been removed an no longer available.
* **route52:** `HostedZoneProvider` has been removed. Use `HostedZone.fromLookup`.
* **ec2:** `VpcNetworkProvider` has been removed. Use `Vpc.fromLookup`.
* **ec2:** `ec2.MachineImage` will now resolve AMIs from SSM during deployment.
* **ecs:** `ecs.EcsOptimizedAmi` will now resolve AMis from SSM during deployment.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment