Hosts file

This first sample is easy to understand and interpret, but definitely should not be used in place of a true Domain Name Server (DNS). A few years ago, I had a customer that was using a public cloud, but it had been acquired by a very large company, which had a team dedicated to managing corporate DNS. The turnaround for a DNS record was often 4 days, while many of the applications they launched had a lifetime of only a few days before being replaced with a new node. The solution had some issues for resolution if node networking information changed for a period of time, but it was an effective short-term solution until the policies around DNS were relaxed for the customer.

In the following example, we'll use a single profile that exports the FQDN and IP address of every system classified by profile::etchosts, which is to be consumed and actioned on by every node (including the originator) in the environment:

class profile::etchosts {
# A host record is made containing the FQDN and IP Address of the classified node
@@host {$::fqdn:
ensure => present,
ip => $::ipaddress,
tag => ['shoddy_dns'], }
# The classified node collects every shoddy_dns host entry, including its own,
# and adds it to the nodes host file. This even works across environments, as
# we haven't isolated it to a single environment.
Host <<| tag == 'shoddy_dns' |>>
}
If we wanted to ensure that we only collect host entries for hosts in the same Puppet environment, we can simply change our manifest to read Host <<| tag == 'shoddy_dns' and environment == $environment |>>.

This manifest contains both the exported resource and the resource collection call. Any node we include this on will both report its host record and retrieve all host records (including its own). Because we want to apply this code to all nodes in our infrastructure, we will place it outside of any node definition in site.pp, causing it to apply to all nodes in the infrastructure:

# site.pp
include profile::etchosts
# Provided so nodes don't fail to classify anything
node default { }

When we run our agent, we retrieve each host entry individually and place it in /etc/hosts. In the following example, I run this catalog against my Puppet Master. The Puppet Master retrieves each host entry found in PuppetDB and places it in /etc/hosts. The nodes reported are haproxy, appserver, and mysql. These nodes will be used for the rest of the examples in this chapter:

[root@pe-puppet-master vagrant]# puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for pe-puppet-master
Info: Applying configuration version '1529033713'
Notice: /Stage[main]/Profile::Etchosts/Host[mysql]/ensure: created
Info: Computing checksum on file /etc/hosts
Notice: /Stage[main]/Profile::Etchosts/Host[appserver]/ensure: created
Notice: /Stage[main]/Profile::Etchosts/Host[haproxy]/ensure: created
Notice: Applied catalog in 14.07 seconds

[root@pe-puppet-master vagrant]# cat /etc/hosts
# HEADER: This file was autogenerated at 2018-06-15 03:36:02 +0000
# HEADER: by puppet. While it can still be managed manually, it
# HEADER: is definitely not recommended.
127.0.0.1 localhost
10.20.1.3 pe-puppet-master
10.20.1.6 mysql
10.20.1.5 appserver
10.20.1.4 haproxy
As noted previously, this should not be seen as a replacement for a true DNS. It is a simple and functional sample of how to build and use a Puppet exported resource.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.46.36