À 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.
La latence entre les nœuds principaux et réplicas doit être inférieure à 70 millisecondes. Il n'est pas recommandé de configurer un pare-feu entre les réseaux des nœuds.
- Ports d’application pour les utilisateurs finaux
- Ports d’administration
- Ports de communication de cluster
Ports d’application pour les utilisateurs finaux
Les ports d’application fournissent un accès à l’application web et à Git pour les utilisateurs finaux.
| Port | Description | Chiffré |
|---|---|---|
| 22/TCP | Git via SSH | |
| 25/TCP | SMTP | Nécessite STARTTLS |
| 80/TCP | HTTP | Quand SSL est activé, ce port redirige vers HTTPS |
| 443/TCP | HTTPS | |
| 9418/TCP | Port 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.
| Port | Description | Chiffré |
|---|---|---|
| ICMP | Ping ICMP | |
| 122/TCP | SSH administratif | |
| 161/UDP | SNMP | |
| 8080/TCP | HTTP Management Console | Quand SSL est activé, ce port redirige vers HTTPS |
| 8443/TCP | HTTPS 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.
| Port | Description |
|---|---|
| 1336/TCP | API interne |
| 3033/TCP | Accès SVN interne |
| 3037/TCP | Accès SVN interne |
| 3306/TCP | MySQL |
| 4486/TCP | Accès Governor |
| 5115/TCP | Back-end de stockage |
| 5208/TCP | Accès SVN interne |
| 6379/TCP | Redis |
| 8001/TCP | Grafana |
| 8090/TCP | Accès GPG interne |
| 8149/TCP | Accès au serveur de fichiers GitRPC |
| 8300/TCP | Consul |
| 8301/TCP | Consul |
| 8302/TCP | Consul |
| 9000/TCP | Démon Git |
| 9102/TCP | Serveur de fichiers Pages |
| 9105/TCP | Serveur LFS |
| 9200/TCP | Elasticsearch |
| 9203/TCP | Service de code sémantique |
| 9300/TCP | Elasticsearch |
| 11211/TCP | Memcache |
| 161/UDP | SNMP |
| 8125/UDP | Statsd |
| 8301/UDP | Consul |
| 8302/UDP | Consul |
| 25827/UDP | Collectd |
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 source | Port de destination | Description du service |
|---|---|---|
| 22 | 23 | Git via SSH |
| 80 | 81 | HTTP |
| 443 | 444 | HTTPS |
| 8080 | 8081 | HTTP Management Console |
| 8443 | 8444 | HTTPS Management Console |
| 9418 | 9419 | Git |
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 source | Port de destination | Description du service |
|---|---|---|
| 22 | 22 | Git via SSH |
| 25 | 25 | SMTP |
| 80 | 80 | HTTP |
| 443 | 443 | HTTPS |
| 8080 | 8080 | HTTP Management Console |
| 8443 | 8443 | HTTPS 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 ».