• 티어별 기능
• 코드 품질 결과 보기
  • 병합 요청 위젯
  • 병합 요청 변경 사항 보기
  • 파이프라인 세부정보 보기
  • 프로젝트 품질 보기
• 코드 품질 활성화
  • 개인 러너로 코드 품질 성능 개선
  • 코드 품질을 위한 Rootless로 실행하기
• 코드 품질 비활성화
• 스캔 설정 사용자 정의
• 사용 가능한 CI/CD 변수
• 출력
  • JSON 및 HTML 형식으로 출력
  • 오직 HTML 형식으로 코드 품질 보고서 다운로드
• 머지 요청 파이프라인에서 코드 품질 사용
• 개인 컨테이너 이미지 레지스트리 사용
  • 필수 이미지
• 인증을 사용하는 DockerHub
• 의존성 프록시 사용
• 커스텀 도구 구현
• 여러 도구 통합
• 분석 플러그인 사용
• Kubernetes 및 OpenShift에서 코드 품질 사용
  • Kubernetes
  • OpenShift
    • 볼륨 및 Docker 저장소

코드 품질

코드 품질을 사용하여 소스 코드의 품질과 복잡성을 분석하세요. 이는 프로젝트의 코드가 단순하고 가독성이 높으며 유지보수가 용이하도록 하는 데 도움이 됩니다. 코드 품질은 다른 검토 프로세스를 보완해야 하며, 대체해서는 안 됩니다.

코드 품질은 CI/CD 파이프라인에서 실행되며, 코드 품질을 저하할 수 있는 변경 사항을 병합하지 않도록 도와줍니다.

코드 품질은 오픈 소스 Code Climate 도구와 선택된
플러그인을 사용하여 소스 코드를 분석합니다. 코드의 언어가 지원되는지 확인하려면 Code Climate의
유지 관리 가능성 지원 언어 목록을 참조하세요. 코드 범위를 확장하려면 Code Climate
분석 플러그인이나
사용자 정의 도구를 사용할 수 있습니다.

티어별 기능

다양한 기능이 다양한 GitLab 티어에서 제공됩니다. 다음 표에 나와 있습니다:

코드 품질 결과 보기

코드 품질 결과는 다음에 표시됩니다:

• 병합 요청 위젯
• 병합 요청 변경 사항 보기
• 파이프라인 세부 정보 보기
• 프로젝트 품질 보기

병합 요청 위젯

코드 품질 분석 결과는 비교를 위해 대상 브랜치에서 보고서가 있는 경우 병합 요청 위젯 영역에 표시됩니다. 병합 요청 위젯은 병합 요청에서 변경된 사항으로 도입된 코드 품질 발견 사항과 해결책을 표시합니다. 동일한 지문을 가진 여러 코드 품질 발견 사항은 병합 요청 위젯에 하나의 항목으로 표시됩니다. 각 발견 사항은 파이프라인 세부 정보 보기에서 사용할 수 있는 전체 보고서에 있습니다.

병합 요청 변경 사항 보기

코드 품질 결과는 병합 요청 변경 사항 보기에서 표시됩니다. 코드 품질 문제가 포함된 줄은 가장자리 옆에 기호로 표시됩니다. 기호를 선택하면 문제 목록이 표시되며, 문제를 선택하면 자세한 정보를 확인할 수 있습니다.

파이프라인 세부정보 보기

파이프라인에서 생성된 코드 품질 위반의 전체 목록은 파이프라인 세부정보 페이지의 코드 품질 탭에 표시됩니다. 파이프라인 세부정보 보기는 실행된 브랜치에서 발견된 모든 코드 품질 결과를 표시합니다.

프로젝트 품질 보기

• GitLab 14.5에서 도입됨 project_quality_summary_page라는 플래그와 함께. 이 기능은 베타입니다. 기본적으로 비활성화되어 있습니다.

프로젝트 품질 보기는 코드 품질 결과에 대한 개요를 표시합니다. 이 보기는 분석 > CI/CD 분석 아래에서 찾을 수 있으며, 특정 프로젝트에 대해 project_quality_summary_page 기능 플래그가 활성화되어 있어야 합니다.

