Recently I have been working on server side service discovery (#841). We have chosen Consul to achieve this functionality. In addition, I included Registrator, so we don’t have to take care of service registration (or deregistration) by ourselves. The good news is that they seem to work flawlessly with our current configuration, so can hopefully keep our jwilder’s nginx-proxy.
Consul and Registrator services are added to docker-compose files for requisition and example, so whenever you run those, the Consul UI (and API) should be accessible on port 8500.
I have also added an example of environment configuration allowing us to have multiple services accessed over the same host and port. It is available here: https://github.com/OpenLMIS/openlmis-blue/tree/poc-service-discovery
Little explanation over what’s happening there:
In order to achieve the goal of accessing services over single host and port, I had to override the nginx configuration template, so we can point to multiple upstreams.
I have introduced the VIRTUAL_LOCATION variable, which represents the location of the service like http://host/VIRTUAL_LOCATION (nested locations not supported, but it wouldn’t be a huge effort to introduce this, if needed), that needs to be provided for each service that also has VIRTUAL_HOST provided (again, we could make it optional and/or use container names, but I didn’t feel like we really need that kind of feature in PoC). Nginx-proxy also gets passed another volume, which is our modified template.
The template itself is a copy of original one, with different upstream generation (to divide those by VIRTUAL_LOCATION), and adjusted routing.
So, running with the provided example configuration, we would access requisition and example services under localhost/requisition and localhost/example respectively.
Let me know what do you think about this.