SlideShare a Scribd company logo
Modules of
the twenties
Alessandro Franceschi
example42 Gmbh
@alvagante
A Bio based on talks: Obsessed by Puppet modules
I’ve been working on Puppet modules for more than 10 years.
Always looking for answers to problems like:
Reusability Puppet Camp San Francisco 2010: Re-use Your Modules!
Puppet Conf San Francisco 2013: Anatomy of a Reusable Module
Naming standards Puppet Camp Europe Ghent 2010: Puppet Modules and Module Standards
App deploy Puppet Camp Europe Amsterdam 2011: Automating Applications deployment with Puppi
Configurability Puppet Conf San Francisco 2012: Puppet modules for fun and profit
Puppet Camp Dublin 2012: Puppet Modules: an holistic approach
Optimization CfgMgmtCamp Ghent 2016 - Essential application management with Tiny Puppet
CfgMgmtCamp Ghent 2018 - Puppet Systems Infrastructure Construction Kit
Many things happened in module-land
Since when Puppet modules have been introduced, they succeeded in many
areas, like extendability to support new OSes, devices, IT objects,
interoperability, improved reusability and composability.
Puppet has evolved as well, with the introduction of Data in Modules,
functions in Puppet DSL, external facts, Tasks, Plans, Data Types.
In this presentation we will have an high level review of them.
New patterns have emerged over the years, here we focus on the ones I
prefer, in some cases they are so unorthodox that for someone they can
look like anti-patterns. I can explain. We will see them.
Well known Module paths and conventions
Common directories in modules we have always used:
manifests Puppet code in files with .pp extension whose names match class names
Class mysql is defined in mysql/manifests/init.pp
Class mysql::server in mysql/manifests/server.pp
files Static files used in the source argument of the file resource.
source => 'puppet:///modules/mysql/my.cnf' matches file mysql/files/my.cnf
templates Dynamic .erb or .epp templates used as argument of template() or epp()
functions. Typically used in the content arg of a file resource.
content => template('mysql/my.cnf.erb') matches file mysql/templates/my.cnf.erb
content => epp('mysql/my.cnf.epp') matches file mysql/templates/my.cnf.epp
lib Directory with custom functions, facts, types and providers in Ruby
language. This content is automatically synced to clients.
spec Directory for unix tests with Rspec Puppet.
Module paths added in more recent years
Directories added to modules for different purposes:
data Hiera data in module.
locales Multi language translations.
types Custom data types
tasks Bolt tasks
plans Bolt plans
facts.d External facts. Automatically synced to clients
functions Functions written in Puppet language
Custom Data Types
Puppet 4 comes with a rich type system for any kind of data, like:
String, Boolean, Integer, Array, Hash, Pattern, Struct, Undef...
It's possible to create custom data types to filter and validate our data.
They are shipped in the types dir of a module.
They are named and located in the module namespace:
Stdlib::Absolutepath is defined in stdlib/types/absolutepath.pp
New data types can use any other native or custom data type:
type Stdlib::Absolutepath = Variant[Stdlib::Windowspath, Stdlib::Unixpath]
Puppetlabs-stdlib module provide many useful additional data types.
Any module can provide its own types. IE, puppetlabs' ntp/types/poll_interval.pp:
type Ntp::Poll_interval = Integer[4, 17]
Bolt Tasks
They are scripts, in any language, which can be remotely executed via Bolt.
They are placed in the tasks dir, for each tasks we have the script and its json
metadata descriptor.
They are namespaced with the module, for example:
tp::test is placed under tp/task/test.sh with meta in tp/task/test.json
Scripts can access arguments via env vars with prefix PT_ or an input json.
tp/task/test.json
{ "description": "Run tp test on target nodes",
"parameters": {
"app": {
"description": "The application to test",
"type": "Optional[String[1]]"
} } }
tp/task/test.sh
#!/usr/bin/env bash
declare tp_options
PATH=$PATH:/usr/local/bin
[[ -n "${PT_app}" ]] && tp_options="${PT_app}"
tp test $tp_options
Plans
Orchestrated set of tasks that can be run on different hosts based on custom
logic according to the exit status of other runs.
They can be written in Yaml or in Puppet language and are shipped in the
plans dir.
Puppet plans have .pp extension and syntax similar to classes:
plan amazon_aws::create_kubernetes_cluster is defined in
amazon_aws/plans/create_kubernernes_cluster.pp
Can have parameters and special functions like run_task or run_puppet:
plan amazon_aws::create_kubernetes_cluster(
String[1] $cidr_block, [...]
) {
$responses=run_task("amazon_aws::iam_aws_list_roles", "localhost")
$role_list=$responses.first.value["roles"]
[...]
External facts in facts.d
Facts in the facts.d directory which are automatically synced to clients.
Contrary to native facts in lib directory, external facts don't need to be in written in Ruby.
Executable facts are executable scripts:
- In any language for Linux (must have the executable bit set)
- Files with extensions .bat, .exe, .com or .ps1 for Windows
The output of the script just has to be: fact_name = fact_value
Plain ascii files with extension .yaml, .txt (inifile format) or .json can be used as well.
They just need to specify the fact name and the relevant value (can be a string an array or
an hash).
Note that these facts are distributed to every node without possibility to have different facts
for different clients. So, in most cases, only executable facts are used here.
Functions in Puppet language
Are placed in the functions directory, have .pp extension and are written in Puppet
language. Their syntax is similar to classes or defines. For example, the function
psick::template is defined in psick/functions/template.ppand can look as follows:
function psick::template(
Optional[String] $filename,
Hash $parameters = {}
) >> Optional[String] {
if $filename and $filename !='' {
$ext=$filename[-4,4]
case $ext {
'.epp': { epp($filename, { parameters => $parameters } ) }
'.erb': { template($filename) }
default: { file($filename) }
}
} else {
undef
}
}
Hiera data in modules
Hiera 5 supports data in modules: a revolution on how default params are set.
A hiera.yamlin the module, like the one below, defines a Hierarchy in the module itself,
relative to the datadir.
On component modules this is useful to set the default values of the module classes’
parameters according to different OS. This completely replaces the params pattern.
Note that data in module can only be used to set values for the module’s params.
---
version: 5
defaults:
datadir: data
data_hash: yaml_data
hierarchy:
- name: "In module hierarchy"
paths:
- "%{facts.os.name}%{facts.os.release.major}.yaml"
- "%{facts.os.name}.yaml"
- "%{facts.os.family}%{facts.os.release.major}.yaml"
- "%{facts.os.family}.yaml"
- name: "Common"
path: "common.yaml"
My Unorthodox Patterns (who said anti-patterns?!)
After more than a decade of Puppet consulting, trainings and developments,
I’ve found myself using patterns which some times are so unorthodox that
someone might consider them anti-patterns.
Let’s review a few of them ;-)
● Profiles without roles (classes)
● Hiera driven classification (with Hashes)
● Custom templates and options hash (with hardcoded defaults)
● Ensure everything for presence or absence
● Applications abstraction with Tiny Puppet
● Class based server-side noop management
● Params to manage everything
● Reinvent the wheel (when it’s fast and easy)
Profiles without roles (classes)
The roles and profiles pattern is a widely established pattern which... I never
use, at least in the conventional way. Let's see how the pattern can evolve:
● Profiles can be any class which implements things in the way we need:
○ Classes of a custom profile module which use resources from a component module
○ Directly classes of a component module, if via Hiera data, they can do what we need
○ Maybe even one of the reusable profiles of the example42-psick module
● The concept of role is fundamental. Better if each node has only one
role and we can have a $role fact or global variable to use in hiera.yaml
● A role module and role classes which just include profiles are mostly
useless. Much better and more flexible to replace them with Hiera based
classification, setting profiles to include at a hierarchy level with $role
variable
● In large or complex environments the $role could not be enough to
define what each node does. Concepts like $product or $cluster and
their own roles might blend in.
Hiera driven classification (the psick way) 1/2
Classification is how we assign classes to nodes, according to their functions.
There are various classification methods: Arrays of classes looked via Hiera, an
ENC, role classes, node statement, LDAP....
The one I find the most flexible and easy to use is to set the classes to include
via Hiera, using an hash of keys to lookup in deep merge mode where keys
are arbitrary placeholders we can override in Hierarchies and values are the
class names to include.
A sample implementation is in example42-psick module, where:
- the hiera keys to use are named according to the kernel fact (to avoid the
need to have OS related hierarchies just for classification)
- Keys also identify different phases, whose classes are included in the
relevant order ('pre' before 'base' before 'profiles'). With an optional
'firstrun' phase, with classes included only at the first Puppet run.
Hiera driven classification (psick sample data) 2/2
# Classes applied at the first run on Linux and Windows
psick::enable_firstrun: true # By default firstrun phase is disabled
psick::firstrun::linux_classes:
aws: psick::aws::sdk
psick::firstrun::windows_classes:
aws: psick::aws::sdk
# Normal runs, prerequisite classes, applied before the others
psick::pre::linux_classes:
puppet: ::puppet
dns: psick::dns::resolver
psick::pre::windows_classes:
hosts: psick::hosts::resource
# Common baseline classes for Linux
psick::base::linux_classes:
sudo: psick::sudo
time: psick::time
# Application / role specific profiles (Linux)
psick::profiles::linux_classes:
www_blog: profile::www::blog
Custom templates and options, with defaults 1/2
For each configuration file to manage, let the users decide (via parameters):
- What erb/epp template to use (a default is OK, but allow override)
- A custom Hash of options: key-values used in the template
- Default options can be hardcoded in module and be overridden
- No need of a dedicated parameter for each configuration option!
- An Hash of options can be validated (with the Struct type), exactly as single params
- The class params you need (partial example) are just:
class profile::ssh (
String $config_file_template = 'profile/ssh/sshd_config.epp',
Profile::Ssh::Options $config_file_options = {},
Profile::Ssh::Options $config_file_defaults = {}, # Set in module data
) {
$all_options = $config_file_defaults + $config_file_options
file { '/etc/ssh/sshd_config':
content => epp( $config_file_template , { $options => $all_options }),
}
}
Custom templates and options, with defaults 2/2
User Hiera data, in the control-repo, can look as follows:
profile::ssh::config_file_options:
'PermitRootLogin': 'yes'
In the module Hiera data we can set the default options:
profile::ssh::config_file_defaults:
'PermitRootLogin': 'no'
'ListenAddress': "%{facts.networking.ip}"
The used epp template can be as follows:
PermitRootLogin <%= $options['PermitRootLogin'] %>
ListenAddress <%= $options['ListenAddress'] %>
The custom Profile::Ssh::Options type to validate the above can be like:
type Profile::Ssh::Options = Struct[{
Optional[PermitRootLogin] => Enum['yes','no'],
Optional[ListenAddress] => Stdlib::IP::Address, [...] ]}
Ensure for presence and absence 1/2
Puppet manages what we tell it to manage.
Any resource added in a class should be easily removable.
Any class should have an $ensure parameter which:
● Is applied AS IS to the managed package(s) to eventually allow Hiera
driven management of the version to install, or use latest
● Is adapted via custom functions for the other resources.
When you have to remove what a class has added, is enough to set on Hiera:
class_name::ensure: 'absent'
A Custom data type can be created to validate the possible values for $ensure:
type Profile::Ensure = Variant[ Boolean,
Enum['present', 'absent', 'latest'],
Pattern[/d+(.d+)*/]]
Ensure for presence and absence 2/2
class profile::ssh (
Profile::Ensure $ensure = 'present',
) {
package { $package_name:
ensure => $ensure,
}
service { $service_name:
ensure => psick::ensure2service(
$ensure, 'ensure'),
enable => psick::ensure2service(
$ensure, 'enable'),
}
file { $config_file_path:
ensure => psick::ensure2file(
$ensure),
}
file { $config_dir_path:
ensure => psick::ensure2dir(
$ensure),
}
}
Application abstraction with Tiny Puppet 1/2
Puppet is about abstracting resources from the underlying OS.
Tiny Puppet (example42-tp) is about abstracting applications.
It provides defines that can manage installation and configuration of
potentially any application on any OS, managing also the relevant package
repositories or dependencies, and leaving to used full freedom to manage
files in the way we want.
Can replace, potentially, any module where just packages, services and files
are managed.
Tiny Puppet is ideal for the sysadmin who knows how to configure her/his
files and wants to have freedom in choosing how to manage them (erb/epp
templates, source, content...) without having to study a dedicated module and
make it do what [s]he wants.
Application abstraction with Tiny Puppet 2/2
The sample ssh profile seen so far can become (multi OS support included):
class profile::ssh (
String $ensure = 'present',
String $config_template = 'profile/ssh/sshd_config.epp',
Profile::Ssh::Options $config_options = {},
Profile::Ssh::Options $config_defaults = {},
) {
$all_options = $default_options + $config_options
tp::install { 'openssh':
ensure => $ensure,
}
tp::conf { 'openssh':
ensure => $ensure,
epp => $config_template,
options_hash => $all_options,
}
}
Class based server-side noop management 1/2
The Puppet purist will tell you that you should not have nodes running in noop mode. Let
me argue, again, on this.
On a very sensitive and business critical environments production nodes can, maybe
should, run in noop mode during standard operational times.
Conditions apply, of course:
● They should have regular runs (at least weekly) in enforcing mode during maintenance
windows to prevent the accumulation of changes.
● You should check the reports of the impending changes and eventually trigger from a
central place enforcing runs when needed
● You should have a way to always enforce some classes (see next slide)
● You should have some canary nodes in production where changes are applied
Benefits of production in noop by default are quite clear:
● You don't risk to destroy the business in 30 minutes for a wrong change
● Your DevOps won't have the fear of breaking everything at every commit
● Puppet code development, testing and deployment can be faster
Class based server-side noop management 2/2
We can control noop behaviour for each class, leveraging on trlinkin-noop module
with params as follows in a class:
class profile::ssh (
Boolean $noop_manage = false,
Boolean $noop_value = false,
) {
if $noop_manage {
noop($noop_value)
}
[... class resources ...] }
When profile::ssh::noop_manage: true the noop() function is invoked with
the $noop_value which adds the noop metaparameter to all the resources in the
same scope. This, according to $noop_value allows to:
● false Enforce application of the class resources also when client runs in noop
● true Test in noop mode the class resources when client runs normally
Params to manage everything 1/2
Ever had to modify a module because it was creating some resources in a way
different from your needs or it had duplicated resources?
What if it would be enough to just provide some Hiera data to override the
module default behaviour? ANY behaviour:
- If to manage some of its resources
- Any extra parameters of a given resource
This particularly applies to resources which might conflict with other modules
(this is in itself a red herring, but still might be a needed prerequisite in some
cases) or might need tweaking of arguments.
Say hi to $<something>_manage and $<something>_params parameters
for full freedom in deciding if and what to do with classes' resources.
Params to manage everything 2/2
class profile::ssh (
Profile::Ensure $ensure = 'present',
String $config_file_template = 'profile/ssh/sshd_config.erb',
Boolean $config_file_manage = true,
Hash $config_file_params = {},
) {
if $config_file_manage {
$config_file_defaults = {
ensure => psick::ensure2file( $ensure),
mode => '0644',
owner => 'root',
group => 'root',
content => template( $config_file_template),
}
file { $config_file_path:
* => $config_file_defaults + $config_file_params,
}
}
}
Hiera data to use a static source instead of the template:
profile::ssh::config_file_params:
content: ~
source: puppet:///modules/profile/ssh/sshd_config
Reinvent the wheel (when fast and easy)
Do we really need a dedicated module to manage EPEL? Or Motd?
Or even the typical package-service-file pattern?
A new module added to Puppetfile means:
- Need to resolve and add its dependencies
- Need to study, understand and adapt the module to our needs
- Longer deployment times (a new repo to clone / sync)
When developing my profiles I evaluate:
- If what I have to do is easy and fast enough to avoid the need of a
component module
- If I can use pdk with a custom template to quickly generate full featured
profile classes
- If I can do what I have to do with tp defines or psick profiles
Summing up...
Opinions based on years of modules development and experience, may not
apply to everybody, especially who is new to Puppet.
I think that modules are good, useful and necessary, they are an essential
part of Puppet ecosystem.
Still, even if there's a module for everything,
that doesn't mean you have to use an existing module for everything.
Public modules and common patterns, like roles and profiles, are
the best solution when starting and learning,
but once you grasp Puppet core concepts and are comfortable with writing
code, you can go beyond and explore your own ways.

