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

Configuración de la red de agrupaciones

La agrupación de GitHub Enterprise Server se basa en la resolución de nombre de DNS pertinente, balanceo de carga y comunicación entre los nodos para operar de manera adecuada.

En este artículo

Consideraciones de red

El diseño de red más simple para una agrupación es colocar los nodos en una LAN única. Si una agrupación redundante debe abarcar varias subredes, las rutas apropiadas deben estar disponibles entre las subredes y la latencia debería ser menor que 1ms.

Puertos de la aplicación para usuarios finales

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

PuertoDescripciónCifrado
22/TCPGit sobre SSH
25/TCPSMTPRequiere STARTTLS
80/TCPHTTPNo
(Cuando SSL está habilitado, este puerto redirige a HTTPS)
443/TCPHTTPS
9418/TCPPuerto de protocolo de Git simple
(Inhabilitado en modo privado)
No

Puertos administrativos

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

PuertoDescripciónCifrado
ICMPPing de ICMPNo
122/TCPSSH administrativo
161/UDPSNMPNo
8080/TCPConsola de gestión HTTPNo
(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.

PuertoDescripción
1336/TCPAPI interna
3033/TCPAcceso SVN interno
3037/TCPAcceso SVN interno
3306/TCPMySQL
4486/TCPAcceso del gobernador
5115/TCPRespaldo de almacenamiento
5208/TCPAcceso SVN interno
6379/TCPRedis
8001/TCPGrafana
8090/TCPAcceso a GPG interno
8149/TCPAcceso al servidor de archivos GitRPC
8300/TCPConsul
8301/TCPConsul
8302/TCPConsul
9000/TCPGit Daemon
9102/TCPServidor de archivos de 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 muestra a continuación) deberán ser reenviados 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 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.

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

Habilitar el soporte PROXY en GitHub Enterprise Server

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

  • 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 fuentePuerto 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

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.

Para habilitar el encabezado X-Fowarded-For, usa 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 fuentePuerto de destinoDescripción del servicio
2222Git sobre SSH
2525SMTP
8080HTTP
443443HTTPS
80808080Consola de gestión HTTP
84438443Consola de gestión de HTTPS

Configurar revisiones 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 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."

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