Docker Machine Executor autoscale configuration

Tier: Free, Premium, Ultimate Offering: GitLab.com, 자체 관리
  • 자동 스케일링 기능은 GitLab Runner 1.1.0에서 소개되었습니다.
note
Docker Machine executor는 GitLab 17.5에서 사용 중지되었습니다. AWS(Amazon Web Services) EC2, Microsoft Azure Compute, 또는 Google Compute Engine(GCE)에서 Docker Machine executor를 사용 중이라면 GitLab Runner Autoscaler로 이관하세요.

자동 스케일링을 통해 리소스를 더 유연하고 동적으로 사용할 수 있습니다.

GitLab Runner는 자동 스케일링을 통해 인프라가 필요한 시점에 필요한 빌드 인스턴스만 포함되도록 설정할 수 있습니다. GitLab Runner를 자동 스케일링으로만 구성한다면, GitLab Runner가 설치된 시스템은 생성하는 모든 머신들의 보루 역할을 합니다. 이 머신은 “Runner Manager”로 참조됩니다.

note
Docker는 Docker Machine을 사용한 runner의 퍼브로운 기술인 Docker Machine을 사용 중지했습니다. Docker Machine 사용 중지에 대한 전략에 대한 논의를 보려면 이슈를 참조하세요.

Docker Machine 자동 크기 조정기는 limit 및 concurrent 구성과 무관하게 VM 당 하나의 컨테이너를 만듭니다.

개요

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

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

자동 스케일링 실제 예시

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

시스템 요구 사항

자동 스케일링을 구성하기 전에, 다음을 처리해야 합니다:

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

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

Runner 구성

이 섹션에서 중요한 자동 스케일 구성 매개변수를 설명합니다. 자세한 구성 세부 정보는 고급 구성을 참조하세요.

Runner 전역 옵션

매개변수 값 설명
concurrent integer 전역적으로 동시에 실행될 수 있는 작업 수를 제한합니다. 이는 지정된 모든 러너, 로컬 및 자동 스케일링 러너를 사용하는 모든 작업의 최상위 제한입니다. limit(from [[runners]] section) 및 IdleCount(from [runners.machine] section)와 함께 이 작업의 상한선에 영향을 줍니다.

[[runners]] 옵션

매개변수 값 설명
executor string 자동 스케일링 기능을 사용하려면 executor를 docker+machine으로 설정해야 합니다.
limit integer 이 특정 토큰으로 동시에 처리할 수 있는 작업 수를 제한합니다. 0은 제한 없음을 의미합니다. 자동 슼케일링을 위해, 이것은 이 제공자가 생성하는 머신들의 상한값입니다 (concurrent 및 IdleCount와 함께 작동).

[runners.machine] 옵션

구성 매개변수 세부 정보는 GitLab Runner - 고급 구성 - [runners.machine] 섹션에서 찾을 수 있습니다.

[runners.cache] 옵션

구성 매개변수 세부 정보는 GitLab Runner - 고급 구성 - [runners.cache] 섹션에서 찾을 수 있습니다.

추가 구성 정보

IdleCount = 0로 설정하는 특별한 모드도 있습니다. 이 모드에서는 작업을 시작하기 전마다 기계들이 항상 요청에 따라 생성됩니다 (Idle 상태에서 사용 가능한 기계가 없는 경우). 작업이 완료된 후, 자동 스케일 알고리즘은 아래 설명된 것과 동일하게 작동합니다. 기계는 다음 작업을 기다리다가 어떤 것이 실행되지 않으면 IdleTime 시간이 지나면 제거됩니다. 작업이 없으면 Idle 상태에 기계가 없습니다.

IdleCount는 0보다 큰 값으로 설정하는 경우, 비어있는 VMs이 백그라운드에서 생성됩니다. 러너는 새 작업을 요청하기 전에 기존의 비어 있는 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
(...)

이 구성에서:

  • 하나의 러너 프로세스는 다른 실행 환경을 사용하여 4개의 다른 러너 워커를 만들 수 있습니다.
  • concurrent 값이 100으로 설정되어 있으므로, 이 하나의 러너는 최대 100개의 동시 GitLab CI/CD 작업을 실행합니다.
  • second 러너 워커만 Docker Machine executor를 사용하도록 설정되어 있으며, 따라서 자동으로 VM을 생성할 수 있습니다.
  • limit 설정이 30으로 설정되어 있으므로 second 러너 워커는 언제나 최대 30개의 CI/CD 작업을 동시에 수행할 수 있습니다. 또한 Runner는 [runners.machine]에서 자동 스케일링 구성에 따라 VM을 유지하지만, 모든 상태 (Idle, 사용 중, 생성 중, 제거 중)에서 최대 30개의 VM을 생성합니다.
  • concurrent는 여러 [[runners]] 워커 간의 전역 동시성 제한을 정의하고, limit는 단일 [[runners]] 워커에 대한 최대 동시성을 정의합니다.

다음 예에서는 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개의 작업을 동시에 수행할 수 있습니다.
note
limit 값의 합이 130 (80 + 50 = 130)임에도 불구하고, 전역 수준의 concurrent 값이 100이므로이 러너 프로세스는 동시에 최대 100개의 작업을 실행할 수 있습니다.

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

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

  • IdleCount
  • IdleCountMin
  • IdleScaleFactor
  • IdleTime
  • MaxGrowthRate
  • limit

작업을 실행하지 않는 각 기계를 유휴 상태로 간주합니다. GitLab Runner가 오토스케일 모드인 경우 모든 기계를 모니터링하고 항상 IdleCount만큼의 기계가 유휴 상태에 있도록 보장합니다.

참고: GitLab Runner 14.5에서는 IdleScaleFactor 및 IdleCountMin 설정을 추가하여 이 동작을 약간 변경했습니다. 자세한 내용은 해당 섹션을 참조하세요.

예시: 다음과 같은 오토스케일 매개변수로 GitLab Runner를 구성했다고 가정해봅시다: 

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

처음에는 대기 중인 작업이 없을 때 GitLab Runner는 2개의 기계(IdleCount = 2)를 시작하고 유휴 상태로 설정합니다. IdleTime을 30분(IdleTime = 1800)으로 설정했음에 유의하세요.

이제 GitLab CI에 5개의 작업이 대기 중이라고 가정해봅시다. 처음 2개의 작업은 유휴 기계로 보내지며, 여기에 2대가 있습니다. GitLab Runner는 이제 IdleCount(0 < 2)보다 유휴의 수가 적다는 것을 알고, 새 기계를 시작합니다. 이 기계들은 MaxGrowthRate를 초과하지 않도록 순차적으로 구성됩니다.

나머지 3개의 작업은 준비된 첫 번째 기계에 할당됩니다. 최적화를 위해, 이 기계는 작업이 바쁜 상태였지만 지금은 완료된 기계일 수도 있고, 새로 구성된 기계일 수도 있습니다. 이 예제에서는 기계의 구성이 빠르고, 먼저 일찍 작업이 완료된 기계보다 앞서 완료됩니다.

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

발생한 일: 지금까지 2대의 기계가 새 작업을 기다리는 유휴 상태였습니다. 5개의 작업이 대기하게되면 새로운 기계가 생성되어 총 7대가 되었습니다. 그 중 5대는 작업을 실행하고, 2대는 다음 작업을 기다리는 유휴 상태입니다.

알고리즘은 여전히 동일하게 작동합니다. GitLab Runner는 각 기계에 대해 작업 실행을 위해 새로운 유휴 기계를 생성합니다(IdleCount를 충족할 때까지). 이러한 기계들은 limit 매개변수로 정의된 수까지 생성됩니다. GitLab Runner는 총 생성된 기계의 수가 limit에 도달하면 오토스케일을 중지하고 새 작업은 기다려야 합니다.

위의 예에서 우리는 항상 두 대의 유휴 기계가 있습니다. IdleTime은 IdleCount를 초과한 경우에만 적용됩니다. 그런 다음 기계 수를 IdleCount로 줄이려고 시도합니다.

축소: 작업이 완료된 후 기계는 유휴 상태로 설정되어 다음 작업의 실행을 기다립니다. 대기 중인 작업이 없다고 가정해보겠습니다. IdleTime이 지난 후에 유휴 기계가 제거됩니다. 위의 예에서는 30분 후에 모든 기계가 제거되며, GitLab Runner는 예제의 처음과 같이 유휴 기계 수만큼 기계를 계속 실행합니다.

그래서 요약하면:

  1. GitLab Runner를 시작합니다.
  2. GitLab Runner는 2대의 유휴 기계를 생성합니다.
  3. GitLab Runner는 작업을 선택합니다.
  4. GitLab Runner는 항상 2대의 유휴 기계가 있다는 강한 요구 사항을 충족하기 위해 1대의 추가 기계를 생성합니다.
  5. 작업이 완료되면 3대의 유휴 기계가 있습니다.
  6. 3대 중 하나가 마지막으로 작업을 선택한 후 IdleTime을 초과하면 제거됩니다.
  7. GitLab Runner는 항상 최소한 2대의 유휴 기계가 빠르게 작업을 선택하기 위해 기다립니다.

아래에서는 시간에 따른 작업 상태 및 기계 상태를 비교한 차트를 볼 수 있습니다:

Autoscale state chart

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

limit 또는 concurrent를 설정하기 위한 마법 같은 방정식은 존재하지 않습니다. 필요에 따라 작용하세요. IdleCount의 유휴 기계는 가속 기능입니다. 인스턴스가 생성되기까지 10초/20초/30초를 기다릴 필요가 없습니다. 그러나 사용자로서, 지불해야 하는 모든 기계가 작업을 실행하기를 원하며 유휴 상태가 아닌 상태에 머물지 않기를 원합니다. 따라서 concurrent와 limit를 지불할 의사가 있는 최대 기계 수에 맞게 설정해야 합니다. IdleCount의 경우, 작업 대기열이 비어 있을 때 미사용 기계의 최소한의 양을 생성하는 값을 설정해야 합니다.

다음과 같은 예시가 있다고 가정해봅시다: 

concurrent=20

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

위의 시나리오에서 우리가 가질 수 있는 기계의 총 수는 30대입니다. 총 기계 수의 limit(구성 및 유휴 상태를 합침)은 40입니다. 10대의 유휴 기계를 가질 수 있지만 concurrent 작업은 20개입니다. 그래서 총 20대의 동시 실행 기계와 10대의 유휴 기계를 가질 수 있으며, 합산하여 30대가 됩니다.

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

concurrent=20

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

이 예시에서 최대 20개의 동시 작업 및 25대의 기계가 가능합니다. 최악의 경우에는 limit이 25이기 때문에 10대가 아닌 5대의 유휴 기계만 가질 수 있습니다.

IdleScaleFactor 전략

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 상태의 정의된 머신 수를 유지하려고 노력합니다. 그러나 이 수는 더 이상 정적이지 않습니다. IdleCount 대신에 GitLab Runner는 현재 사용 중인 머신 수를 확인하고 그 수의 배수로 원하는 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에 따라 GitLab Runner는 100 * 1.1 = 110 개의 Idle 머신을 유지해야 한다고 판단합니다. 따라서 다시 새로운 머신을 생성합니다. 그러나 IdleCount에 의해 상한선이 정의되었음을 인식하면 추가적인 Idle 머신은 생성되지 않습니다.

그렇게 사용 중인 100개의 Idle 머신이 20개로 줄어든다면, 원하는 Idle 머신의 수는 20 * 1.1 = 22 이기에, GitLab Runner는 천천히 머신을 종료하기 시작합니다. 앞서 설명한 것과 같이, GitLab Runner는 IdleTime 동안 사용되지 않은 머신을 제거합니다. 그러므로 너무 과하게 Idle 머신을 제거하지 않습니다.

Idle 머신 수가 0이 되면, 원하는 Idle 머신의 수는 0 * 1.1 = 0입니다. 그러나 이는 정의된 IdleCountMin 설정보다 적기 때문에, Runner는 천천히 Idle 머신을 제거하기 시작합니다. 그 이후에 스케일 다운이 멈추고 Runner는 Idle 상태로 10개의 머신을 유지합니다.

자동 스케일링 기간 구성

시간 대에 따라 자동 스케일링을 구성할 수 있습니다. 조직은 작업이 대량으로 실행되는 정규 시간대와 작업이 거의 없는 시간대를 갖는 경우가 있습니다. 예를 들어 대부분의 상업 회사들은 월요일부터 금요일까지 오전 10시에서 오후 6시까지 고정된 시간에 일합니다. 일 및 주말의 밤 동안, 그리고 주말에는 파이프라인이 시작되지 않습니다.

이러한 시기는 [[runners.machine.autoscaling]] 섹션의 Periods를 사용하여 구성할 수 있습니다. 각각은 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시부터 오후 4:59까지, 머신은 운영 시간 동안 대규모 트래픽을 처리할 수 있도록 초과 공급됩니다. 주말에는 IdleCount가 트래픽 감소를 반영하여 5로 감소합니다. 나머지 시간에는 루트 내의 기본값인 IdleCount = 10 및 IdleTime = 1800이 사용됩니다.

참고: 지정한 기간의 마지막 분의 59초는 해당 기간의 일부가 아닙니다. 자세한 내용은 issue #2170을 참조하십시오.

Timezone을 지정할 수 있으며, 예를 들어 "Australia/Sydney"로 설정할 수 있습니다. 설정하지 않으면 각 Runner의 호스트 머신의 시스템 설정이 사용됩니다. 이 기본값은 명시적으로 Timezone = "Local"로 명시할 수 있습니다.

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

분산 러너 캐싱

참고: 분산 캐시를 사용하는 방법을 읽어보세요.

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

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

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

이 기능은 구성된 객체 저장 서버를 사용하여 사용된 도커 호스트 간에 캐시를 공유합니다. GitLab 러너는 서버에 쿼리를 보내 캐시를 복원할 아카이브를 다운로드하거나 캐시 아카이브를 업로드합니다.

분산 캐싱을 활성화하려면 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를 설정하여 러너 간에 별도의 캐시를 구분할 수 있습니다.

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

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

도커 머신 LAN에 미러가 있는 경우 각 호스트에서 이미지 다운로드 단계가 훨씬 빨라질 것입니다.

도커 레지스트리 미러링을 구성하려면 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는 레지스트리 미러가 도커 서비스에서의 연결을 수신하는 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' 실행기를 사용합니다
  limit = 10                         # 이 러너는 최대 10개의 작업(생성된 머신)을 실행할 수 있습니다
  [runners.docker]
    image = "ruby:2.7"               # 작업에 사용되는 기본 이미지는 'ruby:2.7'입니다
  [runners.machine]
    IdleCount = 5                    # 5개의 머신이 유휴 상태에 있어야 합니다 - 평소 시간 배제 모드가 꺼져 있는 경우
    IdleTime = 600                   # 각 머신은 최대 600초 동안 유휴 상태에 있을 수 있습니다(이후 제거됨) - 평소 시간 배제 모드가 꺼져 있는 경우
    MaxBuilds = 100                  # 각 머신은 연속해서 100개의 작업을 처리할 수 있습니다(이후 제거됨)
    MachineName = "auto-scale-%s"    # 각 머신은 고유한 이름을 가져야 합니다('%s'가 필요합니다)
    MachineDriver = "google" # Google Compute Engine에 호스팅되는 머신을 생성하도록 Docker Machine에서 사용하는 방법은 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시까지의 매 업무일
      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

MachineOptions 매개변수에는 Docker Machine이 Google Compute Engine에 호스팅되는 머신을 생성하기 위해 사용하는 google 드라이버의 옵션 및 Docker Machine 자체를 위한 옵션이 포함되어 있음을 참고하세요. (engine-registry-mirror).