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

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

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

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

로드 밸런서를 사용하여 ‘HTTP(S)’ 프로토콜 대신 ‘TCP’를 사용하도록 구성합니다. 로드 밸런서는 엔드 유저가 볼 수 있는 SSL 인증서를 관리합니다.

이 경우 로드 밸런서와 NGINX 간의 트래픽은 안전합니다. 연결이 안전하므로 프록시 SSL에 대한 구성 추가가 필요하지 않습니다. 그러나 GitLab에 SSL 인증서를 구성하기 위해 구성을 추가해야 합니다. 자세한 내용은 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를 열지 않는 정책을 가지고 있습니다. 이 경우, 사용자가 포트 443에서 SSH를 사용할 수 있도록 대체 SSH 호스트 이름을 구성하는 것이 도움이 될 수 있습니다. 다른 GitLab HTTP 구성과 비교했을 때 대체 SSH 호스트 이름은 새 가상 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 버전의 기본 암호는 대상 GitLab 버전에 대응하는 Git 태그를 선택하고(15.0.5+ee.0와 같은) files/gitlab-cookbooks/gitlab/attributes/default.rb 파일에서 확인할 수 있습니다. 로드 밸런서가 필요한 경우 NGINX에 사용자 정의 SSL 암호를 정의할 수 있습니다.