7
edits
Changes
add construct page
[https://github.com/vtluug/construct/ Construct] is VTLUUG's pseudo-mono repo of the future. It contains [https://nixos.org NixOS] configurations for [[Bastille]], [[Vesuvius]], [[Rowhammer]], and more! It also has some [https://kubernetes.io 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, <code>nixos-rebuild</code> will fully roll it back. In the [https://github.com/vtluug/construct/pull/31 near future], <code>nixos-version --configuration-revision</code> 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.
== 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, <code>nixos-rebuild</code> will fully roll it back. In the [https://github.com/vtluug/construct/pull/31 near future], <code>nixos-version --configuration-revision</code> 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.