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

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

다중 노드 GitLab 구성에서, 애플리케이션 서버로 트래픽을 라우팅하기 위해 로드 밸런서가 필요합니다. 어떤 로드 밸런서를 사용해야 하는지 또는 정확한 구성은 GitLab 문서의 범위를 벗어납니다. GitLab과 같은 HA 시스템을 관리하고 있다면, 이미 선택한 로드 밸런서가 있을 것이라고 믿습니다. HAProxy(오픈 소스), F5 Big-IP LTM 및 Citrix NetScaler와 같은 몇 가지 예가 있습니다. 이 문서에서는 GitLab과 함께 사용할 포트와 프로토콜을 설명합니다.

SSL

다중 노드 환경에서 SSL을 어떻게 처리하시겠습니까? 여러 가지 옵션이 있습니다:

• 각 애플리케이션 노드가 SSL을 종료합니다.
• 로드 밸런서가 SSL을 종료하며 로드 밸런서와 애플리케이션 노드 간의 통신은 안전하지 않습니다.
• 로드 밸런서가 SSL을 종료하며 로드 밸런서와 애플리케이션 노드 간의 통신이 안전합니다.

애플리케이션 노드가 SSL을 종료함

로드 밸런서를 포트 443에서 ‘TCP’로 연결을 전달하도록 구성하세요. ‘HTTP(S)’ 프로토콜이 아닙니다. 이렇게 하면 연결이 애플리케이션 노드의 NGINX 서비스로 영향을 받지 않고 전달됩니다. NGINX는 SSL 인증서를 가지고 있으며 포트 443에서 수신 대기합니다.

SSL 인증서 관리 및 NGINX 구성에 대한 자세한 내용은 HTTPS 문서를 참조하세요.

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

로드 밸런서를 ‘TCP’ 대신 ‘HTTP(S)’ 프로토콜을 사용하도록 구성하세요. 로드 밸런서는 SSL 인증서 관리 및 SSL 종료를 책임집니다.

로드 밸런서와 GitLab 간의 통신이 안전하지 않기 때문에 추가 구성 필요합니다. 자세한 내용은 프록시 SSL 문서를 참조하세요.

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

로드 밸런서를 ‘TCP’ 대신 ‘HTTP(S)’ 프로토콜을 사용하도록 구성하세요. 로드 밸런서는 최종 사용자가 보는 SSL 인증서를 관리할 책임이 있습니다.

이 시나리오에서 로드 밸런서와 NGINX 간의 트래픽은 안전합니다. 연결이 끝까지 안전하기 때문에 프록시 SSL에 대한 추가 구성은 필요하지 않습니다. 그러나 GitLab에서 SSL 인증서를 구성하기 위한 구성은 추가해야 합니다. SSL 인증서 관리 및 NGINX 구성에 대한 자세한 내용은 HTTPS 문서를 참조하세요.

포트

기본 포트

• (1): 웹 터미널 지원은 로드 밸런서가 웹소켓 연결을 올바르게 처리해야 합니다. 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를 열지 않는 정책이 있습니다. 이 경우, 사용자가 포트 443에서 SSH를 사용할 수 있도록 대체 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의 Classic Load Balancer를 사용하는 경우, NGINX에서 AES256-GCM-SHA384 암호를 활성화해야 합니다. 자세한 내용은 기본적으로 NGINX에서 더 이상 허용되지 않는 AES256-GCM-SHA384 SSL 암호를 참조하세요.

GitLab 버전의 기본 암호는 files/gitlab-cookbooks/gitlab/attributes/default.rb 파일에서 확인할 수 있으며, 목표 GitLab 버전과 관련된 Git 태그를 선택하세요 (예: 15.0.5+ee.0). 로드 밸런서에서 필요하면 사용자 SSL 암호를 NGINX에 정의할 수 있습니다.

일부 페이지와 링크가 브라우저에서 렌더링되지 않고 다운로드됩니다

일부 GitLab 기능은 WebSocket 사용을 요구합니다. WebSocket 지원이 로드 밸런서에서 활성화되지 않은 경우, 일부 링크나 페이지가 브라우저에서 렌더링되지 않고 다운로드될 수 있습니다. 다운로드된 파일에는 다음과 같은 내용이 포함될 수 있습니다:

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

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