More Related Content

What's hot

Puppet Continuous Integration with PE and GitLab
Puppet Continuous Integration with PE and GitLabPuppet Continuous Integration with PE and GitLab
Puppet Continuous Integration with PE and GitLab
Alessandro Franceschi
 
Puppet: From 0 to 100 in 30 minutes
Puppet: From 0 to 100 in 30 minutesPuppet: From 0 to 100 in 30 minutes
Puppet: From 0 to 100 in 30 minutes
Alessandro Franceschi
 
Essential applications management with Tiny Puppet
Essential applications management with Tiny PuppetEssential applications management with Tiny Puppet
Essential applications management with Tiny Puppet
Alessandro Franceschi
 
Puppet evolutions
Puppet evolutionsPuppet evolutions
Puppet evolutions
Alessandro Franceschi
 
Writing Custom Puppet Types and Providers to Manage Web-Based Applications
Writing Custom Puppet Types and Providers to Manage Web-Based ApplicationsWriting Custom Puppet Types and Providers to Manage Web-Based Applications
Writing Custom Puppet Types and Providers to Manage Web-Based Applications
Tim Cinel
 
OpenRheinRuhr 2018 - Ops hates containers! Why?
OpenRheinRuhr 2018 - Ops hates containers! Why?OpenRheinRuhr 2018 - Ops hates containers! Why?
OpenRheinRuhr 2018 - Ops hates containers! Why?
Martin Alfke
 
