fepli selbst hosten
Die meisten Organisationen nutzen eine Instanz, die fepli hostet. Dann gibt es nichts zu betreiben, und nur Ihre Domain richten Sie selbst ein.
Dieser Bereich richtet sich an Integrator:innen, die fepli für eine oder mehrere Organisationen auf der eigenen Infrastruktur betreiben. Er erklärt, woraus eine Instanz besteht, wie Sie sie konfigurieren und wie Sie den ersten Admin anlegen. PHP-Kenntnisse brauchen Sie nicht, Docker, DNS und Umgebungsvariablen sollten Ihnen aber vertraut sein.
Was Sie bekommen
fepli kommt als Docker-Image, nicht als Quellcode. Das Image enthält die ganze Anwendung: die öffentliche Website mit den Angeboten, das Admin-Panel unter /admin, das CMS unter /cms und die REST API unter /api.
Sie betreiben es neben MariaDB und Redis, auf Wunsch mit Varnish davor, und konfigurieren alles mit Umgebungsvariablen. Sie bauen nichts selbst, und im Container gibt es nichts zu installieren.
Das Selbst-Hosting von fepli ist eine Enterprise-Funktion. Das Image ist privat: fepli gibt Ihnen einen Benutzernamen und ein Token, um es zu laden. Schreiben Sie an support@fepli.de, um beides zu erhalten.
Woraus eine Instanz besteht
Eine Instanz ist das fepli-Image, dreimal gestartet mit jeweils einer anderen Aufgabe, dazu zwei Dienste und ein optionaler Cache:
Dasselbe Image läuft als Web, Worker und Cron. Wählen Sie einen Teil aus, um seine Aufgabe zu sehen.
| Teil | Aufgabe | Womit es läuft |
|---|---|---|
| Web | liefert die Website, das Admin-Panel, das CMS und die API aus | das fepli-Image mit seinem Standardstart |
| Worker | verschickt E-Mails, erzeugt Exporte und Belege, teilt Plätze per Los zu und führt die übrigen Aufträge aus, die länger dauern als eine Seitenanfrage | das fepli-Image mit IS_WORKER=1 |
| Cron | führt zeitgesteuerte Aufgaben aus: Erinnerungen, Fristen und das Löschen von Daten, deren Aufbewahrungsfrist abgelaufen ist | das fepli-Image, das jede Minute php bin/console contao:cron ausführt |
| MariaDB | enthält alle Daten: Angebote, Konten, Anmeldungen, Belege und die CMS-Seiten | MariaDB 11.2 oder neuer. Die Beispiele verwenden 12.3. |
| Redis | enthält die Warteschlange der Hintergrundaufträge, die Sessions, die Sperren und den Cache der Einstellungen | Redis 8 mit eingeschalteter Persistenz |
| Varnish (optional) | legt Seiten vor dem Web-Container im Cache ab. fepli versieht jede Seite mit Tags für das, was sie zeigt, und leert genau diese Seiten, wenn sich die Daten ändern. | das Varnish-Image von fepli, ghcr.io/ferienpass/varnish |
Der Web-Container spricht kein HTTPS, Varnish ebenso wenig. Deshalb beendet ein Proxy von Ihnen TLS davor: Caddy, Traefik, nginx oder ein Load Balancer. Eine Anfrage nimmt diesen Weg:
Mit oder ohne Varnish
fepli arbeitet mit und ohne Varnish gleich. Der Unterschied ist, wie oft der Web-Container eine Seite aufbauen muss:
Die meisten Seitenaufrufe der öffentlichen Website, etwa die Angebotsseiten, kommen aus dem Cache. Das ist sinnvoll, wenn viele Familien gleichzeitig die Website nutzen, zum Beispiel am ersten Tag, an dem sich Familien anmelden können.
Jeder Seitenaufruf erreicht den Web-Container. Das ist weniger aufwendig zu betreiben und reicht für eine kleine Organisation, eine Staging-Instanz oder den eigenen Rechner.
Sie entscheiden mit einer Variable: Ist VARNISH_HOST leer, gibt es kein Varnish, und fepli sendet keine Purge-Anfragen. Varnish können Sie später ergänzen: Starten Sie es, richten Sie Ihren Proxy darauf aus und setzen Sie VARNISH_HOST.
Nur das Varnish von fepli legt Seiten von fepli im Cache ab. fepli teilt ihm
die Dauer in einem eigenen Header mit und kennzeichnet diese Seiten für alle
anderen als private. Ein CDN oder Proxy vor fepli speichert deshalb nichts
davon. Ein anderer Cache kann damit auch nicht an die Stelle von Varnish
treten.
Voraussetzungen
Für einen einzelnen Server genügt Docker mit Compose v2. Kubernetes, Nomad, Dokploy oder Coolify funktionieren genauso: Sie führen dasselbe Image mit denselben Variablen aus.
Das Image ist für linux/amd64 gebaut. Auf einem Mac mit Apple Silicon führt Docker es per Emulation aus, was zum Ausprobieren reicht.
Sie verwalten ihr DNS und haben TLS-Zertifikate dafür. Meist bezieht Ihr Proxy sie von Let's Encrypt.
Er darf für die konfigurierte Absenderadresse Mails versenden. fepli verschickt Anmeldelinks, Bestätigungen und Zulassungsbescheide per E-Mail. Ohne SMTP-Server kann sich niemand anmelden.
Sie sichern die Datenbank und die hochgeladenen Dateien. Siehe Produktivbetrieb.
Zwei Wege zur Einrichtung
Entscheiden Sie zuerst, ob eine Installation eine Organisation oder mehrere bedient: Ein oder mehrere Mandanten. Beide Varianten verwenden dieselbe Konfiguration. Danach haben Sie die Wahl:
Das Image auf Ihrem eigenen Rechner, mit Docker Compose. Sie eignet sich, um fepli auszuprobieren, Kolleg:innen zu schulen oder ein Update zu proben. Lokal einrichten
Dasselbe Image auf einem Server, hinter TLS, mit persistenten Volumes, Backups und einem Ablauf für Updates. Zum Produktivbetrieb
Wer was übernimmt
| fepli | Sie |
|---|---|
| baut und veröffentlicht das Image, einschließlich der Sicherheitsupdates für alles darin | betreiben die Container und die drei Dienste |
| veröffentlicht das Varnish-Image mit seiner Konfiguration, falls Sie es verwenden | sorgen für TLS, DNS und den Mailversand |
| dokumentiert im Changelog, was sich in einem Release ändert | sichern die Daten und laden neue Images; das Image migriert die Datenbank beim Start |
| beantwortet Fragen unter support@fepli.de | überwachen die Instanz und halten die Dienste aktuell |