For the past year or so, I’ve been working on an infrastructure as code project called progfiguration
.
First, the pitch:
It includes an inventory format and a small library of convenience functions for configuring remote systems. It’s very fast on my small infrastructure.
I use it to configure my own machines, many of them running psyopsOS. My site package is called progfiguration_blacksite.
It’s now ready for its first public alpha release – Meet progfiguration 0.0.2! Read the documentation on the homepage or dive into the source at mrled/progfiguration if you want to learn more. In particular, you may be interested in reading the design document, which describes goals and key decisions of the project, including imperative programming, no requirement of a central server for secure secrets (or anything else), editable software, and speed.
Building progfiguration
I’ve been using Ansible for a long time, and for years there’s been a slow nag: why can’t I just write code here? Writing YAML documents to configure systems works great for the constrained set of tasks that someone else has already written, but if you’re deploying thousands of systems with many configuration variations, it doesn’t feel as natural.
With that occasional thorn in my side, I had a reason last year to look for configuration systems other than Ansible for psyopsOS. I wanted psyopsOS machines to boot a stateless operating system from a disk image, and pull down the latest configuration from the Internet, or, failing that, apply a known-good configuration baked into the image. I could have used Ansible for this, except that ansible-vault, which is used for securely storing secrets, expects a single password to encrypt/decrypt everything. I would have needed to use a shared vault secret for all nodes, and I wouldn’t have been able to scope secrets just to nodes that need them.
I started writing a tiny Python package
that configured my infrastructure directly, in plain Python code,
and used the highly regarded age
for scoped encryption keys.
(I even did a quick experiment
to demonstrate to myself that age
would be fast enough in a larger production environment.)
Nodes kept a small amount of metadata,
including their hostname, a unique SSH host key, and an age
private key
on a small volume (typically a USB drive).
Once I got the basics working, I found that I loved it. Even though Ansible is much more fully featured, this advantage is blunted by the fact that Python is so expressive.
The release
Last month, I finally took the leap and split progfiguration into two:
- A generic core package, retaining the name
progfiguration
- Each site (or person/organization/company) has its own site package,
with any name they choose.
Mine is called
progfiguration_blacksite
.
I called this “lobotomization”, splitting the progfiguration brain into two. Commit 13fc08d7342984af09d8d2689c6ff244c3854edf was the last change before lobotomization if you want to see the most advanced version of its original design.
Making it work after splitting it has been a fun challenge, and I think the redesign hasn’t hurt its readability too much. Once I got it working again, I spent some time polishing a few sharp edges and writing a lot of documentation.
And now it’s ready to be released! It’s still alpha at this point, but I would like to make a 1.0 release of the core module eventually. My hope is that someone out there other than me actually uses it.
Even if that doesn’t happen,
I’m looking forward to writing a few more blog posts about what I learned.
(Actually, I have already started:
the magicrun()
function
was originally written for progfiguration.)
Thanks for reading :). Bugs, PRs, blog comments, emails, Matrix messages, or any other feedback is welcome.