Search

creedio

Welcome – First blog post

Here you can learn some tips, tricks and shortcuts for a selection of technologies.

It is definitely puppet biased including all the technologies and processes that come along with it.  I want to go beyond the puppet language, as there are much better articles out there for you to read.   If puppet is the trojan horse, then ruby, jenkins, rspec, serverspec, foreman are just a few of the new things hiding inside that will make their way into the content.

I’ve created this to share some lessons learnt along the way, always fact over opinion wherever possible.  Please let me know if you’d like me to add any more detail.

BTW – I have no affiliation with Puppet.  All words are my own opinion (darn it – facts).

Advertisements
Featured post

Puppet and Solaris 11

Some facts about puppet support for Solaris 11:

  1. is a supported operating system for puppet agent.
  2. is not a supported operating system as puppet master
  3. limited support by puppet module developers, including approved and supported modules
  4. has specialised syntax constructs in the puppet DSL: pkg, zone, zfs
  5. Painfully unreliable when using with Packer
  6. Solaris APIs are deviating more from Linux, more things are command based instead of file based – meaning what works for most Linux variants, will not work on Solaris
  7. It’s part of the Solaris packaging system, but it’s running v3.6

Some tips and tricks to help:

  • Ensure you’re running ruby > 1.8, have seen issues recently where gems that are being maintained will not work
  • Contribute to existing projects, help them to support it – they probably don’t because they haven’t needed to and perhaps don’t have the test infrastructure to facilitate supporting it
  • Create your infrastructure with a different Operating System, and only use Solaris where you have to – easier said than done.  For example, build you master, forge server, jenkins nodes in linux and rely on beaker and virtualization to test against solaris VMs
  • Use puppet as a vehicle for migrating off Solaris.  The business case was clear when I could demonstrate what we took three weeks to do on Solaris took a few hours on Linux when using puppet
  • Install puppet 3.6 from the package repository and then upgrade immediately
  • Test, test, test, test and test

 

 

Puppet Hindsight

The Puppet DSL is an extremely powerful language.  In fact, if you’re anything like me, then as soon as you see it you want to start trying it out.

However, after six months of dabbling, here are some things I wish I’d really understood before embarking on a puppet adventure (retrofitting an environment with puppet):

  1. The Puppet DSL is a very small part of the workload.  Getting the production, test and build infrastructure is a lot more time consuming.
  2. Find the profiles and sites pattern and adopt it, use it for testing as well rather than relying on a UI to assign classes to nodes
  3. If you’re not using Linux and Git then you’re going to hit some challenges
  4. Incorporate rspec-puppet for unit testing your modules before they even touch a server
  5. Use beaker and serverspec to run acceptance tests against real VMs
  6. Learn ruby framework, especially bundler – ignore bundle at your peril
  7. Nested virtualisation is not your friend – if you’re bound to a Windows PC, like many of us, then you really want to run everything from a Linux VM – howerver, you can’t run beaker on this
  8. hiera is part of the solution
  9. Understand how you are going to use environments
  10. Use an internal puppet forge to store your modules, rather than attempting a quick fix and entering the world of SCM branching hell
  11. r10k should not be ignored

Most importantly, walk before you can run.  You probably need to deliver tangible benefits in a short time.  Find a process that is time consuming and painful, and fix it with puppet first.

Blog at WordPress.com.

Up ↑