다중 노드 GitLab을 위한 로드 밸런서
Offering: GitLab Self-Managed
다중 노드 GitLab 구성에서는 애플리케이션 서버로 트래픽을 라우팅하기 위한 로드 밸런서가 필요합니다. 다중 노드 환경에서 SSL을 어떻게 처리하시겠습니까? 로드 밸런서를 구성하여 포트 443에서 연결을 'HTTP(S)' 프로토콜이 아닌 'TCP'로 전달합니다.
다중 노드 GitLab 구성에서는 애플리케이션 서버로 트래픽을 라우팅하기 위한 로드 밸런서가 필요합니다. 사용할 로드 밸런서나 정확한 구성에 대한 세부 사항은 GitLab 문서의 범위를 벗어납니다. GitLab과 같은 HA 시스템을 관리하는 경우 이미 선호하는 로드 밸런서가 있기를 바랍니다. 예시로는 HAProxy(오픈 소스), F5 Big-IP LTM, Citrix NetScaler가 있습니다. 이 문서는 GitLab과 함께 사용할 포트와 프로토콜을 설명합니다.
SSL#
다중 노드 환경에서 SSL을 어떻게 처리하시겠습니까? 여러 가지 옵션이 있습니다:
- 각 애플리케이션 노드가 SSL을 종료
- 로드 밸런서가 SSL을 종료하고 로드 밸런서와 애플리케이션 노드 간 통신이 안전하지 않음
- 로드 밸런서가 SSL을 종료하고 로드 밸런서와 애플리케이션 노드 간 통신이 안전함
애플리케이션 노드가 SSL 종료#
로드 밸런서를 구성하여 포트 443에서 연결을 'HTTP(S)' 프로토콜이 아닌 'TCP'로 전달합니다. 이렇게 하면 연결이 애플리케이션 노드 NGINX 서비스로 그대로 전달됩니다. NGINX에는 SSL 인증서가 있으며 포트 443에서 수신합니다.
SSL 인증서 관리 및 NGINX 구성에 대한 자세한 내용은 HTTPS 문서를 참조하세요.
백엔드 SSL 없이 로드 밸런서가 SSL 종료#
로드 밸런서를 TCP 대신 HTTP(S) 프로토콜을 사용하도록 구성합니다. 로드 밸런서는 SSL 인증서를 관리하고 SSL을 종료할 책임이 있습니다.
로드 밸런서와 GitLab 간의 통신이 안전하지 않으므로 추가 구성이 필요합니다. 자세한 내용은 프록시 SSL 문서를 참조하세요.
백엔드 SSL과 함께 로드 밸런서가 SSL 종료#
로드 밸런서를 TCP 대신 HTTP(S) 프로토콜을 사용하도록 구성합니다. 로드 밸런서는 최종 사용자가 볼 SSL 인증서를 관리할 책임이 있습니다.
이 시나리오에서는 로드 밸런서와 NGINX 간의 트래픽이 안전합니다. 연결이 전체적으로 안전하기 때문에 프록시 SSL 구성을 추가할 필요가 없습니다. 그러나 SSL 인증서를 구성하기 위해 GitLab에 구성을 추가해야 합니다. SSL 인증서 관리 및 NGINX 구성에 대한 자세한 내용은 HTTPS 문서를 참조하세요.
포트#
기본 포트#
| LB 포트 | 백엔드 포트 | 프로토콜 |
|---|---|---|
| 80 | 80 | HTTP (1) |
| 443 | 443 | TCP 또는 HTTPS (1) (2) |
| 22 | 22 | TCP |
- (1): 로드 밸런서는 GitLab Duo Chat (비에이전트), 이슈 및 머지 리퀘스트의 실시간 레이블 업데이트, 웹 터미널과 같은 기능을 위한 WebSocket 연결을 지원해야 합니다. WebSocket을 지원하지 않는 로드 밸런서(예: AWS Classic Load Balancer)는 이러한 기능에 대해 GitLab과 호환되지 않습니다. HTTP 또는 HTTPS 프록시를 사용할 때 로드 밸런서는
Connection및Upgrade홉-바이-홉 헤더를 백엔드 서버로 전달하도록 구성해야 합니다. 이는 Direct Server Return(DSR) 모드가 아닌 HTTP 헤더 전달을 의미합니다. - (2): 포트 443에 HTTPS 프로토콜을 사용할 때 로드 밸런서에 SSL 인증서를 추가해야 합니다. GitLab 애플리케이션 서버에서 SSL을 종료하려면 TCP 프로토콜을 사용하세요.
GitLab Pages 포트#
커스텀 도메인 지원과 함께 GitLab Pages를 사용하는 경우 추가 포트 구성이 필요합니다.
GitLab Pages에는 별도의 가상 IP 주소가 필요합니다. 새 가상 IP 주소에 /etc/gitlab/gitlab.rb의 pages_external_url을 가리키도록 DNS를 구성하세요. 자세한 내용은 GitLab Pages 문서를 참조하세요.
| LB 포트 | 백엔드 포트 | 프로토콜 |
|---|---|---|
| 80 | 다양 (1) | HTTP |
| 443 | 다양 (1) | TCP (2) |
- (1): GitLab Pages의 백엔드 포트는
gitlab_pages['external_http']및gitlab_pages['external_https']설정에 따라 다릅니다. 자세한 내용은 GitLab Pages 문서를 참조하세요. - (2): GitLab Pages의 포트 443은 항상 TCP 프로토콜을 사용해야 합니다. 사용자는 커스텀 SSL로 커스텀 도메인을 구성할 수 있는데, 로드 밸런서에서 SSL이 종료되면 이것이 불가능합니다.
대체 SSH 포트#
일부 조직은 SSH 포트 22를 여는 것에 대한 정책을 가지고 있습니다. 이 경우 사용자가 포트 443에서 SSH를 사용할 수 있는 대체 SSH 호스트명을 구성하는 것이 도움이 될 수 있습니다. 대체 SSH 호스트명은 이전에 문서화된 다른 GitLab HTTP 구성과 비교하여 새 가상 IP 주소가 필요합니다.
altssh.gitlab.example.com과 같은 대체 SSH 호스트명에 대한 DNS를 구성합니다.
| LB 포트 | 백엔드 포트 | 프로토콜 |
|---|---|---|
| 443 | 22 | TCP |
준비 상태 확인#
다중 노드 배포는 트래픽을 라우팅하기 전에 노드가 트래픽을 수락할 준비가 되었는지 확인하기 위해 로드 밸런서가 준비 상태 확인을 사용하도록 구성하는 것을 강력히 권장합니다. 이는 특히 Puma를 사용할 때 중요한데, 재시작 중에 Puma가 요청을 수락하지 않는 짧은 기간이 있기 때문입니다.
GitLab 버전 15.4~15.8에서 준비 상태 확인과 함께 all=1 파라미터를 사용하면 Praefect 메모리 사용량 증가가 발생하고 메모리 오류가 발생할 수 있습니다.
트러블슈팅#
헬스 체크가 로드 밸런서를 통해 408 HTTP 코드를 반환함#
GitLab 15.0 이상에서 AWS Classic Load Balancer를 사용하는 경우 NGINX에서 AES256-GCM-SHA384 암호를 활성화해야 합니다.
자세한 내용은 AES256-GCM-SHA384 SSL 암호가 NGINX에서 더 이상 기본적으로 허용되지 않음을 참조하세요.
GitLab 버전의 기본 암호는 files/gitlab-cookbooks/gitlab/attributes/default.rb 파일에서 대상 GitLab 버전에 해당하는 Git 태그(예: 15.0.5+ee.0)를 선택하여 볼 수 있습니다. 로드 밸런서에서 필요한 경우 NGINX에 대한 커스텀 SSL 암호를 정의할 수 있습니다.
일부 페이지와 링크가 브라우저에서 렌더링되지 않고 다운로드됨#
일부 GitLab 기능은 WebSocket 사용이 필요합니다. 로드 밸런서에서 WebSocket 지원이 활성화되지 않은 일부 시나리오에서 일부 링크나 페이지가 브라우저에서 렌더링되지 않고 다운로드될 수 있습니다. 다운로드된 파일에는 다음과 같은 내용이 포함될 수 있습니다:
One or more reserved bits are on: reserved1 = 1, reserved2 = 0, reserved3 = 0
로드 밸런서는 HTTP WebSocket 요청을 지원할 수 있어야 합니다. 링크가 이런 방식으로 다운로드되는 경우 로드 밸런서 구성을 확인하고 HTTP WebSocket 요청이 활성화되어 있는지 확인하세요.