feat: Add module to migrate from public dns to private setting

[sanster23]

Feat: Adding a new module here so that users who have setup an AWS External DNS WandB stack can migrate it to a private stack (which is only accessible inside AWS network)

Assumptions/Pre-reqs:

• AWS external dns setup ready
• User has a private network setup in AWS (for eg: OpenVpn)
• User has a Private hosted zone setup in AWS

New Module added - migrate-public-to-private. This module will create following resources and will not touch any of the current external stack resources, so this will be a plug and play solution that introduces no drift in current terraform.

If users need to migrate to private they can just add this module. If they want to revert to original public setting, simply remove this module.

Below is a list of resources that will be created for private access:

• NLB in private subnet
• Security group for NLB
• Target Group and Listener
  • K8s ALB will be the target
• Route53 DNS record in private hosted zone
  • Record points towards NLB.

New flow should look like this:

And the new sample tfvars with variables introduced:

namespace   = "wandb"
domain_name = "mywandb.io"
subdomain   = "test"
zone_id     = "Zxxxxxxxxxxx"
wandb_license = "xxxx"

migrate_public_to_private           = true
private_hosted_zone_id              = "Zxxxx"
private_dns_network_id              = "vpc-xxx"
private_dns_network_cidr_block      = "10.x.x.x/16"
private_dns_network_private_subnets = ["subnet-xxxx", "subnet-xxxx"]

Attaching output and screenshot

out.log

[flamarion]

In this first iteration, I think it's fine we make the customer input all data from their private network. We can improve it in the future and create all all of these things if the customer do not supply the network configuration.
Main changes here are:

• Ensure to use the dynamic configuration from main module to configure the ALB. Making it tied to a string concatenation is very fragile, so we need to ensure we're pointing to something that exists in the main module without worry about names.
• Do not use the private network from the main module in the examples. They are used by Kubernetes Cluster and we don't want to mix the subnets. Leave this decision for the customners.

[flamarion]

You should use the output from the main module or make this an env var.
Example: If this is part of the main module, we may want to use local.lb_name_truncated

[sanster23]

ack, updated code

[flamarion]

If I leave this an empty string, what is the result?
It should be mandatory, or a new private hosted zone will be created if empty.

[sanster23]

oh yes, made this params mandatory

[flamarion]

These network configurations from the main module are used to configure the Kubernetes cluster.
The example shouldn't use it, but the network configuration from where the Customer will access the service.
If the customer wants to use the same network as the Kubernetes cluster, that's okay, but I don't recommend putting the Kubernetes and the VMs that will use the service in the same subnet.
We must let the customer decide.

[sanster23]

ack, updated code

[flamarion]

Could you add the same instructions you added to the PR to a README.md inside the module and in the example folder?