Consideraciones de 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.
Para contar con alta disponibilidad, la latencia entre la red con los nodos activos y la red con los pasivos debe ser de menos de 70 milisegundos. No te recomendamos configurar una firewall entre las dos redes.
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.
| Port (Puerto) | Descripción | Cifrado |
|---|---|---|
| 22/TCP | Git sobre SSH | Sí |
| 25/TCP | SMTP | Requiere STARTTLS |
| 80/TCP | HTTP | No (Cuando SSL está habilitado, este puerto redirige a HTTPS) |
| 443/TCP | HTTPS | Sí |
| 9418/TCP | Puerto de protocolo de Git simple (Inhabilitado en modo privado) | No |
Puertos administrativos
No se requieren puertos administrativos para el uso de la aplicación básica por parte de los usuarios finales.
| Port (Puerto) | Descripción | Cifrado |
|---|---|---|
| ICMP | Ping de ICMP | No |
| 122/TCP | SSH administrativo | Sí |
| 161/UDP | SNMP | No |
| 8080/TCP | Consola de gestión HTTP | No (Cuando SSL está habilitado, este puerto redirige a HTTPS) |
| 8443/TCP | Consola de gestión de HTTPS | Sí |
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.
| Port (Puerto) | Descripción |
|---|---|
| 1336/TCP | API interna |
| 3033/TCP | Acceso SVN interno |
| 3037/TCP | Acceso SVN interno |
| 3306/TCP | MySQL |
| 4486/TCP | Acceso del gobernador |
| 5115/TCP | Respaldo de almacenamiento |
| 5208/TCP | Acceso SVN interno |
| 6379/TCP | Redis |
| 8001/TCP | Grafana |
| 8090/TCP | Acceso a GPG interno |
| 8149/TCP | Acceso al servidor de archivos de GitRPC |
| 8300/TCP | Consul |
| 8301/TCP | Consul |
| 8302/TCP | Consul |
| 9000/TCP | Git Daemon |
| 9102/TCP | Servidor de archivos de las páginas |
| 9105/TCP | Servidor LFS |
| 9200/TCP | ElasticSearch |
| 9203/TCP | Servicio de código semántico |
| 9300/TCP | ElasticSearch |
| 11211/TCP | Memcache |
| 161/UDP | SNMP |
| 8125/UDP | Statsd |
| 8301/UDP | Consul |
| 8302/UDP | Consul |
| 25827/UDP | Collectd |
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.
Nota: GitHub Enterprise Server es compatible con el protocolo de PROXY V1, el cual no es compatible con los balanceadores 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 fuente | Puerto de destino | Descripción del servicio |
|---|---|---|
| 22 | 23 | Git sobre SSH |
| 80 | 81 | HTTP |
| 443 | 444 | HTTPS |
| 8080 | 8081 | Consola de gestión HTTP |
| 8443 | 8444 | Consola de gestión de HTTPS |
| 9418 | 9419 | Git |
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-Forwarded-For, usa este comando:
$ ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-applyMapeos de puertos de protocolo TCP para usar sin soporte de PROXY
| Puerto fuente | Puerto de destino | Descripción del servicio |
|---|---|---|
| 22 | 22 | Git sobre SSH |
| 25 | 25 | SMTP |
| 80 | 80 | HTTP |
| 443 | 443 | HTTPS |
| 8080 | 8080 | Consola de gestión HTTP |
| 8443 | 8443 | Consola 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/statussi HTTPS está habilitado (por defecto)http://HOSTNAME/statussi 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."