Skip to content
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

Add -resolve-hostnames flag #271

Merged
merged 1 commit into from
Jun 8, 2020
Merged

Add -resolve-hostnames flag #271

merged 1 commit into from
Jun 8, 2020

Conversation

lkysow
Copy link
Member

@lkysow lkysow commented Jun 3, 2020

Add a -resolve-hostnames flag to the service-address command that
defaults to false. If true, any service with a hostname as its address
will have that hostname resolved and the first ip written.

If false, (default) the hostname will be written. Consul now supports hostnames for mesh gateway addresses so that's why we're adding this now.

This is useful in the case of EKS where load balancers have hostnames.
For WAN federation we want to use the hostname because the underlying
IPs can change. For ingress gateways this command is used to set the
address field in the service definition which only accepts IPs. This
flag allows the service-address command to be used so the service
registration is valid and then we document that in the EKS case users
shouldn't use the ingress consul DNS and should instead set up their own
DNS that resolves to the load balancer.

Add a -resolve-hostnames flag to the service-address command that
defaults to false. If true, any service with a hostname as its address
will have that hostname resolved and the first ip written.

If false, the hostname will be written.

This is useful in the case of EKS where load balancers have hostnames.
For WAN federation we want to use the hostname because the underlying
IPs can change. For ingress gateways this command is used to set the
address field in the service definition which only accepts IPs. This
flag allows the service-address command to be used so the service
registration is valid and then we document that in the EKS case users
shouldn't use the ingress consul DNS and should instead set up their own
DNS that resolves to the load balancer.
@lkysow lkysow requested a review from a team June 3, 2020 22:32
@lkysow lkysow marked this pull request as draft June 3, 2020 22:32
@lkysow lkysow marked this pull request as ready for review June 4, 2020 20:15
@lkysow
Copy link
Member Author

lkysow commented Jun 4, 2020

I've tested this in EKS with Freddie's latest version of Consul that supports hostnames and it works.

@lkysow lkysow added this to the Consul 1.8.0 milestone Jun 4, 2020
@lkysow
Copy link
Member Author

lkysow commented Jun 5, 2020

So to be more clear, for wan federation this value is used in

service {
  tagged_addresses {
    wan {
       address = "<here>"
     }
   }
}

which supports hostnames now with the latest Consul 1.8 beta.

But for ingress gateways this value is also used for the actual address of the service so that <svc>.ingress.consul resolves to the WAN IP.

service {
  address = "<here>"
}

In this case, we have to provide a way to resolve to ips since a hostname isn't supported in the address field.

@lkysow
Copy link
Member Author

lkysow commented Jun 8, 2020

I need to re-test that this is necessary. On Friday I learned we can use a hostname for the address field.

@lkysow
Copy link
Member Author

lkysow commented Jun 8, 2020

After further investigation I've seen that while Consul will allow you to set a hostname for the address, DNS resolution will fail unless recursors is set (https://www.consul.io/docs/agent/options.html#recursors) so this flag is necessary.

@lkysow lkysow merged commit 45ffd70 into master Jun 8, 2020
@lkysow lkysow deleted the service-address-dns branch June 8, 2020 22:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants