We are in the process of moving a number of our services to the service discovery model whereas in the past services would be hardcoded. The topology is based on a large number of services on Windows driven by IIS and a number of Dockerized services. Each of these services need to be able to find each other.
We have been using the http catalog api to discover the services in the catalog.
However, for our dockerised services, we normally use the docker dns. Hence we were looking into the Consul DNS capabilities. That’s when we found that we may be using the service registration incorrectly.
In our setup, the IIS servers are all virtual applications on there own app pool, for instance, we have addresses lik:
ServiceA and ServiceB have their own app pool and are different applications in IIS.
We have registered these into Consul with:
- ServiceAddress = my.host.com/servicea
- ServicePort = 80
Which has lead to the dns lookup to be:
$ dig @192.168.140.64 -p 8600 servicea.service.consul
; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> @192.168.140.64 -p 8600 servicea.service.consul
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7270
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;servicea.service.consul. IN A
;; ANSWER SECTION:
servicea.service.consul. 0 IN CNAME my.host.com/servicea.
;; Query time: 262 msec
;; SERVER: 192.168.140.64#8600(192.168.140.64)
;; WHEN: Tue Jul 07 12:05:30 SAST 2020
;; MSG SIZE rcvd: 108
So we can change the registration in order to achieve this, but we would lose the ability to know the service address.
However, the question is, how are you meant to handle situations like this where IIS doesn’t have different ports but different paths to applications?
Does Consul handle this in someway? Are we meant to link the service name with the service endpoint on IIS?