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
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 (  => Array ( [host] => myservice.s.myapp.net [type] => TXT [txt] => 192.168.1.123:9976;192.168.1.124:9976 [entries] => Array (  => 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:
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.
Dec 11, 2011
© Céondo GmbH, 2014. © Céondo Ltd, 2007-2014. All rights reserved.