InfoGrab Docs

보조 러너

요약

보조 사이트의 Geo 프록시를 사용하면 gitlab-runner를 보조 사이트에 등록할 수 있습니다. 파이프라인의 첫 번째 stage에서 시작하는 job은 거의 항상 Git 클론 요청이 기본 사이트로 전달됩니다. 기능 플래그가 활성화된 상태에서 위치 인식 DNS를 사용하면 추가 구성 없이 작동합니다.

히스토리
  • GitLab 16.8에서 geo_proxy_check_pipeline_refs라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 16.9에서 기본적으로 활성화되었습니다.

보조 사이트의 Geo 프록시를 사용하면 gitlab-runner를 보조 사이트에 등록할 수 있습니다. 이를 통해 기본 인스턴스의 부하를 분산할 수 있습니다.

Note

파이프라인의 첫 번째 stage에서 시작하는 job은 거의 항상 Git 클론 요청이 기본 사이트로 전달됩니다. 이는 보조 사이트가 Git 데이터를 복제하고 검증하기 전에 해당 클론이 발생하기 때문입니다. 이후 stage도 보조 사이트에서 처리된다는 보장이 없습니다. 예를 들어 Git 변경 사항이 크거나, 대역폭이 작거나, 파이프라인 stage가 짧은 경우가 그렇습니다. 대부분의 경우 파이프라인의 이후 stage에서는 보조 사이트에서 Git 데이터를 제공합니다. 이슈 446176은 첫 번째 stage 클론 요청이 보조 사이트에서 처리될 가능성을 높이기 위한 개선 사항을 제안합니다.

위치 인식 공개 URL(통합 URL)과 함께 보조 러너 사용#

기능 플래그가 활성화된 상태에서 위치 인식 DNS를 사용하면 추가 구성 없이 작동합니다. 보조 사이트와 동일한 위치에 러너를 설치하고 등록하면, 자동으로 가장 가까운 사이트와 통신하며, 보조 사이트가 최신 상태가 아닌 경우에만 기본 사이트로 프록시합니다.

별도의 URL과 함께 보조 러너 사용#

별도의 보조 URL을 사용할 경우 러너는 다음과 같이 구성되어야 합니다:

  1. 보조 외부 URL로 등록합니다.
  2. 보조 인스턴스의 external_url로 설정된 clone_url로 구성합니다.

보조 러너가 있는 계획된 페일오버 처리#

계획된 페일오버를 실행할 때 보조 러너는 로컬 인스턴스와 계속 통신하려고 합니다. 이로 인해 러너 용량이 감소할 수 있으므로 이를 고려해야 합니다.

위치 인식 공개 URL 사용 시#

위치 인식 DNS를 사용할 경우 모든 러너가 자동으로 가장 가까운 Geo 사이트에 연결됩니다.

새 기본 사이트로 페일오버할 때:

  • 이전 기본 사이트가 DNS 레코드에 있는 동안 이전 기본 사이트에 연결된 러너는 계속 이전 기본 사이트에서 job을 가져오려고 합니다. 이전 기본 사이트에 연결할 수 없는 경우 러너는 이를 감지하고, 인스턴스가 돌아온 후 일정 시간 동안 요청을 중단합니다.
  • 여러 보조 노드가 있는 경우, 초기 페일오버 후 나머지 보조 사이트는 새 기본 사이트와 복제될 때까지 비정상 상태가 됩니다. 해당 사이트에 연결된 러너는 체크인할 수 없으며 상태 확인도 작동합니다.
  • 비정상 노드를 Geo DNS 항목에서 제거하면 러너가 다음으로 가까운 인스턴스를 선택합니다. 아키텍처에 따라 감소된 상태의 사이트에 과부하가 걸릴 수 있으므로 원치 않을 수 있습니다.

이러한 문제를 완화하려면 사이트가 100%로 복구될 때까지 일부 러너를 일시 중지하거나 종료할 수 있습니다.

이러한 문제가 우려되지 않는 경우 아무것도 할 필요가 없습니다.

별도의 URL 사용 시#

  • 이전 기본 사이트를 다시 서비스에 복귀시키는 경우, 복구될 때까지 이전 기본 사이트 러너를 일시 중지할 수 있습니다. 이렇게 하면 상태 확인이 작동하지 않습니다.
  • 이전 기본 사이트가 복귀하지 않거나 일시적으로 러너 용량이 감소하는 것을 피하려면 기본 사이트 러너를 새 기본 사이트에 연결하도록 재구성해야 합니다.
  • 여러 보조 사이트를 사용 중인 경우 새 기본 사이트로 복제되는 동안 러너를 일시 중지하거나, 종료하거나, 새 기본 사이트에 연결하도록 재구성해야 합니다.

러너 일시 중지#

다음 방법을 사용하려면 관리자 권한이 있어야 합니다:

  • Admin 영역을 통해:
    1. 오른쪽 상단 모서리에서 Admin을 선택합니다.
    2. Settings > Runners를 선택합니다.
    3. 일시 중지할 러너를 식별합니다.
    4. 일시 중지할 각 러너 옆에 있는 pause 버튼을 선택합니다.
    5. 페일오버가 완료된 후 이전 단계에서 일시 중지한 러너를 다시 활성화합니다.
  • 러너 API 사용:
    1. 관리자 권한이 있는 개인 액세스 토큰을 가져오거나 생성합니다.
    2. 러너 목록을 가져옵니다. API를 사용하여 목록을 필터링할 수 있습니다.
    3. 일시 중지할 러너를 식별하고 해당 id를 기록합니다.
    4. API 문서를 따라 각 러너를 일시 중지합니다.
    5. 페일오버가 완료된 후 paused=false로 설정하여 API를 통해 러너 목록을 다시 활성화합니다.

