• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Thinking through styling and layout of modules, class and defines by Tom Doran
 

Thinking through styling and layout of modules, class and defines by Tom Doran

on

  • 471 views

How do you structure your puppet code? Where do you put the files, how do you name things, how do you structure parameters and hieradata? I’m still stuck on puppet 2.7, how do I write code now to ...

How do you structure your puppet code? Where do you put the files, how do you name things, how do you structure parameters and hieradata? I’m still stuck on puppet 2.7, how do I write code now to take advantage of puppet 3.0 features when I upgrade?
This talk will go through a set of guidelines for writing classes, defines, having defaults and how to use hieradata right. It’ll be focusing on real code with real examples taken from modules I’ve helped write or code review.
Whilst suitable for beginners, this talk should hopefully be helpful for more advanced users as whilst most of us have a shared vision of ‘well known’ ways things can be done - we rarely step back and think through exactly why in detail.

Statistics

Views

Total Views
471
Views on SlideShare
471
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Thinking through styling and layout of modules, class and defines by Tom Doran Thinking through styling and layout of modules, class and defines by Tom Doran Presentation Transcript

    • Thinking through code layout - Tomas Doran @bobtfish tdoran@yelp.com 28/11/2013
    • Lots of great material • Still takes effort to understand • More than one right way to do it • KISS • Get data out of manifests • Follow conventions http://www.slideshare.net/PuppetLabs/modern-module-development-ken-barber-2012-edinburgh-puppet-camp http://www.slideshare.net/slideshow/embed_code/25536833 https://speakerdeck.com/player/889a6450ee6b0130026036a0670cc949
    • Modules only! • No manifests except site.pp • autoload structure • Modules work with environments • Well known higher level reuse patterns! (Later) All code should be in modules, always - with no exceptions except a site.pp
    • Be flexible! • Most important for forge modules! • For your own modules, KISS • Allow package install to be overridden! • Allow service to be not managed! • Don’t manage users!
    • Version compatibility • Puppet 0.x • … upgrade? • Puppet 2.7 • Parameterized classes • Dynamic scope • Puppet 3.0 • NO dynamic scope • Data bindings (automatic hiera) • Puppet 3.3 • Hiera in modules http://docs.puppetlabs.com/guides/parameterized_classes.html
    • Dynamic scope
    • Dynamic scope
    • NO Dynamic scope
    • Data binding Puppet 2.7
    • Data binding Puppet 2.7 Puppet 3.x
    • ARM9
    • ARM9 ????? Eh? Is that a processor type?
    • ARM9 Or one of these?
    • ARM9 - hiera in modules • In puppet 3.3: modules/foo/data modules/foo/data/common.yaml modules/foo/data/os/Linux.yaml modules/foo/hiera.yaml • Doesn’t really affect design if you did it right! https://github.com/puppetlabs/armatures/blob/master/arm-9.data_in_modules/index.md
    • Package / File / Service Starting at the basics….
    • Package / File / Service Most modules do something like this. Note the ${module_name} variable for DRY http://docs.puppetlabs.com/puppet/3/reference/lang_variables.html#parser-set-variables http://docs.puppetlabs.com/learning/ordering.html#packagefileservice
    • Metaparameters http://docs.puppetlabs.com/learning/ordering.html#packagefileservice
    • Package/Config/Service classes Putting each component in it’s own class makes dependencies simpler / more declarative http://www.devco.net/archives/2009/09/28/simple_puppet_module_structure.php
    • One entry point • Entry point should always be init.pp:
 
 include foo ! http://www.devco.net/archives/2009/09/28/simple_puppet_module_structure.php
    • Externalize dependencies • Put inter-class dependencies in init.pp Some people don’t like this (I do), as it makes the dependencies obvious from the entry point you include. http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.php
    • Separate parameters This is the traditional method, having a ::params class. This is good when you have conditional logic around parameters. http://docs.puppetlabs.com/puppet/3/reference/lang_classes.html#inheritance http://docs.puppetlabs.com/guides/parameterized_classes.html#appendix-smart-parameter-defaults
    • Hiera parameters (2.7) For simple (non conditional) values, you can just use a hiera lookup. If you’re shipping to the forge you still need params class, if you’re not you can just use hiera.
    • Hiera parameters (3.x) http://docs.puppetlabs.com/puppet/3/reference/lang_classes.html#inheritance http://docs.puppetlabs.com/guides/parameterized_classes.html#appendix-smart-parameter-defaults
    • Hiera parameter variance Data in params.pp is kinda gross. Move it out to common.yaml? Logic for which key to look in can be embedded in the hiera call (instead of params.pp).
    • Hiera parameter variance If your hierarchy includes: os/%{::operatingsystem} common ! You can just use: foo::package_name ! If you have ${::operating_system} in your hierarchy, you can do this simpler thing. Possible to argue this both ways round, but I’d recommend this as it’s more forward compatible (ARM9)
    • Hiera parameter variance If your hierarchy includes: os/%{::operatingsystem} common ! You can just use: foo::package_name ! Unless it’s a forge module :( If you’re shipping to the forge, you can’t (sanely) rely on puppet 3.3, and you don’t want to force people to add to their hieradata - fallback to params.pp
    • Puppet 3.3 Per module hierarchy: foo/data/os/%{::operatingsystem}.yaml foo/data/common.yaml
    • Use stdlib • str2bool • any2array • ensure_packages • ensure_resource • get_module_path • getparam • facts.d • many many more! https://github.com/puppetlabs/puppetlabs-stdlib
    • str2bool • ‘true’ vs true • All class parameters • All hiera data • Other backends may not have booleans! https://github.com/puppetlabs/puppetlabs-stdlib
    • any2array • Any time you take an array parameter! https://github.com/puppetlabs/puppetlabs-stdlib
    • ensure_packages / ensure_resource ! • Avoids duplicate resources ! ! ! • Same for generic resources https://github.com/puppetlabs/puppetlabs-stdlib
    • Toolkits • nginx::vhost {} • docker::run {}
    • Toolkits • nginx::vhost {} • docker::run {} • create_resources helper
    • Multiple instances • May have more than one nginx running! • This is where it gets complex :) • Class or define params override hiera • Default params in foo::bar • Instance params:
 foo::instance::${instance_name}::bar
    • Toolkits + Multiple instances
    • getparam (stdlib) https://github.com/puppetlabs/puppetlabs-stdlib
    • Toolkits + Multiple instances
    • Roles and profiles • Role = node classifier (contains >= 1 profile) • role::webserver • Profile = use multiple modules + hiera data • profile::apache • profile::tomcat • Module = Single concern • apache • tomcat http://www.craigdunn.org/2012/05/239/ http://blog.keepingyouhonest.net/?p=443 https://puppetlabs.com/learn/roles-profiles-introduction
    • tags for overriding http://docs.puppetlabs.com/puppet/3/reference/lang_resources.html#amending-attributes-with-a-collector
    • Thanks! http://www.yelp.com/careers?jvi=ogVTXfwL Slides will be up shortly at: http://slideshare.net/bobtfish/ Questions? $864 Mail: tdoran@yelp.com Twitter: @bobtfish