libral - a systems management api
TRANSCRIPT
The trouble with management
Large-scale management well understood
4
What if you're not interested in scale ?
5
What if all you need is a shell script ?
6
$ usermod -s /sbin/nologin tcpdump
$ usermod -s /sbin/nologin tcpdumpusermod: user 'tcpdump' does not exist
$ usermod -s /sbin/nologin tcpdumpusermod: user 'tcpdump' does not exist
$ grep -q tcpdump /etc/passwd && \ usermod -s /sbin/nologin tcpdump || \ useradd -u 72 -g 72 -s /sbin/nologin \ -M -r -d / tcpdump
What if all you want is some insight ?
10
$ grep tcpdump /etc/passwd | \ cut -d ':' -f 7/sbin/nologin
Insight much overlooked as a usecase
❏ regular audits
❏ verify that what you built is what you meant
❏ inspect running containers
❏ ask adhoc questions of your infrastructure
12
Is "learn this big config management system"
the best we can do ?
13
14
Workflow
Global controller
Local controller
Resource abstraction
15
Workflow
Global controller
Local controller
libral
16
Workflow
Global controller
Local controller
libral
???
Analysis
Global storage
Local collector
What makes a
good management API ?
Desired state
(idempotency)
18
Bidirectional
(change & insight)
19
Light-weight abstractions
20
Simple to extend
21
But what about … ?
What about CIM ?
23
What about OpenLMI ?
24
What about $cm_system ?
25
Liberating the RAL(Resource Abstraction Layer)
27
https://github.com/puppetlabs/libral
Inspired by Puppet, not tied to it
28
$ ralsh user tcpdumpuser { 'tcpdump': ensure => 'present', comment => '', gid => '72', home => '/', shell => '/sbin/nologin', uid => '72',}
$ ralsh user tcpdump \ ensure=present \ gid=72 \ home=/ \ shell=/sbin/nologin \ uid=72
Writing providers
1. Pick scripting language and calling convention
2. Write standalone script
a. Start with list/find
b. Get update working
3. Try out/integrate with ralsh
32
33
# 'Simple' calling convention
$ systemd.prov ral_action=describe ↳ some yaml
$ systemd.prov ral_action=find name=<name> ↳ one resource
$ systemd.prov ral_action=list ↳ all resources
# 'Simple' calling convention
$ systemd.prov ral_action=update \ attr1=value1 \ attr2=value2 ↳ changes performed
---
provider: type: service invoke: simple actions: [list,find,update] suitable: ${suitable} attributes:
name: type: string
ensure: type: enum[running, stopped]
enable: type: enum[true, false, mask]
---
provider: type: service invoke: simple actions: [list,find,update] suitable: ${suitable} attributes:
name: type: string
ensure: type: enum[running, stopped]
enable: type: enum[true, false, mask]
# systemd provider: 'list' all known serviceslist() {
echo '# simple'join -j 1 -o 1.1,1.2,2.3 \
<(systemctl list-unit-files ...) \ <(systemctl list-units --type service ...) \ | while read svc enable ensure
do echo "name: $svc" echo "ensure: $ensure" echo "enable: $enable"
done}
# systemd provider: 'list' all known serviceslist() {
echo '# simple'join -j 1 -o 1.1,1.2,2.3 \
<(systemctl list-unit-files ...) \ <(systemctl list-units --type service ...) \ | while read svc enable ensure
do echo "name: $svc" echo "ensure: $ensure" echo "enable: $enable"
done}
# systemd provider: 'list' all known serviceslist() {
echo '# simple'join -j 1 -o 1.1,1.2,2.3 \
<(systemctl list-unit-files ...) \ <(systemctl list-units --type service ...) \ | while read svc enable ensure
do echo "name: $svc" echo "ensure: $ensure" echo "enable: $enable"
done}
.
Demo
What now ?
Firm up interfaces/calling conventions
43
More providers
44
Dealing with provider configuration(remote API's)
45
Distribution
46
Desired-state bidirectional APIjoin the fun
48
https://github.com/puppetlabs/libral