8th December 2019
I already briefly wrote about the idea of having dynamically discoverable upstreams in NGINX when I covered the topic of NGINX Extended. With the boom of microservices and containers scattered all over the place there was suddenly a need for something that would serve as a single source of truth. When solutions like Mesos/Marathon or Kubernetes kicked in, notion of having services statically assigned to particular address and/or port went straight to the trash. That’s exactly where Consul comes into play. I first crossed my paths with it years ago when it was both relatively new concept and software. These days I think it’s safe to say that, along etcd, it became industry’s standard. But even with its mature state, it solves only half of the problem – it registers and allows services to discover each other for variety of connection purposes, but if there’s anything that needs to serve as an application for HTTPs reverse-proxy, it has to be relatively static. Or does it?