Managing HeterogeneousSystems with Puppet

Phil Fenstermacherpcfens@wm.edu

Heterogeneous?Lots of variance across what we run

VMs/BareMetalOperating SystemsBaseline ConfigurationsWhat we can reasonably manage

<me>Systems/Operations EngineerCollege of William & MaryPuppeting for ~3 years

</me>

You?Using Puppet?Write Modules?Higher Education?

When to start listening1. Why talk about this?2. Identifying Systems3. Assigning Resources4. Keeping it Manageable5. A few extras

Higher EducationIT supports our product — not a part of it

Support lots of things on campus mostly from one IT department

Multi-tennant NetworkE-MailERP SystemsHealth/Counseling Center (HIPAA)Athletics (Ticketing, eligibility, etc.)TelephonePolice (including 911)ID Card SystemsAll that academic stuff too

Why talk about heterogeneity?It's not easy obvious.

But Puppet is really good at (helping you do) it

Companies getting into Puppet for heterogeneous support

Constant Contact (March 16, 2011)Dell (December 4, 2013)

Puppet abstracts differencesWe don't have to figure out the apt-get vs. yum

puppet abstracts really common things

Puppet can't magically handleall differenceshttpd-devel vs. apache2-dev

Identifying SystemsfacterhieraEnvironmentsExternal Node Classifier (ENC)

facterProvides information about system

Tells what you need to know to decide apache2 or httpd

$package = $::osfamily ? { 'Debian' => 'apache2', default => 'httpd', }

hiera :hierarchy: - "%{::clientcert}" # host-00.example.com.yaml - "%{::osfamily}" # RedHat.yaml - "virtual_%{::virtual}" # virtual_vmware.yaml - "%{::custom_fact}" # cluster_01.yaml

Can merge all together

$ntp_servers = hiera_array('ntp_servers') # An array of all NTP servers, # including the special # cluster_01 servers hiera_include('classes') # Include classes merged from all levels, # global through host specific.

Or pull the first matching

$webserver = hiera('webserver') # $::osfamily says this is httpd

Environments if $::environment == 'production' { # (Almost) Everything in production } elsif $::environment == 'testing' { # (Almost) Everything in testing }

External Node ClassifierAssign Information Outside of Puppet

Declare ClassesAssign Global Variables*Set Environments

* Manifests still have to know what to do with this

Then what?Getting from variables to resources

Good Coding(Things that have bit us)

Avoid Manifests ConditionalsTend to get unmanageable as manifests grow

Modules don't use hiera()At least not now

Let hiera supply data to classes

hiera() inside a module isn't portable

Avoid re-inventing thingsCheck the forgeIf something is established — try using itIf it doesn't quite do what you need — try forking itSend back a pull request if you can

Model your modules afterothers

puppetlabs/apache and puppetlabs/ntp support a lot of OSes

Code samples of handling multiple OSes

Write Versatile ModulesDon't assume your use case is the use case

Avoid giant conditional blocks

Write everything like it's going to be open sourced

Write Testsspec tests seems simple – but they can prevent big errors

Especially useful for testing potential changes

Beaker tests are great for testing cross platform stuff

Other Heterogeneous WinsExported Resources

mcollective filters

@@f5_node { $::fqdn: addresses => [$::ipaddress], connection_limit => 100, session_enabled_state => 'STATE_ENABLED', }

$ mco puppet runall 5 -F osfamily=Debian -C mysql::server

Just SuggestionsHeterogeneity already means things are a little differentOur manifests and modules break these rulesWe also use node inheritenceNot everything can be handled by just changing some resourceparameters

package { 'puppetlabs-release': ensure => present, provider => $provider, source => $uri, }

Thank YouQuestions?