TELEICU/Path B: NixOS: Difference between revisions
More languages
More actions
Replace ASCII art with Mermaid diagrams (via update-page on MediaWiki MCP Server) |
Fix Mermaid diagrams: remove <pre> wrapping so parser functions execute (via update-page on MediaWiki MCP Server) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 12: | Line 12: | ||
Every hospital PC runs NixOS with identical, pinned system configuration. A flake repository defines the full OS state — packages, services, users, firewall, K3s agent — and nodes converge to the declared state via <code>comin</code> (pull-based, primary) or <code>deploy-rs</code> (push-based, backup). |
Every hospital PC runs NixOS with identical, pinned system configuration. A flake repository defines the full OS state — packages, services, users, firewall, K3s agent — and nodes converge to the declared state via <code>comin</code> (pull-based, primary) or <code>deploy-rs</code> (push-based, backup). |
||
<pre> |
|||
{{#mermaid:flowchart TB |
{{#mermaid:flowchart TB |
||
subgraph Repo["Flake Repository"] |
subgraph Repo["Flake Repository"] |
||
| Line 36: | Line 35: | ||
DEPLOY --> N2 |
DEPLOY --> N2 |
||
}} |
}} |
||
</pre> |
|||
== Provisioning (zero-touch) == |
== Provisioning (zero-touch) == |
||
| Line 97: | Line 95: | ||
== Repository structure == |
== Repository structure == |
||
<pre> |
|||
{{#mermaid:flowchart LR |
{{#mermaid:flowchart LR |
||
subgraph Flake["teleicu-nixos/"] |
subgraph Flake["teleicu-nixos/"] |
||
| Line 109: | Line 106: | ||
end |
end |
||
}} |
}} |
||
</pre> |
|||
== Flake structure == |
== Flake structure == |
||
| Line 119: | Line 115: | ||
- <code>packages</code> for the bootstrap ISO |
- <code>packages</code> for the bootstrap ISO |
||
- <code>devShells</code> for development tooling |
- <code>devShells</code> for development tooling |
||
{{Navbox TELEICU}} |
|||
{{Related}} |
{{Related}} |
||
Latest revision as of 08:48, 6 July 2026
Full architecture and workflow for the NixOS migration path.
Architecture
Every hospital PC runs NixOS with identical, pinned system configuration. A flake repository defines the full OS state — packages, services, users, firewall, K3s agent — and nodes converge to the declared state via comin (pull-based, primary) or deploy-rs (push-based, backup).
Provisioning (zero-touch)
New sites are provisioned using a custom ISO generated with nixos-generator:
- The ISO boots with a pre-configured Cloudflare Tunnel or Tailscale connection already active
- A bootstrap script on the ISO initiates
nixos-anywhereover the tunnel nixos-anywherepartitions the disk (ZFS via disko) and installs NixOS- The node reboots into its NixOS generation and registers as a K3s agent
cominstarts polling for configuration updates
What NixOS manages
- Every system package, kernel parameter, and service
- Tailscale configuration and bringup
- K3s agent installation, config, and auto-join
- Cloudflare tunnel service (cloudflared)
- ZFS dataset layout and mount points
- OpenEBS localPV provisioner for K3s
- Monitoring agent, log shipper, downtime classifier
- Firewall rules (strict — only Tailscale + K3s + tunnel outbound)
- sops-nix secret decryption at build time
What K3s manages
- Middleware container deployments
- Service discovery, ingress, workload scaling
- Identity as a Kubernetes node (identical to Path A at this layer)
Storage
ZFS + OpenEBS localPV:
- Root pool: mirrored (if multiple disks) or single-disk with regular snapshots
- LocalPV datasets for stateful middleware workloads
- ZFS snapshots via sanoid/syncoid for fast backup
- Off-site backup via restic or zfs send to S3
Rollback
- Instant:
nixos-rebuild switch --rollbackreverts to the previous generation - At boot: hold Shift/space during systemd-boot to select a previous generation
- Every NixOS generation is an atomic, bootable unit — rollback is always available even if the OS is partially broken
Update mechanism
comin is the primary path (pull-based, suited for unreliable connectivity):
- Each node polls the flake repository on a configurable interval - When a new generation is available, it builds and activates it atomically - If the build fails, the node stays on its current generation — no partial state
deploy-rs is the backup path:
- Push-based, triggered from CI for urgent/canary deploys - Requires the node to be reachable at deploy time - Used for staging and canary nodes where immediate rollout is needed
Repository structure
Flake structure
flake.nix exposes:
- nixosConfigurations for each host (CP VMs + spoke/hub templates)
- cominConfigurations for comin-based auto-updates
- packages for the bootstrap ISO
- devShells for development tooling