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
77
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
420
Applying Graph Theory to Infrastructure As Code
phinze
6
1.9k
Infrastructure as Code with Terraform and Friends
phinze
2
270
SWIM: Scalable Weakly Consistent Infection Style Process Group Membership Protocol
phinze
2
300
Smoke & Mirrors: The Primitives of High Availability
phinze
1
480
Git: Everybody's Favorite MMO
phinze
0
120
Shut Up and Pipe! Unix-style Object Collaboration in Rack and Vagrant
phinze
0
120
Freighthop: Vagrant on Rails
phinze
0
270
Who Needs Clouds?: HA in Your Datacenter
phinze
1
490
Other Decks in Technology
See All in Technology
可視化により内部品質をあげるAIドキュメントリバース/20240910 Hiromitsu Akiba
shift_evolve
0
220
サーバレスでモバイルアプリ開発! NTTコム「ビジネスdアプリ」のアーキテクチャ / The architecture of business d app
nttcom
12
240
『GRANBLUE FANTASY Relink』ソフトウェアラスタライザによる実践的なオクルージョンカリング
cygames
0
170
フルカイテン株式会社 採用資料
fullkaiten
0
32k
【株式会社ELYZA】|GENIAC成果報告会 自社開発モデルプレゼンテーション
elyza
1
270
Segment Anything Model 2
tenten0727
3
700
開発者の定量・定性データを組み合わせて開発者体験を把握するための取り組み
ham0215
1
130
サーバー管理しないサーバーサービスManaged DevOps Pool
kkamegawa
0
130
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
310
どこよりも遅めなWinActor Ver.7.5.0 新機能紹介
tamai_63
0
210
OSTという文化を組織に根付かせてみた
sansantech
PRO
2
390
サプライチェーン攻撃に備える
ryunen344
0
290
Featured
See All Featured
Visualization
eitanlees
142
15k
Optimizing for Happiness
mojombo
375
69k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
103
48k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
41
6.5k
Why You Should Never Use an ORM
jnunemaker
PRO
53
8.9k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.3k
Code Review Best Practice
trishagee
62
16k
What's in a price? How to price your products and services
michaelherold
242
11k
Building Applications with DynamoDB
mza
90
6k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
1
53
No one is an island. Learnings from fostering a developers community.
thoeni
18
2.9k
Building Flexible Design Systems
yeseniaperezcruz
325
38k
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