Plattformen

Ongrid liefert zwei Binaries mit sehr unterschiedlichen Plattform-Stories aus.

• ongrid (der Cloud-Manager) ist eine Linux- + Docker-Workload. Er ist dafür gedacht, in einem Container zu leben, hinter nginx, mit MySQL darunter. Es gibt keinen erstklassigen Windows- oder macOS-Server-Build.
• ongrid-edge (der Edge-Agent) ist ein einzelnes statisches Binary, das auf jedem Host läuft, den Sie beobachten wollen. Es kreuz-kompiliert out of the Box auf vier Ziele: Linux auf amd64 / arm64 und macOS auf amd64 / arm64. Production-grade-Installation nur auf Linux + systemd; macOS-Ziele existieren, damit Entwickler den Agenten auf ihrem Laptop laufen lassen können, während sie iterieren.

Support-Matrix

Komponente	linux/amd64	linux/arm64	darwin/amd64	darwin/arm64	Windows
ongrid (Manager-Image)	ja	als Build-Target getestet	nein	nein	nein
ongrid-edge (Binary, überwacht)	ja	ja	nur Dev, manuell	nur Dev, manuell	nein
promtail-Plugin (Logs)	ja	ja	nein (Upstream-Lücke)	nein (Upstream-Lücke)	nein
node_exporter-Plugin (Host-Metriken)	ja	ja	nein (Upstream-Lücke)	nein (Upstream-Lücke)	nein
process-exporter-Plugin (Proc-Metriken)	ja	ja	nein (Upstream-Lücke)	nein (Upstream-Lücke)	nein
otelcol-contrib-Plugin (Traces)	ja	ja	nein (nicht gebündelt)	nein (nicht gebündelt)	nein

Die vier Edge-Cross-Compile-Ziele kommen direkt aus dem Makefile:

build-edge-linux-amd64
build-edge-linux-arm64
build-edge-darwin-amd64
build-edge-darwin-arm64

make build-edge-all führt alle vier aus; make package produziert das Release-Tarball, das jedes Ziel plus die Linux-only Plugin-Binaries bündelt.

Warum keine Windows- / BSD-Edge?

Der Agent selbst ist reines Go und würde sauber kompilieren; die Lücke ist das Plugin-Bundle. promtail, node_exporter, process-exporter und otelcol-contrib liefern alle nur Linux-Artefakte in ihren Upstream-Releases. Ohne diese vier bleiben die Logs- / Monitor- / Traces-Panels auch nach Connect des Agenten leer. Wir würden lieber keine halb-funktionierende Installation ausliefern als eine versteckt-deaktivierte Plattform mitzuschleppen.

Wenn Sie einen starken Windows- oder FreeBSD-Use-Case haben, öffnen Sie ein Issue auf github.com/ongridio/ongrid — Pluggable-Bundler werden unter ADR-015 getrackt.

Cloud-seitige Anforderungen

Überall, wo Sie Docker Engine 24+ und Docker Compose v2 betreiben können, hostet den Manager. Wir testen auf:

• Ubuntu 22.04 LTS, 24.04 LTS
• Debian 12 (bookworm)
• RHEL 9, Rocky Linux 9, AlmaLinux 9

Speicher-Untergrenze: 4 GB. Disk-Untergrenze: 20 GB (am meisten davon ist Prometheus- + Loki-Retention, siehe Linux (Server)).

Edge-seitige Anforderungen

Der offizielle curl-pipe-Installer (deploy/install/edge/install.sh) handhabt explizit nur Linux:

if [[ "$OS" != "linux" ]]; then
    log_error "only linux is supported by this installer; got: $OS"
    exit 1
fi

Dieser Installer legt eine systemd-Unit (/etc/systemd/system/ongrid-edge.service) ab, erstellt einen System-User ongrid-edge und überwacht den Agenten via systemd mit Restart=always. macOS-Hosts können das Binary für Entwicklung weiterhin von Hand ausführen — siehe macOS (Edge-Dev) — aber Sie bekommen den überwachten Service, die journald-Log-Quelle oder das Plugin-Bundle nicht.

Die richtige Seite wählen

• Manager installieren? → Linux (Server)
• Einen Edge-Agenten auf einem echten Linux-Host installieren? → Linux (Edge)
• Den Agenten auf einem Mac für Entwicklung laufen lassen? → macOS (Edge-Dev)
• Alles auf Kubernetes deployen? → Kubernetes
• Air-Gapped oder private Container-Registry? → Air-Gapped / On-Prem

Versionierungs-Policy

Der Manager und der Agent teilen eine einzelne VERSION-Datei (/Users/.../ongrid/VERSION) und werden als ein Tarball released. Ein Edge-Agent, älter als sein Manager, wird weiter funktionieren: jeder Tunnel-RPC ist versioniert, und der Manager behandelt unbekannte Reply-Felder als Null-Werte. Ein Edge-Agent neuer als sein Manager ist nicht unterstützt — upgraden Sie zuerst den Manager.

Siehe Upgrade für das Staged-Swap-then-Rollback-Modell (ADR-024).