보조 러너

Tier: Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

보조 사이트의 Geo 프록시를 사용하면 gitlab-runner를 보조 사이트에 등록할 수 있습니다. 파이프라인의 첫 번째 stage에서 시작하는 job은 거의 항상 Git 클론 요청이 기본 사이트로 전달됩니다. 기능 플래그가 활성화된 상태에서 위치 인식 DNS를 사용하면 추가 구성 없이 작동합니다.

히스토리
  • GitLab 16.8에서 geo_proxy_check_pipeline_refs라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 16.9에서 기본적으로 활성화되었습니다.

보조 사이트의 Geo 프록시를 사용하면 gitlab-runner를 보조 사이트에 등록할 수 있습니다. 이를 통해 기본 인스턴스의 부하를 분산할 수 있습니다.

Note

파이프라인의 첫 번째 stage에서 시작하는 job은 거의 항상 Git 클론 요청이 기본 사이트로 전달됩니다. 이는 보조 사이트가 Git 데이터를 복제하고 검증하기 전에 해당 클론이 발생하기 때문입니다. 이후 stage도 보조 사이트에서 처리된다는 보장이 없습니다. 예를 들어 Git 변경 사항이 크거나, 대역폭이 작거나, 파이프라인 stage가 짧은 경우가 그렇습니다. 대부분의 경우 파이프라인의 이후 stage에서는 보조 사이트에서 Git 데이터를 제공합니다. 이슈 446176은 첫 번째 stage 클론 요청이 보조 사이트에서 처리될 가능성을 높이기 위한 개선 사항을 제안합니다.

위치 인식 공개 URL(통합 URL)과 함께 보조 러너 사용#

기능 플래그가 활성화된 상태에서 위치 인식 DNS를 사용하면 추가 구성 없이 작동합니다. 보조 사이트와 동일한 위치에 러너를 설치하고 등록하면, 자동으로 가장 가까운 사이트와 통신하며, 보조 사이트가 최신 상태가 아닌 경우에만 기본 사이트로 프록시합니다.

별도의 URL과 함께 보조 러너 사용#

별도의 보조 URL을 사용할 경우 러너는 다음과 같이 구성되어야 합니다:

  1. 보조 외부 URL로 등록합니다.
  2. 보조 인스턴스의 external_url로 설정된 clone_url로 구성합니다.

보조 러너가 있는 계획된 페일오버 처리#

계획된 페일오버를 실행할 때 보조 러너는 로컬 인스턴스와 계속 통신하려고 합니다. 이로 인해 러너 용량이 감소할 수 있으므로 이를 고려해야 합니다.

위치 인식 공개 URL 사용 시#

위치 인식 DNS를 사용할 경우 모든 러너가 자동으로 가장 가까운 Geo 사이트에 연결됩니다.

새 기본 사이트로 페일오버할 때:

  • 이전 기본 사이트가 DNS 레코드에 있는 동안 이전 기본 사이트에 연결된 러너는 계속 이전 기본 사이트에서 job을 가져오려고 합니다. 이전 기본 사이트에 연결할 수 없는 경우 러너는 이를 감지하고, 인스턴스가 돌아온 후 일정 시간 동안 요청을 중단합니다.
  • 여러 보조 노드가 있는 경우, 초기 페일오버 후 나머지 보조 사이트는 새 기본 사이트와 복제될 때까지 비정상 상태가 됩니다. 해당 사이트에 연결된 러너는 체크인할 수 없으며 상태 확인도 작동합니다.
  • 비정상 노드를 Geo DNS 항목에서 제거하면 러너가 다음으로 가까운 인스턴스를 선택합니다. 아키텍처에 따라 감소된 상태의 사이트에 과부하가 걸릴 수 있으므로 원치 않을 수 있습니다.

이러한 문제를 완화하려면 사이트가 100%로 복구될 때까지 일부 러너를 일시 중지하거나 종료할 수 있습니다.

이러한 문제가 우려되지 않는 경우 아무것도 할 필요가 없습니다.

별도의 URL 사용 시#

  • 이전 기본 사이트를 다시 서비스에 복귀시키는 경우, 복구될 때까지 이전 기본 사이트 러너를 일시 중지할 수 있습니다. 이렇게 하면 상태 확인이 작동하지 않습니다.
  • 이전 기본 사이트가 복귀하지 않거나 일시적으로 러너 용량이 감소하는 것을 피하려면 기본 사이트 러너를 새 기본 사이트에 연결하도록 재구성해야 합니다.
  • 여러 보조 사이트를 사용 중인 경우 새 기본 사이트로 복제되는 동안 러너를 일시 중지하거나, 종료하거나, 새 기본 사이트에 연결하도록 재구성해야 합니다.

러너 일시 중지#

다음 방법을 사용하려면 관리자 권한이 있어야 합니다:

  • Admin 영역을 통해:
    1. 오른쪽 상단 모서리에서 Admin을 선택합니다.
    2. Settings > Runners를 선택합니다.
    3. 일시 중지할 러너를 식별합니다.
    4. 일시 중지할 각 러너 옆에 있는 pause 버튼을 선택합니다.
    5. 페일오버가 완료된 후 이전 단계에서 일시 중지한 러너를 다시 활성화합니다.
  • 러너 API 사용:
    1. 관리자 권한이 있는 개인 액세스 토큰을 가져오거나 생성합니다.
    2. 러너 목록을 가져옵니다. API를 사용하여 목록을 필터링할 수 있습니다.
    3. 일시 중지할 러너를 식별하고 해당 id를 기록합니다.
    4. API 문서를 따라 각 러너를 일시 중지합니다.
    5. 페일오버가 완료된 후 paused=false로 설정하여 API를 통해 러너 목록을 다시 활성화합니다.