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
94
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
650
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
『バイトル』CTOが語る! AIネイティブ世代と切り拓くモノづくり組織
dip_tech
PRO
1
110
定期的な価値提供だけじゃない、スクラムが導くチームの共創化 / 20251004 Naoki Takahashi
shift_evolve
PRO
4
360
大規模サーバーレスAPIの堅牢性・信頼性設計 〜AWSのベストプラクティスから始まる現実的制約との向き合い方〜
maimyyym
6
4k
OCI Network Firewall 概要
oracle4engineer
PRO
2
7.8k
20201008_ファインディ_品質意識を育てる役目は人かAIか___2_.pdf
findy_eventslides
2
600
【Kaigi on Rails 事後勉強会LT】MeはどうしてGirlsに? 私とRubyを繋いだRail(s)
joyfrommasara
0
220
能登半島災害現場エンジニアクロストーク 【JAWS FESTA 2025 in 金沢】
ditccsugii
0
290
なぜAWSを活かしきれないのか?技術と組織への処方箋
nrinetcom
PRO
1
370
Large Vision Language Modelを用いた 文書画像データ化作業自動化の検証、運用 / shibuya_AI
sansan_randd
0
130
from Sakichi Toyoda to Agile
kawaguti
PRO
1
110
10年の共創が示す、これからの開発者と企業の関係 ~ Crossroad
soracom
PRO
1
700
AI時代こそ求められる設計力- AWSクラウドデザインパターン3選で信頼性と拡張性を高める-
kenichirokimura
3
270
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Facilitating Awesome Meetings
lara
56
6.6k
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
The World Runs on Bad Software
bkeepers
PRO
71
11k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
A designer walks into a library…
pauljervisheath
209
24k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6.1k
The Power of CSS Pseudo Elements
geoffreycrofte
79
6k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
32
2.3k
Context Engineering - Making Every Token Count
addyosmani
5
220
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
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