보조 러너
- GitLab 16.8에서 소개됨 지명이
geo_proxy_check_pipeline_refs
로 명명되었습니다. 기본 설정으로 비활성화됨.- GitLab 16.9에서 기본으로 활성화됨.
보조 사이트를 위한 Geo 프록시를 사용하면 gitlab-runner
를 보조 사이트에 등록할 수 있습니다. 이는 주 사이트에서의 부하를 줄입니다.
참고: 파이프라인의 첫 번째 단계에서 시작하는 작업은 대부분의 경우 Git 복제 요청을 주 사이트로 전달합니다. 이는 대부분의 복제가 보조 사이트에서 검증되기 전에 발생하기 때문입니다. 후속 단계는 일반적으로 보조 사이트에서 Git 데이터를 제공받지 않는데, 예를 들어 Git 변경이 크거나 대역폭이 제한되어 있거나 파이프라인 단계가 짧을 경우입니다. 대부분의 경우, 파이프라인의 후속 단계는 보조 사이트에서 Git 데이터를 제공받습니다. Issue 446176은 첫 번째 단계 복제 요청이 보조 사이트에서 제공될 확률을 높이기 위한 개선을 제안합니다.
지역 인식 공용 URL(통합 URL)을 사용하여 보조 러너 사용하기
지역 인식 DNS를 사용하면, 활성화된 특성 플래그로 추가 구성 없이 작동합니다. 보조 사이트와 동일한 위치에 러너를 설치하고 등록한 후, 가장 가까운 사이트와 자동으로 통신하며, 보조 사이트가 오래된 경우에만 주 사이트로 프록시합니다.
별도의 URL을 사용하여 보조 러너 사용하기
별도의 보조 URL을 사용하는 경우, 러너는 다음과 같이 설정되어야 합니다:
- 보조 외부 URL로 등록됩니다.
-
clone_url
이 보조 인스턴스의external_url
로 설정됩니다.clone_url
설정 방법을 확인하세요.
보조 러너를 사용한 예정된 장애 조치 처리
예정된 장애 조치를 실행하는 경우, 보조 러너가 계속해서 로컬 인스턴스와 통신을 시도합니다. 이로 인해 러너 용량이 감소되고 고려해야 할 사항이 있을 수 있습니다.
지역 인식 공용 URL을 사용하는 경우
지역 인식 DNS를 사용하는 경우, 모든 러너가 자동으로 가장 가까운 Geo 사이트에 연결됩니다.
새로운 주 사이트로 장애 조치를 실행하는 경우:
- 이전 주 사이트가 DNS 레코드에 남아 있는 동안 이전에 연결된 러너들은 여전히 이전 주 사이트에서 작업을 가져가려고 시도합니다. 이것이 연결할 수 없는 경우, 러너는 이를 감지합니다 그리고 인스턴스가 돌아온 후에는 긴 시간 동안 요청을 중지합니다.
- 여러 보조 노드가 있는 경우, 초기 장애 조치 후 나머지 보조 노드는 새로운 주 사이트와 복제될 때까지 불안정한 상태입니다. 이들에 연결된 러너는 체크인 할 수 없으며 그들의 상태 확인도 실행됩니다.
- 불안정한 노드 중 하나를 Geo DNS 항목에서 제거하면 러너는 다음으로 가장 가까운 인스턴스를 선택합니다. 아키텍처에 따라, 이는 원하는 동작이 아닐 수 있습니다. 왜냐하면 줄어든 상태에서 사이트를 압도할 수 있기 때문입니다.
이러한 문제 중 하나를 완화하기 위해, 여분의 러너를 일시 중단하거나 인스턴스가 100% 정상 상태로 돌아올 때까지 몇 개의 러너를 종료할 수 있습니다.
이러한 문제에 대해 걱정하지 않는다면, 여기에 할 일은 없습니다.
별도의 URL을 사용하는 경우
- 이전 주 사이트로 돌아가는 경우, 이전 주 사이트 러너를 일시 중단하여 온라인 상태로 돌아올 때까지 방지할 수 있습니다.
- 이전 주 사이트가 복구되지 않거나 일시적으로 감소된 러너 용량을 피하려는 경우, 주 러너는 새로운 주 사이트에 연결하도록 다시 구성되어야 합니다.
- 여러 보조가 사용되는 경우, 보조가 새 주 사이트와 복제될 동안 러너를 일시 중단하거나 종료하거나 새로운 주 사이트에 연결하도록 다시 구성해야 합니다.
러너 일시 중단
다음 방법 중 하나를 사용하려면 관리자 액세스 권한이 있어야 합니다:
-
관리자 영역을 통해:
- 왼쪽 사이드바에서 가장 아래에 관리자를 선택하세요.
- 설정 > 러너를 선택합니다.
- 일시 중단하려는 러너를 식별하세요.
- 각 러너 옆의
일시 중단
버튼을 선택합니다. - 장애 조치가 완료되면 이전 단계에서 일시 중단한 러너를 다시 시작하세요.
- 러너 API 사용: