Informationen zum Netzwerk für ein GitHub Enterprise Server-Cluster
Jeder Knoten in deinem GitHub Enterprise Server-Cluster muss über das Netzwerk mit allen anderen Knoten im Cluster kommunizieren können. Du kannst die erforderlichen Ports und Protokolle für Endbenutzer*innen, Verwaltung und Kommunikation zwischen den Knoten überprüfen. Um Datenverkehr auf Front-End-Knoten zu verteilen, empfiehlt GitHub die Konfiguration eines externen Lastenausgleichs.
Überlegungen zu Netzwerken
Das einfachste Netzwerkdesign für Clustering besteht darin, die Knoten in einem einzelnen LAN zu platzieren. Wenn ein Cluster mehrere Subnetzwerke abdecken muss, sollten zwischen den Netzwerken keine Firewallregeln konfiguriert werden. Zudem sollte die Latenz kleiner als 1 ms sein.
Die Latenz zwischen primären und Replikatknoten muss kleiner als 70 Millisekunden sein. Es wird nicht empfohlen, eine Firewall zwischen den Netzwerken der Knoten zu konfigurieren.
Anwendungsports für Endbenutzer
Mit Anwendungsports können Endbenutzer auf Webanwendungen und Git zugreifen.
Port | BESCHREIBUNG | Verschlüsselt |
---|---|---|
22/TCP | Git über SSH | |
25/TCP | SMTP | Erfordert STARTTLS |
80/TCP | HTTP | Wenn SSL aktiviert ist, leitet dieser Port Elemente an HTTPS weiter. |
443/TCP | HTTPS | |
9418/TCP | Einfacher Git-Protokollport (Im privaten Modus deaktiviert) |
Verwaltungsports
Verwaltungsports sind für die einfache Verwendung von Anwendungen durch Endbenutzer nicht erforderlich.
Port | BESCHREIBUNG | Verschlüsselt |
---|---|---|
ICMP | ICMP-Ping | |
122/TCP | Verwaltungs-SSH | |
161/UDP | SNMP | |
8080/TCP | HTTP für Managementkonsole | Wenn SSL aktiviert ist, leitet dieser Port Elemente an HTTPS weiter. |
8443/TCP | HTTPS für Managementkonsole |
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 | Speicher-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
Du solltest einen externen TCP-basierten Load-Balancer verwenden, der das PROXY-Protokoll unterstützt, um den Traffic auf die Knoten zu verteilen. Beachte die folgenden Load-Balancer-Konfigurationen:
- TCP-Ports (siehe unten) sollten an Knoten weitergeleitet werden, auf denen der Dienst
web-server
ausgeführt wird. Dies sind die einzigen Knoten, die externe Clientanfragen verarbeiten. - Sticky Sessions sollten nicht aktiviert werden.
Warning
Wenn HTTPS-Verbindungen in einem Lastenausgleich beendet werden, müssen die vom Lastenausgleich 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 X-Forwarded-For
-Headers 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 Datenverkehr 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 deine Instanz und für den Load-Balancer zu aktivieren.
Note
GitHub Enterprise Server unterstützt PROXY Protocol V1, welches nicht mit AWS Network Load Balancers kompatibel ist. Wenn du AWS Network Load Balancers mit GitHub Enterprise Server verwendest, aktiviere nicht die PROXY-Unterstützung.
-
Führe für deine Instanz den folgenden Befehl aus:
ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply
-
Verwende für den Load-Balancer die von deinem 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 X-Forwarded-For
-Protokoll nur, wenn das PROXY-Protokoll nicht verfügbar ist. Der X-Forwarded-For
-Header ist nur mit HTTP und HTTPS kompatibel. Bei Git-Verbindungen über SSH wird als IP-Adresse die des Load Balancers angegeben. In einigen Umgebungen werden Client-IP-Adressen im Überwachungsprotokoll der Instanz möglicherweise fälschlicherweise als 127.0.0.1
angezeigt.
Führe zum Aktivieren des Headers X-Forwarded-For
den folgenden Befehl aus:
ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply
Protokoll – 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 Lastenausgleich, um die folgende URL zu überprüfen.
http(s)://HOSTNAME/status
Der Endpunkt gibt den Statuscode 200
(OK) zurück, wenn der Knoten fehlerfrei ist und zum Beantworten von Endbenutzeranforderungen verfügbar ist. Weitere Informationen findest du unter Überwachen einer Hochverfügbarkeitskonfiguration.
Note
Wenn sich die Anwendung im Wartungsmodus befindet, gibt die URL https://HOSTNAME/status
den Statuscode 503
(Service Unavailable) 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 Lastenausgleich aufgelöst werden. Weitere Informationen findest du unter Subdomain-Isolation aktivieren.