CFEngine vs. Puppet vs. Chef vs. Ansible vs. Salt

Last month Infoworld published an article titled “Review: Puppet vs. Chef vs. Ansible vs. Salt” written by Paul Venezia, that prompted many people in the configuration management community to get in touch with us to ask why CFEngine was not included. Our answer was simple: “No, we have no clear reason as to why this has occurred and it is bizarre not to have included CFEngine in the article.”

The article seeks to present the reader with a choice of configuration management technologies according to the following needs:

“In some cases, we may be talking about large installations that exist only to support very large applications or large installations that support myriad smaller services. In either case, the ability to wave a wand and cause them all to bend to the will of the admin cannot be discounted. It’s the only way to manage these large and growing infrastructures.”

Certainly, the scope indicated suggests CFEngine should be on the shortlist!

While the article is titled and written in the style of a review we would seek to remind readers that any review of such technology that dedicates 5 to 7 paragraphs per technology is hardly exhaustive. Indeed, we need a decent testbed to deploy all these tools to in order to back up assertions and claims with hard data for this to be considered a factual review. Instead, at best, it can be considered a primer to the options available.

We thought we’d try and help out here and share some content that could easily be inserted into the existing article at Infoworld should the editors feel inclined to provide a more complete picture to their readership…

CFEngine in a nutshell

CFEngine also started out as an open source project, in 1993. Both the technology and the author, Mark Burgess, receive recognition for this on-going contribution and have been called the Grand/Godfather of Configuration Management. The latest version of CFEngine continues to build on scientific research conducted by Mark Burgess. The concept of promise theory, first proposed by Mark in 2004, and the facility to exploit this has been available since version 3 of CFEngine, released in 2009.

Isn’t CFEngine just a by-product of scientifc research? Yes and no. Yes, CFEngine continues to receive plenty of interest from academia. However, in 2008, CFEngine AS was founded to support the ever-growing commercial interest as enterprise had not missed the opportunity to benefit from such learning. Today, JP Morgan, LinkedIn, IBM and many other organisations publicly acknowledge the value they get from using CFEngine for configuration management. CFEngine is by far the most widely used technology in production and is a core sysadmin skillset, even for today’s cloud architects!

You can find CFEngine deployed on many different platforms: AIX support came in 2005, we now use agents across Android-based deployments and of course Microsoft’s platform is supported as well, albeit only the enterprise version of CFEngine and that requires purchase of a license. Either way, if you are running a mixed environment then CFEngine is a very interesting proposition for you.

Not one single tool uses the same approach, all tools require the understanding and use of their specific vocabulary and syntax. CFEngine is no exception and with that there is the inevitable learning curve. Where some of the other tools (Puppet and Chef) have opted to leverage the Ruby ecosystem and require the dependencies and resources that go along with such a decision, CFEngine’s unequaled strength in this regard is its lightweight approach. Written in C, with a very small footprint and far fewer dependencies, CFEngine continues to execute significantly faster and with greater reliability than any other tool thus far.

CFEngine in a Web UI

ssh-config-in-Rudder-GUICFEngine AS offers an enterprise version with a Web UI, for a fee. There is also Rudder, from Normation that is free (100% open source, free software, with enterprise-grade support available). In terms of what one can get done using a Web UI and as we provide an enterprise Web UI in the form of Rudder we’ll talk about what you can do with CFEngine using Rudder.

With Rudder you have a complete web interface with which to administer and interact with your configuration management technology (CFEngine).

You can configure and manage nodes and their configuration. You are able to automate common system administration tasks (installation, configuration), enforce configuration over time (configuring once is good, ensuring that configuration is valid and automatically fixing it is better), establish and maintain an inventory of all managed nodes, and report on the compliance of configurations (desired vs actual state) by node or group(s).

ReportsRudder’s workflow combines templates known as ‘Techniques’, from which new instances are created as ‘Directives’. Together, with Nodes that are grouped together according to user-specified patterns, Configuration Rules are generated that are responsible for applying the Directives to the associated Group(s). All of this is done via the web interface. Separation of user roles is also possible allowing for the implementation of change control throughout each and every stage of interaction with Rudder.

 

