Versão do artigo: Enterprise Server 2.17
Cluster network configuration
O funcionamento correto do clustering do GitHub Enterprise Server depende da resolução adequada de nome DNS, do balanceamento de carga e da comunicação entre os nós.
Considerações de rede
A composição de rede mais simples para o clustering é deixar os nós em uma única LAN. Se for necessário que um cluster redundante envolva sub-redes, as rotas adequadas devem estar disponíveis entre as sub-redes e a latência deve ser inferior a 1 ms.
Portas de aplicativo para usuários finais
As portas de aplicativo fornecem aplicativos da web e acesso dos usuários finais ao Git.
| Porta | Descrição | Criptografia |
|---|---|---|
| 22/TCP | Git em SSH | Sim |
| 25/TCP | SMTP | Requer STARTTLS |
| 80/TCP | HTTP | Não (com SSL habilitado, essa porta redireciona para HTTPS) |
| 443/TCP | HTTPS | Sim |
| 9418/TCP | Porta de protocolo simples do Git (desabilitada no modo privado) | Não |
Portas administrativas
Não é preciso haver portas administrativas para os usuários finais aproveitarem os recursos básicos do aplicativo.
| Porta | Descrição | Criptografia |
|---|---|---|
| ICMP | Ping ICMP | Não |
| 122/TCP | SSH administrativa | Sim |
| 161/UDP | SNMP | Não |
| 8080/TCP | HTTP de console de gerenciamento | Não (com SSL habilitado, essa porta redireciona para HTTPS) |
| 8443/TCP | HTTPS de console de gerenciamento | Sim |
Portas de comunicação de cluster
Se houver um firewall no nível da rede entre os nós, essas portas terão que estar acessíveis. A comunicação entre os nós não é criptografada, e essas portas não devem ficar acessíveis externamente.
| Porta | Descrição |
|---|---|
| 1336/TCP | API interna |
| 3033/TCP | Acesso SVN interno |
| 3037/TCP | Acesso SVN interno |
| 3306/TCP | MySQL |
| 4486/TCP | Acesso do controlador |
| 5115/TCP | Backend de armazenamento |
| 5208/TCP | Acesso SVN interno |
| 6379/TCP | Redis |
| 8001/TCP | Grafana |
| 8090/TCP | Acesso GPG interno |
| 8149/TCP | Acesso GitRPC ao servidor de arquivos |
| 8300/TCP | Consul |
| 8301/TCP | Consul |
| 8302/TCP | Consul |
| 9000/TCP | Git Daemon |
| 9102/TCP | Servidor de arquivos do Pages |
| 9105/TCP | Servidor LFS |
| 9200/TCP | ElasticSearch |
| 9203/TCP | Serviço 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 um balanceador de carga
É recomendável usar um balanceador de carga baseado em TCP compatível com o protocolo PROXY para distribuir o tráfego entre os nós. Veja estas configurações de balanceador de carga:
- Portas TCP (abaixo) devem ser encaminhadas para nós que executem o serviço
web-server; são os únicos nós que funcionam com solicitações de clientes externos. - Sessões temporárias não devem ser habilitadas.
Warning: When terminating HTTPS connections on a load balancer, the requests from the load balancer to GitHub Enterprise Server also need to use HTTPS. Downgrading the connection to HTTP is not supported.
Informações de conexão do cliente
Como as conexões do cliente com o cluster vêm do balanceador de carga, pode ocorrer a perda do endereço IP do cliente. Para captar as informações de conexão do cliente de maneira adequada, é preciso fazer considerações adicionais.
If your load balancer can support it, we strongly recommend implementing the PROXY protocol. When no PROXY support is available, it is also possible to load balance the HTTP and HTTPS ports using the X-Forwarded-For header.
Security Warning: When either PROXY support or HTTP forwarding is enabled, it is critical that no external traffic can directly reach the GitHub Enterprise Server appliances. If external traffic is not properly blocked, the source IP addresses can be forged.
Habilitar o suporte PROXY no GitHub Enterprise Server
É altamente recomendável ativar o suporte PROXY para sua instância e o balanceador de carga.
-
Na instância, use este comando:
$ ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply -
No balanceador de carga, siga as instruções do seu fornecedor.
PROXY protocol TCP port mappings
| Source port | Destination port | Service description |
|---|---|---|
| 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 |
Habilitar o suporte X-Forwarded-For no GitHub Enterprise Server
Use the X-Forwarded-For protocol only when the PROXY protocol is unavailable. The X-Forwarded-For header only works with HTTP and HTTPS. The IP address reported for Git connections over SSH will show the load balancer IP.
Para habilitar o header X-Fowarded-For, use este comando:
$ ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-applyProtocol TCP port mappings for use without PROXY support
| Source port | Destination port | Service description |
|---|---|---|
| 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 |
Configurar verificações de integridade
As verificações de integridade permitem que um balanceador de carga pare de enviar tráfego para um nó que não responde em caso de falha na verificação pré-configurada do nó em questão. Em caso de falha em um nó do cluster, as verificações de integridade emparelhadas com nós redundantes fornecerão alta disponibilidade.
Configure the load balancer to check one of these URLs:
https://HOSTNAME/statusif HTTPS is enabled (default)http://HOSTNAME/statusif HTTPS is disabled
The check will return status code 200 (OK) if the node is healthy and available to service end-user requests.
Note: When the appliance is in maintenance mode, the https://HOSTNAME/status URL will return status code 503 (Service Unavailable). Para obter mais informações, consulte "Habilitar e programar o modo de manutenção".
Requisitos de DNS
DNS lookups for the GitHub Enterprise Server hostname should resolve to the load balancer. We recommend that you enable subdomain isolation. If subdomain isolation is enabled, an additional wildcard record (*.HOSTNAME) should also resolve to the load balancer. Para obter mais informações, consulte "Habilitar isolamento de subdomínio".