-
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
Cannot find right method to import existing vpc with ec2.Vpc.fromLookup or ec2.Vpc.fromVpcAttributes #12160
Comments
I'd try to give up |
Hardcoded values for vpc and subnets do work, but i cannot use them for automation. The values of the subnets and vpc's are in the export values i need a way to import them in my current cdk stack. Please advise ? |
Is the vpc you want to use also created by cdk? It is possible if this the case, do reference the vpc from the separate stack directly. From the docs for from_lookup:
|
Yes, the vpc is created by CDK but by a totally different codecommmit repo. My main requirement is to import a vpc with private subnets specifically via exported values. The below appears to be working, but i am assuming here there are always two AZs. If the scenario changes in future based on environment, this code will no longer work.
I am not sure why |
Please advise if there is any update on this issue / recommendation on importing an existing vpc without hardcoding the vpcid and subnetid's. |
struggling with the same problem with the newer versions of CDK (1.82.0), when attempting to spin up an EKS cluster. It might be related with #11945 since this worked with 1.76.0. Maybe it's worth mentioning, the VPC has both public/private subnets, thus public/private Routing Tables. Please find my code below: const vpc = Vpc.fromVpcAttributes(scope, 'DefaultVpc', {
vpcId: ssm.StringParameter.valueForStringParameter(scope, `${basePath}/VpcId`),
availabilityZones: ssm.StringParameter.valueForStringParameter(scope, `${basePath}/AvailabilityZones`),
privateSubnetIds: ssm.StringParameter.valueForStringParameter(scope, `${basePath}/PrivateSubnetIds`),
privateSubnetRouteTableIds: ssm.StringParameter.valueForStringParameter(scope, `${basePath}/PrivateSubnetRouteTableIds`),
publicSubnetIds: ssm.StringParameter.valueForStringParameter(scope, `${basePath}/PublicSubnetIds`),
publicSubnetRouteTableIds: ssm.StringParameter.valueForStringParameter(scope, `${basePath}/PublicSubnetRouteTableIds`),
});
const cluster = new eks.Cluster(this, 'DetestadrCluster', {
vpc: vpc,
defaultCapacity: 0,
version: eks.KubernetesVersion.V1_18
}); Throwing the same error when resolving the template:
In addition, spinning an ECS cluster has no issues: const ecsCluster = new ecs.Cluster(this, 'EcsCluster', {
clusterName: `blablablaCluster`,
vpc: vpc,
}); |
Tag your VPC and use |
@rix0rrr the |
For now, that's unfortunately true. Preload the right credentials into your shell while you run |
we are using a CodePipeline-based CI/CD workflow...and committing the credentials in github is not a solution. I can see this was addressed and partially fixed in #11945 , unfortunately I cannot figure it out what is still missing |
You're not committing the credentials, you are committing the result of the lookups. |
Generally, using We don't go ahead and error out when you try to do this, because it accidentally used to work for some special cases (notably, AutoScalingGroups) and we didn't want to break those existing cases. In all other cases, the only correct way to do this is to use |
@adriantaut I am unsure why this would even compile: privateSubnetIds: ssm.StringParameter.valueForStringParameter(scope, `${basePath}/PrivateSubnetIds`), Given that |
Many people don't commit or want to commit `cdk.context.json`, and are subsequently annoyed that they can't use `Vpc.fromLookup()` in a pipeline. Make it very clear that this is the way CDK is designed to work and they must do it. Relates to #12160 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@rix0rrr my mistake, was just trying to make the code as easy as possible, the actual implementation relies on a /**
* Return the default VPC in any account, relying on SSM parameters created by the Cloud Foundations VPC stack (/platform/vpc/*)
*/
export function getVpc(scope: Construct, vpcName?: string, usePublic?: boolean) {
const vpc = vpcName ?? 'default';
const basePath = `/platform/vpc/${vpc}`;
let publicSubnetIds = undefined;
let publicSubnetRouteTableIds = undefined;
const getStringListParam = (name: string) => {
return Fn.split(',', ssm.StringParameter.valueForStringParameter(scope, `${basePath}/${name}`));
};
if (usePublic ?? false) {
publicSubnetIds = getStringListParam('PublicSubnetIds');
publicSubnetRouteTableIds = getStringListParam('PublicSubnetRouteTableIds');
}
return Vpc.fromVpcAttributes(scope, 'DefaultVpc', {
vpcId: ssm.StringParameter.valueForStringParameter(scope, `${basePath}/VpcId`),
// TODO: this will only work if there is a subnet in each AZ within the region
availabilityZones: getStringListParam('AvailabilityZones'),
privateSubnetIds: getStringListParam('PrivateSubnetIds'),
privateSubnetRouteTableIds: getStringListParam('PrivateSubnetRouteTableIds'),
publicSubnetIds,
publicSubnetRouteTableIds,
});
} And this was very appreciated with CDK and helpful having the ability to synthesize account-agnostic CFN templates. |
during the AWS account creation we are creating some VPCs and pushing it's parameters to SSM, then people with this method can get their VPC by name. This was developed having in mind the CDK Pipelines limitation https://docs.aws.amazon.com/cdk/api/latest/docs/pipelines-readme.html#current-limitations. Having this there is no need for local permissions or the need to assume cross-account roles for fetching all the VPC info in |
I am seriously confused about why the code you're showing me would ever have worked. The following line of code would make it so that it never could have, and it has been in there for 6 months. https://github.com/aws/aws-cdk/blame/master/packages/@aws-cdk/aws-eks/lib/cluster.ts#L962 That is, unless:
As soon as that line is trying to select more than one tokenized list of subnets, the code cannot have worked. |
now I'm also confused, indeed, we were only using VPCs with only private subnets and we never had the chance to test it with public subnets since the VPCs are all private |
Okay, that gives me something to go on. Thanks. |
This PR has a fix similar to #12040, and introduces more explanations and safeguards around the mechanism of importing a VPC using `fromVpcAttributes()`. This is not the recommended way of importing VPCs, but many users really don't want to use lookups so we'd better make it a little safer. This PR contains: * A fix in the EKS library to have it stop logging subnet IDs to metadata if it looks like the subnet ID will lead to the aforementioned synthesis error (similar to the fix in the linked PR). * A validation in the EKS library to stop a similar-but-different error from occurring if people select multiple VPC subnet groups from a VPC imported from token lists; this can never work and we might as well tell them directly. * A metadata warning added to VPCs imported using `Vpc.fromVpcAttributes()`, to inform users that their VPC imported in this way has a good chance of not working in all cases they expect it to. * A mechanism to specify the length of deploy-time lists at synthesis time, by passing an `assumedLength` parameter to `Fn.split()`. This will produce a list that is safe for manipulation. * A note on how to use `Vpc.fromVpcAttributes()` in the `ec2` README. Fixes #12160.
This PR has a fix similar to #12040, and introduces more explanations and safeguards around the mechanism of importing a VPC using `fromVpcAttributes()`. This is not the recommended way of importing VPCs, but many users really don't want to use lookups so we'd better make it a little safer. This PR contains: * A fix in the EKS library to have it stop logging subnet IDs to metadata if it looks like the subnet ID will lead to the aforementioned synthesis error (similar to the fix in the linked PR). * A validation in the EKS library to stop a similar-but-different error from occurring if people select multiple VPC subnet groups from a VPC imported from token lists; this can never work and we might as well tell them directly. * A metadata warning added to VPCs imported using `Vpc.fromVpcAttributes()`, to inform users that their VPC imported in this way has a good chance of not working in all cases they expect it to. * A mechanism to specify the length of deploy-time lists at synthesis time, by passing an `assumedLength` parameter to `Fn.split()`. This will produce a list that is safe for manipulation, and removes the limitations addressed by the previous bullets. * A note on how to use `Vpc.fromVpcAttributes()` in the `ec2` README. Fixes #12160. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
@rix0rrr, my original question was not related to EKS at all, it is in general how to import an already existing vpc without hardcoding the vpcid in the code. Specifically either passing the values of vpcid, private subnet id's via CFN Export values or SSM params. It appears the issue was closed incorrectly related to a different issue about EKS. |
Many people don't commit or want to commit `cdk.context.json`, and are subsequently annoyed that they can't use `Vpc.fromLookup()` in a pipeline. Make it very clear that this is the way CDK is designed to work and they must do it. Relates to aws#12160 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This PR has a fix similar to aws#12040, and introduces more explanations and safeguards around the mechanism of importing a VPC using `fromVpcAttributes()`. This is not the recommended way of importing VPCs, but many users really don't want to use lookups so we'd better make it a little safer. This PR contains: * A fix in the EKS library to have it stop logging subnet IDs to metadata if it looks like the subnet ID will lead to the aforementioned synthesis error (similar to the fix in the linked PR). * A validation in the EKS library to stop a similar-but-different error from occurring if people select multiple VPC subnet groups from a VPC imported from token lists; this can never work and we might as well tell them directly. * A metadata warning added to VPCs imported using `Vpc.fromVpcAttributes()`, to inform users that their VPC imported in this way has a good chance of not working in all cases they expect it to. * A mechanism to specify the length of deploy-time lists at synthesis time, by passing an `assumedLength` parameter to `Fn.split()`. This will produce a list that is safe for manipulation, and removes the limitations addressed by the previous bullets. * A note on how to use `Vpc.fromVpcAttributes()` in the `ec2` README. Fixes aws#12160. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@pandrel Have you found the fix for this problem. I am currently facing the same issue. |
@rix0rrr I'm building a CF template with CDK that I want to use in the AWS Marketplace, therefore I need to get a VPC from user input. I was hoping for this code to work, but I get CfnParameter vpcId = new CfnParameter(this, "VPC_ID");
vpcId.setType("AWS::EC2::VPC::Id");
CfnParameter availabilityZones = new CfnParameter(this, "AVAILABILITY_ZONES");
availabilityZones.setType("List<AWS::EC2::AvailabilityZone::Name>");
CfnParameter publicSubnetIds = new CfnParameter(this, "PUBLIC_SUBNET_IDS");
publicSubnetIds.setType("List<AWS::EC2::Subnet::Id>");
IVpc vpc = Vpc.fromVpcAttributes(this, "LDHVPC", VpcAttributes.builder().
vpcId(vpcId.getValueAsString()).
availabilityZones(availabilityZones.getValueAsList()).
publicSubnetIds(publicSubnetIds.getValueAsList()).
build()); |
I am using the ec2.Vpc.fromLookup() with tags option to import an existing vpc. example: const envName = 'dev' // passed from construct stack props but using fixed value for example
const vpc = ec2.Vpc.fromLookup(this, 'vpc', {
tags: { 'envName': envName}
}) |
If you are already using CfnParameter to provide vpcId, then you can use ec2.Vpc.fromlookup() with explicit vpcid option. const vpcId = 'vpc-xxxxx'
const vpc = ec2.Vpc.fromLookup(this, 'vpc', {
vpcId: vpcId
}) Any specific reason you are adding the extra attributes ? |
@pandrel that was the first thing I tried: CfnParameter vpcId = new CfnParameter(this, "VPC_ID");
vpcId.setType("AWS::EC2::VPC::Id");
IVpc vpc = Vpc.fromLookup(this, "LDHVPC", VpcLookupOptions.builder().
vpcId(vpcId.getValueAsString()).
build()); That gives an error |
My mistake, repeated the scenario and tested again .. got the same error as mentioned by you. |
You can get around this by synthesizing the stack from your local environment. The lookup will be triggered and the results cached in the cdk.context.json file. Commit that file. Then, in your pipeline runs, they will use that cached value instead of actually performing the lookup into AWS and thus you won't need to worry about the cross account permissions. |
Issue:
I am trying to import an existing vpc to deploy few lambda, ecs and albs in private subnets. Running into issues when trying to import the vpc using ec2.Vpc.fromLookup or ec2.Vpc.fromVpcAttributes.
The existing vpcid, azs, privatesubnets are exported as
dev-vpcId. - value: 'vpc-xxxxx'
dev-azs - value: 'us-east-1a,us-east-1b'
dev-privateSubnets - 'subnet-xxxx,subnet-yyyy'
Error
with ec2.Vpc.fromLookup() we cannot use import values
Error
Please advise on the right method to import an existing vpc with details from the export values.
This is a 📕 documentation issue
The text was updated successfully, but these errors were encountered: