Network considerations
The simplest network design for clustering is to place the nodes on a single LAN. If a cluster must span subnetworks, we do not recommend configuring any firewall rules between the networks. The latency between nodes should be less than 1 millisecond.
Para alta disponibilidade, a latência entre a rede com os nós ativos e a rede com os nós passivos precisa ser inferior a 70 milissegundos. Não recomendamos configurar um firewall entre as duas redes.
Application ports for end users
Application ports provide web application and Git access for end users.
| Port | Description | Encrypted |
|---|---|---|
| 22/TCP | Git over SSH | Yes |
| 25/TCP | SMTP | Requires STARTTLS |
| 80/TCP | HTTP | No (When SSL is enabled this port redirects to HTTPS) |
| 443/TCP | HTTPS | Yes |
| 9418/TCP | Simple Git protocol port (Disabled in private mode) | No |
Administrative ports
Administrative ports are not required for basic application use by end users.
| Port | Description | Encrypted |
|---|---|---|
| ICMP | ICMP Ping | No |
| 122/TCP | Administrative SSH | Yes |
| 161/UDP | SNMP | No |
| 8080/TCP | Management Console HTTP | No (When SSL is enabled this port redirects to HTTPS) |
| 8443/TCP | Management Console HTTPS | Yes |
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.
| Port | Description |
|---|---|
| 1336/TCP | Internal API |
| 3033/TCP | Internal SVN access |
| 3037/TCP | Internal SVN access |
| 3306/TCP | MySQL |
| 4486/TCP | Governor access |
| 5115/TCP | Storage backend |
| 5208/TCP | Internal SVN access |
| 6379/TCP | Redis |
| 8001/TCP | Grafana |
| 8090/TCP | Internal GPG access |
| 8149/TCP | GitRPC file server access |
| 8300/TCP | Consul |
| 8301/TCP | Consul |
| 8302/TCP | Consul |
| 9000/TCP | Git Daemon |
| 9102/TCP | Pages file server |
| 9105/TCP | LFS server |
| 9200/TCP | Elasticsearch |
| 9203/TCP | Semantic code service |
| 9300/TCP | Elasticsearch |
| 11211/TCP | Memcache |
| 161/UDP | SNMP |
| 8125/UDP | Statsd |
| 8301/UDP | Consul |
| 8302/UDP | Consul |
| 25827/UDP | Collectd |
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-serverservice. These are the only nodes that serve external client requests. - Sticky sessions shouldn't be enabled.
Aviso: no término das conexões HTTPS em um balanceador de carga, as solicitações do balanceador de carga para o GitHub Enterprise Server também precisam usar HTTPS. O downgrading da conexão para HTTP não é suportado.
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.
Se o seu balanceador de carga puder apoiá-lo, recomendamos fortemente a implementação do protocolo PROXY. Quando não há suporte a PROXY disponível, também é possível balancear a carga das portas HTTP e HTTPS usando o cabeçalho X-Forwarded-For.
Aviso de segurança: quando o suporte a PROXY ou o encaminhamento HTTP está habilitado, é fundamental que nenhum tráfego externo possa acessar diretamente os dispositivos do GitHub Enterprise Server. Se o tráfego externo não estiver corretamente bloqueado, os endereços IP de origem podem ser forjados.
Enabling PROXY support on GitHub Enterprise Server
We strongly recommend enabling PROXY support for both your instance and the load balancer.
Observação: o GitHub Enterprise Server dá suporte ao Protocolo PROXY V1, que é incompatível com balanceadores de carga de rede da AWS. Se você usar balanceadores de carga de rede da AWS com o GitHub Enterprise Server, não habilite o suporte a PROXY.
-
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.
Mapeamentos das portas TCP PROXY
| Porta de origem | Porta de destino | Descrição do serviço |
|---|---|---|
| 22 | 23 | Git em SSH |
| 80 | 81 | HTTP |
| 443 | 444 | HTTPS |
| 8080 | 8081 | HTTP de console de gerenciamento |
| 8443 | 8444 | HTTPS de console de gerenciamento |
| 9418 | 9419 | Git |
Enabling X-Forwarded-For support on GitHub Enterprise Server
Use o protocolo X-Forwarded-For somente quando o protocolo PROXY não estiver disponível. O cabeçalho X-Forwarded-For só funciona com HTTP e HTTPS. O endereço IP informado para conexões Git por SSH mostrará o IP do balanceador de carga.
To enable the X-Forwarded-For header, use this command:
$ ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-applyMapeamentos de portas TCP para uso sem suporte PROXY
| Porta de origem | Porta de destino | Descrição do serviço |
|---|---|---|
| 22 | 22 | Git em SSH |
| 25 | 25 | SMTP |
| 80 | 80 | HTTP |
| 443 | 443 | HTTPS |
| 8080 | 8080 | HTTP de console de gerenciamento |
| 8443 | 8443 | HTTPS de console de gerenciamento |
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.
Configure o balanceador de carga para verificar uma destas URLs:
https://HOSTNAME/statusse o HTTPS estiver habilitado (padrão)http://HOSTNAME/statusse o HTTPS estiver desabilitado
A verificação retornará o código de status 200 (OK) se o nó estiver íntegro e disponível para solicitações do usuário final do serviço.
Observação: quando o dispositivo estiver no modo de manutenção, a URL https://HOSTNAME/status retornará o código de status 503 (Serviço Indisponível). Para obter mais informações, confira "Como habilitar e agendar o modo de manutenção".
DNS Requirements
Buscas de DNS para o nome de host GitHub Enterprise Server devem se resolver para o balanceador de carga. Recomendamos que você ative o isolamento de subdomínio. Se o isolamento do subdomínio estiver ativado, um registro de curinga adicional (*.HOSTNAME) também será resolvido para o balanceador de carga. Para obter mais informações, confira "Como habilitar o isolamento de subdomínio".