Config Management, part II: Microcode Language
This cfg mgmt system uses a micro language to perform the changes on the target system. This language is limited in its scope and has the following “instructions”:
INSTRUCTION | ARITY | ARGUMENTS | REMARK |
---|---|---|---|
REM | 1 | TEXT | a comment |
MKDIR | 2 | MODE PATH | create a directory |
COPY | 2 | SRC-PATH DST-PATH | copy a file |
CHMOD | 2 | MODE PATH | set the mode |
CHOWN | 2 | USER/ID PATH | set the owner |
CHGRP | 2 | GROUP/ID PATH | set the group |
RM | 1 | PATH | rm the file |
EXEC | 1 | CMD | install a package |
These micro-instruction basically all call a simple system call to make the changes.
Note, except for the latter this is the Unix API of everything is a file. EXEC
is now only used
to install/deinstall a package; of course such a generic instruction is ripe for abuse…
Each of these instructions has an (implicit?) condition attached. For example COPY will only copy a file if the destination differs from the source in some way.
Instructions always have an action attached to them, so if the condition is false, the instruction executes and the resulting action is also performed. The actions I can think of are:
ACTION | ARITY | ARGUMENTS | REMARK |
---|---|---|---|
NOP | 0 | do nothing | |
SYSCTL | 2 | COMMAND UNIT | execute systemctl |
Using an example, some snippet of a higher level language generated
the following microcode, the condition is implicit, the action is after the &&
:
REM file blah generated this
EXEC apt-get install coredns && NOP
COPY Corefile /etc/coredns/Corefile && SYSCTL restart-or-reload coredns
CHOWN coredns /etc/coredns/Corefile && SYSCTL restart-or-reload coredns
CHGRP coredns /etc/coredns/Corefile && SYSCTL restart-or-reload coredns
COPY db.example /etc/coredns/db.example && SYSCTL restart-or-reload coredns
CHOWN coredns /etc/coredns/db.example && SYSCTL restart-or-reload coredns
CHGRP coredns /etc/coredns/db.example && SYSCTL restart-or-reload coredns
Now when we run through this we just do what it says (we can defer the SYSCTLs and only do them once).
In its core this system will parse a text file with micro-instruction and execute them. There is some intelligence needed to be efficient and do as little work as possible, but we can brush that aside as optimization (for now).
I also really like this file to be in plain text, you can even edit it! And note there is also an implicit version (git hash) to facilitate rollback (and roll forwards). See the first part for some incoherent thoughts on that.