Olá! No momento, esta página ainda está sendo desenvolvida ou traduzida. Para obter as informações mais recentes, acesse a documentação em inglês.
Versão do artigo: Enterprise Server 2.15

Esta versão do GitHub Enterprise será descontinuada em Esta versão do GitHub Enterprise foi descontinuada em 2019-10-16. No patch releases will be made, even for critical security issues. For better performance, improved security, and new features, upgrade to the latest version of GitHub Enterprise. For help with the upgrade, contact GitHub Enterprise support.

Configurar a rede

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

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.

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-apply
Protocol 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:

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). For more information, see "Enabling and scheduling maintenance mode."

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

Pergunte a uma pessoa

Não consegue encontrar o que procura?

Entrar em contato