Initial upload of BB-Apartment 2026 website.
Adds the complete Next.js website including i18n routing, house and apartment pages, Beds24 v2 integration for live availability/pricing, Stripe checkout, contact forms, Docker setup and deployment docs. Generated with [Devin](https://devin.ai) Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
This commit is contained in:
Markus
co-authored by
Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
parent
232770afe7
commit
2b24334bfa
+157
@@ -0,0 +1,157 @@
|
||||
# Deployment-Anleitung (Docker)
|
||||
|
||||
Diese Anleitung beschreibt, wie die BB-Apartment-Website auf einem eigenen Server per Docker deployt wird. Das Projekt bringt bereits ein fertiges `Dockerfile` und `docker-compose.yml` mit.
|
||||
|
||||
## 1. Voraussetzungen auf dem Server
|
||||
|
||||
Docker & Docker Compose installieren (falls noch nicht vorhanden), z. B. auf Debian/Ubuntu:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://get.docker.com | sh
|
||||
sudo usermod -aG docker $USER
|
||||
```
|
||||
|
||||
## 2. Code auf den Server bringen
|
||||
|
||||
Git ist **nicht zwingend erforderlich** – es gibt mehrere gleichwertige Wege:
|
||||
|
||||
### Option A: Mit Git (am einfachsten für spätere Updates)
|
||||
|
||||
```bash
|
||||
git clone <dein-repo-url> bb-apartment-website
|
||||
cd bb-apartment-website
|
||||
```
|
||||
|
||||
Updates später einfach per `git pull` (siehe Abschnitt "Updates einspielen").
|
||||
|
||||
### Option B: Ohne Git – Dateien direkt kopieren (rsync/scp)
|
||||
|
||||
Von deinem lokalen Rechner aus, z. B. per `rsync`:
|
||||
|
||||
```bash
|
||||
rsync -avz --exclude 'node_modules' --exclude '.next' --exclude '.git' \
|
||||
./bb-apartment-website/ \
|
||||
user@dein-server:/pfad/zu/bb-apartment-website/
|
||||
```
|
||||
|
||||
Alternativ per `scp` oder einem SFTP-Programm (z. B. FileZilla) den kompletten Ordner hochladen. `.env.local` am besten separat/sicher übertragen oder direkt auf dem Server neu anlegen (Schritt 3), statt sie mitzukopieren.
|
||||
|
||||
### Option C: Docker-Image lokal bauen und übertragen
|
||||
|
||||
Falls der Server gar keinen Zugriff auf den Quellcode/Registry haben soll:
|
||||
|
||||
```bash
|
||||
# Lokal bauen und als Datei exportieren
|
||||
docker build -t bb-apartment-website .
|
||||
docker save bb-apartment-website | gzip > bb-apartment.tar.gz
|
||||
|
||||
# Auf den Server kopieren und laden
|
||||
scp bb-apartment.tar.gz user@dein-server:/tmp/
|
||||
ssh user@dein-server "gunzip -c /tmp/bb-apartment.tar.gz | docker load"
|
||||
```
|
||||
|
||||
Auf dem Server dann in Schritt 4 `docker compose up -d` **ohne** `--build` verwenden, da das Image schon vorhanden ist (ggf. `image: bb-apartment-website` statt `build:` im `docker-compose.yml` für den `nextjs`-Service eintragen).
|
||||
|
||||
### Option D: Docker Registry (Docker Hub, GitHub Container Registry, ...)
|
||||
|
||||
Lokal bauen → Image in eine Registry pushen → auf dem Server nur pullen. Praktisch bei häufigeren Updates über mehrere Server hinweg, aber etwas mehr initiales Setup (Registry-Zugang einrichten).
|
||||
|
||||
---
|
||||
|
||||
Für die restliche Anleitung wird der einfachste Fall (Git) angenommen – bei den anderen Optionen einfach `git pull` in Schritt "Updates einspielen" durch dein jeweiliges Kopier-/Pull-Verfahren ersetzen.
|
||||
|
||||
## 3. `.env.local` mit echten Werten anlegen
|
||||
|
||||
Diese Datei liegt **nicht** im Git-Repo (enthält Secrets). Auf dem Server einmalig erstellen:
|
||||
|
||||
```bash
|
||||
cp .env.local.example .env.local
|
||||
nano .env.local # alle Platzhalter durch echte Werte ersetzen
|
||||
```
|
||||
|
||||
Wichtig einzutragen:
|
||||
|
||||
- **Beds24**: `BEDS24_REFRESH_TOKEN_HERDWEG` und `BEDS24_REFRESH_TOKEN_SCHOENAICHER` (je Haus ein eigener Zugang, siehe README für die Anleitung zum Beschaffen des Tokens)
|
||||
- **Stripe**: Account-IDs, Secret Keys und Webhook-Secrets für **beide** Häuser
|
||||
- **Datenbank**: `DATABASE_URL` / `POSTGRES_USER` / `POSTGRES_PASSWORD` / `POSTGRES_DB`
|
||||
- **SMTP**: Zugangsdaten für den Versand der Kontaktformular-Mails
|
||||
- **`NEXT_PUBLIC_BASE_URL`**: die echte Domain, z. B. `https://www.bb-apartment.de`
|
||||
- **`N8N_*`**: Zugangsdaten für die n8n-Automatisierung (Buchungsbestätigungen etc.)
|
||||
|
||||
## 4. Container bauen und starten
|
||||
|
||||
```bash
|
||||
docker compose up -d --build
|
||||
```
|
||||
|
||||
Das startet automatisch:
|
||||
|
||||
- **Next.js** (Port 3000) – die eigentliche Website
|
||||
- **PostgreSQL** – Datenbank für Buchungen
|
||||
- **n8n** (Port 5678) – Automatisierungen
|
||||
|
||||
### Falls Port 3000 (oder 5678) auf dem Server schon belegt ist
|
||||
|
||||
Der Container selbst lauscht intern immer auf Port 3000 (bzw. 5678 bei n8n) — nur der **Host-Port** (die linke Seite von `"3000:3000"` in `docker-compose.yml`) muss angepasst werden. Das ist bereits über Umgebungsvariablen konfigurierbar.
|
||||
|
||||
Wichtig: Docker Compose liest diese Variablen für die `ports:`-Zuordnung aus einer Datei namens **`.env`** (nicht `.env.local`!) im selben Ordner wie `docker-compose.yml`, oder aus der Shell-Umgebung. Eine Datei `.env` mit folgendem Inhalt anlegen:
|
||||
|
||||
```bash
|
||||
cat > .env <<'EOF'
|
||||
NEXTJS_HOST_PORT=8080
|
||||
N8N_HOST_PORT=8679
|
||||
EOF
|
||||
```
|
||||
|
||||
Dann wie gewohnt starten:
|
||||
|
||||
```bash
|
||||
docker compose up -d --build
|
||||
```
|
||||
|
||||
Die Website ist danach unter `http://localhost:8080` erreichbar (bzw. dem von dir gewählten Port). Der Reverse Proxy (siehe Schritt 7) muss dann auf diesen Port statt auf 3000 zeigen.
|
||||
|
||||
Alternativ – ohne `.env`-Datei – geht es auch einmalig inline:
|
||||
|
||||
```bash
|
||||
NEXTJS_HOST_PORT=8080 docker compose up -d --build
|
||||
```
|
||||
|
||||
## 5. Datenbank-Migration einmalig ausführen
|
||||
|
||||
```bash
|
||||
docker compose exec nextjs npx prisma migrate deploy
|
||||
```
|
||||
|
||||
## 6. Prüfen, ob alles läuft
|
||||
|
||||
```bash
|
||||
docker compose ps
|
||||
docker compose logs -f nextjs
|
||||
curl http://localhost:3000 # bzw. der Port aus deiner .env, falls angepasst
|
||||
```
|
||||
|
||||
## 7. Reverse Proxy (Domain + HTTPS)
|
||||
|
||||
Das Compose-Setup exponiert Next.js nur auf einem HTTP-Port (Standard 3000) ohne SSL. Für die echte Domain braucht es einen Reverse Proxy (nginx, Caddy o. ä.) davor, der z. B. `www.bb-apartment.de` → `localhost:3000` (bzw. den gewählten Host-Port) weiterleitet und das SSL-Zertifikat (Let's Encrypt) terminiert.
|
||||
|
||||
## Updates einspielen
|
||||
|
||||
```bash
|
||||
git pull
|
||||
docker compose up -d --build # bei Bedarf gezielt nur einen Service: docker compose up -d --build nextjs
|
||||
docker compose exec nextjs npx prisma migrate deploy # nur falls sich das DB-Schema geändert hat
|
||||
```
|
||||
|
||||
## Fehlersuche
|
||||
|
||||
```bash
|
||||
docker compose logs -f nextjs # Next.js-Logs live verfolgen
|
||||
docker compose logs -f postgres # Datenbank-Logs
|
||||
docker compose restart nextjs # Einzelnen Service neu starten
|
||||
docker compose down # Alles stoppen (Daten in Volumes bleiben erhalten)
|
||||
```
|
||||
|
||||
## Hinweise zu Beds24-Rate-Limits
|
||||
|
||||
Die Website cached Beds24-Anfragen serverseitig (5 Minuten bis 1 Stunde, je nach Endpunkt), um innerhalb der Beds24-Anfragelimits zu bleiben. Nach Änderungen in Beds24 (z. B. Mindestaufenthalt, Preise) kann es daher bis zu einer Stunde dauern, bis diese auf der Website sichtbar sind. Details siehe Kommentare in `src/lib/beds24.ts`.
|
||||
Reference in New Issue
Block a user