cdist
| Original author(s) | Nico Schottelius, Steven Armstrong |
|---|---|
| Initial release | 2010 |
| Stable release | 3.1.13 / 16 May 2015 |
| Development status | Active |
| Written in | Python, Bourne shell |
| Operating system | GNU/Linux, Unix-like |
| Type | Configuration management |
| License | GPLv3. |
| Website |
www |
cdist is a free software configuration management system, which declares to adheres to the KISS principle. It manages nodes over SSH and requires only Bourne Shell to be installed on them and no agents (software required for some configuration management system to operate) are installed on nodes.
Types (pieces of code, describing intended state of node) are written in Bourne Shell. The system uses usual shell scripts and functions to express reusable descriptions of systems. The core of software, that manages ordering and executing code on nodes is written in Python, so controlling computer need to have installed Python version 3.2[1] or later.
For most GNU/Linux distributions, required version of Python is provided in default repositories. Cdist is included as part of Debian GNU/Linux distribution.
Development
cdist development started in 2010 at ETH Zurich and is actively being developed[2] by a lot of FOSS contributors and maintained by the two main developers Nico Schottelius and Steven Armstrong.[3] The major part of the discussion about cdist happens on the mailinglist[4] and on the IRC channel #cstar in the Freenode network. cdist is being used at various companies in Switzerland (for instance at ETH Zurich[5] and The OMA Browser project),[6] the US, Germany and France.
Features
cdist is a zero dependency configuration management system: It requires only ssh and a bourne-compatible shell on the target host, which is usually enabled on all Unix-like machines. Because of this, cdist can be used to bootstrap other configuration management systems.[7]
Installation and configuration
cdist is not installed traditionally as a package (like .deb or .rpm), but installed via git. All commands are run from the created checkout. The entry point for any configuration is the shell script conf/manifest/init, which is called initial manifest in cdist terms.
The main components of cdist are so called types, which bundle functionality.[8] The types essentially consists of a number of shell scripts to define which types a type reuses and which code is generated to be executed on the target host.
Architecture
cdist is split into two components:
- The core
- The configuration
Core
The core of cdist is implemented in Python 3 and provides the executables to configure target hosts. The core operates in a push model: It connects from the source host to the target hosts and configures the machines. For communication and file transfer SSH is being used. To allow parallel configuration of hosts, the core supports a parallel mode in which it creates a child process for every connection. This model allows cdist to scale horizontally with the available computing resources: If at a certain limit is reached and the capacity of the available CPUs has been used, adding another CPU or distributing cdist to multiple hosts allows to configure more hosts in parallel.
Configuration
The configuration is written in Bourne Shell and consists of
- The initial manifest (which defines which host is assigned which types)
- Global Explorers (to gain information about the target system)
- Types (which provide all functionality and consist of a manifest, type explorers and gencode scripts)
Although all of these are written in Shell script, the order of execution in the manifests does not matter: cdist employs an idempotent configuration.
Comparison
In comparison to most other configuration management software, cdist does not have any requirements on the target host besides SSH and a bourne shell. It requires Python 3.2 on the source host, though.[1] cdist operates in push based approach, in which a server pushes configurations to the client and the clients do not poll for updates.
Configuration language
All user configurable parts are contained in manifests or gencode-scripts, which are shell scripts. Shell scripts were chosen, because Unix System Administrators are usually proficient in reading and writing shell scripts. Furthermore, shell is also commonly available on potential target systems, thus avoiding the need to install additional software there ("zero dependencies").
cdist reads its configuration from the initial manifest (conf/manifest/init), in which hosts are mapped to types:
case "$__target_host" in
myhostname)
__package zsh --state present
__addifnosuchline /tmp/cdist-welcome --line "Welcome to cdist"
;;
esac
When using the types in cdist, they are called like normal programs in manifests and can make use of advanced parameter parsing as well as reading from stdin:
# Provide a default file, but let the user change it
__file /home/frodo/.bashrc --source "/etc/skel/.bashrc" \
--state exists \
--owner frodo --mode 0600
# Take file content from stdin
__file /tmp/whatever --owner root --group root --mode 644 --source - << DONE
Here goes the content for /tmp/whatever
DONE
Dependencies are expressed by setting up the require environment variable:
__directory /tmp/foobar
require="__directory//tmp/foobar" __file /tmp/foobar/baz
Access to paths and files within types is given by environment variables like $__object.
See also
References
- 1 2 "cdist: Why we require Python 3.2 on the source host". Nico.schottelius.org. Retrieved 2016-04-10.
- ↑
- ↑ "ungleich/cdist: cdist configuration management". GitHub.com. Retrieved 2016-04-10.
- ↑ "Archived copy". Archived from the original on November 21, 2011. Retrieved June 6, 2012.
- ↑
- ↑ "Archived copy". Archived from the original on August 17, 2012. Retrieved June 26, 2012.
- ↑ "Google Groups". Groups.google.com. Retrieved 2016-04-10.
- ↑ "cdist-type(7)". Nico.schottelius.org. Retrieved 2016-04-10.