Frecuentemente publicamos actualizaciones de nuestra documentación. Es posible que la traducción de esta página esté en curso. Para conocer la información más actual, visita la documentación en inglés. Si existe un problema con las traducciones en esta página, por favor infórmanos.

Esta versión de GitHub Enterprise se discontinuará el Esta versión de GitHub Enterprise se discontinuó el 2020-08-20. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener un mejor desempeño, más seguridad y nuevas características, actualiza a la última versión de GitHub Enterprise. Para obtener ayuda con la actualización, contacta al soporte de GitHub Enterprise.

Versión del artículo: Enterprise Server 2.18

Cluster network configuration

GitHub Enterprise Server clustering relies on proper DNS name resolution, load balancing, and communication between nodes to operate properly.

En este artículo

Network considerations

The simplest network design for Clustering is to place the nodes on a single LAN. If a redundant cluster must span across subnets, then appropriate routes should be available between subnets and latency should be less than 1ms.

Application ports for end users

Application ports provide web application and Git access for end users.

PortDescriptionEncrypted
22/TCPGit over SSHYes
25/TCPSMTPRequires STARTTLS
80/TCPHTTPNo
(When SSL is enabled this port redirects to HTTPS)
443/TCPHTTPSYes
9418/TCPSimple Git protocol port
(Disabled in private mode)
No

Administrative ports

Administrative ports are not required for basic application use by end users.

PortDescriptionEncrypted
ICMPICMP PingNo
122/TCPAdministrative SSHYes
161/UDPSNMPNo
8080/TCPManagement Console HTTPNo
(When SSL is enabled this port redirects to HTTPS)
8443/TCPManagement Console HTTPSYes

Cluster communication ports

If a network level firewall is in place between nodes, these ports will need to be accessible. The communication between nodes is not encrypted. These ports should not be accessible externally.

PortDescription
1336/TCPInternal API
3033/TCPInternal SVN access
3037/TCPInternal SVN access
3306/TCPMySQL
4486/TCPGovernor access
5115/TCPStorage backend
5208/TCPInternal SVN access
6379/TCPRedis
8001/TCPGrafana
8090/TCPInternal GPG access
8149/TCPGitRPC fileserver access
8300/TCPConsul
8301/TCPConsul
8302/TCPConsul
9000/TCPGit Daemon
9102/TCPPages fileserver
9105/TCPLFS server
9200/TCPElasticsearch
9203/TCPSemantic code service
9300/TCPElasticsearch
11211/TCPMemcache
161/UDPSNMP
8125/UDPStatsd
8301/UDPConsul
8302/UDPConsul
25827/UDPCollectd

Configuring a load balancer

We recommend an external TCP-based load balancer that supports the PROXY protocol to distribute traffic across nodes. Consider these load balancer configurations:

  • TCP ports (shown below) should be forwarded to nodes running the web-server service. These are the only nodes that serve external client requests.
  • Sticky sessions shouldn't be enabled.

Advertencia: cuando se termina una conexión HTTPS en un balanceador de carga, las solicitudes de éste hacia GitHub Enterprise Server necesitarán utilizar HTTPS. Bajar la conexión de categoría a HTTP no es compatible.

Handling client connection information

Because client connections to the cluster come from the load balancer, the client IP address can be lost. To properly capture the client connection information, additional consideration is required.

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 balancear la carga de los puertos HTTP y HTTPS usando el encabezado X-Forwarded-For.

Advertencia de seguridad: Cuando estén habilitados el soporte de PROXY o el redireccionamiento de HTTP, es muy importante que ningún tráfico externo pueda llegar directamente a los aparatos del GitHub Enterprise Server. Si el tráfico externo no se bloquea correctamente, las direcciones IP de origen se pueden falsificar.

Enabling PROXY support on GitHub Enterprise Server

We strongly recommend enabling PROXY support for both your instance and the load balancer.

  • For your instance, use this command:

    $ ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply
  • For the load balancer, use the instructions provided by your vendor.

    Mapeos de puertos de protocolo TCP de PROXY
Puerto fuentePuerto de destinoDescripción del servicio
2223Git sobre SSH
8081HTTP
443444HTTPS
80808081Consola de gestión HTTP
84438444Consola de gestión de HTTPS
94189419Git

Enabling X-Forwarded-For support on GitHub Enterprise Server

Usa 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.

To enable the X-Fowarded-For header, use this command:

$ ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply
Mapeos de puertos de protocolo TCP para usar sin soporte de PROXY
Puerto fuentePuerto de destinoDescripción del servicio
2222Git sobre SSH
2525SMTP
8080HTTP
443443HTTPS
80808080Consola de gestión HTTP
84438443Consola de gestión de HTTPS

Configuring Health Checks

Health checks allow a load balancer to stop sending traffic to a node that is not responding if a pre-configured check fails on that node. If a cluster node fails, health checks paired with redundant nodes provides high availability.

Configura el balanceador de carga para verificar una de estas URL:

  • https://HOSTNAME/status si HTTPS está habilitado (por defecto)
  • http://HOSTNAME/status si HTTPS está inhabilitado

La verificación arrojará el código de estado 200 (OK) si el nodo es correcto y está disponible para responder a las solicitudes del usuario final.

Nota: cuando el aplicativo se encuentre en modo de mantenimiento, la URL https://HOSTNAME/status devolverá un código de estado 503 (Servicio no disponible). Para obtener más información, consulta "Habilitar y programar el modo mantenimiento."

DNS Requirements

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 subdominio está habilitado, un registro comodín adicional (*.HOSTNAME) también se debería resolver con el balanceador de carga. Para obtener más información, consulta "Habilitar el aislamiento de subdominio."

Pregunta a una persona

¿No puedes encontrar lo que estás buscando?

Contáctanos