VPC module and using its subnets

[cjparsons74]

Hiya, I'm looking into adding ipv6 support since Amazon are going to charge for public IPv4 addresses so am deploying from scratch at the latest version.

I can see the VPC module is now being used in example/main.tf. There are also the subnets and vpc id configured as data still. Should the module replace the data? I tried that but have trouble because I don't know how ./network.tf can see the outputs from example/main.tf, where the vpc module is sourced.

I could move the eip and network interface down into example/main.tf and move the dependent variables around too?

[eana]

Hayo, the bitwarden-tf-aws module is assuming that you already have a VPC deployed.

The code under the example directory is completely independent from the module itself. It creates a VPC using the terraform-aws-vpc module and after that it will invoke the bitwarden-tf-aws module from the parent directory ../. The bitwarden-tf-aws module fetches the resources created by the VPC module (aws_vpc, aws_subnets and aws_route53_zone) using data resources (in the data.tf file).

I haven't dug into the IPv6 deeply, but I think it boils down to how the VPC is created, and then of course to adapt the module a little bit. Unfortunately, I am quite busy at work, but I will try to look into this in the coming days.

I hope this answers your question.

[eana]

Hey there, I have made some progress on the IPv6 issue. I still need to optimize the code a bit and if nothing unexpected shows up this weekend I will be able to publish the changes, please hang on.

[eana]

I didn't feel well and couldn't focus on this topic. There is an obstacle with IPv6, which prevents us from assigning the same IP address to the EC2 instance. Consequently, reliably updating the DNS record, especially using terraform, is not feasible. I'll keep thinking of a solution, but if I don't find a workaround, I may have to consider shutting this issue down.

@cjparsons74, do you have any ideas on a better approach to solve this IPv6 problem?

[cjparsons74]

Ah, thank you, I didn't realise you were thinking about it: I didn't mean to make a feature request! I hope to have a go myself but I don't know if I'll have success or when I'll get round to it. I'll let you know.

[cjparsons74]

I've seen people use a lambda function to check for an address change and update another resource but that's not very clean & could cost more than the IPv4 address.

[eana]

Another hack would be to use the aws cli in the init.sh script, but that means we have to give the instance access to Route53 and I don't think I want that.

[eana]

Hiya @cjparsons74,

Sorry it took me way too long to get back to you on this.

The good news: the rewrite finally landed in [PR #369] (merged yesterday), and it does solve the blocker we were stuck on back then.

On the VPC/module side: network.tf is gone entirely. The VPC module now lives in the root main.tf, and everything references its outputs directly. No more data.aws_vpc / data.aws_subnets lookups by tag, and no more confusion about how network.tf was supposed to see things created in example/. That whole two-directory setup is gone.

The EIP and the separate network interface are gone too. Traffic goes through a Cloudflare Tunnel now, so the instance doesn't need a public IPv4 at all. There's nothing left to shuffle between files. If you do need to reuse an existing VPC, you just pass use_existing_vpc and the IDs explicitly.

And the IPv6 problem we were exploring (the "can't pin an address to the instance / DNS updates get messy" thing): I ended up not needing to solve it head-on. Since there's no public IP, DNS is just a static CNAME to the tunnel, and the VPC comes up with IPv6 enabled by default. So if you were deploying fresh to get away from the IPv4 charges, current master handles that out of the box.

If you're still up for it, I'd love your help testing this against a real deployment. Would be good to have a second pair of eyes on a fresh spin-up (especially the tunnel wiring and the spot fallback), since you're exactly the "deploying from scratch" case it was designed for.

Thanks for hanging in there, and thanks for the Lambda/Route53 ideas back then. Turned out we didn't need either, but they got me thinking the right way.