Troubleshooting Puppet
Troubleshooting PuppetTroubleshooting Puppet
Troubleshooting Puppet
Thomas Howard Uphill
 
Enjoying the Journey from Puppet 3.x to Puppet 4.x (PuppetConf 2016)
Enjoying the Journey from Puppet 3.x to Puppet 4.x (PuppetConf 2016)Enjoying the Journey from Puppet 3.x to Puppet 4.x (PuppetConf 2016)
Enjoying the Journey from Puppet 3.x to Puppet 4.x (PuppetConf 2016)
Robert Nelson
 
Our Puppet Story (Linuxtag 2014)
Our Puppet Story (Linuxtag 2014)Our Puppet Story (Linuxtag 2014)
Our Puppet Story (Linuxtag 2014)
DECK36
 
PuppetConf 2016 Moving from Exec to Types and Provides
PuppetConf 2016 Moving from Exec to Types and ProvidesPuppetConf 2016 Moving from Exec to Types and Provides
PuppetConf 2016 Moving from Exec to Types and Provides
Martin Alfke
 
Puppet for Sys Admins
Puppet for Sys AdminsPuppet for Sys Admins
Puppet for Sys Admins
Puppet
 
Creating a mature puppet system
Creating a mature puppet systemCreating a mature puppet system
Creating a mature puppet system
rkhatibi
 
Learning Puppet Chapter 1
Learning Puppet Chapter 1Learning Puppet Chapter 1
Learning Puppet Chapter 1
Vishal Biyani
 
Auto Deploy Deep Dive – vBrownBag Style
Auto Deploy Deep Dive – vBrownBag StyleAuto Deploy Deep Dive – vBrownBag Style
Auto Deploy Deep Dive – vBrownBag Style
Robert Nelson
 
Tp install anything
Tp install anythingTp install anything
Tp install anything
Alessandro Franceschi
 
Packaging perl (LPW2010)
Packaging perl (LPW2010)Packaging perl (LPW2010)
Packaging perl (LPW2010)
p3castro
 
Puppet modules: A Holistic Approach - Geneva
Puppet modules: A Holistic Approach - GenevaPuppet modules: A Holistic Approach - Geneva
Puppet modules: A Holistic Approach - Geneva
Alessandro Franceschi
 
Virtual Bolt Workshop - March 16, 2020
Virtual Bolt Workshop - March 16, 2020Virtual Bolt Workshop - March 16, 2020
Virtual Bolt Workshop - March 16, 2020
Puppet
 
Learning puppet chapter 2
Learning puppet chapter 2Learning puppet chapter 2
Learning puppet chapter 2
Vishal Biyani
 
Intro To Spring Python
Intro To Spring PythonIntro To Spring Python
Intro To Spring Python
gturnquist
 

What's hot (20)

Puppet Continuous Integration with PE and GitLab
Puppet Continuous Integration with PE and GitLabPuppet Continuous Integration with PE and GitLab
Puppet Continuous Integration with PE and GitLab
 
Puppet: From 0 to 100 in 30 minutes
Puppet: From 0 to 100 in 30 minutesPuppet: From 0 to 100 in 30 minutes
Puppet: From 0 to 100 in 30 minutes
 
Essential applications management with Tiny Puppet
Essential applications management with Tiny PuppetEssential applications management with Tiny Puppet
Essential applications management with Tiny Puppet
 
Puppet evolutions
Puppet evolutionsPuppet evolutions
Puppet evolutions
 
Writing Custom Puppet Types and Providers to Manage Web-Based Applications
Writing Custom Puppet Types and Providers to Manage Web-Based ApplicationsWriting Custom Puppet Types and Providers to Manage Web-Based Applications
Writing Custom Puppet Types and Providers to Manage Web-Based Applications
 
OpenRheinRuhr 2018 - Ops hates containers! Why?
OpenRheinRuhr 2018 - Ops hates containers! Why?OpenRheinRuhr 2018 - Ops hates containers! Why?
OpenRheinRuhr 2018 - Ops hates containers! Why?
 
Troubleshooting Puppet
Troubleshooting PuppetTroubleshooting Puppet
Troubleshooting Puppet
 
Enjoying the Journey from Puppet 3.x to Puppet 4.x (PuppetConf 2016)
Enjoying the Journey from Puppet 3.x to Puppet 4.x (PuppetConf 2016)Enjoying the Journey from Puppet 3.x to Puppet 4.x (PuppetConf 2016)
Enjoying the Journey from Puppet 3.x to Puppet 4.x (PuppetConf 2016)
 
Our Puppet Story (Linuxtag 2014)
Our Puppet Story (Linuxtag 2014)Our Puppet Story (Linuxtag 2014)
Our Puppet Story (Linuxtag 2014)
 
PuppetConf 2016 Moving from Exec to Types and Provides
PuppetConf 2016 Moving from Exec to Types and ProvidesPuppetConf 2016 Moving from Exec to Types and Provides
PuppetConf 2016 Moving from Exec to Types and Provides
 
Puppet for Sys Admins
Puppet for Sys AdminsPuppet for Sys Admins
Puppet for Sys Admins
 
Creating a mature puppet system
Creating a mature puppet systemCreating a mature puppet system
Creating a mature puppet system
 
Learning Puppet Chapter 1
Learning Puppet Chapter 1Learning Puppet Chapter 1
Learning Puppet Chapter 1
 
Auto Deploy Deep Dive – vBrownBag Style
Auto Deploy Deep Dive – vBrownBag StyleAuto Deploy Deep Dive – vBrownBag Style
Auto Deploy Deep Dive – vBrownBag Style
 
Tp install anything
Tp install anythingTp install anything
Tp install anything
 
Packaging perl (LPW2010)
Packaging perl (LPW2010)Packaging perl (LPW2010)
Packaging perl (LPW2010)
 
Puppet modules: A Holistic Approach - Geneva
Puppet modules: A Holistic Approach - GenevaPuppet modules: A Holistic Approach - Geneva
Puppet modules: A Holistic Approach - Geneva
 
Virtual Bolt Workshop - March 16, 2020
Virtual Bolt Workshop - March 16, 2020Virtual Bolt Workshop - March 16, 2020
Virtual Bolt Workshop - March 16, 2020
 
Learning puppet chapter 2
Learning puppet chapter 2Learning puppet chapter 2
Learning puppet chapter 2
 
Intro To Spring Python
Intro To Spring PythonIntro To Spring Python
Intro To Spring Python
 

Similar to Modules of the twenties

