On Sun, Sep 25, 2016 at 2:25 AM, Casey Marshall < casey.marsh...@canonical.com> wrote:
> Awesome idea! Probably more of a wishlist thing at this point.. but can we > also add SSHFP records for all the units? > Great idea! > -Casey > > On Sat, Sep 24, 2016 at 11:47 AM, Marco Ceppi <marco.ce...@canonical.com> > wrote: > >> 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 >> >> +1 to the scheme, and +100 to the idea of the controller being a DNS resolver for units. I have exactly the same scheme in my local juju dns tool (which uses a dnsmasq zone file), minus the RR entries. My root domain is just <model>.juju. Having a charm I can add to just give me that in dev would be awesome, even more awesome if I have the option to use same charm in CI/prod too. It would make configuration, scripting and debugging much easier, as well as provide a basic cross-protocol load balancing OOTB (well, charm would need updating to use the DNS, I guess). A few questions: 1) Any thoughts on TTL for units? I guess it's possibly not too much of a problem, as charms will have explicit info as to other units, but there may be some fun corner cases. 2) Could we add a charmhelpers function that could turn a unit name string into its canonical dns? Like we do already for url/path-safe unit names, IIRC? Even better, down the line, if juju could provide them in the hook env, that would be sweet. 3) In the client interface layer for the charm, do you think it might be possible to enable short-term dns caching for the unit? We just found yet another performance issue where this would have really helped. I realise this might be the wrong place to do it, but I thought I'd check. Thanks -- Simon
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
