Skip to main content

Esta versión de GitHub Enterprise Server se discontinuó el 2024-07-09. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener rendimiento mejorado, seguridad mejorada y nuevas características, actualice a la versión más reciente de GitHub Enterprise Server. Para obtener ayuda con la actualización, póngase en contacto con el soporte técnico de GitHub Enterprise.

Configuración de la red de agrupaciones

Un clúster de GitHub Enterprise Server requiere una resolución de nombres DNS adecuada, equilibrio de carga y comunicación entre nodos.

¿Quién puede utilizar esta característica?

GitHub determina la idoneidad para la agrupación en clústeres y debe habilitar la configuración de la licencia de la instancia. La agrupación en clústeres conlleva una planeación cuidadosa y una sobrecarga administrativa adicional. Para obtener más información, vea «Acerca de las agrupaciones».

Acerca de las redes de un clúster de GitHub Enterprise Server

Cada nodo del clúster GitHub Enterprise Server debe poder comunicarse con los demás nodos del clúster a través de la red. Puedes revisar los puertos y protocolos necesarios para los usuarios finales, la administración y la comunicación entre nodos. Para distribuir el tráfico entre nodos front-end, GitHub recomienda que configures un equilibrador de carga externo.

Consideraciones sobre la red

El diseño de red más simple para una agrupación es colocar los nodos en una LAN única. Si un clúster debe abarcar subredes, no te recomendamos configurar ninguna regla de firewall entre ellas. La latencia entre nodos debe ser de menos de 1 milisegundo.

La latencia entre los nodos principal y de réplica debe ser inferior a 70 milisegundos. No recomendamos configurar un firewall entre las redes de los nodos.

Puertos de la aplicación para usuarios finales

Los puertos de la aplicación permiten que los usuarios finales accedan a Git y a las aplicaciones web.

PortDescripciónCifrados
22/TCPGit sobre SSH
25/TCPSMTPRequiere STARTTLS
80/TCPHTTP

Cuando SSL está habilitado, este puerto redirige a HTTPS
443/TCPHTTPS
9418/TCPPuerto de protocolo Git simple
(Deshabilitado en modo privado)

Puertos administrativos

No se requieren puertos administrativos para el uso de la aplicación básica por parte de los usuarios finales.

PortDescripciónCifrados
ICMPPing de ICMP
122/TCPSSH administrativo
161/UDPSNMP
8080/TCPConsola de gestión HTTP

Cuando SSL está habilitado, este puerto redirige a HTTPS
8443/TCPConsola de gestión de HTTPS

Puertos de comunicación de agrupación

Si un cortafuego de nivel de red se coloca entre los nodos estos puertos deberán estar accesibles. La comunicación entre los nodos no está cifrada. Estos puertos no deberían estar accesibles externamente.

PortDescripción
1336/TCPAPI Interna
3033/TCPAcceso SVN interno
3037/TCPAcceso SVN interno
3306/TCPMySQL
4486/TCPAcceso del gobernador
5115/TCPBack-end de almacenamiento
5208/TCPAcceso SVN interno
6379/TCPRedis
8001/TCPGrafana
8090/TCPAcceso a GPG interno
8149/TCPAcceso al servidor de archivos de GitRPC
8300/TCPConsul
8301/TCPConsul
8302/TCPConsul
9000/TCPGit Daemon
9102/TCPServidor de archivos de las páginas
9105/TCPServidor LFS
9200/TCPElasticsearch
9203/TCPServicio de código semántico
9300/TCPElasticsearch
11211/TCPMemcache
161/UDPSNMP
8125/UDPStatsd
8301/UDPConsul
8302/UDPConsul
25827/UDPCollectd

Configurar un balanceador de carga

Recomendamos un balanceador de carga externo basado en TCP que respalde el protocolo PROXY para distribuir el tráfico a través de los nodos. Considera estas configuraciones del balanceador de carga:

  • Los puertos TCP (que se muestran a continuación) se deberán reenviar a los nodos que ejecutan el servicio web-server. Estos son los únicos nodos que sirven a las solicitudes de clientes externos.
  • Las sesiones pegajosas no deberían habilitarse.

