If you are building your private PaaS and use
ZeroMQ you will end up with the issue of
distributing the ZMQ end points of your services to your
application. You can use a broker approach, but then, what if the
broker is moved to another node? It means that you always end up with
a situation where at least a minimal set of service entries need to be
distributed to your applications and workers.
The simplest approach is rsync and a text file. Just put everything
in a text file and copy it to all the servers. But then you need to
manage the list of servers and be sure that each server get the latest
version — even if you started the new server at the time you
distributed the new version... This starts to be complicated, this is
why the simplest approch is simply using the DNS infrastructure with
the TXT record.
If you are using djbdns, you can simply
add lines like this in your data file:
*.s.myapp.net:192.168.1.100:86400
'myservice.s.myapp.net:192.168.1.123\0729976;192.168.1.124\0729976:3600
'otherservice.s.myapp.net:192.168.1.123\0729976;192.168.1.124\0729976:3600
Now, the day you want to access the myservice from your application,
you simply get the DNS TXT record for the corresponding service.
print_r(dns_get_record('myservice.s.myapp.net', DNS_TXT));
Array
(
[0] => Array
(
[host] => myservice.s.myapp.net
[type] => TXT
[txt] => 192.168.1.123:9976;192.168.1.124:9976
[entries] => Array
(
[0] => 192.168.1.123:9976;192.168.1.124:9976
)
[class] => IN
[ttl] => 86400
)
)
It is simple, robust and allows you to benefit from all the work done
on the DNS — for example:
- you can access it from any languages (PHP, Python, Java, etc.) and the libraries are usually very robust;
- you can announce a different end point depending of the source ip, for example I am using this to announce the testing end points for the services running on the testing subnet;
- your DNS server is nice, you can normally extract a lot of stats from it;
- with several DNS servers, your system is robust.
Of course this is not to be used as a high speed distributed database,
but to distribute service information, this is working perfectly.
Update: Someone nicely pointed out that a SRV record can be used too. Totally right, but in my particular case, I store a JSON string with more than just the end point definition, this is why I need the TXT record flexibility. But if SRV fits your requirements, you should jump for it.
Update: For your information, this is effectively to power Cheméo.
