# Docker Build Anleitung

## Multi-Stage Build

Das Dockerfile verwendet einen Multi-Stage Build mit zwei Stages:

### Stage 1: Builder
- **Base Image**: Node.js 24.7.0-alpine
- **Aufgabe**: Baut die Angular-Applikation
- Installiert Dependencies mit `npm ci`
- Führt `npm run build` aus

### Stage 2: Runner
- **Base Image**: nginx-unprivileged:alpine3.22
- **Aufgabe**: Serviert die statischen Dateien
- Kopiert die gebauten Dateien aus der Builder-Stage
- Läuft auf Port 8080

## Build Ausführen

### Empfohlen: Build-Script mit .env Integration

Das empfohlene Vorgehen ist die Verwendung des Build-Scripts, welches automatisch den Image-Namen und Tag aus der `.env` Datei liest:

```bash
cd docker
./build.sh
```

Das Script liest folgende Variablen aus der `.env` Datei:
- `REGISTRY_URL`: Die Registry-URL (z.B. gitea.moz-tech.de)
- `NAMESPACE`: Der Namespace/Benutzer (z.B. murat)
- `REPO_NAME`: Der Repository-Name (z.B. enerport-web-app)
- `IMAGE_TAG`: Das Image-Tag (z.B. latest, v1.0.0, dev)

Der vollständige Image-Name wird dann als `${REGISTRY_URL}/${NAMESPACE}/${REPO_NAME}:${IMAGE_TAG}` zusammengesetzt.

**Beispiel .env:**
```env
REGISTRY_URL=gitea.moz-tech.de
NAMESPACE=murat
REPO_NAME=enerport-web-app
IMAGE_TAG=latest
```

### Manueller Build

#### Vom docker/ Verzeichnis aus:

```bash
cd docker
docker build -f Dockerfile -t enerport-web-app ..
```

**Wichtig**: Der Build-Kontext muss das Parent-Verzeichnis (`..`) sein, damit alle Source-Dateien verfügbar sind.

#### Vom Root-Verzeichnis aus:

```bash
docker build -f docker/Dockerfile -t enerport-web-app .
```

## Container Starten

```bash
docker run -p 8080:8080 enerport-web-app
```

Die Applikation ist dann unter http://localhost:8080 erreichbar und leitet automatisch zur deutschen Lokalisierung um (http://localhost:8080/de/).

### Verfügbare Sprachen

Die Applikation unterstützt mehrere Sprachen durch i18n:
- **Deutsch (de)**: http://localhost:8080/de/
- **Deutsch-Deutschland (de-DE)**: http://localhost:8080/de-DE/
- **Englisch (en)**: http://localhost:8080/en/

## Image zur Registry pushen

Nach dem erfolgreichen Build kann das Image mit dem Push-Script zur Gitea Registry hochgeladen werden:

```bash
cd docker
./push.sh
```

Das Push-Script:
- ✅ Liest automatisch alle Registry-Daten aus der `.env` Datei
- ✅ Prüft ob das Image lokal existiert
- ✅ Authentifiziert sich bei der Gitea Registry mit Token
- ✅ Pusht das Image zur Registry
- ✅ Logout nach erfolgreichem Push

**Workflow:**
```bash
# 1. Image bauen
./build.sh

# 2. Image zur Registry pushen
./push.sh
```

## CI/CD mit Gitea Actions

Für automatische Builds bei jedem Commit auf den `main` Branch wurde ein Gitea Workflow eingerichtet:

📄 **Workflow-Datei:** `.gitea/workflows/build-and-push.yaml`

Der Workflow:
- ✅ Wird automatisch bei Push auf `main` ausgeführt
- ✅ Baut das Docker Image mit `build.sh`
- ✅ Pusht das Image zur Registry mit `push.sh`
- ✅ Verwendet Gitea Variables und Secrets (keine .env Datei in Git)

**Setup-Anleitung:** Siehe [GITEA_SETUP.md](GITEA_SETUP.md) für die Einrichtung der benötigten Gitea Variables und Secrets.

## Hinweise

- Die `.dockerignore` Datei im docker/ Verzeichnis verhindert, dass unnötige Dateien ins Image kopiert werden
- Das finale Image ist optimiert und enthält nur die gebauten statischen Dateien und Nginx
- Der Nginx-Container läuft unprivileged auf Port 8080 für erhöhte Sicherheit
- Die Scripts `build.sh` und `push.sh` nutzen die `.env` Datei für zentrale Konfiguration
- Das Gitea Token in der `.env` Datei sollte niemals in Git committed werden
- Für CI/CD werden Variables und Secrets aus Gitea verwendet (siehe GITEA_SETUP.md)