PYTHON-COURSE-PROGRAMMING-UNIT-IV--.pptx
PYTHON-COURSE-PROGRAMMING-UNIT-IV--.pptxPYTHON-COURSE-PROGRAMMING-UNIT-IV--.pptx
PYTHON-COURSE-PROGRAMMING-UNIT-IV--.pptx
mru761077
 
pythontraining-201jn026043638.pptx
pythontraining-201jn026043638.pptxpythontraining-201jn026043638.pptx
pythontraining-201jn026043638.pptx
RohitKumar639388
 
Object oriented programming in python
Object oriented programming in pythonObject oriented programming in python
Object oriented programming in python
nitamhaske
 
Patterns in Python
Patterns in PythonPatterns in Python
Patterns in Python
dn
 
OOP, Networking, Linux/Unix
OOP, Networking, Linux/UnixOOP, Networking, Linux/Unix
OOP, Networking, Linux/Unix
Novita Sari
 
Python training
Python trainingPython training
Python training
Kunalchauhan76
 
Why Drupal is Rockstar?
Why Drupal is Rockstar?Why Drupal is Rockstar?
Why Drupal is Rockstar?
Gerald Villorente
 
conceptsinobjectorientedprogramminglanguages-12659959597745-phpapp02.pdf
conceptsinobjectorientedprogramminglanguages-12659959597745-phpapp02.pdfconceptsinobjectorientedprogramminglanguages-12659959597745-phpapp02.pdf
conceptsinobjectorientedprogramminglanguages-12659959597745-phpapp02.pdf
SahajShrimal1
 
Lecture-10_PHP-OOP.pptx
Lecture-10_PHP-OOP.pptxLecture-10_PHP-OOP.pptx
Lecture-10_PHP-OOP.pptx
ShaownRoy1
 
Andy On Closures
Andy On ClosuresAndy On Closures
Andy On Closures
melbournepatterns
 
Learning PHP for Drupal Theming, DC Chicago 2009
Learning PHP for Drupal Theming, DC Chicago 2009Learning PHP for Drupal Theming, DC Chicago 2009
Learning PHP for Drupal Theming, DC Chicago 2009
Emma Jane Hogbin Westby
 
Scala Talk at FOSDEM 2009
Scala Talk at FOSDEM 2009Scala Talk at FOSDEM 2009
Scala Talk at FOSDEM 2009
Martin Odersky
 
Bp301
Bp301Bp301
Functions and Modules.pptx
Functions and Modules.pptxFunctions and Modules.pptx
Functions and Modules.pptx
Ashwini Raut
 
Puppet quick start guide
Puppet quick start guidePuppet quick start guide
Puppet quick start guide
Suhan Dharmasuriya
 
Intro to-puppet
Intro to-puppetIntro to-puppet
Intro to-puppet
F.L. Jonathan Araña Cruz
 
Java notes
Java notesJava notes
Java notes
Upasana Talukdar
 
concept of oops
concept of oopsconcept of oops
concept of oops
prince sharma
 
Standardizing on a single N-dimensional array API for Python
Standardizing on a single N-dimensional array API for PythonStandardizing on a single N-dimensional array API for Python
Standardizing on a single N-dimensional array API for Python
Ralf Gommers
 
Oops
OopsOops

Similar to Modules of the twenties (20)

PYTHON-COURSE-PROGRAMMING-UNIT-IV--.pptx
PYTHON-COURSE-PROGRAMMING-UNIT-IV--.pptxPYTHON-COURSE-PROGRAMMING-UNIT-IV--.pptx
PYTHON-COURSE-PROGRAMMING-UNIT-IV--.pptx
 
pythontraining-201jn026043638.pptx
pythontraining-201jn026043638.pptxpythontraining-201jn026043638.pptx
pythontraining-201jn026043638.pptx
 
Object oriented programming in python
Object oriented programming in pythonObject oriented programming in python
Object oriented programming in python
 
Patterns in Python
Patterns in PythonPatterns in Python
Patterns in Python
 
OOP, Networking, Linux/Unix
OOP, Networking, Linux/UnixOOP, Networking, Linux/Unix
OOP, Networking, Linux/Unix
 
Python training
Python trainingPython training
Python training
 
Why Drupal is Rockstar?
Why Drupal is Rockstar?Why Drupal is Rockstar?
Why Drupal is Rockstar?
 
conceptsinobjectorientedprogramminglanguages-12659959597745-phpapp02.pdf
conceptsinobjectorientedprogramminglanguages-12659959597745-phpapp02.pdfconceptsinobjectorientedprogramminglanguages-12659959597745-phpapp02.pdf
conceptsinobjectorientedprogramminglanguages-12659959597745-phpapp02.pdf
 
Lecture-10_PHP-OOP.pptx
Lecture-10_PHP-OOP.pptxLecture-10_PHP-OOP.pptx
Lecture-10_PHP-OOP.pptx
 
Andy On Closures
Andy On ClosuresAndy On Closures
Andy On Closures
 
Learning PHP for Drupal Theming, DC Chicago 2009
Learning PHP for Drupal Theming, DC Chicago 2009Learning PHP for Drupal Theming, DC Chicago 2009
Learning PHP for Drupal Theming, DC Chicago 2009
 
Scala Talk at FOSDEM 2009
Scala Talk at FOSDEM 2009Scala Talk at FOSDEM 2009
Scala Talk at FOSDEM 2009
 
Bp301
Bp301Bp301
Bp301
 
Functions and Modules.pptx
Functions and Modules.pptxFunctions and Modules.pptx
Functions and Modules.pptx
 
Puppet quick start guide
Puppet quick start guidePuppet quick start guide
Puppet quick start guide
 
Intro to-puppet
Intro to-puppetIntro to-puppet
Intro to-puppet
 
Java notes
Java notesJava notes
Java notes
 
concept of oops
concept of oopsconcept of oops
concept of oops
 
Standardizing on a single N-dimensional array API for Python
Standardizing on a single N-dimensional array API for PythonStandardizing on a single N-dimensional array API for Python
Standardizing on a single N-dimensional array API for Python
 
Oops
OopsOops
Oops
 

More from Puppet

Puppetcamp r10kyaml
Puppetcamp r10kyamlPuppetcamp r10kyaml
Puppetcamp r10kyaml
Puppet
 
2021 04-15 operational verification (with notes)
2021 04-15 operational verification (with notes)2021 04-15 operational verification (with notes)
2021 04-15 operational verification (with notes)
Puppet
 
Puppet camp vscode
Puppet camp vscodePuppet camp vscode
Puppet camp vscode
Puppet
 
Applying Roles and Profiles method to compliance code
Applying Roles and Profiles method to compliance codeApplying Roles and Profiles method to compliance code
Applying Roles and Profiles method to compliance code
Puppet
 
KGI compliance as-code approach
KGI compliance as-code approachKGI compliance as-code approach
KGI compliance as-code approach
Puppet
 
Enforce compliance policy with model-driven automation
Enforce compliance policy with model-driven automationEnforce compliance policy with model-driven automation
Enforce compliance policy with model-driven automation
Puppet
 
Keynote: Puppet camp compliance
Keynote: Puppet camp complianceKeynote: Puppet camp compliance
Keynote: Puppet camp compliance
Puppet
 
Automating it management with Puppet + ServiceNow
Automating it management with Puppet + ServiceNowAutomating it management with Puppet + ServiceNow
Automating it management with Puppet + ServiceNow
Puppet
 
Puppet: The best way to harden Windows
Puppet: The best way to harden WindowsPuppet: The best way to harden Windows
Puppet: The best way to harden Windows
Puppet
 
Simplified Patch Management with Puppet - Oct. 2020
Simplified Patch Management with Puppet - Oct. 2020Simplified Patch Management with Puppet - Oct. 2020
Simplified Patch Management with Puppet - Oct. 2020
Puppet
 
Accelerating azure adoption with puppet
Accelerating azure adoption with puppetAccelerating azure adoption with puppet
Accelerating azure adoption with puppet
Puppet
 
Puppet catalog Diff; Raphael Pinson
Puppet catalog Diff; Raphael PinsonPuppet catalog Diff; Raphael Pinson
Puppet catalog Diff; Raphael Pinson
Puppet
 
