I've driven a CFengine for 15 years, and I'm putting on a Chef's hat so I can get my Puppet to play with an Ansible.
This is good in my books. Still no maven with Puppet. But One Day I'll get there.
*p.s. Automation ROCKS!*
Software automation and management outfit Puppet has inhaled another $42m of funding in its efforts to go global. The Portland, US-based company is big in the DevOps sector, with its products geared towards what it calls “pervasive automation”, and what others might refer to as simply automating the heck out of everything and …
A bit like Docker feels too. It works but it's hardly polished and there are quite a lot of feature holes.
I imagine that the $42 million extra will, if not quite polish a turd, will be able to purchase a nice cologne, so it will at least smell nice :o)
'we' are just getting our feet wet in Docker, will need to do some reading on Puppet, anything that gains that much upfront VC $$ and isn't a console :oP must be doing something right
I worked with Chef or a year and a half, and later with Ansible. With a year and a half at Google as well.
While these tools can be very useful, I have become convinced that they are just "wrong". The tagline "infrastructure as code" is used by all of them. It is an excellent tagline, but what does it mean? When you move a problem into the space of "code", the proper workman is a programmer. If the code is big enough, you want a software engineer. Okay. So the proper users of these tools are SWEs. Not operations engineers. This matters a lot, because the tools of a SWEs are programming languages, libraries, and service APIs. Not DSLs.
You were right to bring me into the room. The problem is not going to be solved by really good hackers (no offense to the Ops Engineers that will instruct me in the fundamentals of their crafts in order for me to function in this space)--you need a SWE. Now, give me the tools that I use in my craft, and let me do my job.
What this really means is your infrastructure config is stored in version controlled text files and applied by the automation software (i.e. Ansible). Then throw in CI/CD into the mix and you have full on automation and change tracking for infrastructure. For e.g. to change a firewall rule in Ansible, you modify the config file similar to:
You then save your text file, do the usual development style commits and merge/pull requests to push that change onto the staging and eventually production (master) branches, where CI/CD will apply the scripts to the actual hosts. The merge/pull requests ensure that if the config breaks staging, you cannot push it to production.
Also keep in mind tools like Ansible aren't limited to Linux/Windows and can configure a huge variety of switches, routers and network equipment.
If that is the case, then why is Ansible constantly adding computational capabilities to their "text file"? Loops (with local variables), conditionals, macro expansions which are inherited from a Turing-complete language, but NO. NO TESTS. WE DON'T DO THAT.
Ansible is particularly problematic because you have to fight it to test the very complex logic that is encourages you to put into these files. At least Chef encourages testing.
Having used Puppet for several years, and Ansible for about 3, given the choice I'd chose Ansible over puppet every time. Much faster and easier to learn, write, deploy, update, maintain and scale. Puppet infrastructure when you scale up to thousands of systems over distributed DCs is a nightmare to get right. When your catalogues mysteriously decide to take several+ minutes to compile you'll lose lots of hair trying to figure out where in the sprawling spread of Load Balancers, Puppetmasters, CA Server(s), Puppet DB servers (and Postgres DB servers) the bottleneck is coming from. Or perhaps the ENC is having an issue pulling from your CMDB. Plus you'll stand no chance what so ever of keeping up with puppet releases. Upgrading the infrastructure and code is such a ball ache you'll always be behind. In fact every place I've seen so far ends up creating new duplicate Infrastructure for later versions and slowly migrating across. At my current place of employment we have THREE of these and haven't even got to Puppet 4 yet. And don't get me started on Certificate management headaches. Puppet consumes a stupid amount of man hours to keep running. Avoid !!