introduction to puppet - hands on session at hpi potsdam

TUTORIAL AND HANDS ON SESSION

*Puppet@HPI

Christoph OelmüllerChristoph.oelmueller@epost-dev.de

*Agenda

*why configuration management?

*puppet DSL - declarative resources instead of procedural code

*writing Puppet manifests

*anatomy of a Puppet run

*using Puppet without/with a master

*nice2knows

*master of Puppets (hands on)

*nice2know cont.

*Q & A

*why configuration management

Lazy admins, DevOps and Managers

*why configuration management

admins are generally as lazy as possible...

for s in $(<some_outdated_list.txt)

do

ssh $s „/bin/false“

done

http://optempo.com/images/trained_monkey.gif

*lazy admin cont.

manually

ssh loop

centralized procedural

• sequential – slow• system-dependant• inventory-

dependant• what about

authorization?

*DevOps toolset

* from dev to prod

* reproducable configurations

* system (*nix flavour) independency

DEV TEST PROD

*management view

* managed „things“ can...

* ...be compliant

* ...be reported

* ...fullfill security requirements

*don‘t forget these...

http://wikipedia.orghttp://www.business-cloud.de/cloudstorage-ja-aber-bitte-sicher/

*Puppet DSLdeclarative resources instead of procedural

code

*Puppet DSL

1. describe what you want to be configured

2. (don‘t care how it is done)

3. describe dependencies

file package service types

win *nix deb rpm POSIX win providers

package{„ntp“: ensure => installed }

