Use the DNS to Announce Your ZeroMQ Services

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.