Dieses Ticket fokussiert auf die Einrichtung des vorgeschalteten Reverse Proxy, um den Traffic zur Wikibase-Instanz korrekt zu managen.
Was getan werden muss
Der bestehende Reverse Proxy (z.B. Nginx oder ein dedizierter Load Balancer/Reverse Proxy) muss konfiguriert werden, um Anfragen an die dedizierte Wikibase-Subdomain an den korrekten Backend-Server weiterzuleiten.
- Proxy-Regel erstellen: Es muss eine spezifische Regel für die Wikibase-Subdomain im Reverse Proxy konfiguriert werden.
- Weiterleitung implementieren: Die Regel muss den eingehenden, verschlüsselten Traffic (HTTPS) an die interne IP-Adresse und den Port des Backend-Servers weiterleiten, auf dem die Wikibase-Instanz läuft.
- Header-Anpassungen: Sicherstellen, dass alle notwendigen Header (z.B. X-Forwarded-For, X-Forwarded-Proto) korrekt an das Backend übergeben werden. Dies ist essenziell für die korrekte Protokollierung der Benutzer-IP-Adressen und für die HTTPS-Erkennung durch MediaWiki.
- Cache-Management: Prüfen und ggf. Konfigurieren von Caching-Regeln auf dem Proxy für die Wikibase-Instanz, um die Performance zu optimieren, ohne veraltete Daten auszuliefern.
- Funktionstest: Überprüfung der Ende-zu-Ende-Verbindung von außen bis zur Wikibase-Anwendung.
Warum wir das tun
Die Nutzung eines Reverse Proxy ist entscheidend für Sicherheit, Performance und Architektur der Lösung.
- Zentraler Zugangspunkt: Der Proxy dient als Single Point of Entry und vereinfacht die Verwaltung der öffentlichen Endpunkte und SSL-Zertifikate.
- Lastverteilung und Sicherheit: Durch die Entkopplung der Backend-Server vom Internet erhöht der Proxy die allgemeine Systemsicherheit. Die Konfiguration ermöglicht zudem eine spätere Lastverteilung, sollte die Instanz stark frequentiert werden.
- Korrekte Funktionsweise: Die korrekte Übergabe der Header (v.a. X-Forwarded-Proto) ist notwendig, damit MediaWiki weiß, dass es über HTTPS angesprochen wurde, was für die Generierung korrekter interner Links unerlässlich ist.