Basic usage of modules in puppet with hiera

Question

I want to use puppet to manage some servers. Even after reading dozens of documentation pages, it is not clear to me how to use modules and how to use them with hiera. As first experiment I wanted a user "admin" to be created on one node and found this module -> https://github.com/camptocamp/puppet-accounts

My /etc/puppet/hiera.yaml looks as simple as this

---
:backends:
  - yaml
:hierarchy:
  - node/%{::fqdn}
  - common
:yaml:
  :datadir: /etc/puppet/hieradata

My /etc/puppet/hieradata/node/node1.example.com.yaml contains this

---
accounts::users:
  admin:
    uid: 1010
    comment: admin
accounts::ssh_keys:
  admin:
    comment: ad
    type: ssh-rsa
    public: AAAAAAAAAAAAAA

This worked after I put this in my /etc/puppet/manifests/site.pp

hiera_include('classes')

class
{
    'accounts':
    ssh_keys   => hiera_hash('accounts::ssh_keys', {}),
    users      => hiera_hash('accounts::users', {}),
    usergroups => hiera_hash('accounts::usergroups', {}),
}

accounts::account
{
    'admin':
}

Is this good practice? To me it feels wrong to put that stuff into site.pp since it gets messed up when I later use more modules. But where else to put it? I also don't understand how this separates data from logic, since I have data in both, node1.example.com.yaml and site.pp (admin). Some help would be great..

Answer 1

To understand what hiera is, you should think simply that Hiera is a DATABASE for puppet, a database of Variables/values and nothing more.

For a beginner I would suggest to focus on other parts of the system, like how to create modules! and how to manage your needs (without complexity) and then slowly build the "smart" recipes or the reusable ones...

Your puppet will first sick for a file called sites.pp (usually is on your main $confdir (puppet.conf variable. I am not going to mention environments it is for later.)

e path is /etc/puppet inside that directory, you have a directory manifests . There is the place for your sites.pp

usually a sites.pp structure is:

node default {
  include *module*
  include *module2*
}

node /server\.fqdn\.local/ {
  include *module2*
  include *module3*
}

this means that you have a default Node (if the node name doesn't fit any other node, will use the default, otherwise it will use the regex matching of the node FQDN in this case server.fqdn.local .

The modules (module, module2 and module3) are stored inside the $modulespath set on your puppet.conf. In our case i will use the: /etc/puppet/modules

the tree will look like:

/etc/puppet/modules/
/etc/puppet/modules/module/
/etc/puppet/modules/module/manifests/
/etc/puppet/modules/module/manifests/init.pp
/etc/puppet/modules/module2/
/etc/puppet/modules/module2/manifests/
/etc/puppet/modules/module2/manifests/init.pp
/etc/puppet/modules/module3/
/etc/puppet/modules/module3/manifests/
/etc/puppet/modules/module3/manifests/init.pp

About classes: https://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html generally what i explained but from puppet labs: https://docs.puppetlabs.com/puppet/latest/reference/dirs_manifest.html

Answer 2

Please note that the example from the README

class { 'accounts':
  ssh_keys   => hiera_hash('accounts::ssh_keys', {}),
  users      => hiera_hash('accounts::users', {}),
  usergroups => hiera_hash('accounts::usergroups', {}),
}

is catering to users of Puppet versions before 3.x which had no automatic parameter lookup . With a recent version, you should just use this manifest:

include accounts

Since the Hiera keys have appropriate names, Puppet will look them up implicitly.

Answer 3

This whole thing still makes no sense to me. Since I have to put

accounts::account
{
    'admin':
}

in a manifest file to create that user, what for is hiera useful in this case? It doesn't separate data from logic. I have data in both, the .yaml file (ssh keys, other account data) and in a manifest file (the snippet above). By using hiera I expect to be able to create that user inside /etc/puppet/hieradata/node/node1.example.com.yaml but this is not the case. What is the right way to do this? What for is the example hiera file of this module useful? Wouldn't it be easier create an account the old style way in site.pp?