Readme

|

Synopsis

This Puppet module configures settings a full Puppet environment, i.e. Puppet master, Puppet agents pointed to the master.

Optionally:

• R10k to connect to a control repo and manage puppet modules
• webhook listener to trigger r10k when a puppet module has been updated.
• PuppetDB for exporting and storing resources.

The syntax is specifically for Puppet Core 8 and Rocky 9, although might work elsewhere as well. This module is also designed to work with Foreman as External Node Classifier (ENC), although it does not install Foreman.

WARNING

Attention: Never use this puppet module on systems which have been previously configured manually. It is impossible to predict how and what would have been configured, hence previous configurations outside the scope of this module may be overwritten! Automated configurations require a test environment to verify that the module suits the purpose intended by the user, as well as tune the parameters, before deploying into live production

Features

Puppet server and agent

• if the host FQDN matches your specified Puppet master via $pt_pm_fqdn, it installs and configures a puppetmaster ready for serving with Foreman as ENC ( Foreman not yet included).
• Any other system becomes a puppet agent.

Firewall

• open firewall ports depending on choices above

Directories, Files and Services,

• manage directories and required files including permissions and selinux context (todo)
• start services as required

Optional

R10k service

• install r10k service on your puppetmaster. If you set $pt_use_r10kto true, it also installs r10k to connect to a control repo and manage the code available to clients via Puppetfile.

R10k Web hook

• installs a webhook listener If you set $pt_use_r10k_webhookto true, it also installs a simple webhook listener to watch for post_hooks from gitlab, and triggers the r10k deployment.

Puppetdb

• to do
• install node.rb from the foreman for puppetdb

Support

• Rocky 9
• Puppet Core 8

Parameter Inheritance

All parameters are listed in params.pp and inherited from there. Variable parameters are in the upper section and also documented in the top. These can be overridden by the ENC. Parameters in the bottom section (curly brackets) cannot be overridden and usually are used for keeping the code in the classes more readable.

Module Deployment

native Puppet deployment: via site.pp or nodes.pp

include cd_puppet

through Foreman

• ensure the module is present on the puppetmaster running Foreman in the module path, i.e. /etc/puppetlabs/code/environments/production/ . use r10k or clone the module there through git
• import the module in Foreman
• assign puppet_cd::params to the nodes in question, typically a host group.
• overwrite the value for $pt_pm_fqdnto match your puppetmaster's fqdn. This will overwrite the puppet.conf with the settings set in params.pp. It is highly recommended to use a test system first to see and fine tune those settings! Any node not matching this fqdn will become an agent.

Tests

• Puppet Lint
  • excluded tests:
    • --no-variable_scope-check: not applicable as we are inheriting parameters from params class. the lint check does not distinguish between facts and inherited parameters.
• Puppet Parser
• ERB Template Parser
• Sonar Quality Gate

Contact Us

contact Us

Documentation

Disclaimer

ConfDroid as entity is entirely independent from Puppet. We provide custom configuration modules, written for specific purposes and specific environments. The modules are tested and supported only as documented, and require testing in designated environments (i.e. lab or development environments) for parameter tuning etc. before deploying into production environments.