“Is my infrastructure compliant?” Rudder reports on the state of all configuration items under management providing a clear signal as to whether you have converged on your desired configuration state. Rudder will show you when configurations have failed to apply and display pertinent information to help with further investigations to resolve these configuration incidents.

In terms of what comes out-of-the-box, Rudder is loaded with predefined ‘techniques’ that cover most common configuration management needs and are easily customized and extended via the GUI for specific and complex use cases. In the latest version, Rudder also offers the ability to manage isolated groups of nodes via Rudder relay servers.

So, we hope Infoworld will appreciate the support and update their article in light of these arguments. Feel free to tweet to Paul and Infoworld to request they correct the omission and include CFEngine – you know it makes sense!

Speed up your CFEngine by using a RAM disk!

When using CFEngine on a daily basis with a heavy set of promises, it is possible that one day you will encounter the following problem, especially on older releases of CFEngine: the underlying databases can get slow over time and eat some I/O. On a “standard” machine it will not cause any harm, but on a heavily loaded one like a log centralization machine, a VM hypervisor or a database host, CFEngine will suffer.

One solution we tested was using a tmpfs (ramdisk) for the CFEngine state directory.

Lire la suite

Avoid CFEngine hanging on start with the ignore_interfaces.rx file

Using CFEngine on a regular basis (and training people to use it), I often have to deploy CFEngine agents on virtual machines. Trouble is that often virtual machines (especially the ones cloned a bit hastily) have broken network configurations (incorrect hosts file, stray network interfaces …).

While CFEngine is quite tolerant about network failures, it is not about interface resolution, as during the agent initialization, a name lookup is done on every interface detected on the machine.

The problem: if this lookup is not possible, the agent will hang until the time out (5-30 seconds usually), and it can get rather frustrating when multiple interfaces are present.

A simple solution is to use the ignore_interfaces.rx file in CFEngine!

What is this special file you’re telling me about?

Well, actually by default it does not even exist!

The purpose of this file is to define whether CFEngine is to ignore or not some networks interface you know that will cause trouble in some conditions.

First, let’s see a verbose CFEngine run, without this file (cf-agent -KIv):

2013-08-13T17:34:26+0200  verbose: GNU autoconf class from compile time: compiled_on_linux_gnu
2013-08-13T17:34:26+0200  verbose: Address given by nameserver: 127.0.1.1
2013-08-13T17:34:26+0200  verbose: No interface exception file /var/cfengine/inputs/ignore_interfaces.rx
2013-08-13T17:34:26+0200  verbose: Interface 1: lo
2013-08-13T17:34:26+0200  verbose: Interface 2: eth0
2013-08-13T17:34:26+0200  verbose: IP address of host set to 192.168.1.254
2013-08-13T17:34:26+0200  verbose: Trying to locate my IPv6 address
2013-08-13T17:34:26+0200  verbose: Found IPv6 address fe80::dead:beef:9999:1337

Everything goes fine, the execution is fast and I got the expected results.

Now, I’m adding some dummy interfaces to the machine:

ip link add dummy0 type dummy
ip link add dummy1 type dummy
ip link add dummy2 type dummy
ifconfig dummy0 192.168.10.1/24
ifconfig dummy1 192.168.11.1/24
ifconfig dummy2 192.168.12.1/24

When I try to run CFEngine again, I notice important delays in the execution (approximately 7 extra seconds per interface) before CFEngine starts executing anything. When launched in verbose mode, this is what happens:

