LOGIN
Sign In or Register
Avatar
Not Registered Yet?

Join Now! It's FREE. Get full access and benefit from this site

Reset My password - Remind Me My username

Username
Password
Remember me

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.

Top 5 Configuration Management Tools

Puppet

In computing, Puppet is an open-source configuration management utility. It runs on many Unix-like systems as well as on Microsoft Windows, and includes its own declarative language to describe system configuration.

Puppet is produced by Puppet Labs, founded by Luke Kanies in 2005. It is written in Ruby and released as free software under the GNU General Public License (GPL) until version 2.7.0 and the Apache License 2.0 after that.

 

What started out as a popular DevOps tool has quickly become a movement. Written in Ruby, like Chef, Puppet also comes in both an open source and enterprise version. However, where Chef has a healthy offering of features across both open source and enterprise versions, Puppet has placed the majority of its feature set into enterprise status. Features that the open source version comes with include provisioning (Amazon EC2, Google Compute Engine), configuration management (operating systems and applications) plus 2,000+ pre-built configurations on Puppet Forge. Considerably more features are available for the enterprise version, including the open source features plus graphical user interface, event inspector (visualize infrastructure changes), supported modules, and provisioning (VMware VMs). Configuration management (discovery, user accounts), orchestration, task automation, role-based access control (with external authentication support) are also included. Puppet enterprise has a unified cross-platform installer of all components and support.

Chef

Offered as both an open source and enterprise product, Chef is a powerful tool for full IT infrastructure configuration management. With open source Chef at the heart of both offerings, shared features include a flexible and scalable automation platform, access to 800+ reusable cookbooks and integration with leading cloud providers. Chef also offers enterprise platform support, including Windows and Solaris, and allows you to create, bootstrap and manage OpenStack clouds. It has easy installation with 'one-click' Omnibus Installer, automatic system discovery with Ohai, text-based search capabilities and multiple environment support. Other notable features inclyde the "Knife" command line interface, "Dry Run" mode for testing potential changes, and the ability to manage 10,000+ nodes on a single Chef server. Features only available in the enterprise version of Chef include availablility as a hosted service, enhanced management console, centralized activity and resource reporting, as well as "Push" command and control client runs. Multi-tenancy, role-based access control (RBAC), high availability installation support and verification, along with centralized authentication using LDAP or Active Directory are included with Chef enterprise.

Ansible

Ansible is a model-driven configuration management tool that leverages SSH to improve security and simplify management. In addition to configuration management, it is capable of automating app deployment (even multi-tier deployment), workflow orchestration and cloud provisioning, hence the company likes the tool to be categorized as an "orchestration engine." Ansible is built on five design principles including ease of use (doesn't require writing scripts or custom code), low learning curve (both for sysadmins and developers), comprehensive automation (allowing you to automate almost anything in your environment), efficiency (since it runs on OpenSSH it doesn't rely on memory or CPU resources), and security (it is inherently more secure because it doesn't require an agent, additional ports or root level daemons). As many other open source projects, Ansible has a paid product that comes in the form of a web UI called Ansible Tower.

 

CFEngine

One of the earliest full-featured configuration management systems out there, CFEngine has gone through several iterations and maintained relevance as OS have gone from the local data center to the cloud. At the heart of the infrastructure automation framework, CFEngine is also a modeling and monitoring compliance engine, capable of sitting on a small footprint. As recommended by CFEngine, steps toward identifying an initial desired state include: 1) model the desired state of your environment; 2) simulate configuration changes before committing them; 3) confirm the desired state and set for automatic self-healing; 4) collect reports on the differences between actual and desired states. CFEngine has a library of reusable data-driven models that will help users model their desired states. These infrastructure patterns are designed to be reusable across the Enterprise.

 

Salt

As part of a larger, enterprise ready application, the configuration management piece of Salt is as robust and feature-full as would be expected. Built upon the remote execution core, execution of the system occurs on "minions" which receives commands from the central Salt master and replies with the results of said commands. Salt support simultaneous configuration of tens of thousands of hosts. Based upon host "states", no programming is required to write the configuration files, which are small and easy to understand, that help identify the state of each host. Additionally, for those who do program, or admins who want to have more control and familiarity with their configuration files, any language can be used to render the configurations.