Files

T

marcoandClaude Opus 4.8 9adf4da0d1 Docker: Test-Setup für self-hosted Betrieb (ohne Änderung des App-Teils)

Neuer Ordner docker/ (Dockerfile, docker-entrypoint.sh, docker-compose.yml, README).
Der bestehende App-/Client-Teil (Start.ps1, src/, www/) bleibt unverändert und wird
nur ins Image kopiert. Container-Spezifika laufen ohne Codeeingriff:
- socat-Bridge 0.0.0.0:8080 -> 127.0.0.1:8077 (App bindet weiter nur loopback)
- Datenpfad via XDG_CONFIG_HOME=/data (Volume) - Get-AppDataDir nutzt das auf Linux
- Login über den vorhandenen Device-Code-Flow (WAM/Loopback geht im Container nicht)
Kein Caddy: der vorhandene Reverse-Proxy zieht Port 8080 an.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-09-21 13:28:43 +02:00

3.2 KiB

Raw Blame History

Intune Manager - Docker-Test (self-hosted)

Test-Aufbau, um den Intune Manager als Container zu verproben. Der bestehende App-/Client-Teil (Start.ps1, src/, www/) wird nicht verändert — er wird nur unverändert ins Image kopiert. Container-Spezifika laufen über Env-Variablen und ein Entrypoint-Script.

Kein Caddy/TLS enthalten — der vorhandene Reverse-Proxy zieht den veröffentlichten Port (8080) an. HTTPS macht der Proxy.

Wie es funktioniert

Die App bindet unverändert auf http://localhost:8077/ (nur containerintern).
Ein socat-Bridge im Container leitet 0.0.0.0:8080 → 127.0.0.1:8077 — dadurch ist die App von außen erreichbar, ohne den App-Code anzufassen.
Settings/Policy-Exporte liegen im Volume /data (XDG_CONFIG_HOME=/data, wird von Get-AppDataDir auf Linux automatisch genutzt).

Bauen & starten

docker compose -f docker/docker-compose.yml up --build -d

Logs ansehen:

docker compose -f docker/docker-compose.yml logs -f

Erwartet: „Intune Manager - Web Edition" und „URL: http://localhost:8077/".

Den Reverse-Proxy auf http://<docker-host>:8080 zeigen lassen (reiner HTTP-Proxy, keine WebSockets/Callbacks nötig).

Erststart: Verbindung konfigurieren

Beim ersten Start ist noch kein Tenant hinterlegt. Zwei Wege:

UI: Seite öffnen → Einstellungen → Tenant-ID, Client-ID (Read/Write), optional Client-ID (Read-Only) und Scopes eintragen und speichern. Landet in /data/IntuneAppManager-Web/settings.json.

oder eine vorhandene settings.json ins Volume legen:

docker cp settings.json intune-manager-test:/data/IntuneAppManager-Web/settings.json
docker compose -f docker/docker-compose.yml restart

Der interaktive „Verbinden"-Button nutzt WAM/Loopback und funktioniert im Container nicht — das ist erwartet. Für den Test den bereits vorhandenen Device-Code-Flow per curl anstoßen (Host = euer Reverse-Proxy oder http://<docker-host>:8080):

curl -s -X POST http://<host>/api/connect/start

Antwort enthält code und urlComplete. Dann:

urlComplete im Browser öffnen und als Admin anmelden.
Status pollen, bis verbunden:
```
curl -s http://<host>/api/status
```
(Feld connected wird true.)
Die UI im Browser neu laden → jetzt verbunden. Geräte/Gruppen/Policies laden zum Verifizieren.

Stoppen / Aufräumen

docker compose -f docker/docker-compose.yml down          # Daten bleiben im Volume
docker compose -f docker/docker-compose.yml down -v       # inkl. Daten löschen

Wichtige Hinweise (für den echten Einsatz)

Kein eigener UI-Login und geteilte Sitzung: Wer die URL erreicht, kann den Login auslösen; die verbundene Graph-Sitzung gilt prozessweit. Die Instanz zwingend hinter Zugangsschutz stellen (Reverse-Proxy-Auth / Netzsegment / VPN). Eine Instanz = eine Team-Sitzung, kein sauberes Multi-Admin.
Reports liegen unter /tmp (nicht persistent) — für den Test ausreichend.
Das ist ein Test-Setup. Echtes Mehrbenutzer (Login pro Admin) wäre ein separater Ausbau (Auth-Code-Flow + Sitzungs-Isolation).

3.2 KiB Raw Blame History