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
Paul Hinze
February 06, 2013
Technology
0
93
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
450
Applying Graph Theory to Infrastructure As Code
phinze
6
2.1k
Infrastructure as Code with Terraform and Friends
phinze
2
300
SWIM: Scalable Weakly Consistent Infection Style Process Group Membership Protocol
phinze
2
350
Smoke & Mirrors: The Primitives of High Availability
phinze
1
640
Git: Everybody's Favorite MMO
phinze
0
170
Shut Up and Pipe! Unix-style Object Collaboration in Rack and Vagrant
phinze
0
150
Freighthop: Vagrant on Rails
phinze
0
300
Who Needs Clouds?: HA in Your Datacenter
phinze
1
510
Other Decks in Technology
See All in Technology
Unlocking the Power of AI Agents with LINE Bot MCP Server
linedevth
0
130
企業の生成AIガバナンスにおけるエージェントとセキュリティ
lycorptech_jp
PRO
3
200
Webアプリケーションにオブザーバビリティを実装するRust入門ガイド
nwiizo
7
900
「全員プロダクトマネージャー」を実現する、Cursorによる仕様検討の自動運転
applism118
22
12k
AIがコード書きすぎ問題にはAIで立ち向かえ
jyoshise
4
1.1k
Wantedlyの開発組織における生成AIの浸透プロジェクトについて
kotominaga
2
130
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
280
Firestore → Spanner 移行 を成功させた段階的移行プロセス
athug
1
510
Snowflake Intelligenceにはこうやって立ち向かう!クラシルが考えるAI Readyなデータ基盤と活用のためのDataOps
gappy50
0
290
開発者を支える Internal Developer Portal のイマとコレカラ / To-day and To-morrow of Internal Developer Portals: Supporting Developers
aoto
PRO
1
480
Rustから学ぶ 非同期処理の仕組み
skanehira
1
160
20250913_JAWS_sysad_kobe
takuyay0ne
2
260
Featured
See All Featured
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.1k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Into the Great Unknown - MozCon
thekraken
40
2k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Designing for Performance
lara
610
69k
Speed Design
sergeychernyshev
32
1.1k
GitHub's CSS Performance
jonrohan
1032
460k
YesSQL, Process and Tooling at Scale
rocio
173
14k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Raft: Consensus for Rubyists
vanstee
140
7.1k
Being A Developer After 40
akosma
90
590k
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