TELEICU/Migration strategy
From OHC Network Wiki
More languages
More actions
This guide presents two independent paths for migrating the TELEICU infrastructure from its current state to a reliable, consistent K3s-based deployment. The paths are separate — choosing one does not mix components from the other.
The shared target
Both paths converge on the same target topology:
- 200+ hospital PCs become K3s agent nodes
- 1–3 cloud VMs serve as the K3s control plane (embedded etcd)
- Tailsecures all inter-node communication
- Pull-based configuration updates (handles unreliable connectivity)
- VictoriaMetrics for monitoring
- On-device agents for downtime classification
- Hub-admin notification chain for incidents
- Secrets managed via sops (sops-nix or Ansible Vault + sops)
Where they diverge
| Dimension | Path A: Ansible Pull | Path B: NixOS |
|---|---|---|
| OS baseline | Ubuntu (existing, kept in-place) | NixOS (fresh install via nixos-anywhere) |
| Immutability | Soft — ansible-pull reverts drift on check-in | Hard — /etc is read-only at runtime |
| Storage | Longhorn on existing ext4/xfs (no repartitioning) | ZFS + OpenEBS localPV |
| Configuration agent | ansible-pull (cron/systemd timer) | comin (primary) / deploy-rs (backup) |
| Provisioning | Minimal OS + Tailscale, then ansible-pull | Custom ISO via nixos-generator with pre-configured Tunnel/Tailscale |
| Learning curve | Low — ops team likely knows Ansible | High — Nix language, new paradigm |
| Drift guarantee | Soft — drift exists between pull intervals | Hard — enforced by OS design |
| Disk changes | No repartitioning required | Full disk reformat (ZFS) |
How to choose
Decision matrix — detailed comparison covering org readiness, timeline, guarantees, and risk.
Path A: Ansible Pull — full architecture and workflow.
Path B: NixOS — full architecture and workflow.
Both paths share the Canary rollout process and the Security baseline.