Tuesday, 10 May 2016

latest puppet features

Just discussing opensource puppet here - puppet 4.4.2 features are included in puppet enterprise 2016.1

naming conventions / version numbers are confusing - there is an overall package - e.g. 4.4 here  -that includes different versions o f puppet,ruby,facter,hiera ...

theres also a separate puppetserver package (this is version 2.3!)

theres also a puppetdb package - installs puppetdb 3

Migrating from puppet 3 to 4 isnt without some effort - existing puppet dsl may no longer work.

pretty good guide to upgrading at upgrade puppet from 3 to 4 (summary - use puppet_agent module)

442 essentially bug fixes
441 bug fixes + minor hiera enhancement
440 iterables, iterator types, type aliases,produce arrays from iterators with splat (*)


  • pluginsync now deprecated - this is now the default behaviour  - same as value use_cached_catalog
  • all in one packaging (AIO) now - as per my initial moan re diverse version numbers
  • stringified facts
  • puppet kick gone - pity
  • node inheritance gone
  • now have epp instead of epp (embedded puppet) erb still works
  • new locations for files and directories:
          /opt/puppetlabs/bin      -> linux executables
          /etc/puppetlabs/puppet -> confdir
          confdir now moved to /etc/puppetlabs/code
          dir environments are always on (yay!)
          vardir moved - /opt/puppetlabs/puppet/ccache
          rundir moved - /var/run/puppetlabs
  • no longer dependent on OS version of RUBY - AIO now bundles it
  • biggest diff is DSL has a new parser and evaluator (re future parser):   
          - iteration/type checking/http api changes/manifest ordering by default





Tuesday, 22 March 2016

Ansible 2.0 New Features

Ansible 2.0 New Features


big software refactoring - previous rapid growth/technical debt, bolted on features like roles not implemented perfectly. lots of code cleanup and make it easier to add ew features going forward..

added blocks - try/except/finally c.f. python; allows you to try things, catch errors falls through to finally.

blocks allow you to group related tasks together, dont need to use tags

- block:
   - name: stuff 1
...
can have nested blocks - too many can be overly complex to debug (e.g. could do for multiple OS)

blocks allow subset of variables only set for tasks within that block - local scope

improved error messages, shows line/file/col of task that failed

new option any_errors_fatal: true (if any host fails in block then all hosts go to rescue section - all or nothing deployment) (from 2.0.1)

execution strategy plugins - linear (traditional, wait for all hosts to complete task before moving on to 2nd task etc) or free - each host runs all tasks asap without waiting for others to catch up.

now have dyn-amic includes

improved variable management - variable precedence more consistent

200+ new modules - e.g. ec2,openstack,windows(beta),docker

new inventory scripts

more OO oriented/inheritance etc - more of an internals feature

what might break in V2? should be 100% backwards compatible, most possible issues due to variable precedence and dynamic includes, stricter with yaml now.







Monday, 14 March 2016

ansible vs puppet

Ansible vs Puppet


ok - so I should be comparing more than this - chef/salt/cfengine(whatver happened to that?) - however my experience of salt was minimal - also in the early days - turned out enought to make me happy to not look at it again. No real experience with chef - something I should look at more. 

cfengine - odd one  - something I did work with a few years ago and quite liked - however from a commercial viewpoint it seems to have disappeared.

Also - and I think this will lead to a bit of a paradigm shift - how will running apps in containers such as docker under control of kubernites mean we no longer need such fully featured config management systems - if (if!) an organisation has a few standard builds then they can easily be replicated using tools such as docker. (is docker ready for prod yet - possibly not!)

I first started using puppet in 2006 - was extremely impressed with it - the abstraction it gave was really useful when handing things over to sysadmins with little experience, also at the time the install was easy, generally using the trinity of file, package, service most modules where very easy to use.

moving forward - my last few contracts have exposed me to some serious problems with  puppet:

  • install - its now so big and complex - enterprise. 
  • no standard install patterns - not even from puppet. for example how does one provide HA for puppetdb.. always home brewed. However this can be an advantage - have flexibility to do things your own way.
  • issues with scalability - performance especially with Ruby - sucks. This is being addressed (e.g. cfacts, rewrite of multiple things in C++ rather than Ruby - ultimately moving to golang?) - however ansible performance doesnt seem to be exceptionally faster (yes I've tried accelerated mode and reusing ssh sockets)
  • running ad hoc commands - mcollective is a wonderful bit of coding, the ideas behind it from a computer science perspective I love .. however its not fit for purpose. One of the first things most experienced puppet devops do is to install parallel shell or something else..
  • after multiple issues with mcollective I installed ansible to run one off commands or queries - then progressed to basic playbooks.
  • Found that ansible is soo easy in comparison - for example I recently upgraded ansible at my current client from 1,9.4 to 2. took me literally 30 seconds - nothing needed other than a simple change on my server - obviously nothing needed on clients.
Now there are lots of arguments and discussions re push vs pull model/ordering/clients/use of ssh/dependencies/relationship graphs .. these to me dont matter  a great deal - what makes ansible the clear winner for me vs puppet enterprise is that I feel again I'm a devops - I'm looking after the business problems of the company and I'm not just debugging issues with puppet setup and installs/upgrades. Once you spend more time administering the software itself - well thats time to look at other solutions.

One of the big advantages puppet has is the userbase - large number of people experienced in it, also most modules you'll need have allready been written (google puppetforge). With Puppets maturity also comes advantages - ansible does have a few bugs, also lacking certain basic features (e.g. the mount doesnt do proper remounts for nfs, issues with variable parsing)


Now - dont get me wrong - if you have a stable puppet install with simple modules then theres no need to move away from it - however do take a look at ansible!

bash best practices

Bash best practices A few hints on bash best practice: * use #!/usr/bin/env bash .. this is more portable but you cant rely on a spe...