2013-08-13T17:37:53+0200  verbose: GNU autoconf class from compile time: compiled_on_linux_gnu
2013-08-13T17:37:53+0200  verbose: Address given by nameserver: 127.0.1.1
2013-08-13T17:37:53+0200  verbose: No interface exception file /var/cfengine/inputs/ignore_interfaces.rx
2013-08-13T17:37:53+0200  verbose: Interface 1: lo
2013-08-13T17:37:53+0200  verbose: Interface 2: eth0
2013-08-13T17:37:53+0200  verbose: IP address of host set to 192.168.90.50
2013-08-13T17:37:53+0200  verbose: Interface 3: dummy0
2013-08-13T17:37:58+0200  verbose: Interface 4: dummy1
2013-08-13T17:38:03+0200  verbose: Interface 5: dummy2
2013-08-13T17:38:03+0200  verbose: Trying to locate my IPv6 address
2013-08-13T17:38:03+0200  verbose: Found IPv6 address fe80::dead:beef:9999:1337
2013-08-13T17:38:03+0200  verbose: Found IPv6 address fe80::dead:beef:9999:1338
2013-08-13T17:38:03+0200  verbose: Found IPv6 address fe80::dead:beef:9999:1339
2013-08-13T17:38:03+0200  verbose: Found IPv6 address fe80::dead:beef:9999:1340

Notice the delay during interface detection: now, it takes 5 seconds to timeout on every dummy interface!

Bloody hell, this sucks. What can I do to prevent this?

The reason for this is simple: CFEngine is trying to resolve these interfaces IP addresses, and as they are using private addressing and are not registered within /etc/hosts, it timeouts on each of them. Not really nice, eh?

The solution? It is easy! You just need to match the problematic interfaces in the “/var/cfengine/inputs/ignore_interfaces.rx” file and CFEngine will no more try to interact with them:

File format definition for ignore_interfaces.rx

This file is a simple plain text file, that contains entries defining the interfaces to ignore using regular expressions. It is intended to contain one regular expression per line.

For example, you can match every interface of the system (.*), a specific interface prefix (evilprefix.* which would match evilprefix1, evilprefix2, …) or a very specific interface (eth2, virbr0, bond0…).

Real life use case

echo "dummy.*" > /var/cfengine/inputs/ignore_interfaces.rx

Result?

2013-08-13T17:48:25+0200  verbose: GNU autoconf class from compile time: compiled_on_linux_gnu
2013-08-13T17:48:25+0200  verbose: Address given by nameserver: 127.0.1.1
2013-08-13T17:48:25+0200  verbose: Interface 1: lo
2013-08-13T17:48:25+0200  verbose: Interface 2: eth0
2013-08-13T17:48:25+0200  verbose: IP address of host set to 192.168.90.50
2013-08-13T17:48:25+0200  verbose: Ignoring interface 'dummy0' because it matches 'ignore_interfaces.rx'
2013-08-13T17:48:25+0200  verbose: Ignoring interface 'dummy1' because it matches 'ignore_interfaces.rx'
2013-08-13T17:48:25+0200  verbose: Ignoring interface 'dummy2' because it matches 'ignore_interfaces.rx'
2013-08-13T17:48:25+0200  verbose: Trying to locate my IPv6 address
2013-08-13T17:48:25+0200  verbose: Found IPv6 address fe80::dead:beef:9999:1337
2013-08-13T17:48:25+0200  verbose: Found IPv6 address fe80::dead:beef:9999:1338
2013-08-13T17:48:25+0200  verbose: Found IPv6 address fe80::dead:beef:9999:1339
2013-08-13T17:48:25+0200  verbose: Found IPv6 address fe80::dead:beef:9999:1340

Notice that there is no longer any delay during the agent execution (less than 1 second) whereas the dummy interfaces are still present.

Conclusion: When you have a specific network configuration on your IT, remember that CFEngine provides features to help you ignore problematic interfaces. The main symptom is, during a verbose execution, a 5-second hang on some interfaces.

rmlllogo

(Français) Normation aux RMLL 2013 !

Sorry, this entry is only available in Français.

(Français) Normation aux RMLL 2012

Sorry, this entry is only available in Français.

Normation

87 rue Turbigo
75003 Paris

Tel : 01 83 62 26 96
Fax : 01 83 62 29 38
Contact us

Sign up for our newsletter

English
Français

Follow us