configuration management

Red Hat acquires Ansible

Linux Weekly News reports that Red Hat acquires Ansible. There are quite a few configuration management tools around, and it was only the matter of time until Red Hat, with all its corporate client base, would buy one. Or pledge allegiance. My personal preference would be in Puppet, but Puppet comes from the Ruby world, where’s Red Hat is more of a Python shop.

Ansible’s simple and agentless approach, unlike competing solutions, does not require any special coding skills, removing some of the most significant barriers to automation across IT. From deployment and configuration to rolling upgrades, by adding Ansible to its hybrid management portfolio, Red Hat will help customers to:

Deploy and manage applications across private and public clouds.

Speed service delivery through DevOps initiatives.

Streamline OpenStack installations and upgrades.

Accelerate container adoption by simplifying orchestration and configuration.

The upstream Ansible project is one of the most popular open source automation projects on GitHub with an active and highly engaged community, encompassing nearly 1,200 contributors. Ansible automation is being used by a growing number of Fortune 100 companies, powering large and complex private cloud environments, and the company has received several notable accolades, including a 2015 InfoWorld Bossie Award, recognizing the best open source datacenter and cloud software.

Regardless, though, of my personal preferences, these are good news for configuration management and automation.

Puppet CookBook – a collection of task oriented solutions in Puppet

Fedora for short-lifespan server instances

Let’s come back to the odd fact that Fedora is both a precursor to RHEL, and yet almost never used in production as a server OS. I think this is going to change. In a world where instances are deployed constantly, instances are born and die but the herd lives on. Once everyone has their infrastructure encoded into a configuration management system, Fedora’s short release cycle becomes much less of a burden. If I have service foo deployed on a Fedora X instance, I willnever be upgrading that instance. Instead I’ll be provisioning a new Fedora X+1 instance to run the foo service, start it, and throw the old instance in the proverbial bitbucket once the new one works.

Via LWN.