homelab-codex-ws/services/agent-system/deploy.sh

39 lines
1.2 KiB
Bash
Raw Permalink Normal View History

#!/bin/bash
set -e
fix(agent-system): deploy.sh nigdy nie dolaczal override'u hosta -> panel czytal legacy Redis, nie VPS observera Root cause rozjazdu panelu agents.okit.pl vs services.json NIE lezal w observer.py/operator_ui.py (te sa poprawne: ghost-prune dziala in-memory i na plik co cykl, operator_ui czyta services.json na zywo bez cache). Prawdziwy lancuch: npm proxy_host agents.okit.pl -> 100.108.208.3:18180 (Tailscale IP PIHA, nie VPS!) -> legacy kontener agent-system-webui (services/agent-system/, sprzed migracji do control-plane/, brak service.yaml, nieobecny w hosts/piha/services.yaml i topology.yaml). Jego runtime-materializer czytal z Redis (homelab:services:*), do ktorego NIC juz nie pisze w obecnej architekturze -- stad 27 martwych/ghost wpisow (w tym hash-prefixed) i inna liczba serwisow (110 vs 117 w services.json z VPS). Fix na to juz istnial w repo od 2026-05-27 (7277bdc): materializer.py ma materialize_from_api() ktory mirroruje czysty output observera z VPS przez CONTROL_PLANE_URL, a hosts/piha/runtime/agent-system/docker-compose.override.yml ustawia ta zmienna. Nigdy sie jednak nie aktywowal, bo services/agent-system/deploy.sh (jedyna sciezka deployu tego serwisu) wolal `docker compose up` uzywajac WYLACZNIE docker-compose.yml, bez dolaczania override'u z hosts/ -- w odroznieniu od control-plane/ deploy-local.sh i stability-agent/deploy-local.sh, ktore ten wzorzec juz stosuja. Fix: deploy.sh dolacza teraz hosts/piha/runtime/agent-system/docker-compose.override.yml (ten sam wzorzec co control-plane, ktory hardkoduje vps). Po nastepnym `services/agent-system/deploy.sh` na PIHA runtime-materializer zacznie mirrorowac /nodes /services /summary itd. z control-plane API zamiast Redis -- panel bedzie pokazywal to samo co services.json. Docker socket PIHA (DOCKER_API_ERROR 2026-07-17T00:00:40Z): NIE regres group_add/gid (node-agent ma poprawne grupy 999/123, gid docker.sock=123 sie zgadza). Wszystkie ~40 kontenerow na PIHA wystartowaly jednoczesnie o 00:00:26 UTC -- to byl automatyczny apt-get upgrade docker-ce 29.6.1->29.6.2 (apt/history.log, Start-Date 02:00:08 CEST), ktory zrestartowal Docker Engine. stability-agent (root) trafil na gniazdo w ~1-sekundowym oknie zanim daemon w pelni wstal (docker.service ActiveEnterTimestamp 02:00:41 CEST). Jednorazowy, samo-naprawiony, zdarzenie sie nie powtorzylo. Brak zmiany kodu. Testy: ast.parse (observer.py, operator_ui.py, materializer.py) OK, bash -n deploy.sh OK, docker compose config (merge z override) poprawnie wstrzykuje CONTROL_PLANE_URL, pytest services/control-plane/tests 114 passed, pytest services/agent-system/telegram-bot/tests 8 passed. Co NIE zrobiono (poza zakresem/deploy nalezy do operatora): rzeczywisty redeploy agent-system na PIHA + weryfikacja panelu na zywo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-17 14:02:04 +02:00
# Host-specific override (e.g. CONTROL_PLANE_URL for runtime-materializer) — same
# convention as services/control-plane/deploy-local.sh. agent-system currently
# only runs on piha, so this is hardcoded like control-plane hardcodes vps.
COMPOSE_ARGS="-f docker-compose.yml"
OVERRIDE_FILE="../../hosts/piha/runtime/agent-system/docker-compose.override.yml"
if [ -f "$OVERRIDE_FILE" ]; then
echo ">>> Using override: $OVERRIDE_FILE"
COMPOSE_ARGS="$COMPOSE_ARGS -f $OVERRIDE_FILE"
fi
echo ">>> Validating docker-compose configuration..."
fix(agent-system): deploy.sh nigdy nie dolaczal override'u hosta -> panel czytal legacy Redis, nie VPS observera Root cause rozjazdu panelu agents.okit.pl vs services.json NIE lezal w observer.py/operator_ui.py (te sa poprawne: ghost-prune dziala in-memory i na plik co cykl, operator_ui czyta services.json na zywo bez cache). Prawdziwy lancuch: npm proxy_host agents.okit.pl -> 100.108.208.3:18180 (Tailscale IP PIHA, nie VPS!) -> legacy kontener agent-system-webui (services/agent-system/, sprzed migracji do control-plane/, brak service.yaml, nieobecny w hosts/piha/services.yaml i topology.yaml). Jego runtime-materializer czytal z Redis (homelab:services:*), do ktorego NIC juz nie pisze w obecnej architekturze -- stad 27 martwych/ghost wpisow (w tym hash-prefixed) i inna liczba serwisow (110 vs 117 w services.json z VPS). Fix na to juz istnial w repo od 2026-05-27 (7277bdc): materializer.py ma materialize_from_api() ktory mirroruje czysty output observera z VPS przez CONTROL_PLANE_URL, a hosts/piha/runtime/agent-system/docker-compose.override.yml ustawia ta zmienna. Nigdy sie jednak nie aktywowal, bo services/agent-system/deploy.sh (jedyna sciezka deployu tego serwisu) wolal `docker compose up` uzywajac WYLACZNIE docker-compose.yml, bez dolaczania override'u z hosts/ -- w odroznieniu od control-plane/ deploy-local.sh i stability-agent/deploy-local.sh, ktore ten wzorzec juz stosuja. Fix: deploy.sh dolacza teraz hosts/piha/runtime/agent-system/docker-compose.override.yml (ten sam wzorzec co control-plane, ktory hardkoduje vps). Po nastepnym `services/agent-system/deploy.sh` na PIHA runtime-materializer zacznie mirrorowac /nodes /services /summary itd. z control-plane API zamiast Redis -- panel bedzie pokazywal to samo co services.json. Docker socket PIHA (DOCKER_API_ERROR 2026-07-17T00:00:40Z): NIE regres group_add/gid (node-agent ma poprawne grupy 999/123, gid docker.sock=123 sie zgadza). Wszystkie ~40 kontenerow na PIHA wystartowaly jednoczesnie o 00:00:26 UTC -- to byl automatyczny apt-get upgrade docker-ce 29.6.1->29.6.2 (apt/history.log, Start-Date 02:00:08 CEST), ktory zrestartowal Docker Engine. stability-agent (root) trafil na gniazdo w ~1-sekundowym oknie zanim daemon w pelni wstal (docker.service ActiveEnterTimestamp 02:00:41 CEST). Jednorazowy, samo-naprawiony, zdarzenie sie nie powtorzylo. Brak zmiany kodu. Testy: ast.parse (observer.py, operator_ui.py, materializer.py) OK, bash -n deploy.sh OK, docker compose config (merge z override) poprawnie wstrzykuje CONTROL_PLANE_URL, pytest services/control-plane/tests 114 passed, pytest services/agent-system/telegram-bot/tests 8 passed. Co NIE zrobiono (poza zakresem/deploy nalezy do operatora): rzeczywisty redeploy agent-system na PIHA + weryfikacja panelu na zywo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-17 14:02:04 +02:00
docker compose $COMPOSE_ARGS config
echo ">>> Building and starting Agent System services..."
fix(agent-system): deploy.sh nigdy nie dolaczal override'u hosta -> panel czytal legacy Redis, nie VPS observera Root cause rozjazdu panelu agents.okit.pl vs services.json NIE lezal w observer.py/operator_ui.py (te sa poprawne: ghost-prune dziala in-memory i na plik co cykl, operator_ui czyta services.json na zywo bez cache). Prawdziwy lancuch: npm proxy_host agents.okit.pl -> 100.108.208.3:18180 (Tailscale IP PIHA, nie VPS!) -> legacy kontener agent-system-webui (services/agent-system/, sprzed migracji do control-plane/, brak service.yaml, nieobecny w hosts/piha/services.yaml i topology.yaml). Jego runtime-materializer czytal z Redis (homelab:services:*), do ktorego NIC juz nie pisze w obecnej architekturze -- stad 27 martwych/ghost wpisow (w tym hash-prefixed) i inna liczba serwisow (110 vs 117 w services.json z VPS). Fix na to juz istnial w repo od 2026-05-27 (7277bdc): materializer.py ma materialize_from_api() ktory mirroruje czysty output observera z VPS przez CONTROL_PLANE_URL, a hosts/piha/runtime/agent-system/docker-compose.override.yml ustawia ta zmienna. Nigdy sie jednak nie aktywowal, bo services/agent-system/deploy.sh (jedyna sciezka deployu tego serwisu) wolal `docker compose up` uzywajac WYLACZNIE docker-compose.yml, bez dolaczania override'u z hosts/ -- w odroznieniu od control-plane/ deploy-local.sh i stability-agent/deploy-local.sh, ktore ten wzorzec juz stosuja. Fix: deploy.sh dolacza teraz hosts/piha/runtime/agent-system/docker-compose.override.yml (ten sam wzorzec co control-plane, ktory hardkoduje vps). Po nastepnym `services/agent-system/deploy.sh` na PIHA runtime-materializer zacznie mirrorowac /nodes /services /summary itd. z control-plane API zamiast Redis -- panel bedzie pokazywal to samo co services.json. Docker socket PIHA (DOCKER_API_ERROR 2026-07-17T00:00:40Z): NIE regres group_add/gid (node-agent ma poprawne grupy 999/123, gid docker.sock=123 sie zgadza). Wszystkie ~40 kontenerow na PIHA wystartowaly jednoczesnie o 00:00:26 UTC -- to byl automatyczny apt-get upgrade docker-ce 29.6.1->29.6.2 (apt/history.log, Start-Date 02:00:08 CEST), ktory zrestartowal Docker Engine. stability-agent (root) trafil na gniazdo w ~1-sekundowym oknie zanim daemon w pelni wstal (docker.service ActiveEnterTimestamp 02:00:41 CEST). Jednorazowy, samo-naprawiony, zdarzenie sie nie powtorzylo. Brak zmiany kodu. Testy: ast.parse (observer.py, operator_ui.py, materializer.py) OK, bash -n deploy.sh OK, docker compose config (merge z override) poprawnie wstrzykuje CONTROL_PLANE_URL, pytest services/control-plane/tests 114 passed, pytest services/agent-system/telegram-bot/tests 8 passed. Co NIE zrobiono (poza zakresem/deploy nalezy do operatora): rzeczywisty redeploy agent-system na PIHA + weryfikacja panelu na zywo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-17 14:02:04 +02:00
docker compose $COMPOSE_ARGS up -d --build
echo ">>> Services status:"
docker ps --filter "name=agent-system" --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
if [ -z "$TELEGRAM_BOT_TOKEN" ]; then
echo ">>> Telegram bot status: DISABLED (token missing)"
else
echo ">>> Telegram bot status: ENABLED"
fi
echo ">>> Verifying API endpoints..."
sleep 5 # Give it a moment to start
endpoints=("summary" "nodes" "services")
for ep in "${endpoints[@]}"; do
echo "Checking /$ep..."
curl -s -f http://localhost:18180/$ep > /dev/null && echo " OK" || echo " FAILED"
done
echo ">>> Deployment complete."