Artikelversion: Enterprise Server 2.17
Cluster network configuration
GitHub Enterprise Server Clustering basiert auf der richtigen DNS-Namensauflösung, dem Lastausgleich und der Kommunikation zwischen den Knoten, um ordnungsgemäß zu funktionieren.
Grundlegendes zu Netzwerken
Das einfachste Netzwerkdesign für Clustering besteht darin, die Knoten in einem einzelnen LAN zu platzieren. Wenn ein redundanter Cluster mehrere Subnetze abdecken muss, sollten zwischen den Subnetzen entsprechende Routen verfügbar sein. Zudem sollte die Latenz kleiner als 1 ms sein.
Anwendungsports für Endbenutzer
Mit Anwendungsports können Endbenutzer auf Webanwendungen und Git zugreifen.
| Port | Beschreibung | Verschlüsselt |
|---|---|---|
| 22/TCP | Git über SSH | Ja |
| 25/TCP | SMTP | Erfordert STARTTLS |
| 80/TCP | HTTP | Nein (Wenn SSL aktiviert ist, leitet dieser Port Elemente an HTTPS weiter) |
| 443/TCP | HTTPS | Ja |
| 9418/TCP | Einfacher Git-Protokollport (Im privaten Modus deaktiviert) | Nein |
Verwaltungsports
Verwaltungsports sind für die einfache Verwendung von Anwendungen durch Endbenutzer nicht erforderlich.
| Port | Beschreibung | Verschlüsselt |
|---|---|---|
| ICMP | ICMP Ping | Nein |
| 122/TCP | Verwaltungs-SSH | Ja |
| 161/UDP | SNMP | Nein |
| 8080/TCP | HTTP für Managementkonsole | Nein (Wenn SSL aktiviert ist, leitet dieser Port Elemente an HTTPS weiter) |
| 8443/TCP | HTTPS für Managementkonsole | Ja |
Clusterkommunikationsports
Wenn sich zwischen Knoten eine Firewall auf Netzwerkebene befindet, müssen diese Ports zugänglich sein. Die Kommunikation zwischen Knoten ist nicht verschlüsselt. Diese Ports sollten extern nicht zugänglich sein.
| Port | Beschreibung |
|---|---|
| 1336/TCP | Interne API |
| 3033/TCP | Interner SVN-Zugriff |
| 3037/TCP | Interner SVN-Zugriff |
| 3306/TCP | MySQL |
| 4486/TCP | Governor-Zugriff |
| 5115/TCP | Storage-Back-End |
| 5208/TCP | Interner SVN-Zugriff |
| 6379/TCP | Redis |
| 8001/TCP | Grafana |
| 8090/TCP | Interner GPG-Zugriff |
| 8149/TCP | GitRPC-Dateiserverzugriff |
| 8300/TCP | Consul |
| 8301/TCP | Consul |
| 8302/TCP | Consul |
| 9000/TCP | Git-Daemon |
| 9102/TCP | Pages-Dateiserver |
| 9105/TCP | LFS-Server |
| 9200/TCP | ElasticSearch |
| 9203/TCP | Dienst für semantischen Code |
| 9300/TCP | ElasticSearch |
| 11211/TCP | Memcache |
| 161/UDP | SNMP |
| 8125/UDP | Statsd |
| 8301/UDP | Consul |
| 8302/UDP | Consul |
| 25827/UDP | Collectd |
Load-Balancer konfigurieren
Sie sollten einen externen TCP-basierten Load-Balancer verwenden, der das PROXY-Protokoll unterstützt, um den Traffic auf die Knoten zu verteilen. Beachten Sie die folgenden Load-Balancer-Konfigurationen:
- TCP-Ports (siehe unten) sollten an Knoten weitergeleitet werden, auf denen der Dienst
web-serverausgeführt wird. Dies sind die einzigen Knoten, die externe Clientanfragen verarbeiten. - Sticky Sessions sollten nicht aktiviert werden.
Warnung: Wenn HTTPS-Verbindungen auf einem Load-Balancer beendet werden, müssen die vom Load-Balancer an GitHub Enterprise Server gesendeten Anforderungen ebenfalls HTTPS verwenden. Das Downgraden der Verbindung auf HTTP wird nicht unterstützt.
Clientverbindungsinformationen verarbeiten
Da Clientverbindungen zum Cluster vom Load-Balancer stammen, kann die Client-IP-Adresse verloren gehen. Zum entsprechenden Erfassen der Clientverbindungsinformationen sind zusätzliche Überlegungen nötig.
Wenn Dein Load-Balancer das PROXY-Protokoll unterstützen kann, wird dringend empfohlen, es zu implementieren. Wenn keine PROXY-Unterstützung verfügbar ist, kann auch mithilfe des Headers X-Forwarded-For der Lastenausgleich auf den HTTP- und HTTPS-Ports vorgenommen werden.
Sicherheitswarnung: Wenn entweder die PROXY-Unterstützung oder die HTTP-Weiterleitung aktiviert ist, ist es von entscheidender Bedeutung, dass kein externer Traffic die GitHub Enterprise Server-Appliances direkt erreichen kann. Wenn der externe Traffic nicht ordnungsgemäß blockiert wird, kann die IP-Quelladresse gefälscht werden.
PROXY-Unterstützung auf GitHub Enterprise Server aktivieren
Es wird dringend empfohlen, die PROXY-Unterstützung für Ihre Instanz und für den Load-Balancer zu aktivieren.
-
Führen Sie für Ihre Instanz den folgenden Befehl aus:
$ ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply -
Verwenden Sie für den Load-Balancer die von Ihrem Anbieter bereitgestellten Anweisungen.
PROXY-Protokoll – TCP-Portzuordnungen
| Quellport | Zielport | Dienstbeschreibung |
|---|---|---|
| 22 | 23 | Git über SSH |
| 80 | 81 | HTTP |
| 443 | 444 | HTTPS |
| 8080 | 8081 | HTTP für Managementkonsole |
| 8443 | 8444 | HTTPS für Managementkonsole |
| 9418 | 9419 | Git |
X-Forwarded-For-Unterstützung für GitHub Enterprise Server aktivieren
Verwende das Protokoll „X-Forwarded-For“ nur dann, wenn das PROXY-Protokoll nicht verfügbar ist. Der Header X-Forwarded-For funktioniert nur mit HTTP und HTTPS. Die für Git-Verbindungen über SSH gemeldete IP-Adresse zeigt die Load-Balancer-IP.
Führen Sie zum Aktivieren des Headers X-Fowarded-For den folgenden Befehl aus:
$ ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-applyProtokoll – TCP-Portzuordnungen für die Verwendung ohne PROXY-Unterstützung
| Quellport | Zielport | Dienstbeschreibung |
|---|---|---|
| 22 | 22 | Git über SSH |
| 25 | 25 | SMTP |
| 80 | 80 | HTTP |
| 443 | 443 | HTTPS |
| 8080 | 8080 | HTTP für Managementkonsole |
| 8443 | 8443 | HTTPS für Managementkonsole |
Zustandsprüfungen konfigurieren
Zustandsprüfungen ermöglichen einem Load-Balancer, das Senden von Traffic an einen nicht antwortenden Knoten zu stoppen, wenn eine vorkonfigurierte Prüfung auf diesem Knoten fehlschlägt. Wenn ein Clusterknoten fehlschlägt, bieten die mit den redundanten Knoten gekoppelten Zustandsprüfungen Hochverfügbarkeit.
Konfiguriere den Load-Balancer, um eine der folgenden URLs zu überprüfen:
https://HOSTNAME/statusbei aktiviertem HTTPS (Standard)http://HOSTNAME/statusbei deaktiviertem HTTPS
Bei der Überprüfung wird der Statuscode 200 (OK) zurückgegeben, wenn der Knoten fehlerfrei ist und zum Beantworten von Endbenutzeranforderungen verfügbar ist.
Hinweis: Wenn sich die Appliance im Wartungsmodus befindet, gibt die https://HOSTNAME/status URL den Statuscode 503 (Dienst nicht verfügbar) zurück. Weitere Informationen findest Du unter „Wartungsmodus aktivieren und planen“.
DNS-Anforderungen
DNS-Nachschlagevorgänge für den GitHub Enterprise Server-Hostnamen sollten im Load-Balancer aufgelöst werden. Es wird empfohlen, dass Du die Subdomain-Isolation aktivierst. Bei aktivierter Subdomain-Isolation sollte ein zusätzlicher Platzhaltereintrag (*.HOSTNAME) ebenfalls im Load-Balancer aufgelöst werden. Weitere Informationen findest Du unter „Subdomain-Isolation aktivieren“.