How does CFEngine work?
CFEngine is a fully distributed system that allows you to define desired states of everything from very large-scale infrastructures to small devices. The lightweight c-based cf-agent runs locally on each resource and persistently tries to converge towards the defined desired state. The actual states of managed resources are available in logs and an enterprise database for compliance and easy reporting. Using CFEngine, can be described in the following 3 simple steps.
1. Define Desired State
As an end-user you can use the CFEngine Domain Specific Language (DSL) to define desired states. CFEngine allows you to define a variety of states ranging from process management to software deployment and file integrity. You can check out CFEngine Promise Types to get an idea of the most common states you can define.
Normally, all desired states are stored in .cf
text-files in the
/var/cfengine/masterfiles
directory on one or more central distribution points,
referred to as CFEngine Policy Hubs.
2. Ensure Actual State
CFEngine typically runs locally on each managed resource. A resource can be anything from a server, network switch, raspberry pi, or any other computational device. CF-agent, the execution engine, is autonomous which means all the evaluations occur on the local node.
Before each run, which by default is every 5 minutes, the agent tries to connect
to one of the Policy Hubs to check if there has been any policy updates. Upon
policy updates, cf-agent will download the latest policy to its own
/var/cfengine/inputs
directory, run a syntax check and upon success start to
execute.
3. Verify Actual State
Whenever the agent runs, it creates a log of local inventory, system states and
execution results. The logs are stored in /var/cfengine/outputs
. For enterprise
customers, all data is also stored in a local database. CFEngine also stores a
large number of asset information like software installed, CPU, memory, disk,
network activity, etc. As for execution results, CFEngine can have 3 states:
Promise Kept: Actual state was equal to Desired State
Promise Repaired: Actual state was not equal to Desired State, but the agent was able to repair the state into compliance
Promise not Kept: Actual state was not equal to Desired state and the agent was not able to restore into compliance
Graphical illustration of CFEngine process

End-user and CFEngine agents workflow
Thanks to the autonomous nature of CFEngine, systems will be continuously maintained even if the Server is down. CFEngine agents on the hosts will opportunistically try to connect to the server. If it fails, last successful policy will apply, and since all evaluation is local, it doesn’t matter if the characteristics of the host changes and needs to be reconfigured. CFEngine will figure it out and ensure compliance. CFEngine has been reported to run on many different platforms in many different environments including traditional servers, workstations and laptops, network gear (routers/switches), bus and tram systems, point of sales systems, smart displays/signs, and even submarines.