Source – http://hub.scalr.com/blog/top-questions-on-server-configuration-management-tools-chef-puppet-and-ansible-2

As a quick recap, configuration management tools enable companies to standardize and automate their infrastructure. Through standardization, you can build systems that are platform independent (i.e. instead of relying on AMIs or provider specific toolsets). These tools also make it easy reproduce servers for scaling or testing, and recover from disaster quickly by defining a proper application state. For example, if servers are not in that defined state when each server is checked, they are restored to their proper state. In addition, this standardization makes it easy to onboard new developers.

While the language across configuration management tools is different, the concepts are the same. At the fundamental level in each configuration tool, a resource represents a part of the system and its desired state, such as a package that should be installed, a service that should be running, or a file that should be generated.

In Chef, a recipe is a collection of resources that describes a particular configuration or policy. These collections are called playbooks in Ansible, and manifests in Puppet. These collections describe everything that is required to configure part of a system. Collections install and configure software components, manage files, deploy applications, and execute other recipes. We go into more detail in our blog post here.

Here are the top questions we got from the community:

How is the concept of master/agent configuration better (or not) than agentless, when it comes to infrastructure as code?

Chef and Puppet are master/agent configuration systems, while Ansible is an agentless system. The historic argument is that the agent-based installation process is difficult –  you have to set up the master, and then set up the agents on your nodes so that they know about the master. If you’ve got servers with diverse linux distros, on different versions of Windows, etc., installation can get tricky. Though, because they’re logging every few minutes, agent-based systems are powerful for advanced monitoring. At the end of the day this really is based on personal preference and what company requires. If your infrastructure is beefy and heavily standardized, installation on nodes isn’t complicated so use agent-based systems. If you have servers that run Python, try agentless.

Are these configuration management systems like MicroSoft System Center Configuration Manager (SCCM) but used for local and cloud?

This is like MS SCCM, but open-source and paid for per node. For those who haven’t used it, MicroSoft System Center Configuration Manager (SCCM) is used for infrastructure provisioning, monitoring, and automating workflow processes (usually sysadmin stuff). SCCM is a powerhouse in the enterprise space. While it can manage end clients on non-Windows servers, the server console portion of SCCM must be hosted and run on a Windows server machine. The reason other orchestration/configuration systems win here is that you pay on a per-node basis and you’re not totally tied into Windows Server’s licensing agreements. In other words, open-source vs proprietary. And with Chef/Puppet/Ansible the thinking is more in resources as opposed to SCCM, which is more in files and terminal commands.

An attendee commented on using SCCM:

 “We really like Ansible because of the none-agent requirement. For Windows patching we utilize System Center Configuration Manager, and even though System Center can provide patching to Linux we have run into issues with SCCM agent staying healthy and running on our Linux systems. We have also run into when the SCCM admins have made changes it broke SCCM agent on a majority of our Linux servers. Our Linux patching process has been highly manual up to this point but we are seeking to automate this to free up staff time to be better directed at other support tasks, which is why were are reviewing several solutions. The non-agent aspect is highly desirable in our situation because of past experience with SCCM agent. I just wanted to provide that feedback so others that have not experienced agent issues with other deployment solutions may want to keep that in mind.”

If we have to pick a tool dependent on whether we deploy on cloud or on-premise – which of these tools would be a better choice?

We would recommend looking into network access requirements for each tool. If you have an agent that checks in periodically with a central master management piece, that is likely to work better then SSH which requires direct path / path through lots of proxies. 

One attendee mentioned in the comments: “[In regards to] SSH vs Agent – Agent is more secure where SSH not an option.”

What happened to cfengine? This tool used to be mentioned alongside Chef and Puppet. 
Version 3 of cfengine is a complete revamp, but it compared to other configuration management tools the brand and community outreach isn’t strong, and does little the others don’t do better.

How does StackStorm compare to the other orchestrators being reviewed?
StackStorm labels itself more of an automation platform, or a DevOps workflow tool that handles provisioning and configuring servers but also leans on automatic and event driven services that plugs into Jenkins and other CI/CD workflows.

From one attendee that had used all three: “For us, getting the Server engineers to adopt Chef has been very difficult. It grew organically on the Dev side of the house. Ansible appears to be something that guys without Dev skills could pick up more easily. Just [my] perception.”

Can I run tasks in parallel with Ansible rather than running it serially (say 50 servers being updated with a patch)?

The default method is to run each task across all servers in parallel, meaning that it will run the first task (e.g. installing Git) on all servers in a group, and once all servers respond with a success, failure, or unchanged response, Ansible will move to the next task on all servers. It doesn’t run on a server, wait, move on to the next, it will run on all servers at once over SSH. If you want to deploy updates in batches, you can run a percentage of servers in a group (e.g. 50%, by listing it in the playbook as serial: 50%).

An attendee made this comment as we mentioned Ansible:

“I have attended a presentation from RedHat regarding Ansible that states [that Ansible scales well]. They have large scale hosting companies that on the fly spin up servers and perform patching for their servers via Ansible. The one mentioned had over 50,000 servers and it seemed to handle the volume / scale fine. I of course don’t know everything about Puppet or Chef or Salt, but one thing I find really nice about Ansible is the ability to perform rolling updates / tasks. So if you say had 1000 servers you can say you want to run 10% or 100 at a time and keep it rolling until all 1000 are done. It can be stated by percentage or defined number…I am sure I sound a bit biased but one of the main reasons Ansible is high on our list right now is the fact that it is agentless and does not really consume resources.”

With Ansible, how can we handle the security implications about allowing passwordless ssh to a root account on all systems? What mechanisms are there for access control and auditing?

There are definitely security implications if you are going to allow passwordless ssh. So it’s on the company to ensure that security groups or NSGs are well defined. We should also mention that the passwordless ssh is only enabled on the machine you are running Ansible commands and playbooks from, so if anything consider that workstation to be your weak point. Make sure SSH access is only permissible through your IP. As an alternative solution to connecting via SSH, if you use docker, Ansible allows you to deploy playbooks directly into Docker containers using the local Docker client. All you need is a user inside that container.

Does ansible run single-threaded or is it addressing multiple servers in a group asynchronously?
Ansible runs on each host in parallel. This means that it attempts to run your tasks on all servers defined at the top of the playbook before moving on to the next task.

One user said in regards to all three tools: “Ansible seems better for “orchestration” and Puppet/Chef are really good for “Configuration Management”.  Ansible can be used to stop applications and databases and then run Puppet and then start applications and databases.”

Lastly, we got a surprise question from the audience on Jenkins, a CI/CD pipeline tool that can be used in conjunction with tools like Chef to completely automate the infrastructure behind your applications.

What is the alternative of Jenkins?
While we recommend Jenkins, If you’re a Ruby shop, Capistrano is geared towards your deployments. If you live in the AWS world, you can try using the CodeCommit/CodeDeploy/CodePipeline toolset. If you’re looking for a provider agnostic solution, CircleCI is great. If your workflows revolve around Atlassian, try Bamboo. 

If you are unsure of what CI/CD pipeline tool to use, or how they work, we will be hosting a webinar on Jenkins as part of our on-going series on infrastructure-as-code.