Advertencia: Cuando se termina una conexión HTTPS en un equilibrador de carga, en las solicitudes de este hacia GitHub Enterprise Server también es necesario usar HTTPS. Bajar la conexión de categoría a HTTP no es compatible.

Manejar información de conexión de clientes

Dado que las conexiones de clientes con el agrupamiento provienen del balanceador de carga, no se puede perder la dirección IP de cliente. Para capturar adecuadamente la información de la conexión de clientes, se requiere una consideración adicional.

Si tu balanceador de carga lo admite, es altamente recomendable implementar el protocolo PROXY. Cuando no está disponible el soporte de PROXY, también se puede equilibrar la carga de los puertos HTTP y HTTPS mediante el encabezado X-Forwarded-For.

Advertencia de seguridad: Cuando está habilitado la compatibilidad con PROXY o el redireccionamiento de HTTP, es muy importante que ningún tráfico externo pueda acceder directamente a los dispositivos de GitHub Enterprise Server. Si el tráfico externo no se bloquea correctamente, las direcciones IP de origen se pueden falsificar.

Habilitar el soporte PROXY en GitHub Enterprise Server

Recomendamos firmemente habilitar el soporte PROXY para tu instancia y el balanceador de carga.

Nota: GitHub Enterprise Server es compatible con el protocolo de PROXY V1, que no es compatible con los equilibradores de carga de red de AWS. Si utilizas balanceadores de carga de red de AWS con GitHub Enterprise Server, no habilites la compatibilidad con el PROXY.

  • Para tu instancia, usa este comando:

    ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply
    
  • Para el balanceador de carga, usa las instrucciones proporcionadas por tu proveedor.

Mapeos de puertos de protocolo TCP de PROXY

Puerto de origenPuerto de destinoDescripción del servicio
2223Git sobre SSH
8081HTTP
443444HTTPS
80808081Consola de gestión HTTP
84438444Consola de gestión de HTTPS
94189419Git

Habilitar el soporte X-Forwarded-For en GitHub Enterprise Server

Use el protocolo X-Forwarded-For solo cuando el protocolo PROXY no esté disponible. El encabezado X-Forwarded-For solo funciona con HTTP y HTTPS. La dirección IP informada para las conexiones de Git a través de SSH mostrarán la IP del balanceador de carga.

Para habilitar el encabezado X-Forwarded-For, use este comando:

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

Mapeos de puertos de protocolo TCP para usar sin soporte de PROXY

Puerto de origenPuerto de destinoDescripción del servicio
2222Git sobre SSH
2525SMTP
8080HTTP
443443HTTPS
80808080Consola de gestión HTTP
84438443Consola de gestión de HTTPS

Configurar la revisión de estado

Las comprobaciones de estado permiten que un balanceador de carga deje de enviar tráfico a un nodo que no responde si una comprobación preconfigurada falla en ese nodo. Si un nodo de agrupación falla, las revisiones de estado emparejadas con nodos redundantes brindan alta disponibilidad.

Configura el equilibrador de carga para comprobar la siguiente dirección URL.

http(s)://HOSTNAME/status

El punto de conexión devolverá el código de estado 200 (correcto) si el nodo es correcto y está disponible para responder a las solicitudes del usuario final. Para obtener más información, vea «Supervisión de una configuración de alta disponibilidad».

Nota: Cuando el dispositivo está en modo de mantenimiento, la dirección URL https://HOSTNAME/status devolverá el código de estado 503 (servicio no disponible). Para obtener más información, vea «Habilitar y programar el modo de mantenimiento».

Requisitos de DNS

Las búsquedas DNS para el nombre del host de GitHub Enterprise Server se deben resolver con el balanceador de carga. Es recomendable que habilites el aislamiento de subdominio. Si el aislamiento de subdominios está habilitado, un registro comodín adicional (*.HOSTNAME) también se debería resolver en el equilibrador de carga. Para obtener más información, vea «Habilitar el aislamiento de subdominio».