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!

No comments:

Post a Comment

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...