GitHub Enterprise Server 클러스터의 네트워킹 정보
GitHub Enterprise Server 클러스터의 각 노드는 네트워크를 통해 클러스터의 다른 모든 노드와 통신할 수 있어야 합니다. 최종 사용자, 관리 및 노드 간의 통신에 필요한 포트 및 프로토콜을 검토할 수 있습니다. GitHub에서는 프런트 엔드 노드 간에 트래픽을 분산하기 위해 외부 부하 분산 장치를 구성할 것을 권장합니다.
네트워크 고려 사항
클러스터링을 위한 가장 간단한 네트워크 디자인은 단일 LAN에 노드를 배치하는 것입니다. 클러스터가 여러 서브 네트워크에 걸쳐 있어야 하는 경우 네트워크 간 방화벽 규칙을 구성하지 않는 것이 좋습니다. 노드 간 대기 시간은 1밀리초 미만이어야 합니다.
주 노드와 복제본(replica) 노드 사이 대기 시간은 70밀리초 미만이어야 합니다. 노드의 네트워크 사이에 방화벽을 구성하지 않는 것이 좋습니다.
최종 사용자용 애플리케이션 포트
애플리케이션 포트는 최종 사용자를 위한 웹 애플리케이션 및 Git 액세스를 제공합니다.
포트 | 설명 | 암호화됨 |
---|---|---|
22/TCP | SSH를 통한 Git | |
25/TCP | SMTP | STARTTLS 필요 |
80/TCP | HTTP | SSL을 사용할 수 있는 경우 이 포트는 HTTPS로 리디렉션됨 |
443/TCP | HTTPS | |
9418/TCP | 간단한 Git 프로토콜 포트 (프라이빗 모드에서는 사용할 수 없음) |
관리 포트
최종 사용자가 사용하는 기본 애플리케이션에는 관리 포트가 필요하지 않습니다.
포트 | 설명 | 암호화됨 |
---|---|---|
ICMP | ICMP Ping | |
122/TCP | 관리 SSH | |
161/UDP | SNMP | |
8080/TCP | 관리 콘솔 HTTP | SSL을 사용할 수 있는 경우 이 포트는 HTTPS로 리디렉션됨 |
8443/TCP | 관리 콘솔 HTTPS |
클러스터 통신 포트
노드 사이에 네트워크 수준 방화벽이 있는 경우 이 포트에 액세스할 수 있어야 합니다. 노드 간 통신은 암호화되지 않습니다. 외부에서는 이 포트에 액세스할 수 없어야 합니다.
포트 | 설명 |
---|---|
1336/TCP | 내부 API |
3033/TCP | 내부 SVN 액세스 |
3037/TCP | 내부 SVN 액세스 |
3306/TCP | MySQL |
4486/TCP | 관리자 액세스 |
5115/TCP | 스토리지 백 엔드 |
5208/TCP | 내부 SVN 액세스 |
6379/TCP | Redis |
8001/TCP | Grafana |
8090/TCP | 내부 GPG 액세스 |
8149/TCP | GitRPC 파일 서버 액세스 |
8300/TCP | Consul |
8301/TCP | Consul |
8302/TCP | Consul |
9000/TCP | Git 디먼 |
9102/TCP | Pages 파일 서버 |
9105/TCP | LFS 서버 |
9200/TCP | Elasticsearch |
9203/TCP | 의미 체계 코드 서비스 |
9300/TCP | Elasticsearch |
11211/TCP | Memcache |
161/UDP | SNMP |
8125/UDP | Statsd |
8301/UDP | Consul |
8302/UDP | Consul |
25827/UDP | Collectd |
부하 분산 장치 구성
노드에 트래픽을 분산하기 위한 프록시 프로토콜을 지원하는 외부 TCP 기반 부하 분산 장치를 사용하는 것이 좋습니다. 다음 부하 분산 장치 구성을 고려합니다.
- TCP 포트(아래 참조)는
web-server
서비스를 실행하는 노드로 전달되어야 합니다. 외부 클라이언트 요청을 처리하는 유일한 노드입니다. - 고정 세션을 사용할 수 없어야 합니다.
경고: 부하 분산 장치에서 HTTPS 연결을 종료할 때 부하 분산 장치에서 GitHub Enterprise Server로의 요청도 HTTPS를 사용해야 합니다. HTTP에 대한 연결을 다운그레이드하는 것은 지원되지 않습니다.
클라이언트 연결 정보 처리
클러스터에 대한 클라이언트 연결은 부하 분산 장치에서 들어오므로 클라이언트 IP 주소가 손실될 수 있습니다. 클라이언트 연결 정보를 제대로 캡처하려면 추가 고려 사항이 필요합니다.
부하 분산 장치가 지원할 수 있는 경우 PROXY 프로토콜을 구현하는 것이 좋습니다. 프록시 지원을 사용할 수 없는 경우 X-Forwarded-For
헤더를 사용하여 HTTP 및 HTTPS 포트의 부하를 분산할 수도 있습니다.
보안 경고: 프록시 지원 또는 HTTP 전달을 사용하는 경우 외부 트래픽이 GitHub Enterprise Server 어플라이언스에 직접 연결할 수 없는 것이 중요합니다. 외부 트래픽이 제대로 차단되지 않으면 원본 IP 주소가 위조될 수 있습니다.
GitHub Enterprise Server에서 프록시 지원 사용
인스턴스와 부하 분산 장치에서 모두 프록시 지원을 사용하도록 설정하는 것이 좋습니다.
참고: GitHub Enterprise Server는 AWS Network Load Balancer와 호환되지 않는 PROXY 프로토콜 V1을 지원합니다. GitHub Enterprise Server에서 AWS Network Load Balancer를 사용하는 경우 PROXY 지원을 사용하지 마세요.
-
인스턴스의 경우 다음 명령을 사용합니다.
ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply
-
부하 분산 장치의 경우 공급업체에서 제공하는 지침을 사용합니다.
PROXY 프로토콜 TCP 포트 매핑
원본 포트 | 대상 포트 | 서비스 설명 |
---|---|---|
22 | 23 | SSH를 통한 Git |
80 | 81 | HTTP |
443 | 444 | HTTPS |
8080 | 8081 | 관리 콘솔 HTTP |
8443 | 8444 | 관리 콘솔 HTTPS |
9418 | 9419 | Git |
GitHub Enterprise Server에서 X-Forwarded-For 지원 사용
PROXY 프로토콜을 사용할 수 없는 경우에만 X-Forwarded-For 프로토콜을 사용합니다. X-Forwarded-For
헤더는 HTTP 및 HTTPS에서만 작동합니다. SSH를 통한 Git 연결에 대해 보고된 IP 주소는 부하 분산 장치 IP를 표시합니다.
X-Forwarded-For
헤더를 사용하도록 설정하려면 다음 명령을 사용합니다.
ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply
PROXY 지원 없이 사용할 프로토콜 TCP 포트 매핑
원본 포트 | 대상 포트 | 서비스 설명 |
---|---|---|
22 | 22 | SSH를 통한 Git |
25 | 25 | SMTP |
80 | 80 | HTTP |
443 | 443 | HTTPS |
8080 | 8080 | 관리 콘솔 HTTP |
8443 | 8443 | 관리 콘솔 HTTPS |
상태 검사 구성
상태 검사를 사용하면 노드에서 미리 구성된 검사가 실패할 경우 부하 분산 장치가 응답하지 않는 노드로의 트래픽 전송을 중지할 수 있습니다. 클러스터 노드에서 오류가 발생할 경우 중복 노드와 페어링된 상태 검사가 고가용성을 제공합니다.
다음 URL을 확인하도록 Load Balancer를 구성합니다.
http(s)://HOSTNAME/status
노드가 정상이고 서비스 최종 사용자 요청에 사용할 수 있는 경우 엔드포인트는 상태 코드 200
(OK)을 반환합니다. 자세한 내용은 "고가용성 구성 모니터링"을(를) 참조하세요.
참고: 어플라이언스가 유지 관리 모드인 경우 https://HOSTNAME/status
URL은 상태 코드 503
(서비스를 사용할 수 없음)을 반환합니다. 자세한 내용은 "유지 관리 모드 사용 설정 및 예약"을(를) 참조하세요.
DNS 요구 사항
GitHub Enterprise Server 호스트 이름에 대한 DNS 조회는 부하 분산 장치로 확인되어야 합니다. 하위 도메인 격리를 사용하도록 설정하는 것이 좋습니다. 하위 도메인 격리를 사용하도록 설정하면 추가 와일드카드 레코드(*.HOSTNAME
)도 부하 분산 장치로 확인되어야 합니다. 자세한 내용은 "하위 도메인 격리 사용"을(를) 참조하세요.