Skip to main content

Esta versão do GitHub Enterprise foi descontinuada em 2022-10-12. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Configuração de rede de cluster

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

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.

Portas de aplicativo para usuários finais

As portas de aplicativo fornecem aplicativos da web e acesso dos usuários finais ao Git.

PortaDescriçãoCriptografado
22/TCPGit em SSHSim
25/TCPSMTPRequer STARTTLS
80/TCPHTTPNo
(Quando o SSL está habilitado, essa porta é redirecionada para HTTPS)
443/TCPHTTPSSim
9418/TCPPorta de protocolo simples do Git
(Desabilitada no modo privado)
No

Portas administrativas

Não é preciso haver portas administrativas para os usuários finais aproveitarem os recursos básicos do aplicativo.

PortaDescriçãoCriptografado
ICMPPing ICMPNo
122/TCPSSH administrativaSim
161/UDPSNMPNo
8080/TCPHTTP de console de gerenciamentoNo
(Quando o SSL está habilitado, essa porta é redirecionada para HTTPS)
8443/TCPHTTPS de console de gerenciamentoSim

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.

PortaDescrição
1336/TCPAPI Interna
3033/TCPAcesso SVN interno
3037/TCPAcesso SVN interno
3306/TCPMySQL
4486/TCPAcesso do controlador
5115/TCPBack-end de armazenamento
5208/TCPAcesso SVN interno
6379/TCPRedis
8001/TCPGrafana
8090/TCPAcesso GPG interno
8149/TCPAcesso GitRPC ao servidor de arquivos
8300/TCPConsul
8301/TCPConsul
8302/TCPConsul
9000/TCPGit Daemon
9102/TCPServidor de arquivos do Pages
9105/TCPServidor LFS
9200/TCPElasticsearch
9203/TCPServiço de código semântico
9300/TCPElasticsearch
11211/TCPMemcache
161/UDPSNMP
8125/UDPStatsd
8301 (UDP)Consul
8302 (UDP)Consul
25827/UDPCollectd

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 origemPorta de destinoDescrição do serviço
2223Git em SSH
8081HTTP
443444HTTPS
80808081HTTP de console de gerenciamento
84438444HTTPS de console de gerenciamento
94189419Git

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 só funciona com HTTP e HTTPS. O endereço IP informado para conexões Git por SSH mostrará o IP do balanceador de carga.

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 origemPorta de destinoDescrição do serviço
2222Git em SSH
2525SMTP
8080HTTP
443443HTTPS
80808080HTTP de console de gerenciamento
84438443HTTPS 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 uma destas URLs:

  • https://HOSTNAME/status se o HTTPS estiver habilitado (padrão)
  • http://HOSTNAME/status se 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".

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 "Como habilitar o isolamento de subdomínio".