Hey everyone, I'm currently working on a charm for NS1, which is a DNS service accessible via API. There are quite a few of these types of services available and I'd like to develop a best practice about how the Juju model is presented as DNS. My hope is this would eventually be something that Juju includes in it's model, but for now charms seem to be a clean way to present this.
My proposal for how public DNS would be configured for mapping a juju deployment to resolvable DNS records is as follows: Given a root TLD: example.tld which represents the root of a model, the following bundle would be represented as such: haproxy/0 104.196.197.94 mariadb/0 104.196.50.123 redis/0 104.196.105.166 silph-web/0 104.196.42.224 silph-web/1 104.196.117.185 silph-web/2 104.196.117.134 I'd expect the following for DNS values haproxy.example.tld - 104.196.197.94 0.haproxy.example.tld - 104.196.197.94 mariadb.example.tld - 104.196.50.123 0.mariadb.example.tld - 104.196.50.123 redis.example.tld - 104.196.105.166 0.redis.example.tld - 104.196.105.166 silph-web.example.tld - 104.196.42.224, 104.196.117.185, 104.196.117.134 0.silph-web.example.tld - 104.196.42.224 1.silph-web.example.tld - 104.196.117.185 2.silph-web.example.tld - 104.196.117.134 I find this to be the simplest form for delineating applications and units as DNS, but I'd like some opinions on design before I implement this in the NS1 charm (and probably eventually other cloud-specific providers) as a base layer. Thanks, Marco Ceppi
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