ServiceNow and Puppet- better together, Kevin Reeuwijk
ServiceNow and Puppet- better together, Kevin ReeuwijkServiceNow and Puppet- better together, Kevin Reeuwijk
ServiceNow and Puppet- better together, Kevin Reeuwijk
Puppet
 
Take control of your dev ops dumping ground
Take control of your  dev ops dumping groundTake control of your  dev ops dumping ground
Take control of your dev ops dumping ground
Puppet
 
100% Puppet Cloud Deployment of Legacy Software
100% Puppet Cloud Deployment of Legacy Software100% Puppet Cloud Deployment of Legacy Software
100% Puppet Cloud Deployment of Legacy Software
Puppet
 
Puppet User Group
Puppet User GroupPuppet User Group
Puppet User Group
Puppet
 
Continuous Compliance and DevSecOps
Continuous Compliance and DevSecOpsContinuous Compliance and DevSecOps
Continuous Compliance and DevSecOps
Puppet
 
The Dynamic Duo of Puppet and Vault tame SSL Certificates, Nick Maludy
The Dynamic Duo of Puppet and Vault tame SSL Certificates, Nick MaludyThe Dynamic Duo of Puppet and Vault tame SSL Certificates, Nick Maludy
The Dynamic Duo of Puppet and Vault tame SSL Certificates, Nick Maludy
Puppet
 
ServiceNow and Puppet- better together, Kevin Reeuwijk
ServiceNow and Puppet- better together, Kevin ReeuwijkServiceNow and Puppet- better together, Kevin Reeuwijk
ServiceNow and Puppet- better together, Kevin Reeuwijk
Puppet
 
Puppet in k8s, Miroslav Hadzhiev
Puppet in k8s, Miroslav HadzhievPuppet in k8s, Miroslav Hadzhiev
Puppet in k8s, Miroslav Hadzhiev
Puppet
 

More from Puppet (20)

Puppetcamp r10kyaml
Puppetcamp r10kyamlPuppetcamp r10kyaml
Puppetcamp r10kyaml
 
2021 04-15 operational verification (with notes)
2021 04-15 operational verification (with notes)2021 04-15 operational verification (with notes)
2021 04-15 operational verification (with notes)
 
Puppet camp vscode
Puppet camp vscodePuppet camp vscode
Puppet camp vscode
 
Applying Roles and Profiles method to compliance code
Applying Roles and Profiles method to compliance codeApplying Roles and Profiles method to compliance code
Applying Roles and Profiles method to compliance code
 
KGI compliance as-code approach
KGI compliance as-code approachKGI compliance as-code approach
KGI compliance as-code approach
 
Enforce compliance policy with model-driven automation
Enforce compliance policy with model-driven automationEnforce compliance policy with model-driven automation
Enforce compliance policy with model-driven automation
 
Keynote: Puppet camp compliance
Keynote: Puppet camp complianceKeynote: Puppet camp compliance
Keynote: Puppet camp compliance
 
Automating it management with Puppet + ServiceNow
Automating it management with Puppet + ServiceNowAutomating it management with Puppet + ServiceNow
Automating it management with Puppet + ServiceNow
 
Puppet: The best way to harden Windows
Puppet: The best way to harden WindowsPuppet: The best way to harden Windows
Puppet: The best way to harden Windows
 
Simplified Patch Management with Puppet - Oct. 2020
Simplified Patch Management with Puppet - Oct. 2020Simplified Patch Management with Puppet - Oct. 2020
Simplified Patch Management with Puppet - Oct. 2020
 
Accelerating azure adoption with puppet
Accelerating azure adoption with puppetAccelerating azure adoption with puppet
Accelerating azure adoption with puppet
 
Puppet catalog Diff; Raphael Pinson
Puppet catalog Diff; Raphael PinsonPuppet catalog Diff; Raphael Pinson
Puppet catalog Diff; Raphael Pinson
 
ServiceNow and Puppet- better together, Kevin Reeuwijk
ServiceNow and Puppet- better together, Kevin ReeuwijkServiceNow and Puppet- better together, Kevin Reeuwijk
ServiceNow and Puppet- better together, Kevin Reeuwijk
 
Take control of your dev ops dumping ground
Take control of your  dev ops dumping groundTake control of your  dev ops dumping ground
Take control of your dev ops dumping ground
 
100% Puppet Cloud Deployment of Legacy Software
100% Puppet Cloud Deployment of Legacy Software100% Puppet Cloud Deployment of Legacy Software
100% Puppet Cloud Deployment of Legacy Software
 
Puppet User Group
Puppet User GroupPuppet User Group
Puppet User Group
 
Continuous Compliance and DevSecOps
Continuous Compliance and DevSecOpsContinuous Compliance and DevSecOps
Continuous Compliance and DevSecOps
 
The Dynamic Duo of Puppet and Vault tame SSL Certificates, Nick Maludy
The Dynamic Duo of Puppet and Vault tame SSL Certificates, Nick MaludyThe Dynamic Duo of Puppet and Vault tame SSL Certificates, Nick Maludy
The Dynamic Duo of Puppet and Vault tame SSL Certificates, Nick Maludy
 
ServiceNow and Puppet- better together, Kevin Reeuwijk
ServiceNow and Puppet- better together, Kevin ReeuwijkServiceNow and Puppet- better together, Kevin Reeuwijk
ServiceNow and Puppet- better together, Kevin Reeuwijk
 
Puppet in k8s, Miroslav Hadzhiev
Puppet in k8s, Miroslav HadzhievPuppet in k8s, Miroslav Hadzhiev
Puppet in k8s, Miroslav Hadzhiev
 

Recently uploaded

Salesforce AI & Einstein Copilot Workshop
Salesforce AI & Einstein Copilot WorkshopSalesforce AI & Einstein Copilot Workshop
Salesforce AI & Einstein Copilot Workshop
CEPTES Software Inc
 
Use Cases & Benefits of RPA in Manufacturing in 2024.pptx
Use Cases & Benefits of RPA in Manufacturing in 2024.pptxUse Cases & Benefits of RPA in Manufacturing in 2024.pptx
Use Cases & Benefits of RPA in Manufacturing in 2024.pptx
SynapseIndia
 
RPA In Healthcare Benefits, Use Case, Trend And Challenges 2024.pptx
RPA In Healthcare Benefits, Use Case, Trend And Challenges 2024.pptxRPA In Healthcare Benefits, Use Case, Trend And Challenges 2024.pptx
RPA In Healthcare Benefits, Use Case, Trend And Challenges 2024.pptx
SynapseIndia
 
Choose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presenceChoose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presence
rajancomputerfbd
 
Password Rotation in 2024 is still Relevant
Password Rotation in 2024 is still RelevantPassword Rotation in 2024 is still Relevant
Password Rotation in 2024 is still Relevant
Bert Blevins
 
find out more about the role of autonomous vehicles in facing global challenges
find out more about the role of autonomous vehicles in facing global challengesfind out more about the role of autonomous vehicles in facing global challenges
find out more about the role of autonomous vehicles in facing global challenges
huseindihon
 
CHAPTER-8 COMPONENTS OF COMPUTER SYSTEM CLASS 9 CBSE
CHAPTER-8 COMPONENTS OF COMPUTER SYSTEM CLASS 9 CBSECHAPTER-8 COMPONENTS OF COMPUTER SYSTEM CLASS 9 CBSE
CHAPTER-8 COMPONENTS OF COMPUTER SYSTEM CLASS 9 CBSE
kumarjarun2010
 
Three New Criminal Laws in India 1 July 2024
Three New Criminal Laws in India 1 July 2024Three New Criminal Laws in India 1 July 2024
Three New Criminal Laws in India 1 July 2024
aakash malhotra
 
“Deploying Large Language Models on a Raspberry Pi,” a Presentation from Usef...
“Deploying Large Language Models on a Raspberry Pi,” a Presentation from Usef...“Deploying Large Language Models on a Raspberry Pi,” a Presentation from Usef...
“Deploying Large Language Models on a Raspberry Pi,” a Presentation from Usef...
Edge AI and Vision Alliance
 
ARTIFICIAL INTELLIGENCE (AI) IN MUSIC.pdf
ARTIFICIAL INTELLIGENCE (AI) IN MUSIC.pdfARTIFICIAL INTELLIGENCE (AI) IN MUSIC.pdf
ARTIFICIAL INTELLIGENCE (AI) IN MUSIC.pdf
Inglês no Mundo Digital
 