코드 품질 활성화

사전 요구 사항:

• GitLab CI/CD 구성(.gitlab-ci.yml)에는 test 단계가 포함되어야 합니다.
• 인스턴스 러너를 사용하는 경우, 코드 품질 작업은 Docker-in-Docker 작업 흐름으로 구성해야 합니다.
  이 작업 흐름을 사용할 때 /builds 볼륨은 보고서를 저장할 수 있도록 매핑되어야 합니다.
• 개인 러너를 사용하는 경우, 코드 품질 분석을 더 효율적으로 실행하기 위해 대체 구성을 사용해야 합니다.
• 러너는 생성된 코드 품질 파일을 저장할 수 있는 충분한 디스크 공간이 있어야 합니다. 예를 들어, GitLab 프로젝트에서는 파일 크기가 약 7GB입니다.

코드 품질을 활성화하려면 다음 중 하나를 수행하십시오:

• 자동 DevOps를 활성화하십시오. 이는 자동 코드 품질을 포함합니다.

• .gitlab-ci.yml 파일에 코드 품질 템플릿을 포함하십시오.

  예:

     include:  
     - template: Jobs/Code-Quality.gitlab-ci.yml  
  

  이제 코드 품질이 파이프라인에서 실행됩니다.

경고:
자체 관리 인스턴스에서 악의적인 행위자가 코드 품질 작업 정의를 손상시킬 경우, 러너 호스트에서 권한 있는 Docker 명령을 실행할 수 있습니다. 적절한 접근 제어 정책을 통해 신뢰할 수 있는 행위자만 접근할 수 있도록 하여 이 공격 벡터를 완화합니다.

개인 러너로 코드 품질 성능 개선

개인 러너가 있는 경우, 코드 품질의 성능 향상을 위해 이 구성을 사용해야 합니다.
이유는 다음과 같습니다:

• 권한 있는 모드가 사용되지 않습니다.
• Docker-in-Docker가 사용되지 않습니다.
• 모든 CodeClimate 이미지를 포함한 Docker 이미지가 캐시되어 후속 작업에 대해 재요청되지 않습니다.

이 대체 구성은 소켓 바인딩을 사용하여 러너의 Docker 데몬을 작업 환경과 공유합니다. 이 구성을 구현하기 전에 제한 사항을 고려하십시오.

개인 러너를 사용하려면:

1. 새 러너 등록:

   $ gitlab-runner register --executor "docker" \  
     --docker-image="docker:latest" \  
     --url "https://gitlab.com/" \  
     --description "cq-sans-dind" \  
     --docker-volumes "/cache"\  
     --docker-volumes "/builds:/builds"\  
     --docker-volumes "/var/run/docker.sock:/var/run/docker.sock" \  
     --registration-token="<project_token>" \  
     --non-interactive  
   

2. 선택 사항이지만 권장됨: 빌드 디렉토리를 /tmp/builds로 설정하여 작업 아티팩트가 주기적으로 러너 호스트에서 정리되도록 합니다. 이 단계를 건너뛰면 기본 빌드 디렉토리(/builds)를 직접 정리해야 합니다. 이전 단계의 gitlab-runner register에 다음 두 플래그를 추가하여 이를 수행할 수 있습니다.

   --builds-dir "/tmp/builds"  
   --docker-volumes "/tmp/builds:/tmp/builds" # --docker-volumes "/builds:/builds" 대신 이 항목을 사용하십시오.  
   

   결과 구성:

   [[runners]]  
     name = "cq-sans-dind"  
     url = "https://gitlab.com/"  
     token = "<project_token>"  
     executor = "docker"  
     builds_dir = "/tmp/builds"  
     [runners.docker]  
       tls_verify = false  
       image = "docker:latest"  
       privileged = false  
       disable_entrypoint_overwrite = false  
       oom_kill_disable = false  
       disable_cache = false  
       volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock", "/tmp/builds:/tmp/builds"]  
       shm_size = 0  
     [runners.cache]  
       [runners.cache.s3]  
       [runners.cache.gcs]  
   

3. 템플릿에 의해 생성된 code_quality 작업에 두 가지 오버라이드를 적용합니다:

   include:  
     - template: Jobs/Code-Quality.gitlab-ci.yml  
   
   code_quality:  
     services:            # Docker-in-Docker 종료  
     tags:  
       - cq-sans-dind     # 이 작업이 새 특수 러너에서만 실행되도록 설정  
   

이제 코드 품질이 표준 Docker 모드에서 실행됩니다.

코드 품질을 위한 Rootless로 실행하기

개인 러너를 사용하고 있고 코드 품질 스캔을 루트리스 도커 모드에서 실행하고 싶다면, 코드 품질이 올바르게 실행될 수 있도록 몇 가지 특별한 변경이 필요합니다. 소켓 바인딩의 변경이 다른 작업에 문제를 일으킬 수 있기 때문에, 코드 품질 작업만을 실행하는 전용 러너를 보유해야 할 수 있습니다.

루트리스 개인 러너를 사용하려면:

1. 새로운 러너 등록:

   /run/user/<gitlab-runner-user>/docker.sock를 gitlab-runner 사용자에 대한 로컬 docker.sock의 경로로 교체합니다.

   $ gitlab-runner register --executor "docker" \
     --docker-image="docker:latest" \
     --url "https://gitlab.com/" \
     --description "cq-rootless" \
     --tag-list "cq-rootless" \
     --locked="false" \
     --access-level="not_protected" \
     --docker-volumes "/cache" \
     --docker-volumes "/tmp/builds:/tmp/builds" \
     --docker-volumes "/run/user/<gitlab-runner-user>/docker.sock:/run/user/<gitlab-runner-user>/docker.sock" \
     --token "<project_token>" \
     --non-interactive \
     --builds-dir "/tmp/builds" \
     --env "DOCKER_HOST=unix:///run/user/<gitlab-runner-user>/docker.sock" \
     --docker-host "unix:///run/user/<gitlab-runner-user>/docker.sock"
   

   결과 구성은 다음과 같습니다:

   [[runners]]
     name = "cq-rootless"
     url = "https://gitlab.com/"
     token = "<project_token>"
     executor = "docker"
     builds_dir = "/tmp/builds"
     environment = ["DOCKER_HOST=unix:///run/user/<gitlab-runner-user>/docker.sock"]
     [runners.docker]
       tls_verify = false
       image = "docker:latest"
       privileged = false
       disable_entrypoint_overwrite = false
       oom_kill_disable = false
       disable_cache = false
       volumes = ["/cache", "/run/user/<gitlab-runner-user>/docker.sock:/run/user/<gitlab-runner-user>/docker.sock", "/tmp/builds:/tmp/builds"]
       shm_size = 0
       host = "unix:///run/user/<gitlab-runner-user>/docker.sock"
     [runners.cache]
       [runners.cache.s3]
       [runners.cache.gcs]
   

2. 템플릿에 의해 생성된 code_quality 작업에 다음 재정의를 적용합니다:

   code_quality:
     services:
     variables:
       DOCKER_SOCKET_PATH: /run/user/997/docker.sock
     tags:
       - cq-rootless
   

코드 품질 분석이 이제 표준 도커 모드 및 루트리스로 실행됩니다.

코드 품질과 함께 루트리스 포드맨을 사용하여 도커를 실행하려는 목표와 동일한 구성이 필요합니다. 시스템에서 올바른 podman.sock 경로로 /run/user/<gitlab-runner-user>/docker.sock를 교체해야 합니다. 예: /run/user/<gitlab-runner-user>/podman/podman.sock.

코드 품질 비활성화

$CODE_QUALITY_DISABLED CI/CD 변수가 존재하는 경우 code_quality 작업이 실행되지 않습니다. 변수를 정의하는 방법에 대한 자세한 정보는 GitLab CI/CD 변수를 참조하세요.

코드 품질을 비활성화하려면, 다음 두 가지 중 하나에 대해 CODE_QUALITY_DISABLED라는 사용자 정의 CI/CD 변수를 만드세요:

