Skip to main content

Cette version de GitHub Enterprise Server ne sera plus disponible le 2024-03-07. 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

Un cluster GitHub Enterprise Server nécessite une bonne résolution de noms DNS, un bon équilibrage de charge et une bonne communication entre les nœuds.

Qui peut utiliser cette fonctionnalité ?

GitHub détermine l’éligibilité au clustering et doit activer la configuration de la licence de votre instance. Le clustering nécessite une planification minutieuse et une surcharge administrative supplémentaire. Pour plus d’informations, consultez « À propos du clustering ».

À propos de la mise en réseau d’un cluster GitHub Enterprise Server

Chaque nœud de votre cluster GitHub Enterprise Server doit être en mesure de communiquer avec tous les autres nœuds du cluster sur le réseau. Vous pouvez passer en revue les ports et protocoles requis pour les utilisateurs finaux, l’administration et la communication entre les nœuds. Pour distribuer le trafic entre les nœuds frontaux, GitHub vous recommande de configurer un équilibreur de charge externe.

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 de réplica 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 SSH
25/TCPSMTPNécessite STARTTLS
80/TCPHTTP

Quand SSL est activé, ce port redirige vers HTTPS
443/TCPHTTPS
9418/TCPPort du protocole Git simple
(Désactivé en mode privé)

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 ICMP
122/TCPSSH administratif
161/UDPSNMP
8080/TCPHTTP Management Console

Quand SSL est activé, ce port redirige vers HTTPS
8443/TCPHTTPS Management Console

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 pour vérifier l’URL suivante.

http(s)://HOSTNAME/status

Le point de terminaison retourne le code d’état 200 (OK) si le nœud est sain et disponible pour les requêtes de l’utilisateur final. Pour plus d’informations, consultez « Surveillance d’une configuration de haute disponibilité ».

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 de 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 ».