Service Discovery and Proxying

Delivery of software as microservices running on immutable and self-sufficient containers is a very sobust method and has gained a lot of popularity in the recent years. Containers usually expose tyhe microservice as a web service acccessible through a certain port number on the host. Because host machines are able to run many conatiners and the fact that these containers need to be started and shut down quickly and easily without any side effects, it is not really feasible for consumers of these web services to point to manually assigned hosts and ports.

It is good practice to let the containers run on random ports, Docker can assign a random unused port to a container, for example. This removes the overhead of having an entity that keeps track of port number assignment, but consumers need to reach the service through a standard address on a standard port (usually port 80 or 443), like;

https://api.my-webservice.net

While the containers are serving at random ports accessible through their IP addresses;

https://172.16.0.21:23091
https://172.16.0.21:75894
https://172.16.0.21:12439

The example above shows all three containers tunning from the same host with IP address 172.16.0.21

The standard solution is to put a reverse proxy (like Nginx or HAProxy) that translates the published standard address into the private IP and port numbers exposed by the containers as shown in the diagram below. The reverse proxies also serve load balancers to distribute the traffic evenly across the containers.

However the proxy service still needs configuration that needs to be updated every time a container is added to the pool or removed, so this ideally should be done automatically, through the use of Service Discovery. Tools like Consul work really well in this space. Consul is a Service Discovery tool (like Zookeeper etc) that can be easily integrated with reverse proxies to update their configuration dynamically - using Consul Template. Consul Template can be configured to populate values from Consul to a file system, like Nginx’s configuration file.

We still need a way to update Consul whenever there is a new container running or a running container is stopped, the proces is called Service Registration. Registrator is one such tool that integrates well with Docker, it watches for new Docker containers and inspects them to determine what service (basically anything listening on a port) they provide and adds them to Consul. With all these in place addition or removal of a service, running as a Docker container listening on a port, will dyamically be made available to the consumers of that service.

The above diagram illustrates the full set of components, at a high level, that achieve Service Discovery for containerized microservices - which is the key to distributed services.