• 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을 종료

로드 밸런서를 구성하여 연결을 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 간의 트래픽은 안전합니다. 연결이 끊임없이 안전하기 때문에 proxied SSL에 대한 구성이 필요하지 않습니다. 그러나 GitLab에 SSL 인증서를 구성해야 합니다. SSL 인증서를 관리하고 NGINX를 구성하는 방법에 대한 자세한 내용은 HTTPS 문서를 참조하십시오.

포트

기본 포트

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

GitLab Pages 포트

사용자 정의 도메인 지원이 있는 GitLab Pages를 사용하는 경우 추가 포트 구성이 필요합니다. GitLab Pages에는 별도의 가상 IP 주소가 필요합니다. DNS를 구성하여 /etc/gitlab/gitlab.rb의 pages_external_url을 새로운 가상 IP 주소를 가리키도록 설정하세요. 자세한 내용은 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가 요청을 수락하지 않는 잠시 동안이 있기 때문에 이 작업이 특히 중요합니다.

문제 해결

로드 밸런서를 통해 건강 상태 확인 시 408 HTTP 코드가 반환됨

GitLab 15.0 이후에 AWS의 클래식 로드 밸런서를 사용하는 경우, NGINX에서 AES256-GCM-SHA384 암호를 활성화해야 합니다. 자세한 내용은 NGINX에서 기본적으로 허용되지 않는 AES256-GCM-SHA384 SSL 암호를 참조하십시오.

GitLab 버전의 기본 암호는 해당 버전에 대한 Git 태그를 선택하고(15.0.5+ee.0와 같은) files/gitlab-cookbooks/gitlab/attributes/default.rb 파일에서 확인할 수 있습니다. 로드 밸런서에서 필요한 경우 NGINX에 대한 사용자 정의 SSL 암호를 정의할 수 있습니다.

일부 페이지 및 링크가 브라우저에서 렌더링되는 대신 다운로드됨

일부 GitLab 기능은 웹소켓을 사용합니다. 로드 밸런서에서 웹소켓 지원이 활성화되지 않은 상황에서는 일부 링크 또는 페이지가 다운로드되어 브라우저에 렌더링되지 않을 수 있습니다. 다운로드된 파일에는 다음과 유사한 내용이 포함될 수 있습니다:

One or more reserved bits are on: reserved1 = 1, reserved2 = 0, reserved3 = 0

로드 밸런서는 HTTP 웹소켓 요청을 지원할 수 있어야 합니다. 이런 방식으로 링크가 다운로드되면 로드 밸런서 구성을 확인하고 HTTP 웹소켓 요청이 활성화되어 있는지 확인하십시오.