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
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Paul Hinze
February 06, 2013
Technology
130
0
Share
Puppet Modules Are Our Friends
Internal presentation given to Instructure Ops team, Feb 2013.
Paul Hinze
February 06, 2013
More Decks by Paul Hinze
See All by Paul Hinze
Getting Good at System Failure Analysis
phinze
0
470
Applying Graph Theory to Infrastructure As Code
phinze
6
2.2k
Infrastructure as Code with Terraform and Friends
phinze
2
330
SWIM: Scalable Weakly Consistent Infection Style Process Group Membership Protocol
phinze
2
390
Smoke & Mirrors: The Primitives of High Availability
phinze
1
740
Git: Everybody's Favorite MMO
phinze
0
200
Shut Up and Pipe! Unix-style Object Collaboration in Rack and Vagrant
phinze
0
180
Freighthop: Vagrant on Rails
phinze
0
330
Who Needs Clouds?: HA in Your Datacenter
phinze
1
540
Other Decks in Technology
See All in Technology
コードや知識を組み込む / Incorporate Code and Knowledge
ks91
PRO
0
150
基盤を育てる 外部SaaS連携の運用
gamonges_dresscode
1
120
AI バイブコーティングでキーボード不要?!
samakada
0
570
Revisiting [CLS] and Patch Token Interaction in Vision Transformers
yu4u
0
360
[OpsJAWS 40]リリースしたら終わり、じゃなかった。セキュリティ空白期間をAWS Security Agentで埋める
sh_fk2
3
240
Keeping Ruby Running on Cygwin
fd0
0
160
AgentCore×VPCでの設計パターンn選と勘所
har1101
3
280
Hacobu Tech Deck
hacobu
PRO
0
110
AI駆動1on1〜AIに自分を育ててもらう〜
yoshiakiyasuda
0
120
生成AIが変える SaaS の競争原理と弁護士ドットコムのプロダクト戦略
bengo4com
0
710
最近の技術系の話題で気になったもの色々(IoT系以外も) / IoTLT 花見予定会(たぶんBBQ) @都立潮風公園バーベキュー広場
you
PRO
1
240
Standards et agents IA : un tour d’horizon de MCP, A2A, ADK et plus encore
glaforge
0
170
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.1k
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
250
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
720
Navigating Team Friction
lara
192
16k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
0
1.1k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Git: the NoSQL Database
bkeepers
PRO
432
67k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
140
Building Applications with DynamoDB
mza
96
7k
Reality Check: Gamification 10 Years Later
codingconduct
0
2.1k
Accessibility Awareness
sabderemane
1
100
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