forked from ungleich-public/cdist
cdist configuration management
Latest manual: https://www.cdi.st/manual/latest/
Home page: https://www.cdi.st
1bfe3c4363
Signed-off-by: Nico Schottelius <nico@kr.ethz.ch> |
||
---|---|---|
bin | ||
conf | ||
doc | ||
test | ||
cdist.mdwn | ||
README |
cdist (=opposite to ccollect) aka puppet don right - reuse of unix, no need for perl^Wruby - shell -------------------------------------------------------------------------------- what is puppet? A configuration deployment assistant, a DSL that allows you define the objectives. A webserver with fileserver capabilities. A client based scheduled polling infrastructure. -------------------------------------------------------------------------------- What do I need from puppet? - handling of package managers - Modules: Nice to put stuff together - and reuse - [LIBRARY] All the helper types like - file - ssh_keys - package - service - user - [CONDITIONS] facter is cool - [PORTABILITY] clients for every unix - mostly ruby + facter in puppet - the DSL - with many bugs - templates - Client/Server approach is nice to have - Clients only get the part of the documentation, that's relevant to them -------------------------------------------------------------------------------- What do I miss from puppet? - speed - elegance - clean design - documentation - the "no surprise" factor - easy to use "data memory" (i.e. external ressources) - easy integration into installation process - copy identity to master - multi master setups - development configurations / tests - editing of configuration files - similar to cfengine - replace bug squasher with bug avoidance - qmail did not need one either - push infrastructure -------------------------------------------------------------------------------- Simple stuff done by Unix[notm] - DSL: Shell! - gives if, else and EVEN elsif for free! - and case - and and and - and there's no os (solaris doesn't count) without a usable /bin/sh - cdist defines what you can use - you _can_ use os specific stuff - but it's ugly and you shoot into your own foot - "manifests" (use the same name here?) will be run/sourced - inheritance possible via sourcing - cdist-lib always preloaded - library == functions? - 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, - matching on explored items, not only on host name? - match function in host? [optional] - file source: - relative to specification - or absolute -------------------------------------------------------------------------------- Architecture -------------------------------------------------------------------------------- Implementation "cdist-server" -> called by cron? -> no need to reimplement scheduling "cdist-explore" (facter replacement) -> running on the client