Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Puppet Modules Are Our Friends
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Paul Hinze
February 06, 2013
Technology
0
120
Puppet Modules Are Our Friends
Internal presentation given to Instructure Ops team, Feb 2013.
Paul Hinze
February 06, 2013
Tweet
Share
More Decks by Paul Hinze
See All by Paul Hinze
Getting Good at System Failure Analysis
phinze
0
460
Applying Graph Theory to Infrastructure As Code
phinze
6
2.2k
Infrastructure as Code with Terraform and Friends
phinze
2
310
SWIM: Scalable Weakly Consistent Infection Style Process Group Membership Protocol
phinze
2
380
Smoke & Mirrors: The Primitives of High Availability
phinze
1
680
Git: Everybody's Favorite MMO
phinze
0
180
Shut Up and Pipe! Unix-style Object Collaboration in Rack and Vagrant
phinze
0
170
Freighthop: Vagrant on Rails
phinze
0
310
Who Needs Clouds?: HA in Your Datacenter
phinze
1
530
Other Decks in Technology
See All in Technology
CDK対応したAWS DevOps Agentを試そう_20260201
masakiokuda
1
300
GitLab Duo Agent Platform × AGENTS.md で実現するSpec-Driven Development / GitLab Duo Agent Platform × AGENTS.md
n11sh1
0
140
モダンUIでフルサーバーレスなAIエージェントをAmplifyとCDKでサクッとデプロイしよう
minorun365
4
210
制約が導く迷わない設計 〜 信頼性と運用性を両立するマイナンバー管理システムの実践 〜
bwkw
3
940
Digitization部 紹介資料
sansan33
PRO
1
6.8k
~Everything as Codeを諦めない~ 後からCDK
mu7889yoon
3
380
30万人の同時アクセスに耐えたい!新サービスの盤石なリリースを支える負荷試験 / SRE Kaigi 2026
genda
4
1.3k
15 years with Rails and DDD (AI Edition)
andrzejkrzywda
0
190
20260204_Midosuji_Tech
takuyay0ne
1
160
コスト削減から「セキュリティと利便性」を担うプラットフォームへ
sansantech
PRO
3
1.5k
CDKで始めるTypeScript開発のススメ
tsukuboshi
1
430
SRE Enabling戦記 - 急成長する組織にSREを浸透させる戦いの歴史
markie1009
0
120
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3.1k
A Soul's Torment
seathinner
5
2.3k
WENDY [Excerpt]
tessaabrams
9
36k
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
230
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
1
1.3k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
290
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
76
Facilitating Awesome Meetings
lara
57
6.8k
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
120
Into the Great Unknown - MozCon
thekraken
40
2.3k
What's in a price? How to price your products and services
michaelherold
247
13k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Transcript
Puppet Modules
constructing a module putting modules together designing good modules
constructing a module
our mission # TODO: Turn this pattern into a puppet
module file { "/etc/init/collect-cpu-stats.conf": content => template("etc/init/collect-cpu-stats.conf.erb") } file { "/etc/init.d/collect-cpu-stats": ensure => "/lib/init/upstart-job", } remotefile { "/usr/local/bin/collect-cpu-stats": mode => 755, notify => Service["collect-cpu-stats"], } service { collect-cpu-stats: ensure => running, require => [ File["/usr/local/bin/collect-cpu-stats"], File["/etc/init/collect-cpu-stats.conf"], File["/etc/init.d/collect-cpu-stats"], ] }
a place for everything... $ tree puppet/modules/collect_cpu_stats collect_cpu_stats # module
root dir ├── files # static files ├── lib │ ├── facter # custom facts │ └── puppet │ ├── parser │ │ └── functions # custom parser functions │ └── type # native puppet types ├── manifests │ └── init.pp # *** entry point *** └── templates # template files
...and everything in its place $ tree puppet/modules/collect_cpu_stats collect_cpu_stats ├──
files │ └── collect-cpu-stats ├── manifests │ ├── config.pp │ ├── init.pp │ ├── script.pp │ └── service.pp └── templates └── collect-cpu-stats.conf.erb
the classic init.pp class collect_cpu_stats { include collect_cpu_stats::package include collect_cpu_stats::config
include collect_cpu_stats::service Class['collect_cpu_stats::package'] -> Class['collect_cpu_stats::config'] -> Class['collect_cpu_stats::service'] -> Class['collect_cpu_stats'] } manifests/init.pp
adding parameters class collect_cpu_stats ( $hostname = $fqdn $interval =
10 ) { include collect_cpu_stats::package class { 'collect_cpu_stats::config' hostname => $hostname, interval => $interval } include collect_cpu_stats::service Class['collect_cpu_stats::package'] -> Class['collect_cpu_stats::config'] -> Class['collect_cpu_stats::service'] -> Class['collect_cpu_stats'] } manifests/init.pp
customize names for clarity class collect_cpu_stats ( $hostname = $fqdn
$interval = 10 ) { include collect_cpu_stats::script class { 'collect_cpu_stats::config' hostname => $hostname, interval => $interval } include collect_cpu_stats::service Class['collect_cpu_stats::script'] -> Class['collect_cpu_stats::config'] -> Class['collect_cpu_stats::service'] -> Class['collect_cpu_stats'] } manifests/init.pp
script.pp: sourcing files class collect_cpu_stats::script { file { '/usr/local/bin/collect-cpu-stats': mode
=> 755, source => 'puppet:///modules/collect_cpu_stats/collect-cpu-stats' } file { '/etc/init.d/collect-cpu-stats': ensure => link, target => '/lib/init/upstart-job' } } manifests/script.pp
config.pp: using templates class collect_cpu_stats::config ( $hostname, $interval ) {
file { '/etc/init/collect-cpu-stats.conf': content => template('collect_cpu_stats/collect-cpu-stats.conf.erb'), notify => Class['collect_cpu_stats::service'] } } manifests/config.pp
service.pp: simple as it gets class collect_cpu_stats::service { service {
'collect-cpu-stats': ensure => running, } } manifests/service.pp
ta da! $ tree puppet/modules/collect_cpu_stats collect_cpu_stats ├── files │ └──
collect-cpu-stats ├── manifests │ ├── config.pp │ ├── init.pp │ ├── script.pp │ └── service.pp └── templates └── collect-cpu-stats.conf.erb
designing good modules
it’s just unix philosophy Rule of Modularity Rule of Clarity
Rule of Composition Rule of Separation ... etc.
unix philosophy in puppet “do one thing well” require/notify classes,
not types design for composability pull configuration up to init.pp intentional interface design
use the puppet style guide one class/define per file one
parameter per line quoting, spacing, etc. when in doubt, check it!
putting modules together
None
types of puppet modules “base-blocks”: generic to the world “weird-blocks”:
specific to us “site-services”: assemble blocks “site-roles”: assemble services
build it up collectd
build it up collectd collect_cpu_stats
build it up instructure::monitoring collectd collect_cpu_stats ...
instructure::monitoring collectd collect_cpu_stats ... instructure::logging rsyslog rsyslog_forward ... build it
up
app_server build it up instructure::monitoring collectd collect_cpu_stats ... instructure::logging rsyslog
rsyslog_forward ... canvas::rails passenger canvas::deps ... apache2
app_server build it up instructure::monitoring collectd collect_cpu_stats ... instructure::logging rsyslog
rsyslog_forward ... canvas::rails passenger canvas::deps ... apache2 db_server instructure::monitoring collectd collect_cpu_stats ... instructure::logging rsyslog rsyslog_forward ... canvas::database pgfouine canvas::pgdbs ... postgres
Puppet Modules