What you don't know can't hurt me. | ||
| --Edward S. Marshall | ||
In this chapter, you will learn why it's useful to separate your data and code. You will see how to set up Puppet's built-in Hiera mechanism, how to use it to store and query configuration data, including encrypted secrets such as passwords, and how to use Hiera data to create Puppet resources.
What do we mean by configuration data? There will be lots of pieces of information in your manifests which we can regard as configuration data: for example, the values of all your resource attributes. Look at the following example:
package { 'puppet-agent':
ensure => '5.2.0-1xenial',
}The preceding manifest declares that version 5.2.0-1xenial of the puppet-agent package should be installed. But what happens when a new version of Puppet is released? When you want to upgrade to it, you'll have to find this code, possibly deep in multiple levels of directories, and edit it to change the desired version number.
Multiply this by all the packages managed throughout your manifest, and there is there's already a problem. But this is just one piece of data that needs to be maintained, and there are many more: the times of cron jobs, the email addresses for reports to be sent to, the URLs of files to fetch from the web, the parameters for monitoring checks, the amount of memory to configure for the database server, and so on. If these values are embedded in code in hundreds of manifest files, you're setting up trouble for the future.
How can you make your config data easy to find and maintain?
Mixing data with code makes it harder to find and edit that data. But there's another problem. What if you have two nodes to manage with Puppet, and there's a config value which needs to be different on each of them? For example, they might both have a cron job to run the backup, but the job needs to run at a different time on each node.
How can you use different values for different nodes, without having lots of complicated logic in your manifest?
What if you have some nodes running Ubuntu 16, and some on Ubuntu 18? As you'll know if you've ever had to upgrade the operating system on a node, things change from one version to the next. For example, the name of the database server package might have changed from mysql-server to mariadb-server.
How can you find the right value to use in your manifest depending on what operating system the node is running?
What we want is a kind of central database in Puppet where we can look up configuration settings. The data should be stored separately from Puppet code, and make it easy to find and edit values. It should be possible to look up values with a simple function call in Puppet code or templates. Further, we need to be able to specify different values depending on things like the hostname of the node, the operating system, or potentially anything else. We would also like to be able to enforce a particular data type for values, such as String or Boolean. The database should do all of this work for us, and just return the appropriate value to the manifest where it's needed.
Fortunately, Hiera does exactly this. Hiera lets you store your config data in simple text files (actually, YAML, JSON, or HOCON files, which use popular structured text formats), and it looks like the following example:
--- test: 'This is a test' consul_node: true apache_worker_factor: 100 apparmor_enabled: true ...
In your manifest, you query the database using the lookup() function, as in the following example (lookup.pp):
file { lookup('backup_path', String):
ensure => directory,
}The arguments to lookup are the name of the Hiera key you want to retrieve (for example backup_path), and the expected data type (for example String).