Tag: Puppet

Why Configuration Management and Provisioning are Different

In “Why Configuration Management and Provisioning are Different” Carlos Nuñez advocates for the use of specialized infrastructure provisioning tools, like Terraform, Heat, and CloudFormation, instead of relying on the configuration management tools, like Ansible or Puppet.

I agree with his argument for the rollbacks, but not so much for the maintaining state and complexity.  However I’m not yet comfortable to word my disagreement – my head is all over the place with clouds, and I’m still weak on the terminology.

The article is nice regardless, and made me look at the provisioning tools once again.

Checking out Ansible. Sorry Puppet

It’s Thursday evening of a particularly difficult week at work.  Tomorrow is a public holiday, effectively making this – a Friday.  My brain is blank and exhausted, so I can’t do anything productive.  And I’m too tired to go out.  But I can still learn a thing or two.

First things first – cancel the external noise.  I want something loud, but not too intensive, and with no words in it.  So this 2 hour blues instrumental collection comes in handy.  Start the playback, put the headphones on, and push the volume up.

Now.  Here’s something I wanted to look into for quite some time – Ansible configuration manager.

Continue reading Checking out Ansible. Sorry Puppet

Puppet : Beginner’s Guide to Modules

I’ve been using Puppet here and there for about a year now.  In the last six month, I went rather heavy, and managed to accumulate quite a bit of modules, configs, hosts, etc.  Refactoring some of the code, and trying out new ideas, I’m reading through the Beginner’s Guide to Modules to help me with the best practices.  A couple of bits from there, I think, are worth quoting:

(Tip: If you describe the function of your module and you find yourself using the word ‘and’, it’s time to split the module at the ‘and’.)

This above is useful to people like me, who got comfortable throwing bits and pieces into modules, but don’t quite know yet where is that thin line for the module separation.  The above tip makes that crystal clear.  So, for example, “my module installs and configures something” no becomes two modules, where one “installs something” and another “configures something”.

It is standard practice for Puppet users to have upwards of 200 modules in their environment.

With this I know that my current setup is rather small and simplistic.  It’s not the numbers I am after, of course.  But, again, it’s difficult to say if I am doing too much of it, or not enough; if the system has been built to scale to the level where I am.  It turns out,  I have a long way to go.  A quick check shows that I’m at 127 modules in my current setup.  And that one is used for configuring pretty much everything – base installs, web / db / dev servers, desktops, etc.

Some of it will get expanded as I am replacing quite a bit of my own modules with third-party ones.  Interestingly enough, I wasn’t comfortable using other people’s code in the beginning and wanted things to be precisely my way (there were some time constraints).  It worked well, for a time.  But not a lot of it can be thrown away and replaced with other people’s code.  More features and less maintenance for the win!