gitea-pages/engineering-guide/puppet/overview.md

Overview

Puppet is used in master mode and the general idea is to make large use of indipendent and (relatively) small puppet modules and composing profiles and roles based on them to create classes that are assigned to the hosts. By independence of puppet modules we mean that each puppet module targets a single functionality (eg. web server, afs client) and this is choosen to keep the code of the single module smaller, more coherent and easier to debug.

Furthermore the system makes use of some puppet modules from the puppet forge. These puppet modules are not accessed directly but through a PSI mirror.

Code and data are kept separated, using puppet modules for code and hiera for data. Secure data are safely managed inside hiera using hiera eyaml.

For each host the following parameters will determine how it will be configured:

• the puppet environment (that will determine the puppet role/profile code base)
• the sysdb data environment (that will determine the hiera code base)
• the puppet group (that will determine what files will be considered in the hiera code base)
• the role

All these elements are configured inside sysdb as attributes and are accessed by the puppet master via the ENC.

Here you can get a general overview:

Puppet Environments

---

We use Puppet environments for two purposes:

• roll out changes to a small subset of all systems first
• module development

The following environments exist:

• prod - The most stable, and most systems are attached to it. All changes to prod have to go through preprod first.

• preprod - production test environment

• Development environments. These are private to a single developer, can have names matching the regex ^[a-z]+[a-z,0-9,_]+$ like ganglia_issue_21 or klog_client, and are used for developing and testing changes. Generally, only individual systems are attached to these environments.