Pigging Unit Lubricant Oil Blending Plant
Pigging Unit Lubricant Oil Blending PlantPigging Unit Lubricant Oil Blending Plant
Pigging Unit Lubricant Oil Blending Plant
LINUS PROJECTS (INDIA)
 
July Patch Tuesday
July Patch TuesdayJuly Patch Tuesday
July Patch Tuesday
Ivanti
 
High Profile Girls Call ServiCe Hyderabad 0000000000 Tanisha Best High Class ...
High Profile Girls Call ServiCe Hyderabad 0000000000 Tanisha Best High Class ...High Profile Girls Call ServiCe Hyderabad 0000000000 Tanisha Best High Class ...
High Profile Girls Call ServiCe Hyderabad 0000000000 Tanisha Best High Class ...
aslasdfmkhan4750
 
How to build a generative AI solution A step-by-step guide (2).pdf
How to build a generative AI solution A step-by-step guide (2).pdfHow to build a generative AI solution A step-by-step guide (2).pdf
How to build a generative AI solution A step-by-step guide (2).pdf
ChristopherTHyatt
 
Observability For You and Me with OpenTelemetry
Observability For You and Me with OpenTelemetryObservability For You and Me with OpenTelemetry
Observability For You and Me with OpenTelemetry
Eric D. Schabell
 
How RPA Help in the Transportation and Logistics Industry.pptx
How RPA Help in the Transportation and Logistics Industry.pptxHow RPA Help in the Transportation and Logistics Industry.pptx
How RPA Help in the Transportation and Logistics Industry.pptx
SynapseIndia
 
Active Inference is a veryyyyyyyyyyyyyyyyyyyyyyyy
Active Inference is a veryyyyyyyyyyyyyyyyyyyyyyyyActive Inference is a veryyyyyyyyyyyyyyyyyyyyyyyy
Active Inference is a veryyyyyyyyyyyyyyyyyyyyyyyy
RaminGhanbari2
 
Girls Call Churchgate 9910780858 Provide Best And Top Girl Service And No1 in...
Girls Call Churchgate 9910780858 Provide Best And Top Girl Service And No1 in...Girls Call Churchgate 9910780858 Provide Best And Top Girl Service And No1 in...
Girls Call Churchgate 9910780858 Provide Best And Top Girl Service And No1 in...
maigasapphire
 
Comparison Table of DiskWarrior Alternatives.pdf
Comparison Table of DiskWarrior Alternatives.pdfComparison Table of DiskWarrior Alternatives.pdf
Comparison Table of DiskWarrior Alternatives.pdf
Andrey Yasko
 
BT & Neo4j: Knowledge Graphs for Critical Enterprise Systems.pptx.pdf
BT & Neo4j: Knowledge Graphs for Critical Enterprise Systems.pptx.pdfBT & Neo4j: Knowledge Graphs for Critical Enterprise Systems.pptx.pdf
BT & Neo4j: Knowledge Graphs for Critical Enterprise Systems.pptx.pdf
Neo4j
 

Recently uploaded (20)

Salesforce AI & Einstein Copilot Workshop
Salesforce AI & Einstein Copilot WorkshopSalesforce AI & Einstein Copilot Workshop
Salesforce AI & Einstein Copilot Workshop
 
Use Cases & Benefits of RPA in Manufacturing in 2024.pptx
Use Cases & Benefits of RPA in Manufacturing in 2024.pptxUse Cases & Benefits of RPA in Manufacturing in 2024.pptx
Use Cases & Benefits of RPA in Manufacturing in 2024.pptx
 
RPA In Healthcare Benefits, Use Case, Trend And Challenges 2024.pptx
RPA In Healthcare Benefits, Use Case, Trend And Challenges 2024.pptxRPA In Healthcare Benefits, Use Case, Trend And Challenges 2024.pptx
RPA In Healthcare Benefits, Use Case, Trend And Challenges 2024.pptx
 
Choose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presenceChoose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presence
 
Password Rotation in 2024 is still Relevant
Password Rotation in 2024 is still RelevantPassword Rotation in 2024 is still Relevant
Password Rotation in 2024 is still Relevant
 
find out more about the role of autonomous vehicles in facing global challenges
find out more about the role of autonomous vehicles in facing global challengesfind out more about the role of autonomous vehicles in facing global challenges
find out more about the role of autonomous vehicles in facing global challenges
 
CHAPTER-8 COMPONENTS OF COMPUTER SYSTEM CLASS 9 CBSE
CHAPTER-8 COMPONENTS OF COMPUTER SYSTEM CLASS 9 CBSECHAPTER-8 COMPONENTS OF COMPUTER SYSTEM CLASS 9 CBSE
CHAPTER-8 COMPONENTS OF COMPUTER SYSTEM CLASS 9 CBSE
 
Three New Criminal Laws in India 1 July 2024
Three New Criminal Laws in India 1 July 2024Three New Criminal Laws in India 1 July 2024
Three New Criminal Laws in India 1 July 2024
 
“Deploying Large Language Models on a Raspberry Pi,” a Presentation from Usef...
“Deploying Large Language Models on a Raspberry Pi,” a Presentation from Usef...“Deploying Large Language Models on a Raspberry Pi,” a Presentation from Usef...
“Deploying Large Language Models on a Raspberry Pi,” a Presentation from Usef...
 
ARTIFICIAL INTELLIGENCE (AI) IN MUSIC.pdf
ARTIFICIAL INTELLIGENCE (AI) IN MUSIC.pdfARTIFICIAL INTELLIGENCE (AI) IN MUSIC.pdf
ARTIFICIAL INTELLIGENCE (AI) IN MUSIC.pdf
 
Pigging Unit Lubricant Oil Blending Plant
Pigging Unit Lubricant Oil Blending PlantPigging Unit Lubricant Oil Blending Plant
Pigging Unit Lubricant Oil Blending Plant
 
July Patch Tuesday
July Patch TuesdayJuly Patch Tuesday
July Patch Tuesday
 
High Profile Girls Call ServiCe Hyderabad 0000000000 Tanisha Best High Class ...
High Profile Girls Call ServiCe Hyderabad 0000000000 Tanisha Best High Class ...High Profile Girls Call ServiCe Hyderabad 0000000000 Tanisha Best High Class ...
High Profile Girls Call ServiCe Hyderabad 0000000000 Tanisha Best High Class ...
 
How to build a generative AI solution A step-by-step guide (2).pdf
How to build a generative AI solution A step-by-step guide (2).pdfHow to build a generative AI solution A step-by-step guide (2).pdf
How to build a generative AI solution A step-by-step guide (2).pdf
 
Observability For You and Me with OpenTelemetry
Observability For You and Me with OpenTelemetryObservability For You and Me with OpenTelemetry
Observability For You and Me with OpenTelemetry
 
How RPA Help in the Transportation and Logistics Industry.pptx
How RPA Help in the Transportation and Logistics Industry.pptxHow RPA Help in the Transportation and Logistics Industry.pptx
How RPA Help in the Transportation and Logistics Industry.pptx
 
Active Inference is a veryyyyyyyyyyyyyyyyyyyyyyyy
Active Inference is a veryyyyyyyyyyyyyyyyyyyyyyyyActive Inference is a veryyyyyyyyyyyyyyyyyyyyyyyy
Active Inference is a veryyyyyyyyyyyyyyyyyyyyyyyy
 
Girls Call Churchgate 9910780858 Provide Best And Top Girl Service And No1 in...
Girls Call Churchgate 9910780858 Provide Best And Top Girl Service And No1 in...Girls Call Churchgate 9910780858 Provide Best And Top Girl Service And No1 in...
Girls Call Churchgate 9910780858 Provide Best And Top Girl Service And No1 in...
 
Comparison Table of DiskWarrior Alternatives.pdf
Comparison Table of DiskWarrior Alternatives.pdfComparison Table of DiskWarrior Alternatives.pdf
Comparison Table of DiskWarrior Alternatives.pdf
 
