Construct

Construct is VTLUUG's pseudo-mono repo of the future. It contains NixOS configurations for Bastille, Vesuvius, Rowhammer, and more! It also has some Kubernetes manifests, but they aren't automatically applied currently.

Why

Many person-hours have been spent on this repo, and we plan to spend many more, so it's reasonable to ask why Construct is the way it is. I think it's helpful to contrast with the "cowboy-style" system administration that you usually see at our scale:

1. Notice problem
2. SSH in
3. Change some configs, reload etc
4. Done!

Whereas the Construct way is more like

1. Notice problem
2. Make issue
3. Make local branch
4. Test/deploy loop (we don't have a staging environment :P)
5. Make pull request
6. It eventually gets merged into main
7. Done…

The latter is clearly worse in the short-term, but in the long-term it means that:

• The reason for a change is documented
• We have (some) code review before pull requests are merged
• Fixes in shared configuration are actually shared

Why Nix(OS)

With NixOS, our deploys are an atomic unit. If a deploy fails, nixos-rebuild will fully roll it back. In the near future, nixos-version --configuration-revision will tell us what git commit a machine is currently running. NixOS modules make it easy to share common configuration while still overriding stuff where needed, and Nix + Nixpkgs makes packaging our own software in a reproducible way much easier.