Sobre a rede para um cluster do GitHub Enterprise Server
Cada nó no cluster do GitHub Enterprise Server precisa ser capaz de se comunicar com todos os outros nós no cluster pela rede. Você pode examinar as portas e protocolos necessários para usuários finais, administração e comunicação entre nós. Para distribuir o tráfego entre nós de front-end, a GitHub recomenda que você configure um balanceador de carga externo.
Considerações de rede
A composição de rede mais simples para o clustering é deixar os nós em uma única LAN. Se um cluster abranger sub-redes, não recomendamos configurar quaisquer regras de firewall entre as redes. A latência entre os nós deve ser inferior a 1 milissegundo.
A latência entre os nós primário e de réplica deve ser inferior a 70 milissegundos. Não recomendamos configurar um firewall entre as duas redes de nós.
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 | Criptografado |
|---|---|---|
| 22/TCP | Git em SSH | |
| 25/TCP | SMTP | Requer STARTTLS |
| 80/TCP | HTTP | Quando o SSL está habilitado, essa porta é redirecionada para HTTPS |
| 443/TCP | HTTPS | |
| 9418/TCP | Porta de protocolo simples do Git (Desabilitada no modo privado) |
Portas administrativas
Não é preciso haver portas administrativas para os usuários finais aproveitarem os recursos básicos do aplicativo.
| Porta | Descrição | Criptografado |
|---|---|---|
| ICMP | Ping ICMP | |
| 122/TCP | SSH administrativa | |
| 161/UDP | SNMP | |
| 8080/TCP | HTTP de console de gerenciamento | Quando o SSL está habilitado, essa porta é redirecionada para HTTPS |
| 8443/TCP | HTTPS de console de gerenciamento |
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 | Back-end 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:
- As portas TCP (mostradas abaixo) devem ser encaminhadas para os nós que executam 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.
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.
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.
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.
Habilitar o suporte PROXY no GitHub Enterprise Server
É altamente recomendável ativar o suporte PROXY para sua instância e o balanceador de carga.
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.
-
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.
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 |
Habilitar o suporte X-Forwarded-For no 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 é compatível somente com HTTP e HTTPS. Para conexões Git via SSH, o endereço IP informado será o do balanceador de carga. Em alguns ambientes, os endereços IP do cliente no log de auditoria da instância podem aparecer incorretamente como 127.0.0.1.
Para habilitar o cabeçalho X-Forwarded-For, use este comando:
ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply
Mapeamentos 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 |
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 o balanceador de carga para verificar a URL a seguir.
http(s)://HOSTNAME/status
O ponto de extremidade 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. Para obter mais informações, confira "Monitorar uma configuração de alta disponibilidade".
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 "Habilitar e programar o modo de manutenção".
Requisitos de DNS
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 "Habilitar isolamento de subdomínio".