235 lines
11 KiB
Markdown
235 lines
11 KiB
Markdown
# Bunny.net – Ersteinrichtung und Vorab-Veröffentlichung
|
||
|
||
Ziel: `iwz-ferienwohnungen` bei Bunny.net anlegen, eine erste Fassung der Hugo-Seite
|
||
online stellen und den Zugriff darauf auf dich + den Kunden beschränken (Vorschau,
|
||
bevor die Seite öffentlich unter der echten Domain läuft).
|
||
|
||
> Hinweis: Dieser Weg ersetzt den früher geplanten Cloudflare-Pages-Ansatz.
|
||
> Details zum alten Cloudflare/IONOS-Plan siehe weiter unten im Abschnitt
|
||
> "Alt: Cloudflare-Variante (nicht mehr aktuell)".
|
||
|
||
## 1. Bunny.net-Account anlegen
|
||
|
||
1. Auf [bunny.net](https://bunny.net) registrieren (E-Mail + Passwort, keine
|
||
Kreditkarte für den Start nötig, Abrechnung erfolgt nach Traffic/Storage).
|
||
2. E-Mail-Adresse bestätigen und einloggen ins Dashboard.
|
||
|
||
## 2. Storage Zone anlegen (Ablage für die gebauten Hugo-Dateien)
|
||
|
||
1. Im Dashboard-Menü **Storage** → **Add Storage Zone**.
|
||
2. Name vergeben, z. B. `iwz-ferienwohnungen`.
|
||
3. **Main Region**: Region wählen, die am nächsten an euch/den Besuchern liegt
|
||
(z. B. Frankfurt/Falkenstein, Europa).
|
||
4. Replikations-Regionen optional dazuwählen, falls später Besucher aus anderen
|
||
Kontinenten erwartet werden (für die Vorschau-Phase nicht nötig).
|
||
5. Zone erstellen.
|
||
|
||
## 3. Zugangsdaten der Storage Zone notieren
|
||
|
||
1. Storage Zone öffnen → Reiter **FTP & API Access**.
|
||
2. **Hostname**, **Username** und **Password** (nicht das Read-only-Passwort!)
|
||
notieren – diese werden später für den Upload per `deploy.bat`/`deploy.py`
|
||
gebraucht (als `BUNNY_STORAGE_ZONE` und `BUNNY_API_KEY`, siehe CLAUDE.md).
|
||
3. Zugangsdaten **nicht** ins Git-Repo einchecken (z. B. in `.env` oder als
|
||
Windows-Umgebungsvariable ablegen).
|
||
|
||
## 4. Erste Fassung hochladen
|
||
|
||
Lokal die Seite bauen und die `public/`-Inhalte in die Storage Zone hochladen:
|
||
|
||
```powershell
|
||
hugo --gc --minify
|
||
```
|
||
|
||
Für den allerersten Test kann der Upload manuell per **File Manager** im Bunny-
|
||
Dashboard (Storage Zone → Files → Drag & Drop von `public/`) erfolgen. Sobald
|
||
`deploy.bat`/`deploy.py` entsprechend erweitert ist, übernimmt das Skript diesen
|
||
Schritt automatisch (Ordnerinhalt von `public/` 1:1 in die Storage Zone spiegeln).
|
||
|
||
## 5. Pull Zone anlegen (macht die Storage Zone über HTTPS erreichbar)
|
||
|
||
1. In der Storage Zone → **Connected Pull Zones** → **Connect Pull Zone**
|
||
(oder im Menü **CDN → Add Pull Zone** und als Origin die Storage Zone wählen).
|
||
2. Namen vergeben, z. B. `iwz-ferienwohnungen`.
|
||
3. Zonen für die Auslieferung wählen (Europa reicht für die Vorschau).
|
||
4. Pull Zone erstellen → Bunny vergibt automatisch eine Test-URL:
|
||
`https://iwz-ferienwohnungen.b-cdn.net`
|
||
5. HTTPS ist auf dieser `b-cdn.net`-URL automatisch aktiv, kein eigenes
|
||
Zertifikat nötig.
|
||
|
||
Damit ist die Seite technisch live – als nächstes wird sie geschützt, bevor der
|
||
Link an den Kunden geht.
|
||
|
||
## 6. Zugriff beschränken: nur du + der Kunde
|
||
|
||
Bunny.net Pull Zones bieten dafür **Token Authentication**: Requests an die
|
||
Pull Zone werden nur ausgeliefert, wenn die URL einen gültigen, signierten Token
|
||
enthält. Es gibt keinen klassischen Basic-Auth-Login-Dialog im Browser –
|
||
stattdessen bekommt der Kunde einen fertigen Link mit Token, der bis zu einem
|
||
festgelegten Ablaufzeitpunkt gültig ist.
|
||
|
||
### 6.1 Token Authentication aktivieren
|
||
|
||
1. Pull Zone öffnen → Reiter **Security**.
|
||
2. **Token Authentication** aktivieren.
|
||
3. Den angezeigten **Authentication Key** kopieren und sicher aufbewahren
|
||
(nicht ins Git-Repo, nicht per unverschlüsselter Mail verschicken) – wer
|
||
diesen Key kennt, kann selbst gültige Links erzeugen.
|
||
|
||
Ab jetzt liefert die Pull Zone **nichts mehr aus**, ohne gültigen Token in der
|
||
URL – das ist der eigentliche Zugriffsschutz.
|
||
|
||
### 6.2 Signierten Link erzeugen
|
||
|
||
Ein signierter Link besteht aus einem Hash über `Authentication Key + Pfad +
|
||
Ablaufzeitpunkt`. Das lässt sich einfach per kleinem Python-Snippet erzeugen,
|
||
z. B. lokal ausführen, wenn ein neuer Vorschau-Link für den Kunden gebraucht
|
||
wird:
|
||
|
||
```python
|
||
import hashlib
|
||
import base64
|
||
import time
|
||
|
||
security_key = "DEIN_AUTHENTICATION_KEY"
|
||
url_path = "/index.html" # z.B. Startseite, oder "/" je nach Setup
|
||
expires = int(time.time()) + 7 * 24 * 60 * 60 # 7 Tage gültig
|
||
|
||
hashable = f"{security_key}{url_path}{expires}"
|
||
token_hash = hashlib.sha256(hashable.encode()).digest()
|
||
token = base64.urlsafe_b64encode(token_hash).decode().rstrip("=")
|
||
|
||
print(f"https://iwz-ferienwohnungen.b-cdn.net{url_path}?token={token}&expires={expires}")
|
||
```
|
||
|
||
Den ausgegebenen Link schickst du dem Kunden. Läuft die Gültigkeit ab, einfach
|
||
ein neues Snippet mit neuem `expires`-Wert ausführen und den frischen Link
|
||
verschicken.
|
||
|
||
### 6.3 Praktisch für Vorschau-Zwecke
|
||
|
||
- Länge der Gültigkeit (`expires`) nach Bedarf wählen – z. B. 7 Tage für eine
|
||
kurze Abstimmungsrunde, oder wenige Stunden für einen einzelnen Termin.
|
||
- Ohne gültigen Token bekommt jeder andere Besucher einen Fehler von Bunny –
|
||
die Seite ist damit faktisch nur über den geteilten Link erreichbar.
|
||
- Sobald die Seite live gehen soll (echte Domain, öffentlich), wird Token
|
||
Authentication in der Pull Zone einfach wieder deaktiviert.
|
||
|
||
## 7. Domain-Anbindung (später, für den echten Umzug)
|
||
|
||
Noch offen und erst relevant, wenn die Seite final ist:
|
||
|
||
- Eigene Domain (`iwz-ferienwohnungen.de`) als Custom Hostname in der Pull Zone
|
||
hinterlegen.
|
||
- Entweder DNS bei IONOS per CNAME auf die Bunny-Pull-Zone zeigen lassen, oder
|
||
DNS komplett zu Bunny.net DNS umziehen (Nameserver-Wechsel bei IONOS,
|
||
ähnlich wie ursprünglich für Cloudflare geplant).
|
||
- SSL-Zertifikat für die eigene Domain wird von Bunny automatisch ausgestellt,
|
||
sobald der Hostname verifiziert ist.
|
||
- Domain-Registrar bleibt in jedem Fall IONOS.
|
||
|
||
## Zusammenfassung des Stacks (aktuell)
|
||
|
||
```
|
||
Domain-Registrar: IONOS (bleibt so)
|
||
DNS: noch offen (IONOS bleibt vorerst / später ggf. Bunny.net DNS)
|
||
Hosting: Bunny.net (Storage Zone + Pull Zone/CDN)
|
||
Vorschau-Schutz: Bunny Token Authentication (signierte, befristete Links)
|
||
Code/Content: Gitea (eigene Instanz, kein CI/CD-Workflow)
|
||
Deploy: manuell per deploy.bat / deploy.py (hugo build + Upload zur Storage Zone)
|
||
Buchungskalender: webplanner.de (bleibt so, extern)
|
||
```
|
||
|
||
---
|
||
|
||
# Alt: Cloudflare-Variante (nicht mehr aktuell)
|
||
|
||
Der folgende Abschnitt beschreibt den ursprünglich geplanten Umzug auf
|
||
Cloudflare Pages und wird nicht mehr weiterverfolgt (Entscheidung: Umstieg auf
|
||
Bunny.net, siehe oben). Als Referenz stehen gelassen.
|
||
|
||
## SSL/HTTPS auf Cloudflare Pages
|
||
|
||
Ja, vollautomatisch. Es gibt keine Tokens oder Zertifikate, die du selbst beantragen oder verlängern musst. Das läuft komplett im Hintergrund über Let's Encrypt, gesteuert von Cloudflare. Du siehst davon nichts.
|
||
|
||
## DNS und IP-Adresse — das ist der entscheidende Teil
|
||
|
||
Hier gibt es zwei verschiedene Szenarien:
|
||
|
||
### Szenario A: Domain bei einem anderen Registrar (z.B. IONOS, Strato, Hetzner)
|
||
|
||
Du hast zwei Möglichkeiten:
|
||
|
||
#### Option 1 — Nameserver umziehen (empfohlen):
|
||
Beim Registrar trägst du statt dessen Nameserver die Cloudflare-Nameserver ein:
|
||
|
||
aria.ns.cloudflare.com
|
||
bob.ns.cloudflare.com
|
||
|
||
Danach verwaltest du alle DNS-Einträge bei Cloudflare. Cloudflare kennt dann deine Domain vollständig und stellt automatisch ein SSL-Zertifikat aus. Keine IP-Adresse nötig — Cloudflare Pages bekommt einfach einen CNAME-Eintrag wie:
|
||
|
||
www → dein-projekt.pages.dev
|
||
|
||
#### Option 2 — Nur einen CNAME/A-Record setzen (ohne Nameserver-Wechsel):
|
||
Beim Registrar trägst du einen CNAME auf dein-projekt.pages.dev ein. Cloudflare Pages erkennt die Domain und stellt trotzdem ein Zertifikat aus — dauert aber etwas länger zur Verifizierung.
|
||
|
||
### Szenario B: Domain direkt bei Cloudflare registriert
|
||
|
||
Dann ist alles von Anfang an in einem Dashboard, kein Umzug nötig.
|
||
|
||
Konkret: So funktioniert die Weiterleitung
|
||
|
||
Es gibt keine neue feste IP-Adresse im klassischen Sinne. Cloudflare Pages arbeitet mit einem globalen CDN-Netzwerk — deine Seite liegt auf Hunderten von Servern weltweit. Der DNS-Eintrag zeigt auf einen Cloudflare-CNAME, Cloudflare liefert dann vom nächstgelegenen Rechenzentrum aus.
|
||
|
||
Der Besucher tippt www.iwz-ferienwohnungen.de → DNS löst auf Cloudflare-Server auf → Cloudflare liefert deine statische Seite aus → HTTPS ist dabei immer aktiv.
|
||
|
||
# Praktischer Ablauf beim Umzug
|
||
Cloudflare-Account anlegen (kostenlos)
|
||
Domain dort hinzufügen → Cloudflare scannt bestehende DNS-Einträge automatisch
|
||
Beim Registrar die Nameserver auf Cloudflare-Nameserver umstellen (einmalig, ~10 Minuten Aufwand)
|
||
Propagation: 1–24 Stunden, meist unter 1 Stunde
|
||
In Cloudflare Pages dein Hugo-Projekt verknüpfen (GitHub-Repo auswählen)
|
||
Eigene Domain in Pages eintragen → CNAME wird automatisch gesetzt → SSL-Zertifikat wird sofort ausgestellt
|
||
|
||
Danach läuft alles von selbst — das Zertifikat verlängert sich alle 90 Tage automatisch, du wirst nicht mal benachrichtigt.
|
||
|
||
# Wo ist die Domain iwz-ferienwohnungen.de aktuell registriert?
|
||
|
||
## Ablauf IONOS
|
||
|
||
Nameserver-Wechsel bei IONOS zu Cloudflare
|
||
### Schritt 1: Cloudflare-Account anlegen und Domain hinzufügen
|
||
|
||
Auf cloudflare.com kostenlos registrieren, dann „Add a Site" → iwz-ferienwohnungen.de eingeben. Cloudflare liest die bestehenden DNS-Einträge von IONOS automatisch aus und importiert sie. Du siehst danach eine Liste — meist sind alle wichtigen Einträge (MX für E-Mail, A-Record, etc.) schon korrekt übernommen.
|
||
|
||
### Schritt 2: Nameserver bei IONOS umstellen
|
||
|
||
Im IONOS-Kontrollzentrum:
|
||
|
||
Domains & SSL → Domain auswählen → Nameserver → "Nameserver ändern"
|
||
|
||
Dort trägst du die beiden Cloudflare-Nameserver ein, die dir Cloudflare anzeigt (die sind pro Account individuell, z.B. aria.ns.cloudflare.com und bob.ns.cloudflare.com).
|
||
|
||
Wichtig bei IONOS: IONOS fragt manchmal nach, ob du „externe Nameserver" verwenden willst und warnt, dass deren DNS-Verwaltung dann deaktiviert wird. Das ist korrekt und gewollt — ab dann läuft alles über Cloudflare.
|
||
|
||
### Schritt 3: Warten
|
||
|
||
Propagation dauert bei IONOS erfahrungsgemäß 30 Minuten bis 4 Stunden. Cloudflare schickt dir eine E-Mail sobald die Verifizierung erfolgreich war.
|
||
|
||
## Was mit IONOS bleibt
|
||
|
||
IONOS bleibt weiterhin dein Domain-Registrar — das ist wichtig zu verstehen. Du verlängerst die Domain weiterhin bei IONOS, zahlst dort die Jahresgebühr. Nur die DNS-Verwaltung und das SSL-Zertifikat wandern zu Cloudflare.
|
||
|
||
## E-Mail-Adressen — aufpassen!
|
||
|
||
Falls über IONOS auch E-Mail-Adressen laufen (z.B. info@iwz-ferienwohnungen.de), dann müssen die MX-Einträge beim Import in Cloudflare korrekt übernommen werden. Cloudflare importiert die normalerweise automatisch, aber das solltest du einmal kontrollieren bevor du den Nameserver-Wechsel machst. Die E-Mail funktioniert dann wie bisher — Cloudflare leitet den Mail-Verkehr nur weiter, hostet ihn nicht selbst.
|
||
|
||
# Zusammenfassung des gesamten Stacks (alt, Cloudflare)
|
||
Domain-Registrar: IONOS (bleibt so)
|
||
DNS + SSL: Cloudflare (kostenlos)
|
||
Hosting: Cloudflare Pages (kostenlos)
|
||
Code/Content: GitHub Repository (kostenlos)
|
||
Buchungskalender: webplanner.de (bleibt so, extern)
|
||
|
||
Laufende Kosten danach: *nur noch die Domain-Verlängerung bei IONOS* (~10–15 € pro Jahr).
|