Service Discovery = how your individual services know about each other and talk to each other to create a full solution that is a website, platform, saas.
If all your services run on a single machine (database, http server, server-side application), your service discovery is YOU typing localhost in to all the configs.
If you have two machines, your service discovery might be, you editing the /etc/hosts file and adding aliases like:
10.0.88.9 database
10.0.88.10 webserver
You do the service discovery by hand.
Hashi Consul, is an application that runs as a service. Consul has 2 modes, server and agent. Anything can register against the consul API to be a service. You can have services attached on each machine consul agent runs, then the consul agents will talk to consul servers, and let everything in the cluster know what services are running and where.
You can then ask any consul server via the api, for a service via the DNS name.
The standard pattern is something like webserver.service.consul this is the address you would "dig".. and consul would return an IP address.
Consul is better, because consul will de-register dead services after some time, consul also, only sends requests to services that are UP.
Thank you for your reply! So, have I understood it correctly that when people say "Don't use DNS for Service Discovery", it's because of DNS cannot really determine if a service is dead? The domain name might be cached even though the service is gone?
To over-simplify - yes, DNS by design will resolve to IP addresses even if those IP addresses have not been used for 90 years. (assuming that the DNS servers are still there).
DNS in hashi consul is a matter of convenience, and also does routing to services that are available, or in a particular data-center.
If you like to live dangerously, you could implement very primitive service discovery with DNSmasq, but you should not.
DNS itself is not a bad or a good thing, it depends what you use it for, and the tolerances of caching, stale data, failures that your systems will put up with.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Service Discovery = how your individual services know about each other and talk to each other to create a full solution that is a website, platform, saas.
If all your services run on a single machine (database, http server, server-side application), your service discovery is YOU typing
localhostin to all the configs.If you have two machines, your service discovery might be, you editing the /etc/hosts file and adding aliases like:
10.0.88.9 database
10.0.88.10 webserver
You do the service discovery by hand.
Hashi Consul, is an application that runs as a service. Consul has 2 modes, server and agent. Anything can register against the consul API to be a service. You can have services attached on each machine consul agent runs, then the consul agents will talk to consul servers, and let everything in the cluster know what services are running and where.
You can then ask any consul server via the api, for a service via the DNS name.
The standard pattern is something like
webserver.service.consulthis is the address you would "dig".. and consul would return an IP address.Consul is better, because consul will de-register dead services after some time, consul also, only sends requests to services that are UP.
Thank you for your reply! So, have I understood it correctly that when people say "Don't use DNS for Service Discovery", it's because of DNS cannot really determine if a service is dead? The domain name might be cached even though the service is gone?
To over-simplify - yes, DNS by design will resolve to IP addresses even if those IP addresses have not been used for 90 years. (assuming that the DNS servers are still there).
DNS in hashi consul is a matter of convenience, and also does routing to services that are available, or in a particular data-center.
If you like to live dangerously, you could implement very primitive service discovery with DNSmasq, but you should not.
DNS itself is not a bad or a good thing, it depends what you use it for, and the tolerances of caching, stale data, failures that your systems will put up with.