Docker Machine Executor autoscale 구성

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의 사용을 중단했으며, 이것은 Public Cloud 가상 머신에서 실행중인 runner의 autoscale에 사용되는 기술입니다. Docker Machine의 중단에 대한 논의는 이 링크에서 확인할 수 있습니다.

개요

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

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

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

시스템 요구 사항

Autoscale을 구성하기 전에 다음을 해야 합니다:

자체 환경을 준비.
GitLab에서 제공하는 Docker Machine의 포크 버전을 선택적으로 사용하여 몇 가지 추가 수정사항 사용.

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

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

Runner 구성

이 섹션에서는 중요한 autoscale 매개변수를 설명합니다. 더 많은 구성 세부 정보는 고급 구성을 참조하세요.

Runner 전역 옵션

매개변수	값	설명
`concurrent`	정수	글로벌하게 동시에 실행될 수 있는 작업 수를 제한합니다. 이는 모든 정의된 러너, 로컬 및 autoscale을 사용하는 작업 수의 상위 제한입니다. `limit` (from `[[runners]]` section)과 `IdleCount` (from `[runners.machine]` section)과 함께 사용되어 생성된 머신의 상위 제한에 영향을 미칩니다.

`[[runners]]` 옵션

매개변수	값	설명
`executor`	문자열	Autoscale 기능을 사용하려면 `executor`를 `docker+machine`으로 설정해야 합니다.
`limit`	정수	이 특정 토큰에 의해 동시에 처리될 수 있는 작업 수를 제한합니다. `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으로 설정한 특별한 모드도 있습니다. 이 모드에서는 작업이 실행되기 전에 각 작업 전에 머신이 항상 요구에 따라 생성됩니다 (실행 대기 중인 머신이 없는 경우). 작업이 완료되면, autoscaling 알고리즘이 아래 설명된대로 동일하게 작동합니다. 머신은 다음 작업을 기다리고, 실행되는 작업이 없으면 IdleTime 기간 후에 제거됩니다. 작업이 없으면 실행 중인 머신이 없습니다.

IdleCount를 0보다 큰 값으로 설정하면, 대기 중인 VM이 배경에서 생성됩니다. 러너는 새 작업을 요청하기 전에 기존의 대기 중인 VM을 획득합니다.

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

Docker Machine executor에 의해 생성된 가상 머신 수 제한

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

concurrent 매개변수는 가상 머신의 수를 제한하지 않습니다.

여기에서 자세히 설명된대로, 하나의 프로세스는 여러 러너 작업을 관리할 수 있습니다.

이 예시는 한 러너 프로세스에 설정된 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 작업을 병행하여 실행합니다.
두 번째 러너 작업만 Docker Machine executor를 사용하도록 구성되었으며, 따라서 자동으로 VMs를 만들 수 있습니다.
limit 설정인 30은 두 번째 러너 작업이 언제나 최대 30개의 CI/CD 작업을 동시에 실행할 수 있음을 의미합니다. concurrent는 여러 [[runners]] 작업에 대한 전역 병행성 제한을 정의하며, while limit는 단일 [[runners]] 작업에 대한 최대 병행성을 정의합니다.

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

모든 [[runners]] 작업에 대해 최대 100개의 병행 작업.
‘첫 번째’ 작업에 대해 최대 40개의 작업(‘shell’ executor를 사용하여 실행됨).
‘두 번째’ 작업에 대해 최대 30개의 작업(‘docker+machine’ executor를 사용하여 실행 됨). 추가로, Runner는 [runners.machine]의 autoscale 구성에 따라 VMs를 유지하지만 모든 상태(idle, 사용 중, 생성 중, 제거 중)에서 최대 30개의 VMs까지만.
‘세 번째’ 작업에 대해 최대 10개의 작업(‘ssh’ executor를 사용하여 실행 됨).
‘네 번째’ 작업에 대해 최대 20개의 작업(‘virtualbox’ executor를 사용하여 실행됨). 그두 번째 예에서, ‘docker+machine’ executor를 사용하는 두 개의 ‘[[runners]]’ 작업이 구성되어 있습니다. 이 구성으로 인해 각 러너 작업은 limit 매개변수의 값으로 제한되는 별도의 VMs 풀을 관리합니다.

concurrent = 100

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

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

이 예시에서:

러너 프로세스는 최대 100개의 작업을 처리합니다 (concurrent 값).
러너 프로세스는 두 개의 ‘[[runners]]’ 작업에서 작업을 실행하며, 각각은 ‘docker+machine’ executor를 사용합니다.
‘첫 번째’ 러너는 최대 80개의 VMs를 생성할 수 있습니다. 따라서 이 러너는 언제나 최대 80개의 작업을 동시에 실행할 수 있습니다.
‘두 번째’ 러너는 최대 50개의 VMs를 생성할 수 있습니다. 따라서 이 러너는 언제나 최대 50개의 작업을 동시에 실행할 수 있습니다.

limit 값의 합이 130 (80 + 50 = 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가 2개의 기기를 시작하고(IdleCount = 2), 이들을 Idle 상태로 설정합니다. 또한 IdleTime을 30분(IdleTime = 1800)으로 설정했음에 주목하십시오.

이제 GitLab CI에 5개의 작업이 대기 중이라고 가정해 봅시다. 처음 2개의 작업은 가용한 2대의 Idle 기기로 전송됩니다. 그러나 GitLab Runner는 Idle 기기 수가 IdleCount보다 적다는 것을 감지하여(0 < 2) 새로운 기기를 시작합니다. 이러한 기기는 MaxGrowthRate를 초과하지 않도록 순차적으로 프로비저닝됩니다.

남은 3개의 작업은 준비된 첫 번째 기기에 할당됩니다. 최적화로 인해, 이는 이전에 사용 중이었지만 이제 작업이 완료된 기기이거나 새로 프로비저닝된 기기가 될 수 있습니다. 이 예에서는 프로비저닝이 빠르다고 가정하고, 이전의 작업이 완료되기 전에 새로운 기기의 프로비저닝이 완료됩니다.

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

발생한 일: 대기 중인 작업이 없도록 2대의 기기가 Idle 상태로 대기하고 있었습니다. 5개의 작업이 대기 중이고, 그에 따라 새로운 기기가 생성되었으므로 총 7대의 기기가 있었습니다. 이 중 5대는 작업을 실행하고, 2대는 다음 작업을 대기하고 있었습니다.

알고리즘은 여전히 동일하게 작동합니다. GitLab Runner는 IdleCount가 충족될 때까지 각 작업 실행용 기기마다 새로운 Idle 기기를 만듭니다. 이들 기기는 limit 매개변수로 정의된 수까지 생성됩니다. GitLab Runner가 총 생성된 기기 수가 limit 숫자라는 것을 감지하면 오토스케일링을 중지하고 새로운 작업은 기기가 다시 Idle 상태로 돌아올 때까지 작업 대기열에서 대기해야 합니다.

위 예시에서 항상 2대의 idle 기기가 있습니다. IdleTime은 IdleCount를 초과하는 경우에만 적용됩니다. 그럼 우리는 기기 수를 IdleCount로 줄이려고 합니다.

축소: 작업이 완료되면, 기기는 Idle 상태로 설정되어 다음 작업을 실행할 준비를 기다립니다. 대기 중인 작업이 대기열에 없다고 가정해 봅시다. IdleTime으로 지정된 시간이 지나면 Idle 기기가 제거됩니다. 이 예시에서는 30분이 지난 후에 모든 기기가 제거되고(GitLab Runner가 처음 예시와 같이 Idle 기기를 유지하기 시작합니다.)

요약하면 다음과 같습니다:

GitLab Runner를 시작합니다.
GitLab Runner는 2대의 idle 기기를 만듭니다.
GitLab Runner가 작업을 선택합니다.
GitLab Runner는 항상 2대의 idle 기기를 보유하는 강한 요구 사항을 충족시키기 위해 하나의 기기를 더 만듭니다.
작업이 완료되면 우리는 3대의 idle 기기를 가지게 됩니다.
3대의 idle 기기 중 1대의 기기가 작업을 선택한 시점에서부터 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대입니다. 총 기기(구축 중 및 idle)의 limit는 40입니다. 10대의 idle 기기를 가질 수 있지만 concurrent 작업은 20입니다. 따라서 총 20개의 동시 작업 중인 기기와 10개의 idle 기기를 가질 수 있으며, 총 30대가 됩니다.

그러나 limit가 생성될 수 있는 총 기기 수보다 작으면 어떻게 될까요? 아래 예시에서 해당 사례에 대해 설명합니다:

concurrent=20

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

이 예시에서 최대 20개의 동시 작업 및 25대의 기기를 실행할 수 있습니다. 최악의 경우, limit가 25이므로 10대가 아닌 5대의 idle 기기를 가질 수 있습니다.

`IdleScaleFactor` 전략

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

IdleCount 매개변수는 유휴 상태를 유지해야 하는 러너의 정적인 머신 수를 정의합니다. 할당하는 값은 사용 사례에 따라 다릅니다.

사용 사례에 따라 합리적인 작은 수의 머신을 유휴 상태로 할당한 다음, 현재 사용량에 따라 더 큰 수로 자동 조절할 수 있습니다. 이를 위해 실험적인 IdleScaleFactor 설정을 사용합니다.

IdleScaleFactor는 내부적으로 float64 값이며 부동 소수점 형식을 요구합니다. 예: 0.0, 1.0, 1.5 등이 사용됩니다. 정수 형식을 사용하는 경우(예: IdleScaleFactor = 1), 러너의 프로세스는 다음과 같은 오류로 실패합니다: FATAL: Service run failed error=toml: cannot load TOML value of type int64 into a Go float.

이 설정을 사용할 때 GitLab Runner는 유휴 상태의 기계 수를 유지하려고 합니다. 그러나 이제 이 숫자는 정적이 아닙니다. IdleCount 대신 GitLab Runner는 현재 사용 중인 머신 수를 확인하고 해당 수의 인수로 원하는 유휴 용량을 정의합니다.

물론 현재 사용 중인 머신이 없는 경우 IdleScaleFactor는 유지해야 할 유휴 머신이 평가되지 않습니다. 오토스케일링 알고리즘이 작동하는 방식 때문에 IdleCount가 0보다 크면 (그리고 그때만 IdleScaleFactor가 적용됨), 러너는 처리할 수 있는 유휴 머신이 없는 경우에 작업을 요청하지 않을 것입니다. 새로운 작업 없이 사용된 머신 수는 늘어나지 않으므로 IdleScaleFactor는 계속해서 0으로 평가됩니다. 이는 러너를 사용할 수 없는 상태로 차단합니다.

따라서 우리는 두 번째 설정을 도입했습니다: IdleCountMin. 이 설정은 IdleScaleFactor가 평가될 수 있던 형통하지 않는 최소 유휴 머신 수를 정의합니다. 이 설정은 IdleScaleFactor가 사용되는 경우 1보다 적게 설정할 수 없습니다. 그렇게 하면 러너가 자동으로 1로 설정됩니다.

또한 IdleCountMin을 사용하여 항상 사용 가능해야 하는 최소 유휴 머신 수를 정의할 수 있습니다. IdleCount와 마찬가지로 할당하는 값은 사용 사례에 따라 달라집니다.

예를 들어:

concurrent=200

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

이 경우, 러너가 결정점에 다가갈 때, 현재 사용 중인 머신 수를 확인합니다. 현재 5개의 유휴 머신과 10개의 사용 중인 머신이 있다고 가정해 봅시다. IdleScaleFactor로 곱한 결과, 러너는 11개의 유휴 머신을 가져야 한다고 결정합니다. 따라서 6개가 더 생성됩니다.

90개의 유휴 머신과 100개의 사용 중인 머신이 있다면, IdleScaleFactor에 따라 GitLab Runner는 100 * 1.1 = 110개의 유휴 머신을 가져야 한다고 판단합니다. 따라서 다시 새로운 머신을 생성합니다. 그러나 IdleCount이 정의한 상한인 100 유휴 머신에 도달하면, 유휴 머신이 더 이상 생성되지 않음을 인식합니다.

사용 중인 100개의 유휴 머신이 20개로 줄어든 경우, 원하는 유휴 머신의 수는 20 * 1.1 = 22이며, GitLab Runner는 천천히 머신을 종료합니다. 앞서 설명한 대로, GitLab Runner는 IdleTime에 사용되지 않은 머신을 제거할 것입니다. 따라서 너무 과도하게 유휴 VM을 제거하지는 않습니다.

유휴 머신 수가 0으로 감소하면, 원하는 유휴 머신의 수는 0 * 1.1 = 0입니다. 그러나, 이는 IdleCountMin 설정보다 작은 값이므로, 러너는 천천히 유휴 VM을 제거하기 시작할 것입니다. 그 이후에는 스케일다운이 멈추고 러너는 10개의 머신을 유휴 상태로 유지합니다.

오토스케일링 기간 구성

오토스케일링은 시간대에 따라 다른 값을 구성할 수 있습니다. 기관은 실행되는 작업의 급증이 발생하는 정기적인 시기와 작업이 거의 없거나 아예 없는 다른 시기를 가질 수 있습니다. 예를 들어 대부분의 상업 회사는 월요일부터 금요일까지 10시부터 18시까지의 고정된 시간에 작업을 합니다. 나머지 시간에는 작업을 시작하지 않습니다.

이러한 기간은 [[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 - Advanced Configuration - The [runners.machine] section에서 확인할 수 있습니다.

Off peak time mode configuration (제거됨)

이 기능은 GitLab 14.0에서 제거되었습니다. 대신 자동 스케일링 기간을 사용하세요.

분산 실행기 캐싱

분산 캐시 사용 방법은 분산 캐시 사용을 참조하세요.

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

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

이 문제를 극복하기 위해 자동 스케일 기능과 함께 분산 실행기 캐시 기능이 도입되었습니다.

이 기능은 구성된 오브젝트 스토리지 서버를 사용하여 사용된 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 time mode가 꺼진 경우)Idle 상태의 머신이 5개 있어야 합니다
    IdleTime = 600                   # (Off Peak time mode가 꺼진 경우)각 머신은 최대 600초 동안 Idle 상태일 수 있습니다(이후에는 제거됨)
    MaxBuilds = 100                  # 각 머신은 연속해서 최대 100개의 작업을 처리할 수 있습니다(이후에는 제거됨)
    MachineName = "auto-scale-%s"    # 각 머신에는 고유한 이름이 있어야 합니다('"%s"`가 필요합니다)
    MachineDriver = "google" # Docker Machine을 통해 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 *"] # 매주 월요일부터 금요일까지 UTC 9시부터 17시까지
      IdleCount = 50
      IdleCountMin = 5
      IdleScaleFactor = 1.5 # 현재 사용 중인 머신 수가 1.5배되는 것을 의미하며, IdleCount 값(50)을 초과하지 않고 IdleCountMin 값(5)보다 작아지지 않습니다
      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

MachineOptions 매개변수에는 Google Compute Engine에 호스팅된 머신을 생성하는 데 사용되는 google 드라이버에 대한 옵션이 포함되어 있습니다. 그리고 Docker Machine 자체에 대한 하나의 옵션이 있습니다(engine-registry-mirror).

On this page

Docker Machine Executor autoscale 구성

개요

시스템 요구 사항

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

Runner 구성

Runner 전역 옵션

`[[runners]]` 옵션

`[runners.machine]` 옵션

`[runners.cache]` 옵션

추가 구성 정보

Docker Machine executor에 의해 생성된 가상 머신 수 제한

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

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

`IdleScaleFactor` 전략

오토스케일링 기간 구성

Off peak time mode configuration (제거됨)

분산 실행기 캐싱

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

`config.toml`의 완전한 예제

도움말

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

도움받기

On this page

On this page

Docker Machine Executor autoscale 구성

개요

시스템 요구 사항

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

Runner 구성

Runner 전역 옵션

[[runners]] 옵션

[runners.machine] 옵션

[runners.cache] 옵션

추가 구성 정보

Docker Machine executor에 의해 생성된 가상 머신 수 제한

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

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

IdleScaleFactor 전략

오토스케일링 기간 구성

Off peak time mode configuration (제거됨)

분산 실행기 캐싱

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

config.toml의 완전한 예제

도움말

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

도움받기

On this page

`[[runners]]` 옵션

`[runners.machine]` 옵션

`[runners.cache]` 옵션

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

`IdleScaleFactor` 전략

`config.toml`의 완전한 예제