CM tools • Brief description of a few currently popular CM tools • Puppet Audience • Those that are not indoctrinated into DevOps culture • No experience with Puppet or other CM tools
– Often “things” are not setup the way you think they are • Configuration verification is labor intensive – Most installation tools/scripts are brain dead • “Business logic” is often redeveloped over and over again – I know I configured X just last year... • Configuration data ends up being: – ephemeral – unversioned – unreproducible
across many systems ends up costing ~O(N) in labor • Software updates can be even more labor intensive than an initial deployment • Disaster recovery time == help! • By hand configuration scales at best linearly – FTEs = ~servers / admin_efficiency • Automated configuration has the potential to scale based on configuration complexity instead of the number of nodes – FTEs = (resources * resource_complexity) / admin_efficiency
of the instrument, and it may be formulated as follows: Give a small boy a hammer, and he will find that everything he encounters needs pounding." – Abraham Kaplan – Abraham Kaplan
doing anything useful • ~2003 bcfg – Never got it working • ~2003 CFEngine 2.something – Still hadn't learned my lesson • ~2006-2009 rolled my own – Perl, ssh, rsync, make, and unionfs mounts – Static per host configs created by unioning <site>:<group>:<hostname> – Currently still in use managing ~100 hosts
kickstart %postscripts – Update IDL license files on workstations – Started using TheForeman as an ENC • 2011 Puppet & TheForeman (1st project @ NOAO) – Image and configure brand new cluster hardware – Incrementally brought up across most of the server environment for common configs (ntp, resolv.conf, ssh, etc.) – Production applications currently being brought under umbrella
operations – code reuse (write a function instead of cut'n'paste) → configuration automation via reusable modules/cookbooks/recipes/formulas/etc. – source version control → configuration data version control – unit & integration tests → configuration testing (and even CI) • The holy grail is to be able to treat infrastructure “as code”
Small, fast, scalable, few dependencies – Started 1993 – https://en.wikipedia.org/wiki/Promise_theory (you have been warned) – commercial support http://cfengine.com • Puppet – Server/agent model – DSL – Started 2005 – Commercial support http://puppetlabs.com
– Client/server/agent model – Ruby DSL – Started 2009 – Commercial support http://opscode.com • Salt – Publisher/subscriber – Started 2011 – Templated YAML – Commercial support http://saltstack.com
being a mathematical quantity which when applied to itself under a given binary operation (as multiplication) equals itself; also : relating to or being an operation under which a mathematical quantity is idempotent “ - m-w.com Time –> Host state Manifest New resource defined State modified State converged State changed outside of puppet (sudo abuser;)
Resources are modeled with “Types” – One or more “Providers” per Type user { 'bob': uid => 567, ensure => present, } – The user Type has many Providers • useradd Provider on systems that include it with certain capabilities (linux) • directoryservice Provider on darwin • Providers for aix, hpux, solaris, ldap, windows, etc.
}" Notice: hello world Notice: /Stage[main]//Notify[hello world]/message: defined 'message' as 'hello world' Notice: Finished catalog run in 0.18 seconds
not be done for Classes and defined Types in the Puppet DSL but it can be done for Types implemented in Ruby file {'/tmp/b/c': } file {'/tmp/': ensure => directory } file {'/tmp/d/': ensure => directory } file {'/tmp/d/e': } file {'/tmp/b/': ensure => directory } file {'/tmp/a': } file {'/tmp/d/f': }
be declared only once in a manifest • If something needs to be declared multiple times with different titles, you need to use a defined Type (no example). class foo ($arg1 = 'default', $arg2) { user{ $arg1: ensure => $arg2, } } class{ 'foo': arg1 => 'bob', arg2 => 'present, }
on line 53 rake aborted! /home/jhoblitt/.gem/ruby/1.9.1/gems/puppet-lint-0.3.2/lib/puppet-lint/tasks/p /home/jhoblitt/.gem/ruby/1.9.1/gems/puppet-lint-0.3.2/lib/puppet-lint/tasks/p Tasks: TOP => lint (See full trace by running task with --trace) $ rake spec Cloning into 'spec/fixtures/modules/stdlib'... [...] HEAD is now at bebecd3 Merge branch 'update_gemspec' for 4.0.2 /usr/bin/ruby -S rspec spec/classes/gmetad_spec.rb spec/classes/gmond_spe dnsdomainname: Name or service not known ... Finished in 2.24 seconds 3 examples, 0 failures