Difference between revisions of "Dynamic CFEngine3"
(→The dynamics is in the data) |
(→How does it work?) |
||
Line 9: | Line 9: | ||
* A host belongs to a domain |
* A host belongs to a domain |
||
* A host has a role |
* A host has a role |
||
− | In the example the host, domain and role bundles contain data that drive the common logic in the common bundles. When the host is bootstrapped to the CFEngine Master Hub it starts configuring itself by pulling the host and domain bundles from the hub. The host bundles file contains the role information, which convergently is being pulled from the hub in a subsequent iteration. |
+ | In the example the host, domain and role bundles contain data that drive the common logic in the common bundles. When the host is bootstrapped to the CFEngine Master Hub it starts configuring itself by pulling the host and domain bundles from the hub. The host bundles file contains the role information, which convergently is being pulled from the hub in a subsequent iteration.<br/> |
+ | Each host requires a file ${uqhost}.cf in this example. The downside of this approach is that a big data center will have hundreds, if not thousands of host.cf files. In a situation like that it probably is better to have a host naming convention |
||
+ | |||
== Data driven approach == |
== Data driven approach == |
||
Because the data in the host, domain and role bundles drive the common logic in the common bundles Dynamic CFEngine makes little use of classes or contexts. The context is defined beforehand and no decisions have to be made, thus leading to a reduction of complexity in the logic in the common bundles. |
Because the data in the host, domain and role bundles drive the common logic in the common bundles Dynamic CFEngine makes little use of classes or contexts. The context is defined beforehand and no decisions have to be made, thus leading to a reduction of complexity in the logic in the common bundles. |
Revision as of 14:09, 2 July 2014
Although this website is predominatly written in Dutch, because it is aimed at Dutch people using Debian, this set of pages is in English. The reason behind this is Webhuis' desire to support the international CFEngine community.
The dynamics is in the data
A best practice in CFEngine is to make promises or bundles as generic as possible, so that they suite the needs of as many situations as possible. Hosts and Domains contain specific information or data that is applicable to the Host only and that to be used in the configuration of the Host.
Host taylor made provisioning of promises
Dynamic CFEngine is the Webhuis way of providing a taylor made set of promises to each and every node. Webhuis believe this is a security feature, because the host only has the bundles and the data it needs.
Webhuis offers Dynamic CFEngine under GPL-2 as its contribution to the community.
How does it work?
Dynamic CFEngine extends on convergence because it provides the promises to the system in a convergent way, not all the promises are available as of the bootstrap of the host. The Webhuis example setup is structured:
- A host belongs to a domain
- A host has a role
In the example the host, domain and role bundles contain data that drive the common logic in the common bundles. When the host is bootstrapped to the CFEngine Master Hub it starts configuring itself by pulling the host and domain bundles from the hub. The host bundles file contains the role information, which convergently is being pulled from the hub in a subsequent iteration.
Each host requires a file ${uqhost}.cf in this example. The downside of this approach is that a big data center will have hundreds, if not thousands of host.cf files. In a situation like that it probably is better to have a host naming convention
Data driven approach
Because the data in the host, domain and role bundles drive the common logic in the common bundles Dynamic CFEngine makes little use of classes or contexts. The context is defined beforehand and no decisions have to be made, thus leading to a reduction of complexity in the logic in the common bundles.
The structure
The bundlesequence in promises.cf is as follows:
- "role"
- "g"
- "update"
- "@(webhuis_common)"
- "${g.class_domain}"
- "${g.class_host}"
- "${role.role}"
Step by step
In the first iteration almost everything fails, the bundles g, update and the bundlesequence in @(webhuis_common) will execute but will not fulfill all the promises. In the example "${g.class_domain}" is replaced by webhuis_nl, "${g.class_host}" is replaced by bur and "${role.role}" is replaced by backup_recovery. @(webhuis_common) is an slist that contains the bundle names "common_bundles", "os_layer", "hardening".
bundle common role
The bundle common role is the first bundle to be executed when available to the host. It defines the common variable role that has the name of the role to the system and it sets a class with the name of the role. Here you find the bundle common role details.
bundle common g
The bundle common g is contained in promises.cf and it defines common variables to the system. In the Webhuis Dynamic CFEngine3 solution two special slist variables are generated, in order to have dynamic inputs. The dynamic inputs consists of two branches
- A standard inputs branch in /var/cfengine/inputs
- A dynamic inputs specific branch /var/cfengine/inputs-webhuis
Here you find the bundle common g details.
bundle agent update
The bundle agent update carries out very important tasks specific to Dynamic CFEngine3.
The agents use it to pull their specific configuration information from the CFEngine hub they are bootstrapped to. It pulls the standard masterfiles to inputs, but it also pulls domain, host and role specific information from the webhuis branch on the hub and places these bundles into a branch next to inputs /ver/cfengine/inputs-webhuis.
Here you find the bundle agent update details.
bundle agent webhuis common
The bundle webhuis_common carries out common tasks like installing base packages and housekeeeping. Still it uses the variables of the dynamic bundles.
Here you find the bundle agent webhuis common details.
bundle agent webhuis_nl
The bundle webhuis_nl is an example domain bundle, the webhuis branch that is next to masterfiles could contain any number of domains. The domain bundle for the most part defines data that are common to the domain. In this example it defines network addresses, and servers for ldap, dns and ntp.
Here you find the bundle agent webhuis_nl details.
bundle agent bur
The bundle bur defines a couple of variables that are specific to the host and adapt to the role that it has.
Here you find the agent bur details.
bundle agent backup_recovery
The bundle agent backup_recovery is an example of role hosts can have. It deals with the variables it gets passed and takes care of the installation of packages required to carry out the task that belongs to the role.
Here you find the bundle agent backup_recovery details.
Return to: Cfengine