Docker Machine Executor 자동 스케일 구성

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed
  • 자동 스케일 기능은 GitLab Runner 1.1.0에서 도입되었습니다.
note
Docker Machine executor는 GitLab 17.5에서 사용 중단되었습니다.
Amazon Web Services (AWS) 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을 사용 중단했습니다. 사용 중단에 대한
전략 토론을 읽어보세요
자세한 내용은.

Docker Machine 자동 스케일러는 limit 및 concurrent
구성에 관계없이 각 VM당 하나의 컨테이너를 생성합니다.

개요

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

아래는 GitLab.com에서 GitLab Community Edition 프로젝트에 대해 테스트한
GitLab Runner 자동 스케일 기능의 실제 예입니다:

자동 스케일링의 실제 예

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

시스템 요구 사항

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

지원되는 클라우드 공급자

자동 스케일 메커니즘은 Docker Machine을 기반으로 합니다.
지원되는 모든 가상화 및 클라우드 공급자 매개변수는 GitLab에서 관리하는 Docker Machine의 포크에서 확인할 수 있습니다.

러너 구성

이 섹션에서는 중요한 자동 스케일 매개변수를 설명합니다.
자세한 구성 내용은
고급 구성을 읽어보세요.

러너 전역 옵션

매개변수 값 설명
concurrent 정수 전역적으로 동시에 실행할 수 있는 작업의 수를 제한합니다. 이는 모든 정의된 러너, 로컬 및 자동 스케일을 사용하는 작업 수의 가장 높은 상한선입니다. limit ([[runners]] 섹션에서) 및 IdleCount ([runners.machine] 섹션에서)과 함께, 생성된 머신의 상한선에 영향을 미칩니다.

[[runners]] 옵션

매개변수 값 설명
executor 문자열 자동 확장 기능을 사용하려면 executor를 docker+machine으로 설정해야 합니다.
limit 정수 이 특정 토큰이 동시에 처리할 수 있는 작업 수를 제한합니다. 0은 제한이 없음을 의미합니다. 자동 확장에 대해 이 값은 이 공급자가 생성하는 기계의 상한(동시성 및 IdleCount와 함께)입니다.

[runners.machine] 옵션

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

[runners.cache] 옵션

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

추가 구성 정보

IdleCount = 0으로 설정할 경우 특별한 모드도 있습니다. 이 모드에서는 작업마다 항상 필요에 따라 기계가 생성됩니다(사용 가능한 기계가 Idle 상태에 없을 경우). 작업이 완료된 후, 자동 확장 알고리즘은 아래 설명된 것과 같습니다. 기계는 다음 작업을 기다리며, 실행되는 작업이 없으면 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 러너 작업자가 자동 확장된 VM에서 최대 30개의 CI/CD 작업을 동시에 실행할 수 있음을 의미합니다.

  • concurrent는 여러 [[runners]] 작업자에 걸친 전역 동시성 제한을 정의하는 반면, limit은 단일 [[runners]] 작업자에 대한 최대 동시성을 정의합니다.

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

  • 모든 [[runners]] 작업자에 걸쳐 최대 100개의 동시 작업.

  • first 작업자의 경우 최대 40개의 작업, 이는 shell executor로 실행됩니다.

  • second 작업자의 경우 최대 30개의 작업, 이는 docker+machine executor로 실행됩니다. 추가로, 러너는 [runners.machine]의 자동 확장 구성에 따라 VM을 유지하지만, 모든 상태(유휴, 사용 중, 생성 중, 제거 중)에서 최대 30개의 VM을 유지합니다.

  • third 작업자의 경우 최대 10개의 작업, 이는 ssh executor로 실행됩니다.

  • fourth 작업자의 경우 최대 20개의 작업, 이는 virtualbox 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 값)을 수용합니다.

  • 러너 프로세스는 각각 docker+machine executor를 사용하는 두 개의 [[runners]] 작업자에서 작업을 실행합니다.

  • first 러너는 최대 80개의 VM을 생성할 수 있습니다. 따라서 이 러너는 언제든지 최대 80개의 작업을 실행할 수 있습니다.

  • second 러너는 최대 50개의 VM을 생성할 수 있습니다. 따라서 이러너는 언제든지 최대 50개의 작업을 실행할 수 있습니다.

note
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 설정을 추가하여 이 동작을 약간 변경하였습니다. 자세한 내용은 전용 섹션을 참조하세요.

IDel 머신의 수가 부족하면 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는 두 개의 머신(IdleCount = 2)을 시작하고 Idle 상태로 설정합니다. IdleTime을 30분(IdleTime = 1800)으로 설정했음을 기억하세요.

이제 5개의 작업이 GitLab CI에 대기 중이라고 가정해 보겠습니다. 첫 번째 2개의 작업이 Idle 머신으로 전송됩니다.

GitLab Runner는 이제 Idle 수가 IdleCount보다 적다는 것을 감지합니다 (0 < 2), 그래서 새로운 머신을 시작합니다.

이 머신들은 MaxGrowthRate를 초과하지 않도록 순차적으로 프로비저닝됩니다.

남은 3개 작업은 준비된 첫 번째 머신에 할당됩니다. 최적화된 방식으로, 이는 바빴던 머신일 수도 있고, 지금 막 작업을 완료한 머신일 수도 있으며, 혹은 새로 프로비저닝된 머신일 수도 있습니다.

이 예시를 위해 프로비저닝 속도가 빠르다고 가정하고, 새로운 머신의 프로비저닝이 이전 작업들이 완료되기 전에 완료되었다고 가정하겠습니다.

현재 1개의 Idle 머신이 있으므로, GitLab Runner는 IdleCount를 만족시키기 위해 또 다른 1개의 새로운 머신을 시작합니다. 새로운 작업이 대기 중이지 않기 때문에, 두 머신은 Idle 상태로 유지되며 GitLab Runner는 만족합니다.

일어난 일:

우리는 새 작업을 기다리며 Idle 상태인 2개의 머신을 가졌습니다. 5개의 작업이 대기열에 큐잉된 후, 새로운 머신이 생성되었으므로 총 7개의 머신이 있었습니다.

이 중 5개는 작업을 실행 중이었고, 2개는 다음 작업을 기다리며 Idle 상태였습니다.

알고리즘은 여전히 같은 방식으로 작동합니다. GitLab Runner는 작업 실행에 사용된 각 머신에 대해 새로운 Idle 머신을 생성하여 IdleCount가 만족될 때까지 계속합니다.

이 머신들은 limit 매개변수로 정의된 수치까지 생성됩니다.

GitLab Runner가 생성된 머신의 총 수가 limit에 도달한 것을 감지하면, 오토스케일링을 중지하며 신규 작업은 머신이 다시 Idle 상태로 돌아오기까지 작업 큐에서 대기해야 합니다.

위의 예시에서 항상 2개의 유휴 머신이 있습니다.

IdleTime은 IdleCount를 초과할 때에만 적용됩니다. 그러면 머신 수를 IdleCount로 줄이도록 시도합니다.

스케일 다운:

작업이 완료되면 머신은 Idle 상태로 전환되어 다음 작업을 기다립니다. 우리가 대기열에 새 작업이 없다고 가정해 보겠습니다. 지정된 IdleTime이 지나면 Idle 머신이 제거됩니다.

우리의 예시에서 30분 후, 모든 머신이 제거됩니다 (각 머신은 마지막 작업 실행 종료 후 30분 뒤에 제거됨) 그리고 GitLab Runner는 처음 예시에서처럼 Idle 머신의 IdleCount를 유지하기 시작합니다.

정리하자면:

  1. GitLab Runner를 시작합니다.

  2. GitLab Runner는 2개의 유휴 머신을 생성합니다.

  3. GitLab Runner는 한 작업을 선택합니다.

  4. GitLab Runner는 항상 두 개의 유휴 머신이 있도록 강력한 요구를 충족하기 위해 하나의 머신을 더 생성합니다.

  5. 작업이 완료되면, 우리는 3개의 유휴 머신을 갖게 됩니다.

  6. 세 개의 유휴 머신 중 하나가 마지막으로 작업을 선택한 시간에서 IdleTime을 초과하면 제거됩니다.

  7. GitLab Runner는 항상 최소 2개의 유휴 머신을 보유하여 작업을 신속하게 선택할 수 있도록 합니다.

아래는 시간에 따른 작업 상태와 머신 상태의 비교 차트입니다:

오토스케일 상태 차트

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개의 대기 중인 머신을 가질 수 있지만 concurrent 작업은 20입니다. 따라서 총 20개의 동시 실행 머신과 10개의 대기 머신이 있어 총합은 30입니다.

그러나 limit이 생성할 수 있는 총 머신 수보다 적다면 어떻게 될까요? 아래 예제가 그 경우를 설명합니다:

concurrent=20

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

이 예에서는 최대 20개의 동시 작업과 25개의 머신을 가질 수 있습니다. 최악의 경우에는 10개의 대기 머신을 가질 수 없고, 5개만 가질 수 있습니다. 왜냐하면 limit가 25이기 때문입니다.

IdleScaleFactor 전략

IdleCount 매개변수는 러너가 유지해야 하는 정적 Idle 머신 수를 정의합니다.

할당하는 값은 사용 사례에 따라 다릅니다.

기본적으로 Idle 상태의 머신의 작은 수를 할당한 다음 사용량에 따라 자동으로 더 큰 숫자로 조정할 수 있습니다. 이를 위해 실험적 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는 Idle 상태에서 정의된 머신 수를 유지하려고 합니다. 그러나 이 숫자는 더 이상 정적이지 않습니다. IdleCount를 사용하는 대신 GitLab Runner는 현재 사용 중인 머신 수를 확인하고 해당 숫자의 계수로 목표 Idle 용량을 정의합니다.

물론 현재 사용 중인 머신이 없다면 IdleScaleFactor는 유지할 Idle 머신 수를 0으로 평가합니다. 자동 확장 알고리즘의 작동 방식 때문에, IdleCount가 0보다 클 경우(이때만 IdleScaleFactor가 적용됨) 러너는 처리할 수 있는 Idle 머신이 없으면 작업을 요청하지 않습니다. 새로운 작업이 없으면 사용 중인 머신 수가 증가하지 않으므로 IdleScaleFactor는 지속적으로 0으로 평가됩니다. 이로 인해 러너는 사용 불가능한 상태로 차단됩니다.

따라서 두 번째 설정인 IdleCountMin을 도입했습니다. 이는 IdleScaleFactor의 평가 결과에 관계없이 유지해야 할 최소 Idle 머신 수를 정의합니다. 이 설정은 ‘IdleScaleFactor’를 사용할 경우 1보다 적게 설정할 수 없습니다. 그렇게 할 경우 러너는 자동으로 1로 설정됩니다.

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

예를 들면:

concurrent=200

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

이 경우 러너가 결정 지점에 접근하면 현재 사용 중인 머신 수를 확인합니다. 현재 5개의 Idle 머신과 10개의 사용 중인 머신이 있다고 가정해 봅시다. 이를 IdleScaleFactor와 곱한 결과 러너는 11개의 Idle 머신을 가져야 한다고 결정합니다. 그래서 6개가 더 생성됩니다.

사용 중인 머신이 100개이고 Idle 머신이 90개일 경우, IdleScaleFactor에 따라 GitLab Runner는 100 * 1.1 = 110개의 Idle 머신이 있어야 한다고 판단합니다. 그래서 새로운 머신을 생성하기 시작합니다. 그러나 100개의 Idle 머신 수에 도달하면 이는 IdleCount에 의해 정의된 상한선입니다. 그래서 더 이상의 Idle 머신은 생성되지 않습니다.

사용 중인 100개의 Idle 머신 수가 20으로 줄어들면, 원하는 Idle 머신 수는 20 * 1.1 = 22가 됩니다. 이에 따라 GitLab Runner는 머신을 천천히 종료하기 시작합니다. 위에서 설명했듯이 GitLab Runner는 IdleTime 동안 사용되지 않은 머신을 제거합니다. 따라서 과도하게 많은 Idle VM이 삭제되는 일은 방지됩니다.

만약 Idle 머신 수가 0으로 줄어든다면, 원하는 Idle 머신 수는 0 * 1.1 = 0입니다. 그러나 이는 정의된 IdleCountMin 설정보다 적으므로, 러너는 10개의 Idle VM이 남을 때까지 천천히 Idle VM을 제거하기 시작합니다. 그 이후로 규모 축소가 중단되고 러너는 10개의 머신을 Idle 상태로 유지합니다.

자동 확장 기간 구성

자동 확장은 시간대에 따라 다른 값을 가질 수 있도록 구성할 수 있습니다.

조직에는 작업이 실행되는 피크 시간이 있는 정기적인 시간대와

작업이 거의 없는 시간대가 있을 수 있습니다.

예를 들어, 대부분의 상업적인 회사는 월요일부터 금요일까지 정해진 시간인 오전 10시부터 오후 6시까지 운영합니다.

밤이나 주말에는 파이프라인이 시작되지 않습니다.

이러한 기간은 [[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"

이 구성에서는 매주 월요일부터 금요일까지 오전 9시부터 오후 4시 59분까지,

운영 시간 동안의 대량 트래픽 처리에 대비하여 기계가 과잉 제공됩니다.

주말에는 트래픽 감소를 고려하여 IdleCount가 5로 떨어집니다.

나머지 시간에는 기본 값인 IdleCount = 10 및 IdleTime = 1800이 사용됩니다.

note
지정한 모든 기간의 마지막 59초는 기간의 일부로 간주되지 않습니다.

자세한 정보는 issue #2170을 참조하세요.

기간의 Timezone을 예를 들어 "Australia/Sydney"와 같이 지정할 수 있습니다.

지정하지 않으면, 각 러너의 호스트 머신 시스템 설정이 사용됩니다.

이 기본값은 Timezone = "Local"로 명시적으로 선언할 수 있습니다.

[[runner.machine.autoscaling]] 섹션의 구문에 대한 자세한 정보는

GitLab Runner - 고급 구성 - [runners.machine] 섹션에서 확인할 수 있습니다.

분산 러너 캐싱

note
분산 캐시 사용 방법을 읽어보세요.

작업 속도를 높이기 위해 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' 실행기를 사용합니다.
  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" # 인증 방법에 대한 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 값) 이하, 비활성 머신 최소 수(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 매개변수는 Google Compute Engine에서 호스팅되는 머신을 생성하기 위해 Docker Machine이 사용하는 google 드라이버의 옵션과 Docker Machine 자체에 대한 하나의 옵션(engine-registry-mirror)을 포함합니다.