• 전체 프로젝트.
• 단일 파이프라인.

스캔 설정 사용자 정의

코드 품질 스캔 설정은 .gitlab-ci.yml의 CI/CD 변수를 사용하여 변경할 수 있습니다.

코드 품질 작업을 구성하려면:

1. 템플릿 포함 후 코드 품질 작업과 동일한 이름의 작업을 선언합니다.

2. 작업의 stanza에서 추가 키를 지정합니다.

예를 보려면 HTML 형식으로 출력 다운로드를 참조하세요.

사용 가능한 CI/CD 변수

코드 품질은 사용 가능한 CI/CD 변수를 정의하여 사용자 정의할 수 있습니다:

출력

코드 품질은 발견된 문제의 세부 정보를 포함하는 보고서를 출력합니다. 이 보고서의 내용은 내부적으로 처리되며, 결과는 UI에 표시됩니다. 보고서는 code_quality 작업의 아티팩트로도 출력되며, 이름은 gl-code-quality-report.json입니다. 선택적으로 보고서를 HTML 형식으로 출력할 수 있습니다. 예를 들어 HTML 형식 파일을 GitLab Pages에 게시하여 더욱 쉽게 검토할 수 있습니다.

JSON 및 HTML 형식으로 출력

코드 품질 보고서를 JSON 및 HTML 형식으로 출력하려면 추가 작업을 생성합니다. 이는 파일 형식별로 코드 품질이 두 번 실행되어야 함을 요구합니다.

코드 품질 보고서를 HTML 형식으로 출력하려면 extends: code_quality를 사용하여 템플릿에 또 다른 작업을 추가합니다:

include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality_html:
  extends: code_quality
  variables:
    REPORT_FORMAT: html
  artifacts:
    paths: [gl-code-quality-report.html]

JSON 및 HTML 파일은 모두 작업 아티팩트로 출력됩니다. HTML 파일은 artifacts.zip 작업 아티팩트에 포함됩니다.

오직 HTML 형식으로 코드 품질 보고서 다운로드

코드 품질 보고서를 오직 HTML 형식으로 다운로드하려면 REPORT_FORMAT을 html로 설정하여 code_quality 작업의 기본 정의를 재정의합니다.

주의: 이렇게 하면 JSON 형식 파일이 생성되지 않으므로 코드 품질 결과가 머지 요청 위젯, 파이프라인 보고서 또는 변경 사항 보기에서 표시되지 않습니다.

include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality:
  variables:
    REPORT_FORMAT: html
  artifacts:
    paths: [gl-code-quality-report.html]

HTML 파일은 작업 아티팩트로 출력됩니다.

머지 요청 파이프라인에서 코드 품질 사용

기본 코드 품질 구성에서는 code_quality 작업이 머지 요청 파이프라인에서 실행되지 않도록 되어 있습니다.

머지 요청 파이프라인에서 코드 품질을 실행하려면 코드 품질 규칙을 재정의하거나 workflow: rules를 다음과 같이 현재 규칙에 맞게 조정하세요.

예를 들어:

include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality:
  rules:
    - if: $CODE_QUALITY_DISABLED
      when: never
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # 머지 요청 파이프라인에서 코드 품질 작업 실행
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH      # 기본 브랜치에서만 파이프라인에서 코드 품질 작업 실행 (다른 브랜치 파이프라인에서는 실행되지 않음)
    - if: $CI_COMMIT_TAG                               # 태그에 대한 파이프라인에서 코드 품질 작업 실행

개인 컨테이너 이미지 레지스트리 사용

개인 컨테이너 이미지 레지스트리를 사용하면 이미지를 다운로드하는 데 걸리는 시간을 줄이고 외부 종속성을 줄일 수 있습니다. CodeClimate의 이후 docker pull 명령어가 개별 엔진에 대해 전달될 수 있도록 레지스트리 접두사를 구성해야 합니다. 이는 컨테이너 실행 방식의 중첩 방식 때문입니다.

다음 변수는 모든 필수 이미지 풀을 처리할 수 있습니다:

• CODE_QUALITY_IMAGE: 작업 환경에서 액세스할 수 있는 완전히 접두사와 함께 지정된 이미지 이름입니다. GitLab 컨테이너 레지스트리를 이곳에서 사용하여 자신의 복사본을 호스팅할 수 있습니다.

• CODECLIMATE_PREFIX: 의도한 컨테이너 이미지 레지스트리의 도메인입니다. 이는 CodeClimate CLI가 지원하는 구성 옵션입니다. 필요 시:
  • 후행 슬래시(/)를 포함하십시오.
  • https://와 같은 프로토콜 접두사는 포함하지 마십시오.

• CODECLIMATE_REGISTRY_USERNAME: CODECLIMATE_PREFIX에서 구문 분석된 레지스트리 도메인에 대한 사용자 이름을 지정하는 선택적 변수입니다.

• CODECLIMATE_REGISTRY_PASSWORD: CODECLIMATE_PREFIX에서 구문 분석된 레지스트리 도메인에 대한 비밀번호를 지정하는 선택적 변수입니다.

include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality:
  variables:
    CODE_QUALITY_IMAGE: "my-private-registry.local:12345/codequality:0.85.24"
    CODECLIMATE_PREFIX: "my-private-registry.local:12345/"

이 예제는 GitLab 코드 품질에 특화된 것입니다. 레지스트리 미러와 함께 DinD를 설정하는 방법에 대한 일반적인 지침은 Docker-in-Docker 서비스에 대한 레지스트리 미러 활성화를 참조하세요.

필수 이미지

다음 이미지는 기본 .codeclimate.yml에 필요합니다:

• codeclimate/codeclimate-structure:latest
• codeclimate/codeclimate-csslint:latest
• codeclimate/codeclimate-coffeelint:latest
• codeclimate/codeclimate-duplication:latest
• codeclimate/codeclimate-eslint:latest
• codeclimate/codeclimate-fixme:latest
• codeclimate/codeclimate-rubocop:rubocop-0-92

사용자가 커스텀 .codeclimate.yml 구성 파일을 사용하는 경우, 개인 컨테이너 레지스트리에 지정된 플러그인을 추가해야 합니다.

인증을 사용하는 DockerHub

DockerHub를 코드 품질 이미지의 대체 출처로 사용할 수 있습니다.

전제 조건:

• 보호된 CI/CD 변수로 사용자 이름과 비밀번호 추가 프로젝트에.

DockerHub를 사용하려면 .gitlab-ci.yml 파일에 다음 변수를 구성합니다:

• CODECLIMATE_PREFIX
• CODECLIMATE_REGISTRY_USERNAME
• CODECLIMATE_REGISTRY_PASSWORD

예시:

include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality:
  variables:
    CODECLIMATE_PREFIX: "registry-1.docker.io/"
    CODECLIMATE_REGISTRY_USERNAME: $DOCKERHUB_USERNAME
    CODECLIMATE_REGISTRY_PASSWORD: $DOCKERHUB_PASSWORD

의존성 프록시 사용

의존성 프록시를 사용하여 의존성을 다운로드하는 데 걸리는 시간을 줄일 수 있습니다.

전제 조건:

• 프로젝트의 의존성 프록시 활성화.

의존성 프록시를 참조하려면 .gitlab-ci.yml 파일에 다음 변수를 구성합니다:

• CODE_QUALITY_IMAGE
• CODECLIMATE_PREFIX
• CODECLIMATE_REGISTRY_USERNAME
• CODECLIMATE_REGISTRY_PASSWORD

예시:

include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality:
  variables:
    ## `$CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX`에 후행 슬래시를 추가해야 합니다.
    CODECLIMATE_PREFIX: $CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX/
    CODECLIMATE_REGISTRY_USERNAME: $CI_DEPENDENCY_PROXY_USER
    CODECLIMATE_REGISTRY_PASSWORD: $CI_DEPENDENCY_PROXY_PASSWORD

커스텀 도구 구현

GitLab에 커스텀 도구를 통합하여 코드 품질 보고서를 제공할 수 있습니다.

