Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

Cette version de GitHub Enterprise a été abandonnée le 2023-01-18. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Configuration réseau de cluster

Le clustering GitHub Enterprise Server repose sur une résolution de noms DNS, un équilibrage de charge et une communication appropriés entre les nœuds pour fonctionner correctement.

Considérations relatives au réseau

La plus simple conception réseau pour le clustering consiste à placer les nœuds sur un même réseau local. Si un cluster doit englober des sous-réseaux, nous vous déconseillons de configurer des règles de pare-feu entre les réseaux. La latence entre les nœuds doit être inférieure à 1 milliseconde.

Pour la haute disponibilité, la latence entre le réseau comportant les nœuds actifs et le réseau comportant les nœuds passifs doit être inférieure à 70 millisecondes. Nous vous déconseillons de configurer un pare-feu entre les deux réseaux.

Ports d’application pour les utilisateurs finaux

Les ports d’application fournissent un accès à l’application web et à Git pour les utilisateurs finaux.

PortDescriptionChiffré
22/TCPGit via SSHOui
25/TCPSMTPNécessite STARTTLS
80/TCPHTTPNon
(Quand SSL est activé, ce port redirige vers HTTPS)
443/TCPHTTPSOui
9418/TCPPort du protocole Git simple
(Désactivé en mode privé)
Non

Ports d’administration

Les ports d’administration ne sont pas nécessaires dans le cadre d’une utilisation d’application simple de la part des utilisateurs finaux.

PortDescriptionChiffré
ICMPPing ICMPNon
122/TCPSSH administratifOui
161/UDPSNMPNon
8080/TCPHTTP Management ConsoleNon
(Quand SSL est activé, ce port redirige vers HTTPS)
8443/TCPHTTPS Management ConsoleOui

Ports de communication de cluster

Si un pare-feu au niveau du réseau est en place entre les nœuds, ces ports doivent être accessibles. La communication entre les nœuds n’est pas chiffrée. Ces ports ne doivent pas être accessibles en externe.

PortDescription
1336/TCPAPI interne
3033/TCPAccès SVN interne
3037/TCPAccès SVN interne
3306/TCPMySQL
4486/TCPAccès Governor
5115/TCPBack-end de stockage
5208/TCPAccès SVN interne
6379/TCPRedis
8001/TCPGrafana
8090/TCPAccès GPG interne
8149/TCPAccès au serveur de fichiers GitRPC
8300/TCPConsul
8301/TCPConsul
8302/TCPConsul
9000/TCPDémon Git
9102/TCPServeur de fichiers Pages
9105/TCPServeur LFS
9200/TCPElasticsearch
9203/TCPService de code sémantique
9300/TCPElasticsearch
11211/TCPMemcache
161/UDPSNMP
8125/UDPStatsd
8301/UDPConsul
8302/UDPConsul
25827/UDPCollectd

Configuration d’un équilibreur de charge

Nous recommandons un équilibreur de charge TCP externe qui prend en charge le protocole PROXY pour répartir le trafic entre les nœuds. Prenez en considération ces configurations d’équilibreur de charge :

  • Les ports TCP (indiqués ci-dessous) doivent être transférés vers les nœuds exécutant le service web-server. Ce sont les seuls nœuds à traiter les demandes clientes externes.
  • Les sessions persistantes ne doivent pas être activées.

Avertissement : Quand des connexions HTTPS se terminent sur un équilibreur de charge, les demandes de l’équilibreur de charge vers GitHub Enterprise Server doivent également utiliser HTTPS. Le passage de la connexion HTTPS à HTTP n’est pas pris en charge.

Gestion des informations sur les connexions clientes

Sachant que les connexions clientes au cluster proviennent de l’équilibreur de charge, l’adresse IP du client peut être perdue. Pour capturer correctement les informations sur les connexions clientes, il convient de prendre en compte d’autres considérations.

Si votre équilibreur de charge peut le prendre en charge, nous vous recommandons vivement d’implémenter le protocole PROXY. Lorsqu’aucune prise en charge PROXY n’est disponible, il est également possible d’équilibrer la charge des ports HTTP et HTTPS en utilisant l’en-tête X-Forwarded-For.

Avertissement de sécurité : Quand la prise en charge du proxy ou le transfert HTTP sont activés, aucun trafic externe ne doit pouvoir accéder directement aux appliances GitHub Enterprise Server . Si le trafic externe n’est pas correctement bloqué, les adresses IP sources peuvent être falsifiées.

Activation de la prise en charge de PROXY sur GitHub Enterprise Server

Nous vous recommandons vivement d’activer la prise en charge de PROXY pour votre instance et pour l’équilibreur de charge.

Remarque : GitHub Enterprise Server prend en charge le protocole PROXY V1, qui n’est pas compatible avec les équilibreurs de charge réseau AWS. Si vous utilisez des équilibreurs de charge réseau AWS avec GitHub Enterprise Server, n’activez pas la prise en charge de PROXY.

  • Pour votre instance, utilisez cette commande :

    $ ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply
  • Pour l’équilibreur de charge, utilisez les instructions fournies par votre fournisseur.

    Mappages de ports TCP du protocole PROXY

Port sourcePort de destinationDescription du service
2223Git via SSH
8081HTTP
443444HTTPS
80808081HTTP Management Console
84438444HTTPS Management Console
94189419Git

Activation de la prise en charge de X-Forwarded-For sur GitHub Enterprise Server

Utilisez le protocole X-Forwarded-For uniquement lorsque le protocole PROXY n’est pas disponible. L’en-tête X-Forwarded-For fonctionne uniquement avec HTTP et HTTPS. L’adresse IP signalée pour les connexions Git via SSH affiche l’adresse IP de l’équilibreur de charge.

Pour activer l’en-tête X-Forwarded-For, utilisez cette commande :

$ ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply

Mappages de ports TCP de protocole à utiliser sans prise en charge de PROXY

Port sourcePort de destinationDescription du service
2222Git via SSH
2525SMTP
8080HTTP
443443HTTPS
80808080HTTP Management Console
84438443HTTPS Management Console

Configuration des contrôles d’intégrité

Les contrôles d’intégrité permettent à un équilibreur de charge d’arrêter l’envoi de trafic à un nœud qui ne répond pas si une vérification préconfigurée échoue sur ce nœud. Si un nœud de cluster échoue, les contrôles d’intégrité associés à des nœuds redondants offrent une haute disponibilité.

Configurez l’équilibreur de charge de manière à vérifier l’une des URL suivantes :

  • https://HOSTNAME/status si le protocole HTTPS est activé (par défaut)
  • http://HOSTNAME/status si le protocole HTTPS est désactivé

La vérification retourne le code d’état 200 (OK) si le nœud est sain et disponible pour les requêtes de l’utilisateur final.

Remarque : lorsque l’appliance est en mode maintenance, l’URL https://HOSTNAME/status retourne le code de statut 503 (Service indisponible). Pour plus d’informations, consultez « Activation et planification du mode maintenance ».

Configuration requise du DNS

Les recherches DNS pour le nom d’hôte GitHub Enterprise Server doivent être résolues sur l’équilibreur de charge. Nous vous recommandons d’activer l’isolation des sous-domaines. Si l’isolation des sous-domaines est activée, un enregistrement générique supplémentaire (*.HOSTNAME) doit également être résolu sur l’équilibreur de charge. Pour plus d’informations, consultez « Activation de l’isolation de sous-domaine ».