• SSL
  • 애플리케이션 노드가 SSL을 종료
  • 로드 밸런서가 백엔드 SSL 없이 SSL을 종료
  • 로드 밸런서가 백엔드 SSL로 SSL을 종료
• 포트
  • 기본 포트
  • GitLab Pages 포트
  • 대체 SSH 포트
• 준비 상태 확인
• 문제 해결
  • 로드 밸런서를 통해 상태 확인이 408 HTTP 코드를 반환하는 경우
  • 브라우저에서 렌더링되기 대신 일부 페이지 및 링크가 다운로드됨

다중 노드 GitLab을 위한 로드 밸런서

다중 노드 GitLab 구성에서는 애플리케이션 서버로의 트래픽을 라우팅하기 위해 로드 밸런서가 필요합니다. 사용할 로드 밸런서 또는 구체적인 구성은 GitLab 문서의 범위를 벗어납니다. GitLab을 관리하는 경우 이미 선호하는 로드 밸런서가 있을 것으로 기대합니다. 예를들어 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 간 통신이 안전하지 않기 때문에 추가 구성이 필요합니다. 자세한 내용은 proxied SSL 문서를 참조하세요.

로드 밸런서가 백엔드 SSL로 SSL을 종료

로드 밸런서를 ‘TCP’가 아닌 ‘HTTP(S)’ 프로토콜을 사용하도록 구성합니다. 로드 밸런서는 엔드 유저가 보는 SSL 인증서를 관리합니다.

이 경우 로드 밸런서와 NGINX 간의 트래픽은 안전합니다. 따라서 프록시 SSL 구성은 필요하지 않습니다. 그러나 GitLab에 SSL 인증서를 구성해야 합니다. SSL 인증서 관리 및 NGINX 구성에 대한 자세한 내용은 HTTPS 문서를 참조하세요.

포트

기본 포트

• (1): 웹 터미널 지원을 위해서는 로드 밸런서가 WebSocket 연결을 올바르게 처리해야 합니다. HTTP 또는 HTTPS 프록시를 사용하는 경우, 로드 밸런서는 Connection 및 Upgrade 호피호프 헤더를 전달하도록 구성되어야 합니다. 자세한 내용은 웹 터미널 통합 가이드를 참조하세요.
• (2): 포트 443에 HTTPS 프로토콜을 사용하는 경우, 로드 밸런서에 SSL 인증서를 추가해야 합니다. GitLab 응용 프로그램 서버에서 SSL을 종료하려면 TCP 프로토콜을 사용하세요.

GitLab Pages 포트

사용자 정의 도메인 지원을 사용하는 경우 GitLab Pages에는 추가 포트 구성이 필요합니다. GitLab Pages에는 별도의 가상 IP 주소가 필요합니다. /etc/gitlab/gitlab.rb의 pages_external_url을 새 가상 IP 주소로 지정하도록 DNS를 구성하세요. 자세한 내용은 GitLab Pages 문서를 참조하세요.

• (1): GitLab Pages의 백엔드 포트는 gitlab_pages['external_http'] 및 gitlab_pages['external_https'] 설정에 따라 다릅니다. 자세한 내용은 GitLab Pages 문서를 참조하세요.
• (2): GitLab Pages의 포트 443은 항상 TCP 프로토콜을 사용해야 합니다. 사용자는 사용자 정의 SSL로 사용자 정의 도메인을 구성할 수 있습니다. 이는 로드 밸런서에서 SSL을 종료하는 경우 불가능합니다.

대체 SSH 포트

일부 조직은 SSH 포트 22를 열지 않는 정책을 가지고 있습니다. 이 경우 SSH를 443 포트에서 사용할 수 있는 대체 SSH 호스트 이름을 구성하는 것이 도움이 될 수 있습니다. 대체 SSH 호스트 이름은 앞서 언급된 다른 GitLab HTTP 구성과는 달리 새 가상 IP 주소가 필요합니다.

altssh.gitlab.example.com과 같은 대체 SSH 호스트 이름에 대한 DNS를 구성하세요.

준비 상태 확인

다중 노드 배포에서는 트래픽을 라우팅하기 전에 로드 밸런서가 준비 상태 확인을 수행하도록 권장합니다. 특히 Puma를 사용하는 경우 Puma가 요청을 수락하지 않는 잠깐한 시간이 있기 때문에 이 기능이 중요합니다.

경고: GitLab 버전 15.4에서 15.8까지는 준비 상태 확인에서 all=1 매개변수를 사용하면 Praefect 메모리 사용량이 늘어나는 문제가 발생할 수 있으며 메모리 오류가 발생할 수 있습니다.

문제 해결

로드 밸런서를 통해 상태 확인이 408 HTTP 코드를 반환하는 경우

GitLab 15.0 이상에서 AWS의 클래식 로드 밸런서를 사용 중인 경우, 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 기능은 웹소켓을 사용해야 합니다. 로드 밸런서에서 웹소켓 지원이 활성화되지 않은 시나리오에서는 브라우저에 렌더링되는 대신 일부 링크 또는 페이지가 다운로드될 수 있습니다. 다운로드된 파일에는 다음과 유사한 내용이 포함될 수 있습니다:

하나 이상의 예약된 비트가 켜져 있습니다: reserved1 = 1, reserved2 = 0, reserved3 = 0

로드 밸런서는 HTTP 웹소켓 요청을 지원할 수 있어야 합니다. 이와 같이 링크가 다운로드되는 경우, 로드 밸런서 구성을 확인하고 HTTP 웹소켓 요청이 활성화되어 있는지 확인하세요.