Hallo, Entdecker! An dieser Seite wird aktiv gearbeitet, oder sie wird noch übersetzt. Die neuesten und genauesten Informationen findest Du in unserer englischsprachigen Dokumentation.

Diese Version von GitHub Enterprise wird eingestellt am Diese Version von GitHub Enterprise wurde eingestellt am 2020-05-23. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nimm ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wende Dich an den GitHub Enterprise-Support, um Hilfe beim Upgrade zu erhalten.

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.

Inhalt dieses Artikels

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.

PortBeschreibungVerschlüsselt
22/TCPGit über SSHJa
25/TCPSMTPErfordert STARTTLS
80/TCPHTTPNein
(Wenn SSL aktiviert ist, leitet dieser Port Elemente an HTTPS weiter)
443/TCPHTTPSJa
9418/TCPEinfacher Git-Protokollport
(Im privaten Modus deaktiviert)
Nein

Verwaltungsports

Verwaltungsports sind für die einfache Verwendung von Anwendungen durch Endbenutzer nicht erforderlich.

PortBeschreibungVerschlüsselt
ICMPICMP PingNein
122/TCPVerwaltungs-SSHJa
161/UDPSNMPNein
8080/TCPHTTP für ManagementkonsoleNein
(Wenn SSL aktiviert ist, leitet dieser Port Elemente an HTTPS weiter)
8443/TCPHTTPS für ManagementkonsoleJa

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.

PortBeschreibung
1336/TCPInterne API
3033/TCPInterner SVN-Zugriff
3037/TCPInterner SVN-Zugriff
3306/TCPMySQL
4486/TCPGovernor-Zugriff
5115/TCPStorage-Back-End
5208/TCPInterner SVN-Zugriff
6379/TCPRedis
8001/TCPGrafana
8090/TCPInterner GPG-Zugriff
8149/TCPGitRPC-Dateiserverzugriff
8300/TCPConsul
8301/TCPConsul
8302/TCPConsul
9000/TCPGit-Daemon
9102/TCPPages-Dateiserver
9105/TCPLFS-Server
9200/TCPElasticSearch
9203/TCPDienst für semantischen Code
9300/TCPElasticSearch
11211/TCPMemcache
161/UDPSNMP
8125/UDPStatsd
8301/UDPConsul
8302/UDPConsul
25827/UDPCollectd

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-server ausgefü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
QuellportZielportDienstbeschreibung
2223Git über SSH
8081HTTP
443444HTTPS
80808081HTTP für Managementkonsole
84438444HTTPS für Managementkonsole
94189419Git

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-apply
Protokoll – TCP-Portzuordnungen für die Verwendung ohne PROXY-Unterstützung
QuellportZielportDienstbeschreibung
2222Git über SSH
2525SMTP
8080HTTP
443443HTTPS
80808080HTTP für Managementkonsole
84438443HTTPS 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/status bei aktiviertem HTTPS (Standard)
  • http://HOSTNAME/status bei 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“.

Menschliche Unterstützung einholen

Du kannst das Gesuchte nicht finden?

Kontakt