marcoandClaude Opus 4.8
9adf4da0d1
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>
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 vonGet-AppDataDirauf 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.jsonins Volume legen:docker cp settings.json intune-manager-test:/data/IntuneAppManager-Web/settings.json docker compose -f docker/docker-compose.yml restart
Login (Device-Code)
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:
urlCompleteim Browser öffnen und als Admin anmelden.- Status pollen, bis verbunden:
(Feld
curl -s http://<host>/api/statusconnectedwirdtrue.) - 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).