On Thu, Aug 6, 2015 at 5:23 PM, Matthew Ceroni <matthewcer...@gmail.com> wrote:
> Scenario: > > Managing DNS via Puppet. On the master I need to be aware of slave NS > servers so that the NS record can be put into the zone file. > > Creating a zone you supply an array with the name of all the name servers. > Hard coding this into a hiera file (as an example) doesn't scale well as > new servers come online. > > Also, on the slaves I need to be aware of the masters to allow for zone > transfer (again this is passed in via an array to the class that create the > zone). > > Is there a way I can pass, lets say a variable (ie: dns_slave = SLAVE-IP > and dns_master = MASTER-IP) between slaves and masters? That way on the > slaves I can compose my array of masters and pass that to the class and > vice verse on the masters. > > I know I can use exported resources but I am not really exporting a > resource just some data? Or would I encapsulate this in some sort of > resource and then export that? > > One option for doing this type of service discovery with puppetdb is puppetdbquery (https://github.com/dalen/puppet-puppetdbquery). For example, if your slave NS servers are configured using a profile called profile::nameserver::slave and the master is configured using a profile called profile::nameserver::master, the slave profile might query for something like: $dns_masters = query_nodes("Class[Profile::Nameserver::Master]", ipaddress) Conversely, the master profile might query for $dns_slaves = query_nodes("Class[Profile::Nameserver::Slave]", ipaddress) The $dns_masters variable would end up as an array of ipaddresses, listing all nodes which include the profile::nameserver::master profile. The $dns_slaves array would similarly contain a list of ipaddresses listing nodes which include profile::nameserver::slave. There are two big caveats with this approach: 1) you have a circular dependency; when you boot new infrastructure, you'll need to run puppet a few times in order for all the nodes to discover each other. 2) if a node drops out of puppetdb, it will be removed from your configuration. For example, if you configure a puppetdb node ttl and then somebody disables puppet on one of the DNS servers, after the node ttl expires the node will disappear from puppetdb and will consequently be de-configured. If somebody assumes that puppetdb data is ephemeral and does a node deactivate on a bunch of nodes it will cause configuration changes. If you somehow generate empty catalogs, you will also have nodes drop out of configuration. The only workaround I'm aware of is to explicitly check the results and either fail() if you get back an unexpectedly low number of results, or to make management of the config files in question conditional upon the size of the returned array. For example, you may decide that you do not wish to manage config files for DNS slaves when there are zero masters. The advantage of this approach is that you can still bootstrap, whereas if you fail you have a more complicated question around bootstrapping a cluster. -- Daniel Dreier Technical Operations Engineer GPG: BA4379FD -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAGk8suZ0TQ%3D2_y%2Bjbbu08r_ZpRdh2oj3a5DUi5PdRKsiWTJKFQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
