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