# Container-Betrieb
> Die DataBridge als Container bauen, in eine Azure Container Registry veröffentlichen und lokal starten — Beta.
---
Site [llms.txt](/llms.txt)
---
Die DataBridge lässt sich als Container-Image bauen und betreiben. Das Image basiert auf
der Azure-Functions-Laufzeit und enthält dieselbe Anwendung wie das reguläre Deployment.
> **Beta — nicht für den Kundenbetrieb**
>
> Der Container-Betrieb ist eine **Beta-Funktion** und **nicht für den produktiven
> Kundenbetrieb** vorgesehen. Auch der auf dieser Seite beschriebene Weg selbst ist noch
> **Beta**: Abläufe, Dateinamen und Parameter können sich ohne Ankündigung ändern.
>
> Für Kundeninstallationen gilt weiterhin der reguläre Weg über den
> [Azure Marketplace oder Bicep](../installation/).
>
> Wer die DataBridge als Container einsetzen möchte, wendet sich bitte vorab an WYSA —
> dort wird der konkrete Anwendungsfall geprüft und der aktuelle Stand mitgeteilt.
Sinnvoll ist der Container-Betrieb derzeit vor allem für **lokale Tests und
Entwicklung**: Die HTTP-Trigger lassen sich damit ohne Azure-Deployment aufrufen.
## Voraussetzungen
| Werkzeug | Zweck |
|---|---|
| **Docker Desktop** oder **Podman** | Image bauen und Container starten |
| **Azure CLI** (`az`) | Anmeldung an der Azure Container Registry (nur zum Veröffentlichen) |
Alle Befehle auf dieser Seite werden aus dem Ordner **`src/`** ausgeführt — dort liegen
`Dockerfile`, `compose.yml` und die Start-Scripts.
## Image bauen
Das `Dockerfile` liegt in `src/`. Bei Bedarf lässt sich dort das Basis-Image anpassen.
Allgemein aufgebaut ist der Tag so:
```text
{acr-name}.azurecr.io/{image-name}:{version}
```
| Bestandteil | Bedeutung |
|---|---|
| `acr-name` | Name der Azure Container Registry |
| `image-name` | Name des Images, z. B. `containered-connector` |
| `version` | Versionsnummer, üblicherweise dreistellig in der Form `v2.1.0` |
## In die Azure Container Registry veröffentlichen
Zunächst an Azure und anschließend an der Registry anmelden:
```bash
az login
```
```bash
az acr login --name acrwysatest
```
Danach das gebaute Image veröffentlichen:
```bash
docker push acrwysatest.azurecr.io/containered-connector:v2.3.0
```
Damit steht das Image unter der angegebenen Versionsnummer in der Registry bereit.
> **Registry in der Function App nicht auswählbar**
>
> Lässt sich die Registry beim Konfigurieren einer Azure Function App nicht auswählen,
> weil kein Admin-Konto verwendet wird, kann der Admin-Zugang nachträglich aktiviert
> werden:
>
> ```bash
> az acr update -n acrwysatest --admin-enabled true
> ```
## Lokal betreiben
### Umgebungsdatei anlegen
In `src/.podman/` liegt die Vorlage `podman.env.sample`. Diese kopieren und unter dem
Namen `podman..env` ablegen, zum Beispiel `podman.wysatest.env`:
```bash
cp .podman/podman.env.sample .podman/podman.wysatest.env
```
Anschließend die Datei mit den Verbindungsdaten der Zielumgebung füllen. Sie enthält
unter anderem `AzureWebJobsStorage`, `ConnectionStrings__ExportQueueServiceBus`,
`APPLICATIONINSIGHTS_CONNECTION_STRING`, den Timer-Ausdruck
`GetChangesTimerExpression` sowie die
[Funktions-Toggles](../umgebungsvariablen/#funktionen-gezielt-deaktivieren).
Danach in `src/compose.yml` prüfen, dass `env_file` auf die richtige Datei verweist:
```yaml
env_file:
- .podman/podman.wysatest.env
```
Der Container veröffentlicht seinen Port unter **`7071`** und setzt
`AzureWebJobsSecretStorageType=files`, damit die Function-Keys im Container abgelegt
werden können.
### Start-Script (empfohlen)
Der einfachste Weg sind die mitgelieferten Start-Scripts in `src/`. Sie bauen das Image,
starten den Container und geben anschließend alle HTTP-Trigger-URLs inklusive
Authentication-Key aus.
bash start-local.sh
.\start-local.ps1
Die Ausgabe sieht dann ungefähr so aus:
```text
============================================
DataBridge lokal gestartet
============================================
Master Key: abc123...
HTTP-Trigger URLs:
[GET] http://127.0.0.1:7071/api/GetInfo?code=abc123...
[GET] http://127.0.0.1:7071/api/CheckList?code=abc123...
[POST] http://127.0.0.1:7071/api/ExecuteJob?code=abc123...
[POST] http://127.0.0.1:7071/api/ExecuteHttpRequest?code=abc123...
============================================
```
Die URLs lassen sich direkt im Browser öffnen oder in Bruno beziehungsweise curl
verwenden.
### Manueller Start
Wer den Container selbst steuern möchte, startet ihn aus dem Ordner `src/`:
```bash
podman compose up --build -d
```
Logs anzeigen:
```bash
podman compose logs -f
```
Container beenden:
```bash
podman compose down
```
> **Beim manuellen Start muss der Key selbst ausgelesen werden**
>
> Azure Functions verlangen bei `AuthorizationLevel.Function` einen Schlüssel im
> Query-Parameter `?code=`. Das Start-Script liest den Master-Key automatisch aus dem
> laufenden Container.
>
> Beim manuellen Start muss der Schlüssel selbst ermittelt werden — er liegt nach dem
> ersten Aufruf im Container unter `/azure-functions-host/Secrets/host.json`.
## Installation prüfen
Ob der Container korrekt läuft, lässt sich über die HTTP-Trigger prüfen — `GetInfo`
liefert die Version, `CheckList` und `Validate` prüfen Mappings und Konfiguration. Die
Details dazu stehen unter [Installation](../installation/).