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