• 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의 연결을 ‘HTTP(S)’ 프로토콜이 아닌 ‘TCP’로 전달하도록 구성합니다. 이렇게 함으로써 연결은 애플리케이션 노드의 NGINX 서비스로 이동됩니다. NGINX는 SSL 인증서를 가지고 있으며 포트 443에서 수신 대기하고 있습니다.

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

로드 밸런서가 백엔드 SSL을 해제하지 않는 경우

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

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

로드 밸런서가 백엔드 SSL을 해제하는 경우

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

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

포트

기본 포트

• (1): 웹 터미널 지원을 위해서는 로드 밸런서가 WebSocket 연결을 올바르게 처리해야 합니다. HTTP 또는 HTTPS 프록시를 사용할 때는 로드 밸런서가 Connection 및 Upgrade hop-by-hop 헤더를 통과시키도록 구성되어야 합니다. 자세한 내용은 웹 터미널 통합 가이드를 참조하세요.
• (2): 포트 443에 HTTPS 프로토콜을 사용하는 경우, 로드 밸런서에 SSL 인증서를 추가해야 합니다. SSL을 GitLab 애플리케이션 서버에서 해제하려면 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 호스트 이름을 구성하는 것이 도움이 될 수 있습니다. 다른 GitLab HTTP 구성과 비교하여 대체 SSH 호스트 이름을 위한 새로운 가상 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 암호를 정의할 수 있습니다.