How CFEngine works
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. Did you know that CFEngine is used to manage systems on submarines?