Using CTS, we are able to synchronize dynamic services orchestrated by Nomad and registered in Consul /w Hosts in Host Sets that we can then create targets for appropriate users.
However, when building a target, it requires that we define a port, which couples the target to a single service instance rather than the entirety of the service. I understand that Boundary is not a load balancer, but for the purpose of having a highly available connection to a highly available service, is there a way around this limitation? If not, are there patterns folks have tried that will allow a boundary target to represent the entirety of the service instead of just a single instance?
Thanks!
I’m not a deep Consul expert but let me make sure I understand what the situation is:
- You have a set of microservices running on dynamic ports, so different instances of the same microservice have different ports
- Those services are being registered with Consul – so they all show up in Consul DNS but accessible on different port numbers, so the base service DNS name isn’t useful as a target name.
Given that, I can think of a couple of options worth exploring:
- Set up Consul service mesh and join a Boundary worker to the mesh. This should allow you to expose a consistent proxy port that will be forwarded through the mesh to any of the destination services. Setting up the service mesh is beyond the scope of what I can advise on but the Consul Discuss category may be useful to you there.
- Set up a load balancer that can load-balance using SRV records or has a direct integration with Consul’s service API, that a Boundary worker can access. There are several that can do this but the one I personally know best is HAProxy.
Now that you have a consistent port and address, you can use that in your Boundary target.
1 Like
Hi @omkensey, thanks so much for the reply. Yes, your understanding of my question and context is correct!
Your proposal makes a lot of sense and is what I figured we would need, essentially we need an instance serving as a load-balancer that we register as the target for a particular service.
My org does have Consul Connect set up, we would just need to set up an ingress gateway for each service and configure CTS to register those gateways to targets.
We will look to plan this work out, thanks again for the reply! If there are other potential solutions that come to mind, please don’t hesistate to share.
I think maybe one cool proposal would be to support Consul Connect services as a type of “Host”. This would be quite the integration though, as it would require Boundary workers to spawn a connect proxy to serve for the target, this can obviously happen on the network TCP layer. That connect proxy would then have all the information available from Consul to produce the proxy configuration required to route traffic to the available instances that the service represents.
This is actually exactly what producing a Connect Ingress Gateway would do, except the burden of maintaining the gateway would be offloaded to Boundary as native support. The other benefit is that the ingress gateway can come up and be torn down on demand, removing the need for a persistent gateway to exist, further improving the security footprint of connections to services.