Name: puppet-psick
Owner: Example42
Description: An opinionated, integrated, extendable Puppet infrastructure module.
Created: 2017-09-17 10:09:41.0
Updated: 2017-12-19 19:50:36.0
Pushed: 2018-01-15 15:41:38.0
Size: 573
Language: HTML
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
This is the PSICK (Puppet Systems Infrastructure Construction Kit) module.
It is what we call an Infrastructure Puppet module. It provides:
It can be used together with the PSICK control-repo (check the Hiera data there for sample usage patterns) or as a strandalone module, just:
include psick
This doesn't do anything at all, by default, but is enough to let you manage everything via Hiera.
In the following examples we will use Hiera YAML files, but any backend can be used: psick is a normal, even if somehow unusual, Puppet module, with classes (a lot of them) whose params can be set as Hiera data, defines, templates, files, fuctions, custom data types etc.
Psick “language” has the syntax of any Hiera supported backend (here we use YAML), and the semantic you are going to discover here.
The module provides 3 major features:
Psick can manage the whole classification of the nodes of an infrastructure. It can work side by side and External Node Classifier, or it can totally replace it.
All you need is to include the psick class and define, using `${::kernel}_class` parameters, which classes to include in a node in different phases.
Psick provides 4 phases, managed by the relevant subclasses:
An example of configurations, both for Linux and Windows nodes that use all the above phases:
# First run mode must be enabled and each class to include there explicitely defined:
psick::enable_firstrun: true
psick::firstrun::linux_classes:
hostname: psick::hostname
packages: psick::aws::sdk
psick::firstrun::windows_classes:
hostname: psick::hostname
packages: psick::aws::sdk
# Pre and base classes, both on Linux and Windows
psick::pre::linux_classes:
puppet: ::puppet
dns: psick::dns::resolver
hostname: psick::hostname
hosts: psick::hosts::resource
repo: psick::repo
psick::base::linux_classes:
sudo: psick::sudo
time: psick::time
sysctl: psick::sysctl
update: psick::update
ssh: psick::openssh::tp
mail: psick::postfix::tp
mail: psick::users::ad
psick::pre::windows_classes:
hosts: psick::hosts::resource
psick::base::windows_classes:
features: psick::windows::features
registry: psick::windows::registry
services: psick::windows::services
time: psick::time
users: psick::users::ad
# Profiles for specific roles (ie: webserver)
psick::profiles::linux_classes:
webserver: apache
psick::profiles::windows_classes:
webserver: iis
The each key-pair of these $kernel_classes parameters contain an arbitrary tag or marker (users, time, services, but could be any string), and the name the class to include.
This name must be a valid class, which can be found in the Puppet Master modulepath (so probably defined in your control-repo `Puppetfile`): you can use any of the predefinied Psick profiles, or your own local site profiles, or directly classes from public modules and configure them via Hiera in their own namespace.
To manage exceptions and use a different class on different nodes is enough to specify the alternative class name as value for the used marker (here 'ssh'), in the appropriate Hiera file:
psick::base::linux_classes:
ssh: ::profile::ssh_bastion
To completely disable on specific nodes the usage of a class, included in a general hierarhy level, set the class name to an empty string:
psick::base::linux_classes:
ssh: ''
This is the classification part, since it's based on class parameters, it can be managed with flexibility via Hiera and can cohexist (even if this might not be an optimal choice) with other classifications methods.
The pre -> base -> profiles order is strictly enforced, so we sure to place your class in the most appropriate phase (even if functionally they all do the same work: include the specified classes) and, to prevent dependency cycles, avoid to set the same class in two different phases.
If you are lazy or want to try some predefined defaults (always WIP) you can simply try to use one of our embedded sets of configurations, note that you can customise and override everything, in your control-repo hiera data.
For example, to use Psick predefined defaults (as in `data/default/*.yaml`):
psick::auto_conf: default
To use, instead, some hardened defaults (as in `data/hardened/*.yaml`):
psick::auto_conf: hardened
The auto configuration settings are defined at module level hierarchy, so they can be overwritten in the environment's Hiera data.
Psick provides out of the box profiles, based on (Tiny Puppet, to manage common applications. They can replace or complement component modules when applications can be managed via packeages, services and files.
They have generated from a common template so have standard parameters, and are always called `psick::$app::tp`.
For example to configure Openssh both client and server settings we can write something like:
# By including the psick::openssh::tp profile we install Openssh via tp
psick::base::linux_classes:
ssh: 'psick::openssh::tp'
# To customise the configuration files to manage at their options:
psick::openssh::tp::resources_hash:
tp::conf:
openssh: # The openssh main configuration file
template: 'profile/openssh/sshd_config.erb'
openssh::ssh_config # The /etc/ssh/ssh_config file
epp: 'profile/openssh/ssh_config.epp'
# To manage the variables referenced in the used templates (the have to map the same keys):
psick::openssh::options_hash:
AllowAgentForwarding: yes
AllowTcpForwarding: yes
ListenAddress:
- 127.0.0.1
- 0.0.0.0
PasswordAuthentication: yes
PermitEmptyPasswords: no
PermitRootLogin: no
Similary we could manage postfix with data like:
psick::base::linux_classes:
mail: 'psick::postfix::tp'
# To customise the configuration files to manage at their options:
psick::postfix::tp::resources_hash:
tp::conf:
postfix: # Postfix's main.cf
template: 'profile/postfix/main.cf.erb'
postfix::master.cf # master.cf
epp: 'profile/postfix/master.cf.erb'
Basides tp profiles, Psick features a large set of profiles for common baseline configurations.
Some of them are intended to be used both on Linux and Windows, others are more specific.
Here follows documentation on how to manage different common system configurations:
For some applications, besides standard tp profiles, there are dedicated profile classes and defines. Here's a list: