개요
시스템 요구 사항
지원되는 클라우드 제공업체
Runner 구성
Docker Machine executor가 생성하는 VM의 수 제한하기
오토스케일링 알고리즘 및 매개변수
concurrent, limit 및 IdleCount가 실행 중인 기계의 상한선을 생성하는 방법
IdleScaleFactor 전략
자동 스케일링 기간 구성
분산 러너 캐싱
분산 컨테이너 레지스트리 미러링
config.toml의 전체 예제

Docker Machine Executor autoscale configuration

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed

Autoscale 기능은 GitLab Runner 1.1.0에서 소개되었습니다.

Autoscale은 리소스를 더 유연하고 동적으로 사용할 수 있는 기능을 제공합니다.

GitLab Runner는 autoscale을 사용하여, 언제든지 필요한만큼의 빌드 인스턴스만 포함되도록 자동으로 조정할 수 있습니다. GitLab Runner를 autoscale만 사용하도록 구성하면, GitLab Runner가 설치된 시스템이 생성하는 모든 머신의 보루 역할을 합니다. 이 머신을 “Runner Manager”라고 합니다.

Docker는 Docker Machine의 사용을 폐기했으며, 이 기술은 공개 클라우드 가상 머신에서 러너를 자동으로 조정하는 데 사용됩니다. Docker Machine의 폐기에 대한 논의를 보려면 여기를 확인하세요.

Docker Machine autoscaler는 limit 및 concurrent 구성과 관계없이 VM 당 하나의 컨테이너를 만듭니다.

개요

이 기능이 활성화되고 올바르게 구성된 경우 작업은 필요에 따라 생성된 머신에서 실행됩니다. 이러한 머신은 작업이 완료된 후 구성된 IdleTime 이후에 다음 작업을 실행하도록 대기하거나 제거될 수 있습니다. 많은 클라우드 제공업체의 경우 이미 사용된 인스턴스의 비용을 활용하는 데 도움이 됩니다.

아래에서 GitLab Community Edition 프로젝트에서 GitLab.com에서 테스트된 GitLab Runner autoscale 기능의 실제 예제를 볼 수 있습니다:

차트의 각 머신은 독립적인 클라우드 인스턴스로, Docker 컨테이너 내에서 작업을 실행합니다.

시스템 요구 사항

autoscale을 구성하기 전에 다음을 수행해야 합니다:

고유한 환경을 준비.
GitLab이 제공하는 forked version의 Docker Machine을 선택적으로 사용하여 몇 가지 추가 수정을 가했어야 합니다.

지원되는 클라우드 제공업체

autoscale 메커니즘은 Docker Machine을 기반으로 합니다. 모든 지원되는 가상화 및 클라우드 제공자 매개변수는 Docker Machine의 GitLab 관리자가 관리하는 fork에서 사용할 수 있습니다.

Runner 구성

이 섹션에서 중요한 autoscale 파라미터를 설명합니다. 더 많은 구성 상세 정보를 보려면 고급 구성을 읽으세요.

Runner 글로벌 옵션

파라미터	값	설명
`concurrent`	integer	전역적으로 동시에 실행되는 작업 수를 제한합니다. 이는 모든 정의된 러너, 로컬 및 autoscale을 사용하는 모든 작업의 상한선에 영향을 줍니다. `limit` ( `[[runners]]` 섹션의 `concurrent`와 `IdleCount` ( `[runners.machine]` 섹션의 `IdleCount`와 함께 VM의 상한선에 영향을 줍니다.)

`[[runners]]` 옵션

파라미터	값	설명
`executor`	string	autoscale 기능을 사용하려면 `executor`를 `docker+machine`으로 설정해야 합니다.
`limit`	integer	특정 토큰에 의해 동시에 처리될 수 있는 작업 수를 제한합니다. `0`은 제한하지 않음을 의미합니다. autoscale의 경우, 이는 이 제공자에 의해 생성된 머신의 상한선입니다. (`concurrent` 및 `IdleCount`와 함께 사용).

`[runners.machine]` 옵션

구성 매개변수에 대한 자세한 내용은 GitLab Runner - Advanced Configuration - The [runners.machine] section에서 찾을 수 있습니다.

`[runners.cache]` 옵션

구성 매개변수에 대한 자세한 내용은 GitLab Runner - Advanced Configuration - The [runners.cache] section에서 찾을 수 있습니다.

추가 구성 정보

IdleCount = 0으로 설정하는 특별한 모드도 있습니다. 이 모드에서는 각 작업 전에 머신이 항상 순간적으로 생성됩니다 (대기 중인 상태의 사용 가능한 머신이 없는 경우). 작업이 완료되면 대기 상태의 기계가 작동하는 방식은 아래에 설명된 것과 동일합니다. 머신은 다음 작업을 기다린 후 IdleTime 기간이 지나면 제거됩니다. 작업이 없으면 Idle 상태에 머신이 없습니다.

만약 IdleCount를 0보다 큰 값을로 설정하면, 백그라운드에서 대기 중인 VM이 생성됩니다. 러너는 새로운 작업을 요청하기 전에 이미 대기 중인 VM을 획득합니다.

작업이 러너에 할당되면 해당 작업은 이전에 획득한 VM에 전송됩니다.
작업이 러너에 할당되지 않으면 대기 중인 VM의 잠금이 해제되고 VM이 풀로 반환됩니다.

Docker Machine executor가 생성하는 VM의 수 제한하기

Docker Machine executor에 의해 생성되는 가상 머신(VM)의 수를 제한하려면 config.toml 파일의 [[runners]] 섹션에서 limit 매개변수를 사용합니다.

concurrent 매개변수는 VM의 수를 제한하지 않습니다.

여기에서 설명한대로, 하나의 프로세스는 여러 러너 워커를 관리하도록 구성할 수 있습니다.

이 예제는 하나의 러너 프로세스에 설정된 config.toml 파일의 값들을 보여줍니다:

concurrent = 100

[[runners]]
name = "first"
executor = "shell"
limit = 40
(...)

[[runners]]
name = "second"
executor = "docker+machine"
limit = 30
(...)

[[runners]]
name = "third"
executor = "ssh"
limit = 10

[[runners]]
name = "fourth"
executor = "virtualbox"
limit = 20
(...)

이 구성에서:

하나의 러너 프로세스는 여러 실행 환경을 사용하여 네 가지 다른 러너 워커를 생성할 수 있습니다.
concurrent 값은 100으로 설정되어 있으므로, 이 하나의 러너는 최대 100개의 동시 GitLab CI/CD 작업을 실행합니다.
second 러너 워커만 Docker Machine executor를 사용하도록 설정되어 있으므로 자동으로 VM을 만들 수 있습니다.
limit 설정값은 30이며, 이는 second 러너 워커가 언제든지 최대 30개의 CI/CD 작업을 자동으로 생성된 VM에서 실행할 수 있다는 것을 의미합니다.
concurrent는 여러 [[runners]] 워커 전반에서 전역적인 동시성 제한을 정의하고, limit는 단일 [[runners]] 워커의 최대 동시성을 정의합니다.

이 예에서, 러너 프로세스는 다음을 처리합니다:

[[runners]] 워커 전반에서 최대 100개의 동시 작업을 처리합니다.
first 워커에 대해 최대 40개의 작업을 쉘(executor)로 실행합니다.
second 워커에 대해 최대 30개의 작업을 Docker Machine executor로 실행합니다. 또한 Runner는 [runners.machine]의 자동 조정 구성을 유지하지만 여러 상태(대기, 사용 중, 생성 중, 제거 중)의 VM은 30개 이하로 유지합니다.
third 워커에 대해 최대 10개의 작업을 SSH(executor)로 실행합니다.
fourth 워커에 대해 최대 20개의 작업을 가상박스(executor)로 실행합니다.

두 번째 예에서, docker+machine executor를 사용하도록 구성된 두 개의 [[runners]] 워커가 있습니다. 이 구성에서 각 러너 워커는 limit 매개변수 값으로 제한된 별도의 VM 풀을 관리합니다.

concurrent = 100

[[runners]]
name = "first"
executor = "docker+machine"
limit = 80
(...)

[[runners]]
name = "second"
executor = "docker+machine"
limit = 50
(...)

이 예에서:

러너 프로세스는 100개의 작업( concurrent 값) 이상을 처리하지 않습니다.
러너 프로세스는 두 개의 [[runners]] 워커에서 작업을 실행하는데, 각각의 워커는 docker+machine executor를 사용합니다.
first 워커는 최대 80개의 VM를 생성할 수 있습니다. 따라서 이 러너는 언제든지 최대 80개의 작업을 실행할 수 있습니다.
second 워커는 최대 50개의 VM를 생성할 수 있습니다. 따라서 이 러너는 언제든지 최대 50개의 작업을 실행할 수 있습니다.

limit 값의 합은 130이지만, 전역 수준의 concurrent 값인 100은 이 러너 프로세스가 최대 100개의 작업을 동시에 실행할 수 있음을 의미합니다.

오토스케일링 알고리즘 및 매개변수

오토스케일링 알고리즘은 다음과 같은 매개변수를 기반으로 합니다:

IdleCount
IdleCountMin
IdleScaleFactor
IdleTime
MaxGrowthRate
limit

매개변수에 따라 실행되는 작업이 없는 각 기계는 Idle 상태에 있습니다. GitLab Runner가 오토스케일 모드인 경우 모든 기계를 모니터링하고 항상 Idle 상태의 IdleCount 개의 기계가 있는지 확인합니다.

GitLab Runner 14.5에서는 이 동작을 약간 변경하는 IdleScaleFactor 및 IdleCountMin 설정이 추가되었습니다. 자세한 정보는 해당 섹션을 참조하십시오.

Idle 기계 수가 부족한 경우, GitLab Runner는 MaxGrowthRate 제한에 따라 새 기계를 프로비저닝하기 시작합니다. MaxGrowthRate 값 이상의 기계 요청은 기계의 생성 수가 MaxGrowthRate보다 적어질 때까지 대기합니다.

동시에 GitLab Runner는 각 기계의 Idle 상태의 지속 시간도 확인합니다. 시간이 IdleTime 값을 초과하면 기계가 자동으로 제거됩니다.

예: 다음과 같이 GitLab Runner를 구성한 경우:

[[runners]]
  limit = 10
  # (...)
  executor = "docker+machine"
  [runners.machine]
    MaxGrowthRate = 1
    IdleCount = 2
    IdleTime = 1800
    # (...)

처음에는 대기 중인 작업이 없을 때, GitLab Runner는 Idle 상태의 두 개의 기계를 시작하고 설정된 IdleTime을 30분(IdleTime = 1800)으로 설정합니다.

이제, GitLab CI에 5개의 작업이 대기 중이라고 가정해봅시다. 처음 2개의 작업은 두 개의 Idle 기계로 보내집니다. GitLab Runner는 이제 Idle 개수가 IdleCount보다 적다는 것을 알고(0 < 2) 새로운 기계를 시작합니다. 증식률이 초과되지 않도록 새로운 기계를 순차적으로 프로비저닝합니다.

나머지 3개의 작업은 준비된 처음 기계에 할당됩니다. 이를 최적화로, 작업을 빠르게 시작할 수 있도록 준비된 기계 또는 새롭게 프로비저닝된 기계가 될 수 있습니다. 이 예에서는 프로비저닝이 빠르다고 가정하고, 이전 작업이 완료되기 전에 새로운 기계의 프로비저닝이 완료될 것입니다.

이제 Idle 기계가 1개 있으므로 GitLab Runner는 또 다른 1개의 새로운 기계를 시작하여 IdleCount를 충족시킵니다. 대기 중인 새로운 작업이 없으므로, 이 두 기계는 Idle 상태로 유지되고 GitLab Runner는 만족합니다.

이렇게 일어났습니다: 대기 중인 작업이 없는 상태에서 2개의 기계가 대기하고 있었습니다. 5개의 작업이 대기 중이고, 새로운 기계가 생성되어 총 7개의 기계가 있었습니다. 이 중 5개는 작업을 수행하고 2개는 Idle 상태로 다음 작업을 기다립니다.

알고리즘은 여전히 동일하게 작동합니다. GitLab Runner는 작업을 실행하려는 각 기계에 대해 새로운 Idle 기계를 생성하여 IdleCount가 충족될 때까지 생성합니다. 이러한 기계는 limit 매개변수로 정의된 수까지 만들어집니다. GitLab Runner는 limit 수의 전체 생성된 기계 수를 인식하면 오토스케일링을 중지하고, 새로운 작업은 기계가 다시 Idle 상태로 돌아갈 때까지 대기해야 합니다.

위 예시에서 항상 두 개의 대기 중인 기계가 있습니다. IdleTime은 IdleCount를 초과했을 때에만 적용됩니다. 그런 다음 기계 수를 IdleCount로 줄이도록 시도합니다.

축소: 작업이 완료되면, 기계는 Idle 상태로 설정되어 다음 작업을 실행하기를 기다립니다. 큐에 새 작업이 없다고 가정해봅시다. IdleTime에 지정된 시간이 경과하면 Idle 기계가 제거됩니다. 위 예에서는, 30분이 지나면 모든 기계가 제거됩니다(마지막 작업 실행 후 30분 후 발생). 그리고 GitLab Runner는 예시 처음과 마찬가지로 Idle 기계를 계속 유지합니다.

요약하면:

GitLab Runner를 시작합니다.
GitLab Runner는 2개의 Idle 기계를 생성합니다.
GitLab Runner는 작업 하나를 선택합니다.
GitLab Runner는 항상 두 개의 Idle 기계가 있는 강력한 요구 사항을 충족시키기 위해 기계 하나를 더 생성합니다.
작업이 완료되면 3개의 Idle 기계가 있습니다.
3개의 Idle 기계 중 하나가 작업을 마친 후 IdleTime이 초과되면 제거됩니다.
GitLab Runner는 항상 적어도 2개의 Idle 기계를 빠르게 작업 시작을 위해 대기상태로 유지합니다.

아래에서 시간에 따른 작업 상태 및 기계 상태를 비교한 차트를 확인할 수 있습니다.

`concurrent`, `limit` 및 `IdleCount`가 실행 중인 기계의 상한선을 생성하는 방법

limit 또는 concurrent를 설정하는 마법같은 방정식은 없습니다. 필요에 따라 작동하십시오. Idle 기계의 IdleCount는 속도 향상 기능입니다. 인스턴스가 생성되기까지 10초/20초/30초를 기다릴 필요가 없습니다. 그러나 사용자로서는 지불해야 하는 기계가 작업을 실행하는 것을 원하며 Idle 상태에 머무르지 않았으면 합니다. 따라서 concurrent와 limit를 지불할 의미 있는 기계 수로 설정해야합니다. IdleCount는 대기 중인 작업이 없는 경우에 미사용 기계의 최소량을 생성하는 값으로 설정해야합니다.

다음 예를 가정해 봅시다:

concurrent=20

[[runners]]
  limit = 40
  [runners.machine]
    IdleCount = 10

위 시나리오에서 생성할 수 있는 기계의 총 수는 30입니다. 기계의 총 수의 limit(대기 및 대기 중인 기계)은 40입니다. 10개의 Idle 기계를 가질 수 있지만, concurrent 작업은 20개입니다. 따라서 총 20개의 동시 작업 기계와 10개의 대기 중인 기계가 가능합니다.

그러나 limit가 생성 가능한 총 기계 수보다 적을 경우에는 어떻게 될까요? 아래 예제가 해당 사례를 설명합니다.

concurrent=20

[[runners]]
  limit = 25
  [runners.machine]
    IdleCount = 10

이 예에서 최대 20개의 동시 작업 및 25개의 기계를 가질 수 있습니다. 최악의 경우, limit가 25이므로 10개의 Idle 기계 대신 5개만 가능합니다.

`IdleScaleFactor` 전략

GitLab Runner 14.6에서 실험적인 기능으로 소개되었습니다.

IdleCount 매개변수는 runner가 유지해야 하는 Idle 기계의 정적 수를 정의합니다. 할당하는 값은 사용 사례에 따라 다릅니다.

작은 숫자의 Idle 기계를 시작하고 현재 사용량에 따라 자동으로 큰 수로 조정할 수 있습니다. 실험적인 IdleScaleFactor 설정을 사용하여 이러한 작업을 수행할 수 있습니다.

IdleScaleFactor는 내부적으로 float64 값이며 부동 소수점 형식이 사용되어야합니다. 예: 0.0, 1.0, 1.5 등. 정수 형식이 사용된다면(예: IdleScaleFactor = 1), Runner의 프로세스가 오류로 실패합니다. FATAL: Service run failed error=toml: cannot load TOML value of type int64 into a Go float.

이 설정을 사용하면 GitLab Runner는 Idle 상태의 기계 수를 유지하려고 합니다. 그러나 이 번호는 더 이상 정적이 아닙니다. GitLab Runner는 IdleCount를 사용하는 대신 현재 사용 중인 기계 수를 확인하고 현재 사용 중인 기계 수의 요인으로 정의된 원하는 Idle 용량을 결정합니다.

물론 현재 사용 중인 기계가 없는 경우, IdleScaleFactor는 유지할 Idle 기계가 없도록 평가됩니다. 오토스케일링 알고리즘의 동작 방식 때문에 IdleCount가 0보다 크면(그리고 이때만 IdleScaleFactor가 적용됨) Runner는 처리할 수 있는 Idle 기계가 없는 경우 작업을 요청하지 않을 것입니다. 새로운 작업이 없는 경우 사용 중인 기계 수가 상승하지 않기 때문에 IdleScaleFactor는 계속 0으로 평가됩니다. 이로 인해 Runner가 사용할 수 없는 상태로 차단됩니다.

따라서 두 번째 설정인 IdleCountMin을 소개했습니다. 이 설정은 IdleScaleFactor가 평가되는 최소 Idle 기계 수를 정의합니다. 이 설정은 IdleScaleFactor가 사용되는 경우 1 미만으로 설정할 수 없습니다. 그렇게 되면 Runner가 자동으로 1로 설정됩니다.

또한 IdleCountMin을 사용하여 항상 사용 가능한 최소 Idle 기계 수를 정의할 수 있습니다. 이를 통해 대기열에 들어가는 새 작업이 빠르게 시작될 수 있습니다. IdleCount와 마찬가지로 할당하는 값은 사용 사례에 따라 다릅니다.

예를들어:

concurrent=200

[[runners]]
  limit = 200
  [runners.machine]
    IdleCount = 100
    IdleCountMin = 10
    IdleScaleFactor = 1.1

이 경우 Runner가 결정점에 접근할 때 현재 사용중인 기계가 몇 대인지 확인합니다. 예를 들어 현재 5개의 Idle 기계가 있고 10대의 사용 중인 기계가 있습니다. IdleScaleFactor를 곱하면 Runner는 11개의 Idle 기계를 설정해야한다고 결정합니다. 따라서 6개가 더 생성됩니다.

90개의 Idle 기계와 100대의 사용 중인 기계가 있는 경우, IdleScaleFactor에 따라 지금 100 * 1.1 = 110대의 Idle 기계가 필요하다고 판단됩니다. 따라서 다시 새로운 기계가 생성됩니다. 그러나 100개의 Idle 기계 수가 IdleCount에 의해 상한선으로 설정되었다는 것을 인식하면 더 이상 Idle 기계가 생성되지 않습니다.

100개의 Idle 기계가 20개로 줄어들면, 원하는 Idle 기계 수는 20 * 1.1 = 22대이며 GitLab Runner는 기존의 기계를 천천히 종료하게됩니다. 위에서 설명한대로, IdleTime에 사용되지 않았던 기계들이 제거됩니다. 따라서 너무 많은 Idle VMs을 제거하지 못하게 됩니다.

만약 Idle 기계 수가 0으로 내려가면, 원하는 Idle 기계 수는 0 * 1.1 = 0입니다. 그러나, 이것은 정의된 IdleCountMin 설정보다 작은값이므로 Runner는 10개가 남을 때까지 천천히 Idle VMs을 제거하기 시작합니다. 이후, 축소가 멈추고 Runner는 10개의 기계를 Idle 상태로 유지합니다.

자동 스케일링 기간 구성

시간에 따라 다른 값으로 구성할 수 있습니다. 조직은 일정한 시간에 작업이 많이 실행되는 규칙적인 시간을 가질 수 있으며, 다른 시간에는 거의 또는 전혀 작업이 없는 시간을 가질 수 있습니다. 예를 들어, 대부분의 상업 회사는 월요일부터 금요일까지 10am부터 6pm과 같이 고정된 시간에 작업합니다. 주말 밤이나 주말에는 파이프라인이 시작되지 않습니다.

[[runners.machine.autoscaling]] 섹션의 도움으로 이러한 기간을 구성할 수 있습니다. 각 기간은 Periods 집합을 기반으로 IdleCount와 IdleTime을 설정합니다.

자동 스케일링 기간 작동 방식

[runners.machine] 설정에서 여러 [[runners.machine.autoscaling]] 섹션을 추가할 수 있으며, 각 섹션은 각자 별도의 IdleCount, IdleTime, Periods, Timezone 속성을 가집니다. 가장 일반적인 시나리오부터 가장 구체적인 시나리오까지 순서대로 각 구성에 대해 섹션을 정의해야 합니다.

모든 섹션이 구문 분석됩니다. 현재 시간과 일치하는 마지막 섹션이 활성화됩니다. 일치하는 섹션이 없으면 [runners.machine]의 루트에서 값을 사용합니다.

예를 들어:

[runners.machine]
  MachineName = "auto-scale-%s"
  MachineDriver = "google"
  IdleCount = 10
  IdleTime = 1800
  [[runners.machine.autoscaling]]
    Periods = ["* * 9-17 * * mon-fri *"]
    IdleCount = 50
    IdleTime = 3600
    Timezone = "UTC"
  [[runners.machine.autoscaling]]
    Periods = ["* * * * * sat,sun *"]
    IdleCount = 5
    IdleTime = 60
    Timezone = "UTC"

이 구성에서 UTC 기준으로 매주 월요일부터 금요일까지 9시부터 16시 59분 사이에 기계는 운영 시간 동안 큰 트래픽을 처리하기 위해 과다하게 설정됩니다. 주말에는 IdleCount가 5로 설정되어 트래픽 감소를 반영합니다. 나머지 시간에는 루트의 기본값에서 값을 가져옵니다 - IdleCount = 10 및 IdleTime = 1800.

지정된 기간의 마지막 분에있는 59초는 기간의 일부로 *간주되지 않습니다. 자세한 내용은 이슈 #2170을 참조하십시오.

기간의 Timezone을 지정할 수 있습니다. 예를 들어 "Australia/Sydney"와 같이 구성할 수 있습니다. 그렇지 않으면 각 실행기의 호스트 기계의 시스템 설정이 사용됩니다. 이 기본값은 명시적으로 Timezone = "Local"로 명시할 수 있습니다.

[[runner.machine.autoscaling]] 섹션 구문의 구문에 대한 자세한 내용은 GitLab Runner - 고급 구성 - [runners.machine] 섹션에서 찾을 수 있습니다.

분산 러너 캐싱

분산 캐시 사용 방법은 여기에서 확인하십시오.

작업을 가속화 하기 위해 GitLab Runner는 선택한 디렉터리 및/또는 파일을 저장하고 후속 작업간에 공유하는 캐시 메커니즘을 제공합니다.

작업이 동일한 호스트에서 실행될 때 이는 잘 작동하지만, GitLab Runner의 autoscale 기능을 사용하기 시작하면 대부분의 작업이 새로운 (또는 거의 새로운) 호스트에서 실행되어 각 작업을 새 Docker 컨테이너에서 실행하게 됩니다. 이러한 경우 캐시 기능을 활용할 수 없습니다.

이 문제를 극복하기 위해, autoscale 기능과 함께 분산 러너 캐시 기능이 소개되었습니다.

이 기능은 구성된 객체 스토리지 서버를 사용하여 사용된 Docker 호스트 간에 캐시를 공유합니다. GitLab Runner는 서버를 쿼리하여 아카이브를 다운로드하여 캐시를 복원하거나, 캐시를 아카이브하여 업로드합니다.

분산 캐싱을 활성화하려면 config.toml에서 [runners.cache] 지시어를 정의해야 합니다:

[[runners]]
  limit = 10
  executor = "docker+machine"
  [runners.cache]
    Type = "s3"
    Path = "path/to/prefix"
    Shared = false
    [runners.cache.s3]
      ServerAddress = "s3.example.com"
      AccessKey = "access-key"
      SecretKey = "secret-key"
      BucketName = "runner"
      Insecure = false

위 예에서 S3 URL은 구조를 따릅니다 http(s)://<ServerAddress>/<BucketName>/<Path>/runner/<runner-id>/project/<id>/<cache-key>.

여러 개의 러너 간에 캐시를 공유하려면 Shared 플래그를 true로 설정합니다. 이 플래그는 URL에서 러너 토큰을 제거하여 (runner/<runner-id>) 모든 구성된 러너가 동일한 캐시를 공유합니다. 캐시 공유가 활성화된 경우 러너 간에 별도의 캐시를 설정할 수 있도록 Path를 설정할 수 있습니다.

분산 컨테이너 레지스트리 미러링

Docker 컨테이너 내에서 실행된 작업을 가속화하기 위해 Docker 레지스트리 미러링 서비스를 사용할 수 있습니다. 이 서비스는 Docker 머신과 모든 사용된 레지스트리 사이에 프록시를 제공합니다. 이미지는 레지스트리 미러에서 한 번 다운로드됩니다. 각 호스트에서는 이미지가 존재하지 않는 새 호스트 또는 기존 호스트에서 이미지가 다시 구성된 레지스트리에서 다운로드됩니다.

Docker 머신 LAN에 미러가 있는 경우 각 호스트에서 이미지 다운로드 단계는 훨씬 더 빨라야 합니다.

Docker 레지스트리 미러링을 구성하려면 config.toml에 MachineOptions를 추가해야 합니다:

[[runners]]
  limit = 10
  executor = "docker+machine"
  [runners.machine]
    (...)
    MachineOptions = [
      (...)
      "engine-registry-mirror=http://10.11.12.13:12345"
    ]

여기서 10.11.12.13:12345은 Docker 서비스에서 연결을 수신하기 위해 레지스트리 미러가 수신 대기하는 IP 주소와 포트입니다. 이 주소는 Docker Machine에 의해 생성된 각 호스트에서 접근할 수 있어야 합니다.

컨테이너를 위한 프록시를 이용하는 방법에 대해 더 알아보려면 여기에서 확인하십시오.

`config.toml`의 전체 예제

아래의 config.toml은 google Docker Machine 드라이버를 사용합니다:

concurrent = 50   # 등록된 모든 러너는 최대 50개의 작업을 실행할 수 있습니다.

[[runners]]
  url = "https://gitlab.com"
  token = "RUNNER_TOKEN"             # gitlab-runner register에 사용된 등록 토큰과는 다름에 유의
  name = "autoscale-runner"
  executor = "docker+machine"        # 이 러너는 'docker+machine' executor를 사용합니다.
  limit = 10                         # 이 러너는 최대 10개의 작업(생성된 머신)을 실행할 수 있습니다.
  [runners.docker]
    image = "ruby:2.7"               # 작업에 사용되는 기본 이미지는 'ruby:2.7'입니다.
  [runners.machine]
    IdleCount = 5                    # Off Peak 시간 모드가 꺼진 경우 5개의 머신이 비활성 상태여야 합니다.
    IdleTime = 600                   # 각 머신은 600초까지 비활성 상태가 될 수 있으며(이 후에 제거됨) - Off Peak 시간 모드가 꺼진 경우
    MaxBuilds = 100                  # 각 머신은 최대 100개의 작업을 연속으로 처리할 수 있으며(이 후에 제거됨)
    MachineName = "auto-scale-%s"    # 각 머신은 고유한 이름을 가져야 합니다. ('%s'가 필요함)
    MachineDriver = "google"         # Google Compute Engine에 호스팅된 머신을 생성하는 Docker Machine 문서를 참조하십시오. (https://docs.docker.com/machine/drivers/gce/#credentials)
    MachineOptions = [
      "google-project=GOOGLE-PROJECT-ID",
      "google-zone=GOOGLE-ZONE",            # 예: 'us-central-1'
      "google-machine-type=GOOGLE-MACHINE-TYPE",         # 예: 'n1-standard-8'
      "google-machine-image=ubuntu-os-cloud/global/images/family/ubuntu-1804-lts",
      "google-username=root",
      "google-use-internal-ip",
      "engine-registry-mirror=https://mirror.gcr.io"
    ]
    [[runners.machine.autoscaling]]  # 다른 설정을 가진 기간을 정의합니다.
      Periods = ["* * 9-17 * * mon-fri *"]   # 매주 월요일부터 금요일까지 9시부터 17시까지 UTC
      IdleCount = 50
      IdleCountMin = 5
      IdleScaleFactor = 1.5   # 현재 사용 중인 머신의 1.5배만큼의 비활성 머신이며, 최대 50(IdleCount의 값) 이상이거나 최소 5(IdleCountMin의 값) 이하여야 합니다.
      IdleTime = 3600
      Timezone = "UTC"
    [[runners.machine.autoscaling]]
      Periods = ["* * * * * sat,sun *"]   # 주말에는
      IdleCount = 5
      IdleTime = 60
      Timezone = "UTC"
  [runners.cache]
    Type = "s3"
    [runners.cache.s3]
      ServerAddress = "s3.eu-west-1.amazonaws.com"
      AccessKey = "AMAZON_S3_ACCESS_KEY"
      SecretKey = "AMAZON_S3_SECRET_KEY"
      BucketName = "runner"
      Insecure = false

Docker Machine Executor autoscale configuration

개요

시스템 요구 사항

지원되는 클라우드 제공업체

Runner 구성

Runner 글로벌 옵션

`[[runners]]` 옵션

`[runners.machine]` 옵션

`[runners.cache]` 옵션

추가 구성 정보

Docker Machine executor가 생성하는 VM의 수 제한하기

오토스케일링 알고리즘 및 매개변수

`concurrent`, `limit` 및 `IdleCount`가 실행 중인 기계의 상한선을 생성하는 방법

`IdleScaleFactor` 전략

자동 스케일링 기간 구성

분산 러너 캐싱

분산 컨테이너 레지스트리 미러링

`config.toml`의 전체 예제

도움말

기능 사용 가능성과 제품 평가판

도움받기

Docker Machine Executor autoscale configuration

개요

시스템 요구 사항

지원되는 클라우드 제공업체

Runner 구성

Runner 글로벌 옵션

[[runners]] 옵션

[runners.machine] 옵션

[runners.cache] 옵션

추가 구성 정보

Docker Machine executor가 생성하는 VM의 수 제한하기

오토스케일링 알고리즘 및 매개변수

concurrent, limit 및 IdleCount가 실행 중인 기계의 상한선을 생성하는 방법

IdleScaleFactor 전략

자동 스케일링 기간 구성

분산 러너 캐싱

분산 컨테이너 레지스트리 미러링

config.toml의 전체 예제

도움말

기능 사용 가능성과 제품 평가판

도움받기

`[[runners]]` 옵션

`[runners.machine]` 옵션

`[runners.cache]` 옵션

`concurrent`, `limit` 및 `IdleCount`가 실행 중인 기계의 상한선을 생성하는 방법

`IdleScaleFactor` 전략

`config.toml`의 전체 예제