feat: Support for wildcard domains #412
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #148
What
Allows for using wildcard domains via the ingress controller.
How
Domain
CR namingThe algorithm for creating domains was to aggregate all of the
rules.Host
s from ingresses and thelistener.hostnames
from Gateways. This would give us a list of ngrokDomain
CRs to create/update. We currently replace.
with-
in the domain name to create theDomain
CRs. This works fine expect that*
are not valid in kubernetes resource names. So we now replace*
withwildcard
when generating theDomain
CR Name. This makes the name now a valid k8s name.This could cause future problems if you want to reserve the domain
wildcard.example.com
as the name wouldn't be able to be distinguished from the one generated by*.example.com
as they would both generate aDomain
CR namedwildcard-example-com
. We should probably look at generating these names like we do forHTTPSEdge
CRs going forward to prevent this future problem, but this is not handled in this PR.HTTPS
Edge LabelsPreviously we would add a label to the
HTTPSEdge
CR with the domain. This causes problems when using wildcards since*
is not a valid character for labels. I initially debated about hashing the domain and using that as the label instead. However, we can extract thehostports
from the existing edge. ForHTTPSEdges
generated by the driver, they will only ever have a single domain perHTTPSEdge
and will always be listening on port 443. We can use this to compare if the edge in question is the same one as the one we are generating from the Ingress/Gateway configuration. This allows us to get rid of using the domain label or having to implement hashing for it.Breaking Changes
No, with the caveat that if you could hit the above edge case temporarily if you are using both
wildcard.example.com
and*.example.com