BT & Neo4j: Knowledge Graphs for Critical Enterprise Systems.pptx.pdf
BT & Neo4j: Knowledge Graphs for Critical Enterprise Systems.pptx.pdfBT & Neo4j: Knowledge Graphs for Critical Enterprise Systems.pptx.pdf
BT & Neo4j: Knowledge Graphs for Critical Enterprise Systems.pptx.pdf
 

Modules of the twenties

  • 1. Modules of the twenties Alessandro Franceschi example42 Gmbh @alvagante
  • 2. A Bio based on talks: Obsessed by Puppet modules I’ve been working on Puppet modules for more than 10 years. Always looking for answers to problems like: Reusability Puppet Camp San Francisco 2010: Re-use Your Modules! Puppet Conf San Francisco 2013: Anatomy of a Reusable Module Naming standards Puppet Camp Europe Ghent 2010: Puppet Modules and Module Standards App deploy Puppet Camp Europe Amsterdam 2011: Automating Applications deployment with Puppi Configurability Puppet Conf San Francisco 2012: Puppet modules for fun and profit Puppet Camp Dublin 2012: Puppet Modules: an holistic approach Optimization CfgMgmtCamp Ghent 2016 - Essential application management with Tiny Puppet CfgMgmtCamp Ghent 2018 - Puppet Systems Infrastructure Construction Kit
  • 3. Many things happened in module-land Since when Puppet modules have been introduced, they succeeded in many areas, like extendability to support new OSes, devices, IT objects, interoperability, improved reusability and composability. Puppet has evolved as well, with the introduction of Data in Modules, functions in Puppet DSL, external facts, Tasks, Plans, Data Types. In this presentation we will have an high level review of them. New patterns have emerged over the years, here we focus on the ones I prefer, in some cases they are so unorthodox that for someone they can look like anti-patterns. I can explain. We will see them.
  • 4. Well known Module paths and conventions Common directories in modules we have always used: manifests Puppet code in files with .pp extension whose names match class names Class mysql is defined in mysql/manifests/init.pp Class mysql::server in mysql/manifests/server.pp files Static files used in the source argument of the file resource. source => 'puppet:///modules/mysql/my.cnf' matches file mysql/files/my.cnf templates Dynamic .erb or .epp templates used as argument of template() or epp() functions. Typically used in the content arg of a file resource. content => template('mysql/my.cnf.erb') matches file mysql/templates/my.cnf.erb content => epp('mysql/my.cnf.epp') matches file mysql/templates/my.cnf.epp lib Directory with custom functions, facts, types and providers in Ruby language. This content is automatically synced to clients. spec Directory for unix tests with Rspec Puppet.
  • 5. Module paths added in more recent years Directories added to modules for different purposes: data Hiera data in module. locales Multi language translations. types Custom data types tasks Bolt tasks plans Bolt plans facts.d External facts. Automatically synced to clients functions Functions written in Puppet language
  • 6. Custom Data Types Puppet 4 comes with a rich type system for any kind of data, like: String, Boolean, Integer, Array, Hash, Pattern, Struct, Undef... It's possible to create custom data types to filter and validate our data. They are shipped in the types dir of a module. They are named and located in the module namespace: Stdlib::Absolutepath is defined in stdlib/types/absolutepath.pp New data types can use any other native or custom data type: type Stdlib::Absolutepath = Variant[Stdlib::Windowspath, Stdlib::Unixpath] Puppetlabs-stdlib module provide many useful additional data types. Any module can provide its own types. IE, puppetlabs' ntp/types/poll_interval.pp: type Ntp::Poll_interval = Integer[4, 17]
  • 7. Bolt Tasks They are scripts, in any language, which can be remotely executed via Bolt. They are placed in the tasks dir, for each tasks we have the script and its json metadata descriptor. They are namespaced with the module, for example: tp::test is placed under tp/task/test.sh with meta in tp/task/test.json Scripts can access arguments via env vars with prefix PT_ or an input json. tp/task/test.json { "description": "Run tp test on target nodes", "parameters": { "app": { "description": "The application to test", "type": "Optional[String[1]]" } } } tp/task/test.sh #!/usr/bin/env bash declare tp_options PATH=$PATH:/usr/local/bin [[ -n "${PT_app}" ]] && tp_options="${PT_app}" tp test $tp_options
  • 8. Plans Orchestrated set of tasks that can be run on different hosts based on custom logic according to the exit status of other runs. They can be written in Yaml or in Puppet language and are shipped in the plans dir. Puppet plans have .pp extension and syntax similar to classes: plan amazon_aws::create_kubernetes_cluster is defined in amazon_aws/plans/create_kubernernes_cluster.pp Can have parameters and special functions like run_task or run_puppet: plan amazon_aws::create_kubernetes_cluster( String[1] $cidr_block, [...] ) { $responses=run_task("amazon_aws::iam_aws_list_roles", "localhost") $role_list=$responses.first.value["roles"] [...]
  • 9. External facts in facts.d Facts in the facts.d directory which are automatically synced to clients. Contrary to native facts in lib directory, external facts don't need to be in written in Ruby. Executable facts are executable scripts: - In any language for Linux (must have the executable bit set) - Files with extensions .bat, .exe, .com or .ps1 for Windows The output of the script just has to be: fact_name = fact_value Plain ascii files with extension .yaml, .txt (inifile format) or .json can be used as well. They just need to specify the fact name and the relevant value (can be a string an array or an hash). Note that these facts are distributed to every node without possibility to have different facts for different clients. So, in most cases, only executable facts are used here.
  • 10. Functions in Puppet language Are placed in the functions directory, have .pp extension and are written in Puppet language. Their syntax is similar to classes or defines. For example, the function psick::template is defined in psick/functions/template.ppand can look as follows: function psick::template( Optional[String] $filename, Hash $parameters = {} ) >> Optional[String] { if $filename and $filename !='' { $ext=$filename[-4,4] case $ext { '.epp': { epp($filename, { parameters => $parameters } ) } '.erb': { template($filename) } default: { file($filename) } } } else { undef } }
  • 11. Hiera data in modules Hiera 5 supports data in modules: a revolution on how default params are set. A hiera.yamlin the module, like the one below, defines a Hierarchy in the module itself, relative to the datadir. On component modules this is useful to set the default values of the module classes’ parameters according to different OS. This completely replaces the params pattern. Note that data in module can only be used to set values for the module’s params. --- version: 5 defaults: datadir: data data_hash: yaml_data hierarchy: - name: "In module hierarchy" paths: - "%{facts.os.name}%{facts.os.release.major}.yaml" - "%{facts.os.name}.yaml" - "%{facts.os.family}%{facts.os.release.major}.yaml" - "%{facts.os.family}.yaml" - name: "Common" path: "common.yaml"
  • 12. My Unorthodox Patterns (who said anti-patterns?!) After more than a decade of Puppet consulting, trainings and developments, I’ve found myself using patterns which some times are so unorthodox that someone might consider them anti-patterns. Let’s review a few of them ;-) ● Profiles without roles (classes) ● Hiera driven classification (with Hashes) ● Custom templates and options hash (with hardcoded defaults) ● Ensure everything for presence or absence ● Applications abstraction with Tiny Puppet ● Class based server-side noop management ● Params to manage everything ● Reinvent the wheel (when it’s fast and easy)
  • 13. Profiles without roles (classes) The roles and profiles pattern is a widely established pattern which... I never use, at least in the conventional way. Let's see how the pattern can evolve: ● Profiles can be any class which implements things in the way we need: ○ Classes of a custom profile module which use resources from a component module ○ Directly classes of a component module, if via Hiera data, they can do what we need ○ Maybe even one of the reusable profiles of the example42-psick module ● The concept of role is fundamental. Better if each node has only one role and we can have a $role fact or global variable to use in hiera.yaml ● A role module and role classes which just include profiles are mostly useless. Much better and more flexible to replace them with Hiera based classification, setting profiles to include at a hierarchy level with $role variable ● In large or complex environments the $role could not be enough to define what each node does. Concepts like $product or $cluster and their own roles might blend in.
  • 14. Hiera driven classification (the psick way) 1/2 Classification is how we assign classes to nodes, according to their functions. There are various classification methods: Arrays of classes looked via Hiera, an ENC, role classes, node statement, LDAP.... The one I find the most flexible and easy to use is to set the classes to include via Hiera, using an hash of keys to lookup in deep merge mode where keys are arbitrary placeholders we can override in Hierarchies and values are the class names to include. A sample implementation is in example42-psick module, where: - the hiera keys to use are named according to the kernel fact (to avoid the need to have OS related hierarchies just for classification) - Keys also identify different phases, whose classes are included in the relevant order ('pre' before 'base' before 'profiles'). With an optional 'firstrun' phase, with classes included only at the first Puppet run.
  • 15. Hiera driven classification (psick sample data) 2/2 # Classes applied at the first run on Linux and Windows psick::enable_firstrun: true # By default firstrun phase is disabled psick::firstrun::linux_classes: aws: psick::aws::sdk psick::firstrun::windows_classes: aws: psick::aws::sdk # Normal runs, prerequisite classes, applied before the others psick::pre::linux_classes: puppet: ::puppet dns: psick::dns::resolver psick::pre::windows_classes: hosts: psick::hosts::resource # Common baseline classes for Linux psick::base::linux_classes: sudo: psick::sudo time: psick::time # Application / role specific profiles (Linux) psick::profiles::linux_classes: www_blog: profile::www::blog
  • 16. Custom templates and options, with defaults 1/2 For each configuration file to manage, let the users decide (via parameters): - What erb/epp template to use (a default is OK, but allow override) - A custom Hash of options: key-values used in the template - Default options can be hardcoded in module and be overridden - No need of a dedicated parameter for each configuration option! - An Hash of options can be validated (with the Struct type), exactly as single params - The class params you need (partial example) are just: class profile::ssh ( String $config_file_template = 'profile/ssh/sshd_config.epp', Profile::Ssh::Options $config_file_options = {}, Profile::Ssh::Options $config_file_defaults = {}, # Set in module data ) { $all_options = $config_file_defaults + $config_file_options file { '/etc/ssh/sshd_config': content => epp( $config_file_template , { $options => $all_options }), } }
  • 17. Custom templates and options, with defaults 2/2 User Hiera data, in the control-repo, can look as follows: profile::ssh::config_file_options: 'PermitRootLogin': 'yes' In the module Hiera data we can set the default options: profile::ssh::config_file_defaults: 'PermitRootLogin': 'no' 'ListenAddress': "%{facts.networking.ip}" The used epp template can be as follows: PermitRootLogin <%= $options['PermitRootLogin'] %> ListenAddress <%= $options['ListenAddress'] %> The custom Profile::Ssh::Options type to validate the above can be like: type Profile::Ssh::Options = Struct[{ Optional[PermitRootLogin] => Enum['yes','no'], Optional[ListenAddress] => Stdlib::IP::Address, [...] ]}
  • 18. Ensure for presence and absence 1/2 Puppet manages what we tell it to manage. Any resource added in a class should be easily removable. Any class should have an $ensure parameter which: ● Is applied AS IS to the managed package(s) to eventually allow Hiera driven management of the version to install, or use latest ● Is adapted via custom functions for the other resources. When you have to remove what a class has added, is enough to set on Hiera: class_name::ensure: 'absent' A Custom data type can be created to validate the possible values for $ensure: type Profile::Ensure = Variant[ Boolean, Enum['present', 'absent', 'latest'], Pattern[/d+(.d+)*/]]
  • 19. Ensure for presence and absence 2/2 class profile::ssh ( Profile::Ensure $ensure = 'present', ) { package { $package_name: ensure => $ensure, } service { $service_name: ensure => psick::ensure2service( $ensure, 'ensure'), enable => psick::ensure2service( $ensure, 'enable'), } file { $config_file_path: ensure => psick::ensure2file( $ensure), } file { $config_dir_path: ensure => psick::ensure2dir( $ensure), } }
  • 20. Application abstraction with Tiny Puppet 1/2 Puppet is about abstracting resources from the underlying OS. Tiny Puppet (example42-tp) is about abstracting applications. It provides defines that can manage installation and configuration of potentially any application on any OS, managing also the relevant package repositories or dependencies, and leaving to used full freedom to manage files in the way we want. Can replace, potentially, any module where just packages, services and files are managed. Tiny Puppet is ideal for the sysadmin who knows how to configure her/his files and wants to have freedom in choosing how to manage them (erb/epp templates, source, content...) without having to study a dedicated module and make it do what [s]he wants.
  • 21. Application abstraction with Tiny Puppet 2/2 The sample ssh profile seen so far can become (multi OS support included): class profile::ssh ( String $ensure = 'present', String $config_template = 'profile/ssh/sshd_config.epp', Profile::Ssh::Options $config_options = {}, Profile::Ssh::Options $config_defaults = {}, ) { $all_options = $default_options + $config_options tp::install { 'openssh': ensure => $ensure, } tp::conf { 'openssh': ensure => $ensure, epp => $config_template, options_hash => $all_options, } }
  • 22. Class based server-side noop management 1/2 The Puppet purist will tell you that you should not have nodes running in noop mode. Let me argue, again, on this. On a very sensitive and business critical environments production nodes can, maybe should, run in noop mode during standard operational times. Conditions apply, of course: ● They should have regular runs (at least weekly) in enforcing mode during maintenance windows to prevent the accumulation of changes. ● You should check the reports of the impending changes and eventually trigger from a central place enforcing runs when needed ● You should have a way to always enforce some classes (see next slide) ● You should have some canary nodes in production where changes are applied Benefits of production in noop by default are quite clear: ● You don't risk to destroy the business in 30 minutes for a wrong change ● Your DevOps won't have the fear of breaking everything at every commit ● Puppet code development, testing and deployment can be faster
  • 23. Class based server-side noop management 2/2 We can control noop behaviour for each class, leveraging on trlinkin-noop module with params as follows in a class: class profile::ssh ( Boolean $noop_manage = false, Boolean $noop_value = false, ) { if $noop_manage { noop($noop_value) } [... class resources ...] } When profile::ssh::noop_manage: true the noop() function is invoked with the $noop_value which adds the noop metaparameter to all the resources in the same scope. This, according to $noop_value allows to: ● false Enforce application of the class resources also when client runs in noop ● true Test in noop mode the class resources when client runs normally
  • 24. Params to manage everything 1/2 Ever had to modify a module because it was creating some resources in a way different from your needs or it had duplicated resources? What if it would be enough to just provide some Hiera data to override the module default behaviour? ANY behaviour: - If to manage some of its resources - Any extra parameters of a given resource This particularly applies to resources which might conflict with other modules (this is in itself a red herring, but still might be a needed prerequisite in some cases) or might need tweaking of arguments. Say hi to $<something>_manage and $<something>_params parameters for full freedom in deciding if and what to do with classes' resources.
  • 25. Params to manage everything 2/2 class profile::ssh ( Profile::Ensure $ensure = 'present', String $config_file_template = 'profile/ssh/sshd_config.erb', Boolean $config_file_manage = true, Hash $config_file_params = {}, ) { if $config_file_manage { $config_file_defaults = { ensure => psick::ensure2file( $ensure), mode => '0644', owner => 'root', group => 'root', content => template( $config_file_template), } file { $config_file_path: * => $config_file_defaults + $config_file_params, } } } Hiera data to use a static source instead of the template: profile::ssh::config_file_params: content: ~ source: puppet:///modules/profile/ssh/sshd_config
  • 26. Reinvent the wheel (when fast and easy) Do we really need a dedicated module to manage EPEL? Or Motd? Or even the typical package-service-file pattern? A new module added to Puppetfile means: - Need to resolve and add its dependencies - Need to study, understand and adapt the module to our needs - Longer deployment times (a new repo to clone / sync) When developing my profiles I evaluate: - If what I have to do is easy and fast enough to avoid the need of a component module - If I can use pdk with a custom template to quickly generate full featured profile classes - If I can do what I have to do with tp defines or psick profiles
  • 27. Summing up... Opinions based on years of modules development and experience, may not apply to everybody, especially who is new to Puppet. I think that modules are good, useful and necessary, they are an essential part of Puppet ecosystem. Still, even if there's a module for everything, that doesn't mean you have to use an existing module for everything. Public modules and common patterns, like roles and profiles, are the best solution when starting and learning, but once you grasp Puppet core concepts and are comfortable with writing code, you can go beyond and explore your own ways.