-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Closed
Environment defaults and support for relocatable templates #2866
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
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).
4 tasks
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).
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.
7 tasks
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.
This was referenced Aug 22, 2019
This was referenced Dec 12, 2019
This was referenced Dec 13, 2019
This was referenced Jan 20, 2020
This was referenced Sep 24, 2024
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
feature-request
A feature should be added or improved.
needs-triage
This issue or PR still needs to be triaged.
[Only using “region” here, but same applies for account].
stack.region
will resolve to:env.region || Aws.region
Token.isUndefined(stack.region)
, either fall back and return a "relocatable" result (e.g. useFn::GetAZs
) or emit a metadata error and return dummy values for tests.stack.region
is not a concrete value, assembly manifest will indicateany-region
in the stack's environment spec (aws://1287239487234/any-region
). Same for account.cdk deploy
seesany-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.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.The text was updated successfully, but these errors were encountered: