Writing tests is pivotal to building software. Perhaps it is reasonable to say that the habit of writing tests is what a programmer means by engineering. Other essential practices include everything you need to build a project, and certainly source control! Systems administration borrows many of the same concepts: write a configuration, run to verify, then commit to deploy. Just like software development, this workflow must have a tight feedback loop, where we make one change at a time while monitoring for success or failure.
Unfortunately we have been have been tricked into believing that systems orchestration is an advanced topic. This is for good reason: traditional configuration management systems are cumbersome to use in trivial cases, and complex tasks quickly become intractable. The following demonstrations show how rset(1) can be used to define and test systems configuration. Since it is a tool for staging and executing scripts, you are free to use your own programming skills to build an approach tailored to the target environment.
Demo: A New Configuration for a Home Network
This is the sequence of events:
|0:06||The routes file defines the directories containing configuration to stage and a list of pln(5) files to evaluate for this host|
The contents of a
|0:30||Create configuration files|
Execute on hosts matching an address. The default regular expression for
Subsequent commands will require elevated privileges since the ssh user is not
Specifying the label pattern to run, a subset of the scripts.
|1:49||Use the native tools already provided by the target OS to configure services|
Demo: Manage a PostgreSQL Installation
This is a moderately complex example of building a data-driven orchestration framework:
|0:07||Starting with two newly provisioned VMs. These are referenced by IP address, but hostnames would work as well|
Most of the code in this repository is written in
|0:37||Configure the first database (master)|
The schema for this database
is located in
|1:16||Upgrading from PG 11 to 12 accomplished by changing the version and running the configuration again|
|1:45||Configure the second database (standby)|
Most of these scripts import common functionality from
|2:28||Each label contains logic for testing and establishing a consistent state on the remote system|
|3:06||The final step isn't configuration, just a convenient way to check on the replication status|