NOTE: 2016-06-22 시점에 http://docs.gitlab.com/ce/ci/runners/README.html 에 기술된 내용을 번역합니다.

Runner

Runner는 yaml 파일을 수행합니다. Runner는 build를 pick up해서 Gitlab CI의 coordinate API를 이용하여 빌드하는 독립된 (virtual) machine입니다.

Runner는 특정 프로젝트에 국한해서, 또는 어떤 프로젝트라도 사용할 수 있도록 제공할 수 있습니다. 모든 프로젝트에서 사용할 수 있는 runner를 share runner라고 합니다.

Runner는 Gitlab과 같은 machine에 설치하지 않기를 권장합니다. requirements documentation 문서를 참고 바랍니다.

Shared vs. Specific Runners

Specific한 runner는 특정 profect를 위해서만 동작합니다. Shared runner는 모든 프로젝트의 job을 수행할 수 있습니다. 이는 Allow shared runners option을 통해 활성화됩니다.

Shared runners 는 여러 프로젝트에서 유사한 requirement를 갖는 job이 있는 경우 유용합니다. 여러 runner가 여러 project를 위해 대기하는 것 보다는 여러 project를 핸들링하는 하나 또는 소수의 runner를 갖는 것이 좋습니다.

이 편이 runner의 유지보수나 update에 유리합니다.

Specific runners 는 job이나 project가 특별한 요청사항을 가질 때에 필요합니다.

Job이 특별한 requirement가 있는 경우 이를 모든 runner에 설정하는 대신 specific runner를 설정할 수 있습니다.

예를들어 특정 프로젝트를 deploy하려 할 때 이를 위한 권한을 갖는 specific runner를 셋업할 수 있습니다.

그리고 CI activity를 자주 요청하는 프로젝트의 경우 specific runner를 사용하는 것이 유리합니다. 다른 프로젝트의 job에 의해 딜레이되지 않도록 별도의 runner를 설정할 수 있습니다.

Specific runner를 여러 프로젝트에서 사용할 수 있도록 셋업할 수도 있습니다. 각 프로젝트에서 명시적으로 해당 runner를 활성화해야 한다는 점이 shared runner와 다른 점입니다.

Shared runner는 project를 forking한다 해서 자동적으로 공유되지 않습니다. Form는 CI setting(job, shared 허용여부, etc)만을 copy합니다.

Runner 생성하고 등록하기

Runner를 생성하는 데에는 몇 가지 방법이 있습니다. 생성 후 registration 시 status를 Shared로 할 지 Specific으로 할지가 결정됩니다.

Runner instance를 설치하는 다른 방법들은 다음 문서를 참조바랍니다.

Runner를 설치한 후 Shared 또는 Specific으로 설정할 수 있습니다. 이 중 shared runner는 admin 권한을 갖고 있는 경우에만 설정할 수 있습니다.니다.

Shared Runner 등록하기

연결된 Gitlab instance의 admin인 경우에만 shared runner를 등록할 수 있습니다.

Gitlab CI instance의 admin/runners 페이지에서 shared-runner token을 가져오세요.

shared token

그리고 아래와같이 runner를 등록합니다:

sudo gitlab-ci-multi-runner register

Shared runner는 Gitlab 8.2부터 default로 활성화되어 있고, DISABLE SHARED RUNNERS 버튼으로 비활성화할 수 있습니다. 이전 버전은 default로 비활성화되어 있습니다.

Specific Runner 등록하기

Specific으로 등록하는데에는 다음 두 가지 방법이 있습니다:

  1. Project registration token으로 runner를 생성.
  2. Shared runner를 specific runner로 변경(반대로는 불가능, admin only)

Runner instance를 생성하는 데에는 몇 가지 방법이 있습니다. 아래에는 runner를 Gitlab CI에 등록하는 것만 언급해 놓았습니다.

Project Registration Token으로 Specific Runner 등록하기

Gitlab instance에 대한 admin 권한 없이 specific runner를 등록하려면 해당 project 페이지를 방문해야 합니다.

Runner tab을 클릭하고 registration token을 찾아서 specific runner를 해당 프로젝트를 위한 것으로 설정해 주세요.

project runners in GitLab CI

Runner를 등록하기 위해서는 다음 command를 실행하고 지시를 따라가야 합니다:

sudo gitlab-ci-multi-runner register

Specific Runner를 특정 project를 위해서만 사용할 수 있도록 잠그기

Runner를 특정 프로젝트에서만 동작하도록 설정할 수 있습니다. 이와같이 runner가 잠긴 경우 다른 프로젝트에서는 이를 활성화할 수 없습니다. Project Settings > Runners 에서 이를 설정할 수 있습니다.

Share Runner를 Specific으로 바꾸기

Gitlab instance의 admin은 share runner를 specific runner로 변환할 수 있습니다. 하지만 반대로 specific runner를 shared로 변경하는 것은 불가능합니다.

Share runner를 specific하게 변경하려면 /admin/runners 페이지로 이동해서 변환하고자 하는 runner를 찾아야 합니다. 그리고 프로젝트를 add해서 해당 프로젝트에 대해서만 exclusively하게 돌도록 설정하면 specific runner로의 변환이 완료됩니다.

making a shared runner specific

Share Runner를 효율적으로 활용하기

Shared runner를 사용하려는 경우 몇 가지 염두에 두어야 할 내용이 있습니다.

Tag 활용하기

Runner를 여러가지 type의 job을 수행할 수 있도록 설정하는 것이 shared runner를 사용하는 다른 프로젝트에 영향을 줄 수 있습니다.

매우 많은 프로젝트를 지원하는 경우 tag가 설정되어 있지 않으면 문제가 복잡해집니다.

지원하는 job의 type에 따라 runner를 tagging해 놓으면 shared runner가 수행 가능하도록 준비된 job만 수행하는 것이 보장됩니다.

예를들어 runner가 Rails test suites를 돌리기 위한 적절한 dependency들이 포함되어 있는 경우 이를 “rails”라고 tagging할 수 있습니다.

Tag가 달린 Runner가 Tag가 없는 Job을 Picking하지 않도록 막기

Tag가 assign되지 않은 runner가 tag가 달린 job을 picking하지 못하도록 설정할 수 있습니다. Project Settings > Runners 페이지에서 각 runner에 대해 이를 설정할 수 있습니다.

Sensitive한 정보가 포함되지 않도록 유의하세요

Runner에서 build를 수행할 수 있다면 runner가 수행하는 code나 runner의 token에 access할 수 있습니다. 이를 shared runner에 대해 생각해 보면, runner에서 job을 수행할 수 있는 유저는 해당 runner에서 build되는 다른 사람의 code도 볼 수 있다는 이야기입니다.

또한 runner token에 access할 수 있으므로 runner의 clone을 만들어서 false build를 summit하는 등의 작업이 가능해집니다.

위 사항은 대규모의 public gitlab instance등에서 shared runner의 사용을 제한하거나 gitlab instance에 access를 제어하는 등으로 쉽게 회피할 수 있습니다.

Forks

Project가 fork되면 job 관련 setting도 copy됩니다.

이는 특정 프로젝트에 대해 shared runner를 setup해 놓았는데 누군가 해당 프로젝트를 fork하면 해당 shared runner가 fork된 프로젝트의 job 또한 serve한다는 것을 의미합니다.

보안문제

앞서 간단히 언급한 것 처럼 runner와 관련된 동작들이 exploit될 수 있습니다. Security Considerations에 언급된 이슈들을 완화할 수 있는 contribution을 기대합니다!