This document summarizes a puppet master class presentation. Puppet is a configuration management tool that ensures systems are in a consistent state regardless of their starting point. The presentation covers puppet fundamentals like declaring system configurations through manifests and templates, using variables and modules, separating data from code with Hiera, and bootstrapping new servers. It provides an example manifest to configure NTP using resources, templates, and variables.
3. What is puppet
CM tool - Bring running systems to consistent
state;
Despite the starting point systems will end in
the same point, in a repeatable and
predictable way;
Other CM tools : Chef, Ansible, Salt,
Capistrano…..
4. What is the need for a CM ?
Admin one, two … servers is nice … do it on
1000 is awful
boring
repeatable
…..
To Err is Human; To Really Foul Things Up
Requires a Computer…. image the mess in
100's or 1000's of computers
5. @WikiLovers
Started by Luke Kanies in 2005
founded Puppet Labs
GPL
Unix* and Windows
Ruby
Have one language (DSL)
more details: Wiki for it ;-)
6. Declare where you want to be ( not how to get
there ) - presenting Manifest’s
file: some_manifest.pp
node ‘some_name_or_ip’ {
….
do_stuff_to_get_servers_where_You_want
….
}
puppet apply some_manifest.pp
7. Hold on … Are there any requisites ?
Need running system ( bootstrapping is another
issue, more on that later )
puppet installed ( How2 and dependencies are
OS specific )
8. Do Stuff
puppet apply classes to nodes
classes are set of resources
and resources are ….
10. Facts: "that is life"
We take decisions based on facts , so puppet
can do it
Facts are variables to puppet
environment facts
others ( eg: this server is “yellow”)
facts can ( should be ) used in classes
12. Ntp and Time, one classic example
Challenge
What time is it ?
Systems need to be accurate
update logs with timestamps
do action based on time
Network Time Protocol (NTP) is a networking
protocol for clock synchronization
13. Basic Ntp on a server (variables,
resources and templates)
file: some_manifest.pp
node ‘some_name_or_ip’ {
$package_name= “ntp”
$host_config = “xpto”
$ntp1 = “ip_or_address_1”
$ntp2 = “ip_or_address_2”
package { $package_name: ensure => installed, }
file { 'ntp_config_file':
ensure => file,
path => '/etc/ntp.conf',
require => Package[$package_name],
content => template('ntp.conf.erb'),
mode => '0644',
owner => 'root',
group => 'root',
}
(variables in orange and resources in red)
service { 'ntpd':
ensure => running,
name => 'ntpd',
enable => true,
subscribe => File['ntp_config_file'],
}
}
puppet apply some_manifest.pp
14. Templates … Files
Files are used to
configure services
The content can be
static ;-( or should
be based on
environment
Templates can add
Dynamic content
Based on variables
have ruby logic in it
( if/else, cycles, ….
)
15. Ntp template (ntp.conf.erb)- template
example
restrict default ignore
<% if @host_config == "some_value" -%>
server <%= @ntp1 %>
<% else -%>
server <%= @ntp2 %>
<% end -%>
server 127.127.1.0
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
keys /etc/ntp/keys
restrict 127.0.0.1
16. Not a clever way to code , Modules are
here
Modules are self-
contained bundles of
code and data.
file: some_manifest.pp
node ‘some_name_or_ip’ {class { 'my_ntp_module':}}
file: ./modules/my_ntp_module/manifests/init.pp
class my_ntp_module {
…. same do_stuff ….
file { 'ntp.conf':
….
content =>
template('my_ntp_module/ntp.conf.erb'),
..
}
}
file:./modules/my_ntp_module/templates/ntp.conf.erb
puppet apply --modulepath
./modules/some_manifest.pp
18. Code and data “all together” :-(...
welcome to backends (Hiera)
Purpose
separate data ( values) from logic (code)
support multiple data types (values, list, hash ….)
Hiera is a key/value lookup tool for configuration
data
Hiera can use several different data backends,
including two built-in backends ( yaml and JSON
) and other optional ones.
19. Data Encryption
Why ?
Secrets should be kept … secret
“someone” should know about Secrets
Backends may be encrypted when and where
needed for a list of “trusted persons"
21. Where Manifests (and related stuff)
are?
Manifests (and resources specified in it) must
exist on the system at the time they are
applied
They go there “by magic”:
“Someone” send them to the system ( push approach)
fetched from some place ( eg: VCS like git, svn, … ) (pull
approach )
“just are there”
23. Bootstrapping Servers - Process (1)
1.Install OS
2.“Hard” install
a.Set keys for VCS authorization
b.Set facts for the host (product/env/role/location/… )
c.Set hostname, and "basic stuff"
24. Bootstrapping Servers - Process (2)
3.“Soft” install
a.Fetch manifests code and backend data from VCS
based on facts
b.Apply puppet
