cdist/doc/man/cdist-design.text

84 lines
2.5 KiB
Text
Raw Normal View History

cdist-design(7)
===============
Nico Schottelius <nico-cdist--@--schottelius.org>
NAME
----
cdist-design - Design ideas for cdist
DESCRIPTION
-----------
When using cdist with the push principle, the execution tree looks likes this:
--------------------------------------------------------------------------------
% server
cdist-deploy-to(1)
cdist-build(1)
cdist-preprocess(1) # fills up variables with content
cdist-explore(1) % client # explores client configuration
cdist-compile(1) # parses configuration, creates internal state in cconfig format, verifies
cdist-link(1) # uses cconfig output, creates executable
cdist-remote-exec(1) #
cdist-transfer(1) # transfer executable to client
cdist-execute(1) % client # execute resulting executable
--------------------------------------------------------------------------------
Operation on the server is run as "cdist" user.
Operation on the client is run as "root" user.
When using cdist with the pull principle (configuration triggered by client):
--------------------------------------------------------------------------------
% client
cdist-trigger(1) <server-hostname> # connects to server
cdist-deploy-to(1) <client-hostname> % server: see above
--------------------------------------------------------------------------------
MERGE INTO ABOVE.....
## How cdist works
### Exploring your system
cdist analyses the system to apply the configuration on and
selects the right backends. You can use ***cdist-explore*** to
the results of the explore functions.
### Applying the configuration
cdist looks for the configuration to apply on the local host
and applies it using ***cdist-apply***.
### Managing many hosts
Whereas ***cdist-apply*** manages one host, ***cdist-deploy***
applies the configuration on enabled hosts.
- version control via git
- file distribution via ssh
- authentication via ssh
- dumb clients, similar to manifest compile in puppet
- clients just execute commands
- dependencies via make?
- how to ensure sigletons / conflicting definitions?
file { "/a":
ensure => present,
file { "/a":
ensure => absent,
=>=>>>>>>>>>>>>>>>> via cconfig
SEE ALSO
--------
cdist(7), website: http://www.nico.schottelius.org/cdist/[]
COPYING
-------
Copyright \(C) 2010 Nico Schottelius. Free use of this software is
granted under the terms of the GNU General Public License version 3 (GPLv3).