코드 품질 보고서 아티팩트 JSON 파일은 다음 속성을 가진 객체 배열을 포함해야 합니다:

참고: 코드 클라이밋 사양은 더 많은 속성을 지원하지만, GitLab에서는 이를 무시합니다.

GitLab 파서는 파일 시작 부분에 바이트 순서 표시를 허용하지 않습니다.

커스텀 코드 품질 도구를 구현하려면:

1. .gitlab-ci.yml 파일에 코드 품질 보고서 아티팩트를 생성하는 작업을 정의합니다.
2. 도구를 구성하여 코드 품질 보고서 아티팩트를 생성하도록 설정합니다. 이는 Code Climate 사양의 하위 집합을 구현하는 JSON 파일이어야 합니다.

예시:

[
  {
    "description": "'unused'는 값이 할당되었지만 사용되지 않았습니다.",
    "check_name": "no-unused-vars",
    "fingerprint": "7815696ecbf1c96e6894b779456d330e",
    "severity": "minor",
    "location": {
      "path": "lib/index.js",
      "lines": {
        "begin": 42
      }
    }
  }
]

여러 도구 통합

코드 품질은 파이프라인의 모든 작업 결과를 단일 gl-code-quality-report.json 파일로 결합합니다. 그 결과, 여러 개별 도구를 파이프라인에서 함께 사용하거나 지원되는 Code-Quality.gitlab-ci.yml 템플릿의 대신 사용할 수 있습니다.

필요한 형식으로 ESLint 출력을 반환하는 예는 다음과 같습니다:

eslint:
  image: node:18-alpine
  script:
    - npm ci
    - npx eslint --format gitlab .
  artifacts:
    reports:
      codequality: gl-code-quality-report.json

분석 플러그인 사용

코드 품질 기능은 Code Climate Analysis Plugins를 사용하여 확장할 수 있습니다.

예를 들어, SonarJava 분석기를 사용하려면:

1. 저장소의 루트에 .codeclimate.yml이라는 파일을 추가하십시오.

2. 플러그인을 위한 활성화 코드를 .codeclimate.yml 파일의 루트에 추가하십시오:

   version: "2"
   plugins:
     sonar-java:
       enabled: true
   

이는 기본 .codeclimate.yml의 plugins: 섹션에 SonarJava를 추가합니다. 기본 .codeclimate.yml

plugins: 섹션에 대한 변경 사항은 기본 .codeclimate.yml의 exclude_patterns 섹션에 영향을 미치지 않습니다. 파일 및 폴더 제외에 대한 자세한 내용은 Code Climate 문서를 참조하세요. 파일 및 폴더 제외.

Kubernetes 및 OpenShift에서 코드 품질 사용

코드 품질을 사용하려면 Docker-in-Docker 컨테이너 내에서 Docker를 설정해야 합니다. Kubernetes 실행자는 Docker-in-Docker를 지원합니다.

Kubernetes 실행자에서 코드 품질 작업이 실행될 수 있도록 하려면:

• Docker 데몬과 통신하기 위해 TLS를 사용하는 경우, 실행자는 특권 모드에서 실행되어야 합니다. 또한, 인증서 디렉터리는 볼륨 마운트로 지정해야 합니다.
• DinD 서비스가 코드 품질 작업이 시작되기 전에 완전히 시작되지 않을 수 있습니다. 이는 Kubernetes 실행자 문제 해결에 문서화된 한계입니다. 문제를 해결하려면 before_script를 사용하여 Docker 데몬이 완전히 부팅되는 것을 기다리십시오. 예시는 아래 .gitlab-ci.yml 파일의 구성에서 확인하십시오.

Kubernetes

Kubernetes에서 코드 품질을 실행하려면:

• Docker-in-Docker 서비스는 config.toml 파일의 서비스 컨테이너로 추가되어야 합니다.
• 서비스 컨테이너 내의 Docker 데몬은 코드 품질에서 필요로 하는 TCP 및 UNIX 소켓 모두에서 수신 대기해야 합니다.
• Docker 소켓은 볼륨으로 공유되어야 합니다.

