TELEICU/Path A: Ansible Pull

guideteleicuCARE 3.0+

Full architecture and workflow for the Ansible Pull migration path.

Architecture

All node configuration is declared in a central git repository. Each hospital PC runs ansible-pull on a cron or systemd timer, checking out the repo and applying the playbook for its host group.

What Ansible manages

OS package state (apt pins to prevent version drift)
System configuration (ssh, sysctl, ntp, firewall)
K3s agent install and registration
Cloudflare tunnel service definition and credentials (from vault)
Docker/containerd configuration if needed by workloads
Monitoring agent and log shipper setup
Tailscale install and configuration

What K3s manages

Middleware container deployments
Service discovery and ingress within the cluster
Workload scaling and updates
All workloads are declarative Kubernetes manifests, versioned alongside playbooks

Storage

Longhorn on existing filesystems. No disk repartitioning — Longhorn uses a configured directory or dedicated mount point on the existing ext4/xfs partition.

Rollback

git revert the offending commit in the ansible repo
ansible-pull runs on next timer — nodes converge to the reverted state
For urgent rollbacks, trigger an immediate pull: ansible-pull -U <repo>

Constraints

No filesystem immutability — drift can exist between pull intervals (default: every 15–30 minutes)
Existing OS fragmentation must be handled through conditional Ansible roles
In-place OS upgrade playbook needed to converge Ubuntu versions before or during migration

Repository structure