docker.compose_check/_update über VM-Guest-Agent statt QEMU-Guest-Agent relayen #43

New issue

Closed

opened 2026-06-02 09:36:14 +00:00 by chinux · 0 comments

chinux commented

2026-06-02 09:36:14 +00:00

Owner

Ziel

docker.compose_check/docker.compose_update über den theProx-VM-Guest-Agent laufen lassen statt über den QEMU-Guest-Agent — kein qemu-guest-agent mehr nötig, ein Kanal für Discovery (#31), Check und Update.

Ist-Zustand

Node-Agent/src/commands.rs:284/288 rufen docker_compose::compose_check/update, die via qm::qm_agent_exec(vmid, …) (= pvesh …/agent/exec, QEMU-Guest-Agent) im Gast ausführen. Voraussetzung: qemu-guest-agent läuft im Gast. Das ist ein anderer Kanal als der VM-Guest-Agent (TCP-9100), über den z. B. vm.port_scan und collect_docker laufen → unterschiedliche Voraussetzungen, kann auseinanderlaufen.

Soll: Relay über VM-Guest-Agent (Muster: `vm.port_scan`)

Node-Agent

Die beiden Docker-Arme von commands.rs (sync, qm_agent_exec) nach commands_async.rs verlagern und an den VM-Guest-Agent relayen — analog vm.port_scan (commands_async.rs:155):

"docker.compose_check" => {
    let vmid = p_i64("vmid", 0);
    if vmid == 0 { return Some(json!({"status":"error","error":"vmid required"})); }
    let path = p_str("path");
    if path.is_empty() { return Some(json!({"status":"error","error":"path required"})); }
    if let Some(resp) = shared.vm_agents
        .send_and_wait(vmid, "vm.compose_check", cmd_id, 120, /* params: {path} */).await {
        return Some(resp);
    }
    Some(json!({"status":"error","error":"VM Guest Agent nicht verbunden"}))
}

(analog docker.compose_update, Timeout ~300). send_and_wait ggf. um die Param-Weitergabe (path) erweitern, falls es aktuell nur action schickt.
Optional: qm_agent_exec als Fallback behalten, wenn kein VM-Guest-Agent verbunden ist (rückwärtskompatibel).

VM-Guest-Agent (alle Varianten)

Neue Command-Handler vm.compose_check / vm.compose_update, die lokal im Gast laufen:

Linux/FreeBSD (VM-Guest-Agent/src/main.rs Command-Match): cd <path> && docker compose pull --dry-run bzw. … pull && docker compose up -d, stdout/stderr einsammeln.
Windows (Windows-VM-Guest-Agent/src/main.rs): dito mit docker compose (sofern Docker im Windows-Gast).
pfSense/FreeBSD-Python (pfsense_agent.py): i. d. R. kein Docker → status:"skipped"/Fehler „kein Docker".
Rückgabe-Shape wie heute ({status, output, error}) bzw. direkt die strukturierte Digest-Antwort aus #42.

Voraussetzung

VM-Guest-Agent muss im Gast Docker-Zugriff haben (Gruppe docker bzw. root) — im Issue/Doku vermerken.

Bezug

#31: Compose-Pfad-Discovery läuft dann über denselben Agent → Discovery + Check + Update konsistent, gleiche Voraussetzung.
#42: die Digest-basierte Erkennung sollte dann ebenfalls im VM-Guest-Agent-Handler sitzen.

Akzeptanz

Compose-Check/-Update laufen über den VM-Guest-Agent (kein qemu-guest-agent nötig).
Bei nicht verbundenem VM-Guest-Agent klare Meldung (optional qm_agent_exec-Fallback).
cargo build (Linux/FreeBSD/Windows) grün — vor Merge.

Branch

feat/compose-via-vm-guest-agent

## Ziel `docker.compose_check`/`docker.compose_update` über den **theProx-VM-Guest-Agent** laufen lassen statt über den QEMU-Guest-Agent — kein `qemu-guest-agent` mehr nötig, ein Kanal für Discovery (#31), Check und Update. ## Ist-Zustand `Node-Agent/src/commands.rs:284/288` rufen `docker_compose::compose_check/update`, die via `qm::qm_agent_exec(vmid, …)` (= `pvesh …/agent/exec`, **QEMU-Guest-Agent**) im Gast ausführen. Voraussetzung: qemu-guest-agent läuft im Gast. Das ist ein **anderer Kanal** als der VM-Guest-Agent (TCP-9100), über den z. B. `vm.port_scan` und `collect_docker` laufen → unterschiedliche Voraussetzungen, kann auseinanderlaufen. ## Soll: Relay über VM-Guest-Agent (Muster: `vm.port_scan`) ### Node-Agent Die beiden Docker-Arme von `commands.rs` (sync, qm_agent_exec) nach `commands_async.rs` verlagern und an den VM-Guest-Agent relayen — analog `vm.port_scan` (`commands_async.rs:155`): ```rust "docker.compose_check" => { let vmid = p_i64("vmid", 0); if vmid == 0 { return Some(json!({"status":"error","error":"vmid required"})); } let path = p_str("path"); if path.is_empty() { return Some(json!({"status":"error","error":"path required"})); } if let Some(resp) = shared.vm_agents .send_and_wait(vmid, "vm.compose_check", cmd_id, 120, /* params: {path} */).await { return Some(resp); } Some(json!({"status":"error","error":"VM Guest Agent nicht verbunden"})) } ``` (analog `docker.compose_update`, Timeout ~300). `send_and_wait` ggf. um die Param-Weitergabe (`path`) erweitern, falls es aktuell nur `action` schickt. **Optional:** `qm_agent_exec` als Fallback behalten, wenn kein VM-Guest-Agent verbunden ist (rückwärtskompatibel). ### VM-Guest-Agent (alle Varianten) Neue Command-Handler `vm.compose_check` / `vm.compose_update`, die lokal im Gast laufen: - **Linux/FreeBSD** (`VM-Guest-Agent/src/main.rs` Command-Match): `cd <path> && docker compose pull --dry-run` bzw. `… pull && docker compose up -d`, stdout/stderr einsammeln. - **Windows** (`Windows-VM-Guest-Agent/src/main.rs`): dito mit `docker compose` (sofern Docker im Windows-Gast). - **pfSense/FreeBSD-Python** (`pfsense_agent.py`): i. d. R. kein Docker → `status:"skipped"`/Fehler „kein Docker". Rückgabe-Shape wie heute (`{status, output, error}`) bzw. direkt die strukturierte Digest-Antwort aus #42. ### Voraussetzung VM-Guest-Agent muss im Gast Docker-Zugriff haben (Gruppe `docker` bzw. root) — im Issue/Doku vermerken. ## Bezug - #31: Compose-Pfad-Discovery läuft dann über **denselben** Agent → Discovery + Check + Update konsistent, gleiche Voraussetzung. - #42: die Digest-basierte Erkennung sollte dann ebenfalls im VM-Guest-Agent-Handler sitzen. ## Akzeptanz - Compose-Check/-Update laufen über den VM-Guest-Agent (kein qemu-guest-agent nötig). - Bei nicht verbundenem VM-Guest-Agent klare Meldung (optional qm_agent_exec-Fallback). - `cargo build` (Linux/FreeBSD/Windows) grün — vor Merge. ## Branch `feat/compose-via-vm-guest-agent`

chinux

2026-06-02 09:36:14 +00:00