file{„/etc/ntp.conf“: ensure => present, user => root, group => root, mode => 644, source => puppet://...}

service{„/etc/ntp.conf“: ensure => running,}

package{„ntp“: ensure => installed }

file{„/etc/ntp.conf“: ensure => present, user => root, group => root, mode => 644, source => puppet://..., require => Package[‚ntp‘]}

service{„ntpd“: ensure => running, require => File[‚/etc/ntp.conf‘]}

*resource ordering

before after

without refresh

before => Resource[‚name‘] require => Resource[‚name‘]

with refresh notify => Resource[‚name‘] subscribe => Resource[‚name‘]

in our resources

chaining syntax

Resource[‚‘] -> Resource[‚name‘] ~> Resource[‚name‘] mind th

e ca

se!

*anatomy of a Puppet run

1. retreive plugins from server

2. get „facts“ on client and send them to master

3. compile catalog and send it to the client

4. apply catalog on client

5. process report

*names, names, names...

* Manifest: your Puppet DSL (*.pp)

* Catalog: serialized host specific DSL

* Facts: host specific set of vars

* Plugins: puppet extensions

* facts, types, providers, reports...

*get server facts - facter

[root@puppet ~]# facter

architecture => x86_64

augeasversion => 0.9.0

bios_release_date => 12/01/2006

bios_vendor => innotek GmbH

bios_version => VirtualBox

blockdevice_sda_model => VBOX HARDDISK

blockdevice_sda_size => 214748364800

blockdevice_sda_vendor => ATA

domain => example.com

facterversion => 1.7.2

filesystems => ext4,iso9660

fqdn => puppet.example.com

hardwareisa => x86_64

hardwaremodel => x86_64

hostname => puppet

id => root

interfaces => eth0,lo

ipaddress => 10.0.2.15

ipaddress_eth0 => 10.0.2.15

ipaddress_lo => 127.0.0.1

is_virtual => true

kernel => Linux

*writing manifests

node definitions & modules & delivering content

*node definitions

%manifestdir/site.pp:node frontend.example.com {

file{‚/etc/apache2/httpd.conf‘:

ensure => present,

...

}

...

}

node db1.example.com {

...

}

which

type

s ge

tting

app

lied

where

?

*node definitions cont

%manifestdir/site.pp:node frontend.example.com {

# file{‚/etc/apache2/httpd.con‘:

# ensure => present,

# ...

#}

include apache2

# class{„apache2“:}

}

node db1.example.com {

...

}

use

mod

ules

!

*modules – putting it all together

directory structure in %modulepath:

mkdir –p modulename/{manifests,files,templates,lib,spec}

- manifests : where your .pp goes

- files : where your static content goes

- templates : where your dynamic content goes

(remember facts)

- lib : where your advanced puppet knowledge goes

- specs : home of Q&A‘s happiness

*modules – init.pp

%modulepath/modulename/manifests/init.pp:

class modulename() {

file{„/tmp/testfile.conf“:

ensure => present,

...

}

package{„mypackage“:

ensure => latest,

}

service{„myinitscript“:

ensure => running

}

}

* delivering content – the file type

# static file content

file{„/tmp/testfile1.conf“:

ensure => present,

source => „puppet://mymodule/testfile1.conf“

}

# templating

file{„/tmp/testfile2.conf“:

ensure => present,

content => template(„testfile2.conf.erb“)

}

remember the dire

ctorie

s „files“

and „templates“

...

*using puppetone binary to rule them all - faces

[root@puppet ~]# puppet helpUsage: puppet <subcommand> [options] <action> [options]

Available subcommands: agent The puppet agent daemon apply Apply Puppet manifests locally cert Manage certificates and requests master The puppet master daemon module Creates, installs and searches for modules on the Puppet Forge. parser Interact directly with the parser.

puppet apply: • apply manifests locally• no master needed• no centralized fileserver

• test • headless puppet

• no SSL-communication allowed

???

[root@puppet ~]# puppet helpUsage: puppet <subcommand> [options] <action> [options]

Available subcommands: agent The puppet agent daemon apply Apply Puppet manifests locally cert Manage certificates and requests master The puppet master daemon module Creates, installs and searches for modules on the Puppet Forge. parser Interact directly with the parser.

puppet master: • starts https service• TCP/8140• internal webserver (ruby)• scalable (mod_passenger)

puppet agent:• manages puppet runs on client

• regularly• one-time

SSL

[root@puppet ~]# puppet helpUsage: puppet <subcommand> [options] <action> [options]

Available subcommands: agent The puppet agent daemon apply Apply Puppet manifests locally cert Manage certificates and requests master The puppet master daemon module Creates, installs and searches for modules on the Puppet Forge. parser Interact directly with the parser.

puppet module: • interacts with puppetlabs module repository

puppet parser validate:• syntax check manifests

*nice2knowpre-Hands-On...

*nice2know

* find puppets configuration:

* puppet config print

* puppet.conf (PE vs. OSE)

* debugging puppet:

* puppet parser validate <file.pp>

* puppet agent/apply –-noop (use it!!!)

* running agent in „test“ mode

* includes one-time

* includes verbose

* doesn‘t include noop!!!

*master of puppets

Hands-On

*Tasks 1

* connect to your learning instance and play around a bit

* launch puppet help

* launch a puppet master

* launch a client side puppet run

* find configuration files

* inspect the process list / ports

* find your manifests, site.pp, modules

* create an empty testfile via local puppet run

* implement a NTP module _1

*make sure NTPd is installed

* deliver your ntp.conf via puppet

*make sure NTPd is running

pin

g y

ou

rself if

idle

: p

ing

loca

lhost

*Tasks 2

* implement a NTP module _2

*make sure NTPd is installed

* deliver your ntp.conf via puppet – dynamic content

*make sure NTPd is running

pin

g y

ou

rself if

idle

: p

ing

loca

lhost

*Tasks 3

* implement a NTP module _3

*make sure NTPd is installed

* deliver your ntp.conf via puppet

* dynamic file content

* make sure NTPd is running

* first install NTPd, then configure it, then handle the service

* restart the service, if configuration file has been changed

pin

g y

ou

rself if

idle

: p

ing

loca

lhost

*nice2knowpost-Hands-On...

*nice2know

* puppets internal CA

* on master: puppet cert --list --all

* on client: NIL

* rm –rf /var/lib/puppet/ssl

* don‘t repeat others

* forge.puppetlabs.com – puppet module

* ask others:

*ask.puppetlabs.com

*Nice2know cont.

* resource ordering f*ck-ups?!

* puppet agent –t –-graph --noop

external

internal

regulary

one-time

*discussion

* how to trigger a puppet run?

puppet agent

cron‘d one-time

ssh‘d one-time

MCollective

*Q & Agot questions?

*build your labvagrant & puppet