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>
75 lines
3.2 KiB
Markdown
75 lines
3.2 KiB
Markdown
# 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
|
|
```bash
|
|
docker compose -f docker/docker-compose.yml up --build -d
|
|
```
|
|
Logs ansehen:
|
|
```bash
|
|
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:
|
|
```bash
|
|
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`):
|
|
|
|
```bash
|
|
curl -s -X POST http://<host>/api/connect/start
|
|
```
|
|
Antwort enthält `code` und `urlComplete`. Dann:
|
|
1. `urlComplete` im Browser öffnen und als Admin anmelden.
|
|
2. Status pollen, bis verbunden:
|
|
```bash
|
|
curl -s http://<host>/api/status
|
|
```
|
|
(Feld `connected` wird `true`.)
|
|
3. Die UI im Browser **neu laden** → jetzt verbunden. Geräte/Gruppen/Policies laden
|
|
zum Verifizieren.
|
|
|
|
## Stoppen / Aufräumen
|
|
```bash
|
|
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).
|