SLIDE 1 Recursive inventory management
Martin F. Krafft madduck@debian.org 13 Aug 2013 @ DebConf 13, Vaumarcus, Switzerland
SLIDE 2
Configuration management
(system administration)
SLIDE 3 Configuration management
CFEngine bcfg2 Puppet Chef Salt Ansible
SLIDE 4 Configuration management
CFEngine bcfg2 Puppet Chef Salt Ansible
SLIDE 5
Two approaches
Cloud provisioning System administration (classical)
SLIDE 6
Configuring the cloud
Unprecedented ease! Scalability ”Orchestration“ Ad-hoc provisioning Homogeneous
SLIDE 7
Classical system administration
SLIDE 8
Classical system administration
Longevity
SLIDE 9
Classical system administration
Longevity Heterogeneous
SLIDE 10
Classical system administration
Longevity Heterogeneous Themed hostnames, not canonical names and numbers
SLIDE 11
Classical system administration
Longevity Heterogeneous Themed hostnames, not canonical names and numbers Laziness (vs. unprecedented ease)
SLIDE 12
Classical system administration
Longevity Heterogeneous Themed hostnames, not canonical names and numbers Laziness (vs. unprecedented ease) Orchestration
SLIDE 13
Configuration management with reclass
reclass comes from classical system administration
SLIDE 14
Configuration management with reclass
reclass comes from classical system administration It might well suit your cloud needs
SLIDE 15
Configuration management with reclass
reclass comes from classical system administration It might well suit your cloud needs (might require rethinking)
SLIDE 16
Targeting nodes vs. classifying hosts
SLIDE 17 Targeting nodes
Mailservers
SLIDE 18 Targeting nodes
Mailservers Rack somewhere
SLIDE 19 Targeting nodes
Mailservers Rack somewhere 192.0.2.64/28
SLIDE 20 Targeting nodes
Mailservers Rack somewhere 192.0.2.64/28 Debian has debian fact
SLIDE 21 Targeting nodes
Mailservers Rack somewhere 192.0.2.64/28 Debian has debian fact hosted @ Zurich *.zurich.corp
SLIDE 22 Targeting nodes
Mailservers Rack somewhere 192.0.2.64/28 Debian has debian fact hosted @ Zurich *.zurich.corp
Backwards!
SLIDE 23 Targeting nodes
Mailservers Rack somewhere 192.0.2.64/28 Debian has debian fact hosted @ Zurich *.zurich.corp
Backwards!
To what classes does a specific node belong?
SLIDE 24 Targeting nodes
Mailservers Rack somewhere 192.0.2.64/28 Debian has debian fact hosted @ Zurich *.zurich.corp
Backwards!
To what classes does a specific node belong? Behaviour is partially reactive, may depend on data on host
SLIDE 25 Classifying hosts
blue.example.org
SLIDE 26 Classifying hosts
blue.example.org mailserver ntpclient hosted@zurich
SLIDE 27 Classifying hosts
blue.example.org mailserver ntpclient hosted@zurich server = ’0.pool.ntp.org’
SLIDE 28 Classifying hosts
blue.example.org mailserver ntpclient hosted@zurich server = ’0.pool.ntp.org’ server = ’0.ch.pool.ntp.org’
SLIDE 29 Classifying hosts
white.example.org
SLIDE 30 Classifying hosts
white.example.org webserver ntpclient hosted@munich server = ’0.pool.ntp.org’
SLIDE 31 Classifying hosts
white.example.org webserver ntpclient hosted@munich server = ’0.pool.ntp.org’ server = ’0.de.pool.ntp.org’
SLIDE 32 Puppet
node ’blue.example.org’ { $ntpserver = ’red.example.org’ include common include ntp }
SLIDE 33 Puppet
node ’common’ { $ntpserver = ’0.pool.ntp.org’ include common include ntp } node ’blue.example.org ’ inherits ’common ’ { }
SLIDE 34 Puppet
node ’common’ { $ntpserver = ’0.pool.ntp.org’ include common include ntp } node ’blue.example.org ’ inherits ’common ’ { $ntpserver = ’red.example.org’ }
SLIDE 35 Puppet
node ’common’ { $ntpserver = ’0.pool.ntp.org’ include common include ntp } node ’blue.example.org ’ inherits ’common ’ { $ntpserver = ’red.example.org’ }
Anger!
SLIDE 36 Puppet
node ’common’ { $ntpserver = ’0.pool.ntp.org’ include common include ntp } node ’blue.example.org ’ inherits ’common ’ { $ntpserver = ’red.example.org’ }
Anger!
No multiple inheritance
SLIDE 37 Puppet
node ’common’ { $ntpserver = ’0.pool.ntp.org’ include common include ntp } node ’blue.example.org ’ inherits ’common ’ { $ntpserver = ’red.example.org’ }
Anger!
No multiple inheritance Inheritance generally discouraged (cf. docs)
SLIDE 38 Puppet
node ’common’ { $ntpserver = ’0.pool.ntp.org’ include common include ntp } node ’blue.example.org ’ inherits ’common ’ { $ntpserver = ’red.example.org’ }
Anger!
No multiple inheritance Inheritance generally discouraged (cf. docs) Parametrisation unnecessarily difficult
SLIDE 39
System administration automation principles (abridged)
SLIDE 40
System administration automation principles (abridged)
Central control, versioned
SLIDE 41
System administration automation principles (abridged)
Central control, versioned Parametrisation (no special casing in code)
SLIDE 42
System administration automation principles (abridged)
Central control, versioned Parametrisation (no special casing in code) No redundancy
SLIDE 43
System administration automation principles (abridged)
Central control, versioned Parametrisation (no special casing in code) No redundancy Use node information as parameters, don’t rely on them for behaviour selection
SLIDE 44
recursive external (node) classifier
SLIDE 45
Data use by the CMS What applications should a role have? (aka. modules, states, playbooks)
SLIDE 46
Data use by the CMS What applications should a role have? (aka. modules, states, playbooks) How does this node differ from all other nodes that have the same application? (aka. parameters, pillar, variables)
SLIDE 47
Data use by the CMS What applications should a role have? (aka. modules, states, playbooks) How does this node differ from all other nodes that have the same application? (aka. parameters, pillar, variables) Which nodes belong to a group? (aka. nodegroups, clusters)
SLIDE 48
Usage by the system administrator
SLIDE 49
Usage by the system administrator Deploy and manage site-wide configuration changes
SLIDE 50
Usage by the system administrator Deploy and manage site-wide configuration changes Upgrade all nodes tagged debian@stable
SLIDE 51
Usage by the system administrator Deploy and manage site-wide configuration changes Upgrade all nodes tagged debian@stable Update /etc/motd on all hosts hosted@zurich
SLIDE 52
Usage by the system administrator Deploy and manage site-wide configuration changes Upgrade all nodes tagged debian@stable Update /etc/motd on all hosts hosted@zurich Fetch logs of all hosts tagged mailserver
SLIDE 53
Usage by the system administrator Deploy and manage site-wide configuration changes Upgrade all nodes tagged debian@stable Update /etc/motd on all hosts hosted@zurich Fetch logs of all hosts tagged mailserver
reclass just assembles/provides the data
SLIDE 54
Configuration management vs. remote execution ?
SLIDE 55
Configuration management & remote execution !
SLIDE 56
Single data source
SLIDE 57
reclass adapters
Adapters interface between configuration management system and reclass
SLIDE 58
reclass adapters
Adapters interface between configuration management system and reclass: Mode of invocation (module, command-line switches, etc.)
SLIDE 59
reclass adapters
Adapters interface between configuration management system and reclass: Mode of invocation (module, command-line switches, etc.) Output (YAML, JSON, . . . )
SLIDE 60
reclass adapters
Adapters interface between configuration management system and reclass: Mode of invocation (module, command-line switches, etc.) Output (YAML, JSON, . . . ) Adapters provided: Puppet (not yet re-implemented)
SLIDE 61
reclass adapters
Adapters interface between configuration management system and reclass: Mode of invocation (module, command-line switches, etc.) Output (YAML, JSON, . . . ) Adapters provided: Puppet (not yet re-implemented) Salt (module)
SLIDE 62
reclass adapters
Adapters interface between configuration management system and reclass: Mode of invocation (module, command-line switches, etc.) Output (YAML, JSON, . . . ) Adapters provided: Puppet (not yet re-implemented) Salt (module) Ansible (exec required)
SLIDE 63
reclass and Puppet Original reclass written for Puppet
SLIDE 64
reclass and Puppet Original reclass written for Puppet . . . out of frustration
SLIDE 65
reclass and Puppet Original reclass written for Puppet . . . out of frustration Rage-quit Puppet two years ago
SLIDE 66
reclass and Puppet Original reclass written for Puppet . . . out of frustration Rage-quit Puppet two years ago Rewritten reclass from scratch since then
SLIDE 67
reclass and Puppet Original reclass written for Puppet . . . out of frustration Rage-quit Puppet two years ago Rewritten reclass from scratch since then Could not be bothered to reimplement
SLIDE 68
reclass and Puppet Original reclass written for Puppet . . . out of frustration Rage-quit Puppet two years ago Rewritten reclass from scratch since then Could not be bothered to reimplement Trivially done through adapter plugin
SLIDE 69
reclass and Salt Provides top and pillar data
SLIDE 70
reclass and Salt Provides top and pillar data Adapter is a Salt module, since 0.16.0
SLIDE 71
reclass and Salt Provides top and pillar data Adapter is a Salt module, since 0.16.0 nodegroups not yet implemented (Salt issue #5787)
SLIDE 72
reclass and Ansible Provides inventory and node information
SLIDE 73
reclass and Ansible Provides inventory and node information Implemented as external script
SLIDE 74
reclass and Ansible Provides inventory and node information Implemented as external script Does not yet support batched calls (recent Ansible feature)
SLIDE 75
Enough of this boring stuff!
SLIDE 76
Parametrisation is key Parametrise modules as much as possible
SLIDE 77
Parametrisation is key Parametrise modules as much as sensible
SLIDE 78
Parametrisation is key Parametrise modules as much as sensible At all cost, avoid special-casing in module code
SLIDE 79
Parametrisation is key Parametrise modules as much as sensible At all cost, avoid special-casing in module code Reclass allows you to keep your parameters modular
SLIDE 80
Parametrisation is key Parametrise modules as much as sensible At all cost, avoid special-casing in module code Reclass allows you to keep your parameters modular Define your data in one place only (no redundancy)
SLIDE 81 reclass node definition
blue.example.org.yaml:
- applications:
- postfix
- ntp
parameters: ntp: server: 0. pool.ntp.org
SLIDE 82 reclass node definition
blue.example.org.yaml:
- applications:
- postfix
- ntp
parameters: ntp: server: 0. pool.ntp.org
SLIDE 83
But wait! You promised recursion!
SLIDE 84
yaml fs YAML files for nodes in $inventory base uri/nodes
SLIDE 85
yaml fs YAML files for nodes in $inventory base uri/nodes YAML files defining classes in $inventory base uri/classes
SLIDE 86
yaml fs YAML files for nodes in $inventory base uri/nodes YAML files defining classes in $inventory base uri/classes Nodes and classes files may specify classes to inherit
SLIDE 87
yaml fs YAML files for nodes in $inventory base uri/nodes YAML files defining classes in $inventory base uri/classes Nodes and classes files may specify classes to inherit You can think of classes as tags, too!
SLIDE 88
yaml fs YAML files for nodes in $inventory base uri/nodes YAML files defining classes in $inventory base uri/classes Nodes and classes files may specify classes to inherit You can think of classes as tags, too! Smart (deep) merging on return from recursive descent walk
SLIDE 89 reclass node definition
nodes/blue.example.org.yaml: classes:
parameters: ntp: server: 0.ch.pool.ntp.org classes/common.yaml: applications:
parameters: ntp: server: 0. pool.ntp.org
SLIDE 90 reclass node definition
nodes/blue.example.org.yaml: classes:
parameters: ntp: server: 0.ch.pool.ntp.org classes/common.yaml: applications:
parameters: ntp: server: 0. pool.ntp.org
SLIDE 91 reclass node definition
nodes/blue.example.org.yaml: classes:
parameters: ntp: server: 0.ch.pool.ntp.org classes/common.yaml: applications:
parameters: ntp: server: 0. pool.ntp.org
SLIDE 92 More specific classes
less specific classes
SLIDE 93 reclass node definition
nodes/blue.example.org.yaml: classes:
- common
- mailserver
- hosted@zurich
classes/hosted@zurich.yaml: parameters: ntp: server: 0.ch.pool.ntp.org
SLIDE 94 reclass node definition
nodes/blue.example.org.yaml: classes:
- common
- mailserver
- hosted@zurich
classes/hosted@zurich.yaml: parameters: ntp: server: 0.ch.pool.ntp.org
SLIDE 95
Multiple inheritance well-defined order
SLIDE 96 reclass node definition
nodes/blue.example.org.yaml: classes:
classes/ssh-server.yaml parameters: permit root login: no
SLIDE 97 reclass node definition
nodes/blue.example.org.yaml: classes:
classes/ssh-server.yaml parameters: permit root login: no classes/backup-client.yaml parameters: permit root login: without-password
SLIDE 98 reclass node definition
nodes/blue.example.org.yaml: classes:
classes/ssh-server.yaml parameters: permit root login: no classes/backup-client.yaml parameters: permit root login: without-password classes:
SLIDE 99 Parameter interpolation
nodes/diamond.example.org.yaml: classes:
classes/motd.yaml parameters: motd: message: ${floyd reference}
SLIDE 100 Parameter interpolation
nodes/diamond.example.org.yaml: classes:
parameters:
- floyd reference: Shine on, you crazy diamond
classes/motd.yaml parameters: motd: message: ${floyd reference}
SLIDE 101
reclass future work Package it.
SLIDE 102
reclass future work Package it. Doh!
SLIDE 103
reclass future work Package it. Doh! preseed.cfg/d-i adapter?
SLIDE 104
reclass future work Package it. Doh! preseed.cfg/d-i adapter? Policy classification (regexp → class mappings)
SLIDE 105
reclass future work Package it. Doh! preseed.cfg/d-i adapter? Policy classification (regexp → class mappings) Membership lists
SLIDE 106
reclass future work Package it. Doh! preseed.cfg/d-i adapter? Policy classification (regexp → class mappings) Membership lists Other data sources?
SLIDE 107
reclass future work Package it. Doh! preseed.cfg/d-i adapter? Policy classification (regexp → class mappings) Membership lists Other data sources? Better unit testing (without philosophical debates)
SLIDE 108
reclass future work Package it. Doh! preseed.cfg/d-i adapter? Policy classification (regexp → class mappings) Membership lists Other data sources? Better unit testing (without philosophical debates) Your idea here!