Principled

Getting Started

The initial setup of CFEngine 3 took place with the bootstrapping section at the end of the listings for installation on the various systems. Among other things, sample configurations were copied from the installed package, and important directory structures were created under /var/cfengine/. The predefined contents in detail are described in the online documentation [7].

On Policy Hub cf3-ubsrv, I stored several of my own CFEngine files with instructions in /var/cfengine/masterfiles/. The folder there already contained files that CFEngine created automatically. For the sake of order, CFEngine 3 wants you to store DIY-created policy files in /var/cfengine/masterfiles/services/. If you want a policy file to be executed automatically, as I did in this article, you need store it in /var/cfengine/masterfiles/services/autorun/.

All files stored on the central Policy Hub at /var/cfengine/masterfiles/ (Figure 3) download the agents at five-minute intervals by default and make them available locally at /var/cfengine/inputs/. Following the principle of infrastructure as a code, the developers recommend that the content of /var/cfengine/masterfiles/ be placed under version control through SVN or Git.

Figure 3: Distributing policy files from the CFEngine 3 infrastructure. © CFEngine

To illustrate how CFEngine 3 works, I introduced a simple policy that installs the lightweight Nginx web server on the target systems and enables the associated systemd service, starting it at the same time. To do this, I launched a text editor on Policy Hub to create the /var/cfengine/masterfiles/services/autorun/webserver.cf file and filled it with life (Listing 4). The "webserver.cf in Detail" box provides more information. The command

# cf-promises -f /var/cfengine/masterfiles/services/autorun/webserver.cf

bundle agent nginx_installed_running {
  meta:
    "tags" slist => { "autorun" };
  vars:
    "package_list" slist => { "nginx" };
  packages:
    "$(package_list)"
      package_policy => "add",
      package_method => generic;
  services:
    "$(package_list)"
      service_policy => "start";
}

checks the content of the file for errors.

To enable automatic execution of your own policy files on the Policy Hub, create the def.json file under /var/cfengine/masterfiles/ to configure the services_autorun option (or, more precisely, the CFEngine class):

{
  "classes":
  {
    "services_autorun": [ "any" ]
  }
}

The comments in the /var/cfengine/masterfiles/promises.cf file show its effect.

In the default configuration, the CFEngine agent on the target systems implements the promises every five minutes. The command

cf-agent --dry-run --inform

shows what it will trigger the next time it is executed automatically (Figure 4).

Figure 4: The dry run of the local CFEngine agent shows potential changes.

After the next automatic execution, the installed nginx package and the matching service, enabled and running, can be found on the target systems (Figure 5), but on the cf3-centcli lab system, systemd seems to have failed to start Nginx because of an Nginx configuration problem, which I did not investigate further. CFEngine 3 will always try to start Nginx on the CentOS system in the future.

Figure 5: After the first run of CFEngine on the Ubuntu client, Nginx is installed and started.

If you want to delve deeper, you can now add instructions to the webserver.cf file about what to do in case of unfulfillable promises. Also, Nginx can only be reached from other systems by opening the local firewall. Configuring this for two different distributions by promise is not so easy and another possible exercise for the future.

Documentation and Community

In this article, custom policy files were included and executed by the autorun method. However, sys admins have other ways to activate bundles and policies [10].

The use of CFEngine 3 gets more exciting with the use of preconfigured bundles from the creators and the community. You can find these several places on the web – the CFEngine Design Center [11] with its Sketches being one of the best known. Ready-made bundles are intended to facilitate the tasks for newcomers and act as templates for your own configuration snippets.

Somewhat confusingly the CFEngine documentation appears to be distributed several places. The official website http://cfengine.com has a Quickstart Guide with mini-documentation, whereas http://docs.cfengine.com has the official documentation. An archive [12] also houses a hodgepodge of old manuals, some of which are easier to read than the current documentation.

If you want to go further into CFEngine 3, you have to allocate plenty of time. The approach seems a bit unwieldy in places, and the comparatively small community makes it difficult to get good learning resources or even help online. However, you can find a few good books. The members who are involved in the community seem to have been around for a long time and know all the tricks. In researching for this article, I often stumbled across the same names I did in 2012 and 2013 when researching previous articles.

Strengths and Weaknesses

CFEngine shows its strengths wherever admins need to manage a large number of heterogeneous systems with the smallest possible footprint. According to statements from the community, environments with a million or more agents can be realized, which is also attributable to the ability to cascade the central Policy Hub (e.g., with one hub per data center).

Once it's up and running, CFEngine 3 proves to be a powerful and lean machine that takes very little performance away from the applications on the target systems. Unlike Puppet or SaltStack, for example, the CFEngine agent also assumes virtually no dependencies. The ability to manage Linux, Unix, and Windows (in the enterprise variant) with a common tool proves to be an advantage in many environments.

The weaknesses of CFEngine 3 reveal themselves if getting started needs to be a fast and simple process, which would presuppose a large number of up-to-date libraries with prefabricated configuration snippets. Moreover, CFEngine 3 lacks the popularity of Puppet and the like, which will slow down the influx of new users and, in turn, new cash flow to fund development.

However, if you choose to get involved with CFEngine 3 and give the tool some time, you can use it to build a solid and functional configuration management system. If you are eager to experiment, you can also take a look at a SlideShare presentation [13], in which the CFEngine makers demonstrate the orchestration of Docker containers with CFEngine 3.