Host health check

[JasonN3]

trafficstars

Is your feature request related to a problem? Please describe. I have an application that can be active on a couple of hosts. Due to the way the application works, the active node hosts the web interface and the standby node returns a redirect to the active node. If I put both hosts in a host set, there's a chance the standby node would be selected and then the website will fail to load.

Describe the solution you'd like It would be nice if you could define a health check on the hosts or target so unhealthy hosts could still be in the host set, but not be used until they become healthy. The health check could be run on a regular schedule or run right before connecting. Running it right before connecting could slow down the connection, but would be the most accurate.

Describe alternatives you've considered Another option would be to put a load balancer that can run health checks in front of the nodes, but it seems a little excessive to run an extra server just for a health check.

Explain any additional use-cases This can be used for any application that you want to make available through Boundary. Whenever a restart of a server is required, you don't need to pull the server from the host catalog first. You can just restart the server and it won't be utilized until it passes the health check.

[omkensey]

This is an ideal case for deploying Consul alongside Boundary:

1. A Consul agent on each node serving the web GUI health-checks the service.
2. The active, "healthy" instance becomes part of the set of service endpoints while the "unhealthy" instance does not (or is removed if it recently changed from active to standby).
3. A Boundary worker is configured so that it can access the Consul DNS (e.g. a Boundary worker is also a Consul client node, "client" here meaning "not part of the control plane" and just implying that a Consul agent process is running on the Boundary worker and that the worker's DNS is properly configured to match -- Boundary itself doesn't need to know anything about Consul).
4. The Boundary target for the service is set up to use the Consul service DNS name as the embedded host. (You can just add that directly to the target config without needing the abstraction of host sets here.)
5. Users can connect to that target and it will resolve to whichever instance of the web GUI is active.

One caveat is that if TLS is involved, browser TLS verification will fail (not because of Consul, because the browser will be accessing the web service over 127.0.0.1 and that's probably not in the TLS certificate). Making this experience cleaner is an active area of Boundary development.

[anando-chatterjee]

Hi @JasonN3 thanks for logging this feature request. The scenario that you have described above is not something that we are looking to address in the near term. However I will keep this issue open so that community members can upvote it and show their support in order for us to reconsider this in the future.