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:
- Notice problem
- SSH in
- Change some configs, reload etc
- Done!
Whereas the Construct way is more like
- Notice problem
- Make issue
- Make local branch
- Test/deploy loop (we don't have a staging environment :P)
- Make pull request
- It eventually gets merged into main
- 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.