Serverless Puppet with control repo, Hiera, roles and profiles and Puppet Bolt
The traditional way of managing systems with Puppet is to install Puppet agent on the nodes being managed and point those agents to a Puppet server (more details here). This approach works well for environments with tens or hundreds of nodes, but is an overkill for small environments with just a handful of nodes. Fortunately nowadays Puppet Bolt enables you to push configurations to the managed nodes via SSH and WinRM. When using Bolt the catalog (desired state) is created on the computer running Puppet Bolt using facts from managed nodes and then sent to the managed nodes to be applied.
Fattening the workflow, part 5: Hiera and content encryption
Separating data from code in Puppet modules is advisable as it improves reusability of code. The separation can be accomplished with Hiera by having separate levels based on facts, organizational units, locations, etc.
Hiera can also be used for storing private data that needs to be protected and must not be readable by outsiders. Typically the data, like all other code, is stored in a version control system that may be located outside the organisation. In such a case Hiera encryption is a must.
Fattening the Puppet workflow, part 1: The control repository
If editing Puppet code and Hiera directly with puppetmaster feels too easy, you can complicate the Puppet workflow as much you like by adding more components to the palette. Adding the so called control repository and r10k to Puppet environment maintenance instantly adds several phases to your initially simple workflow. There are also benefits that I’ll discuss later on.
The control repository (control repo for short) is a Git repository that is used to create dynamic Puppet environments on the Puppet master. Each Git branch can be turned into a matching Puppet environment. The name of the default branch, production, is the same as the environment the Puppet agents use by default. The content of the control repo branches look like this:
Määriteltyjen resurssien luonti suoraan Puppet-luokista
Jotkin Puppet ENC:t (External Node Classifier), hyvänä esimerkkinä Foreman, eivät tue määriteltyjen resurssien (Defined Resource Types) käyttöä suoraan, vaan kaikki konfiguraatiot pitää sisällyttää Puppet-luokkiin.
Myös Hieran kanssa määritellyt resurssit ovat hieman ongelmallisia, koska ne pitää erikseen luoda create_resources funktiolla. Eräs ratkaisu on määrittää kaikki create_resources -funktiot site.pp-tiedostossa (sovellettu täältä):
create_resources('mysqldump::backup',hiera('mysqldump_backups', {}))
Tämän lähestymistavan ongelma on se, että uudet määritellyt resurssit pitää muistaa lisätä site.pp-tiedostoon.
Yksinkertaisempi ja myös Foremanin kanssa toimiva ratkaisu on luoda määritellyt resurssit suoraan Puppet-moduulin pääluokasta (sovellettu täältä):