Support DNS setup with different domain

[mjnagel]

Is your feature request related to a problem? Please describe.

Currently our NGINX setup assumes uds.dev as the domain. While this is great and works well for most dev use-cases sometimes it is helpful to deploy a dev/demo instance with a different domain and be able to inherit the dns setup from uds-k3d.

Describe the solution you'd like

By swapping uds.dev to the zarf var for DOMAIN, defaulting to uds.dev this would ensure that it remains as expected for current users but allows a configuration option for dev/demo scenarios where this is useful.

Describe alternatives you've considered

• End users can build their own k3d + metallb + nginx setup to account for this
• End users should not use k3d for their custom domain demo needs

[mjnagel]

@rjferguson21 I don't recall if there was a reason for us locking the setup down to only uds.dev, outside of being clear that this is a dev setup?

[rjferguson21]

I agree, I think it was mostly to avoid it being used outside of dev, as opposed to a technical limitation.

[joelmccoy]

I have another similar issue related to this. I am trying to test a multi-gateway setup locally on k3d (related to this issue in uds-core).

I am currently building a package to enable a custom Istio Gateway and associated Netpols/Virtual services to enable ingress on a different domain.

In order to test this I am deploying a new gateway using a new domain uds2.dev with self signed certs. I believe I now have the capabilities to provide CoreDNS overrides, but I don't have a method to override the nginx config to add domain routes to the new gateway.

Would we be against exposing the nginx config here as a value do that it can be overridden? If not, I'd be happy to toss up a PR.

Alternatively I could just create my own dev package, but would really like to hook into this package for continual updates if possible.

[mjnagel]

@joelmccoy definitely nothing technical stopping this, and as you indicated we just added support for coredns overrides. I think we have primarily been focused on the needs of core CI/dev where multi-domain isn't supported and wasn't really a consideration here. Adding support for the extra ports was similar - we have it now, but initially didn't have any support for that because core defaults to just using the default http/https ports.

I don't have any strong objections to exposing this as another option, with the same qualifications as the coredns and nginx port overrides - they aren't really tested in CI and it's sort of "use at your own risk and discretion". We do already have the note about this being for dev/CI only so I think we might be okay exposing more flexibility, we just don't want people to see this as a real cluster solution for prod type use cases.