Docker 요구 사항으로 인해 특권 플래그가 서비스 컨테이너에 대해 활성화되어야 합니다.

[runners.kubernetes]

[runners.kubernetes.service_container_security_context]
privileged = true
allow_privilege_escalation = true

[runners.kubernetes.volumes]

[[runners.kubernetes.volumes.empty_dir]]
mount_path = "/var/run/"
name = "docker-sock"

[[runners.kubernetes.services]]
alias = "dind"
command = [
    "--host=tcp://0.0.0.0:2375",
    "--host=unix://var/run/docker.sock",
    "--storage-driver=overlay2"
]
entrypoint = ["dockerd"]
name = "docker:20.10.12-dind"

참고: GitLab Runner Helm Chart를 사용하는 경우, values.yaml 파일의 config 필드에서 위의 Kubernetes 구성을 사용할 수 있습니다.

최고의 전반적인 성능을 제공하는 overlay2 스토리지 드라이버를 사용하려면:

• Docker CLI가 통신하는 DOCKER_HOST를 지정하십시오.
• DOCKER_DRIVER 변수를 비워둡니다.

before_script 섹션을 사용하여 Docker 데몬이 완전히 부팅되기를 기다리십시오. GitLab Runner v16.9부터는 HEALTHCHECK_TCP_PORT 변수를 설정하는 것만으로도 가능합니다.

include:
  - template: Code-Quality.gitlab-ci.yml

code_quality:
  services: []
  variables:
    DOCKER_HOST: tcp://dind:2375
    DOCKER_DRIVER: ""
  before_script:
    - while ! docker info > /dev/null 2>&1; do sleep 1; done

OpenShift

OpenShift의 경우 GitLab Runner Operator를 사용해야 합니다.

서비스 컨테이너의 Docker 데몬이 저장소를 초기화할 수 있는 권한을 부여하려면, /var/lib 디렉토리를 볼륨 마운트로 마운트해야 합니다.

Docker 데몬의 권한을 구성하려면,

1. 아래에 제공된 구성으로 config.toml이라는 파일을 생성합니다. 이 구성은 GitLab Runner가 생성한 config.toml을 사용자 정의하는 데 사용됩니다:

[[runners]]

[runners.kubernetes]

[runners.kubernetes.service_container_security_context]
privileged = true
allow_privilege_escalation = true

[runners.kubernetes.volumes]

[[runners.kubernetes.volumes.empty_dir]]
mount_path = "/var/run/"
name = "docker-sock"

[[runners.kubernetes.volumes.empty_dir]]
mount_path = "/var/lib/"
name = "docker-data"

[[runners.kubernetes.services]]
alias = "dind"
command = [
    "--host=tcp://0.0.0.0:2375",
    "--host=unix://var/run/docker.sock",
    "--storage-driver=overlay2"
]
entrypoint = ["dockerd"]
name = "docker:20.10.12-dind"

1. 러너에 사용자 정의 구성을 설정합니다.

2. 선택 사항. 빌드 Pod에 privileged 서비스 계정을 연결합니다. 이는 OpenShift 클러스터 설정에 따라 다릅니다:

   oc create sa dind-sa
   oc adm policy add-scc-to-user anyuid -z dind-sa
   oc adm policy add-scc-to-user -z dind-sa privileged
   

3. [runners.kubernetes] 섹션에서 권한을 설정합니다.

4. 작업 정의는 Kubernetes의 경우와 동일하게 유지합니다:

   include:
   - template: Code-Quality.gitlab-ci.yml
   
   code_quality:
   services: []
   variables:
     DOCKER_HOST: tcp://dind:2375
     DOCKER_DRIVER: ""
   before_script:
     - while ! docker info > /dev/null 2>&1; do sleep 1; done
   

볼륨 및 Docker 저장소

Docker는 모든 데이터를 /var/lib 볼륨에 저장하며, 이로 인해 큰 볼륨이 생성될 수 있습니다. 클러스터 전반에 걸쳐 Docker-in-Docker 저장소를 재사용하기 위해, Persistent Volumes를 대안으로 사용할 수 있습니다.