작업 아티팩트 관리

Tier: Free, Premium, Ultimate Offering: Self-managed

이 문서는 아티팩트를 관리하는 문서입니다.
GitLab CI/CD 파이프라인에서 작업 아티팩트를 사용하는 방법에 대해서는
작업 아티팩트 구성 문서를 참조하세요.

아티팩트는 작업이 완료된 후 작업에 첨부된 파일 및 디렉터리 목록입니다.
이 기능은 모든 GitLab 설치에서 기본적으로 활성화되어 있습니다.

작업 아티팩트 비활성화

사이트 전체에서 아티팩트를 비활성화하려면:

Linux 패키지 (Omnibus)
  1. /etc/gitlab/gitlab.rb를 편집합니다:

    gitlab_rails['artifacts_enabled'] = false  
    
  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure  
    
Helm 차트 (Kubernetes)
  1. Helm 값을 내보냅니다:

    helm get values gitlab > gitlab_values.yaml  
    
  2. gitlab_values.yaml를 편집합니다:

    global:  
      appConfig:  
        artifacts:  
          enabled: false  
    
  3. 파일을 저장하고 새 값을 적용합니다:

    helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab  
    
Docker
  1. docker-compose.yml를 편집합니다:

    version: "3.6"  
    services:  
      gitlab:  
        environment:  
          GITLAB_OMNIBUS_CONFIG: |  
            gitlab_rails['artifacts_enabled'] = false  
    
  2. 파일을 저장하고 GitLab을 재시작합니다:

    docker compose up -d  
    
소스에서 컴파일한 (Self-compiled)
  1. /home/git/gitlab/config/gitlab.yml을 편집합니다:

    production: &base  
      artifacts:  
        enabled: false  
    
  2. 파일을 저장하고 GitLab을 재시작합니다:

    # systemd가 실행되는 시스템의 경우  
    sudo systemctl restart gitlab.target  
    
    # SysV init이 실행되는 시스템의 경우  
    sudo service gitlab restart  
    

작업 아티팩트 저장

GitLab Runner는 작업 아티팩트를 포함하는 아카이브를 GitLab에 업로드할 수 있습니다.
기본적으로, 이 작업은 작업이 성공할 때 수행되지만 실패할 때 또는 항상 수행할 수도 있습니다,
artifacts:when 매개변수를 사용합니다.

대부분의 아티팩트는 Coordinator에 전송되기 전에 GitLab Runner에 의해 압축됩니다.
예외는 리포트 아티팩트로, 이는 업로드 후에 압축됩니다.

로컬 스토리지 사용

Linux 패키지를 사용하거나 소스에서 컴파일한 설치를 사용하는 경우에,
아티팩트를 로컬에 저장할 위치를 변경할 수 있습니다.

note
Docker 설치의 경우, 데이터가 마운트되는 경로를 변경할 수 있습니다.
Helm 차트의 경우, 오브젝트 스토리지를 사용하세요.
Linux 패키지 (Omnibus)

아티팩트는 기본적으로 /var/opt/gitlab/gitlab-rails/shared/artifacts에 저장됩니다.

  1. 예를 들어 /mnt/storage/artifacts로 저장 경로를 변경하려면,
    /etc/gitlab/gitlab.rb를 편집하고 다음 줄을 추가합니다:

    gitlab_rails['artifacts_path'] = "/mnt/storage/artifacts"  
    
  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure  
    
소스에서 컴파일한 (Self-compiled)

아티팩트는 기본적으로 /home/git/gitlab/shared/artifacts에 저장됩니다.

  1. 예를 들어 /mnt/storage/artifacts로 저장 경로를 변경하려면,
    /home/git/gitlab/config/gitlab.yml을 편집하고 다음 줄을 추가하거나 수정합니다:

    production: &base  
      artifacts:  
        enabled: true  
        path: /mnt/storage/artifacts  
    
  2. 파일을 저장하고 GitLab을 재시작합니다:

    # systemd가 실행되는 시스템의 경우  
    sudo systemctl restart gitlab.target  
    
    # SysV init이 실행되는 시스템의 경우  
    sudo service gitlab restart  
    

오브젝트 스토리지 사용하기

GitLab이 설치된 로컬 디스크를 사용하여 아티팩트를 저장하고 싶지 않다면, 대신 AWS S3와 같은 오브젝트 스토리를 사용할 수 있습니다.

GitLab을 오브젝트 스토리지에 아티팩트를 저장하도록 구성하면, 작업 로그에 대한 로컬 디스크 사용을 없애는 것을 고려할 수도 있습니다.

두 가지 경우 모두, 작업이 완료되면 작업 로그가 아카이브되어 오브젝트 스토리지로 이동됩니다.

경고: 멀티 서버 설정에서는 작업 로그에 대한 로컬 디스크 사용을 없애는 옵션 중 하나를 사용해야 하며, 그렇지 않으면 작업 로그가 손실될 수 있습니다.

통합 오브젝트 스토리지 설정을 사용해야 합니다.

오브젝트 스토리지로 마이그레이션하기

로컬 스토리지에서 오브젝트 스토리지로 작업 아티팩트를 마이그레이션할 수 있습니다. 처리는 백그라운드 작업자에서 수행되며 다운타임이 필요 없습니다.

  1. 오브젝트 스토리지 구성하기.
  2. 아티팩트 마이그레이션:

    리눅스 패키지 (Omnibus)
    sudo gitlab-rake gitlab:artifacts:migrate
    
    도커
    sudo docker exec -t <container name> gitlab-rake gitlab:artifacts:migrate
    
    셀프 컴파일 (소스)
    sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
    
  3. 선택 사항. PostgreSQL 콘솔을 사용하여 모든 작업 아티팩트가 성공적으로 마이그레이션되었는지 진행 상황을 추적하고 확인하세요.
    1. PostgreSQL 콘솔을 엽니다:

      리눅스 패키지 (Omnibus)
      sudo gitlab-psql
      
      도커
      sudo docker exec -it <container_name> /bin/bash
      gitlab-psql
      
      셀프 컴파일 (소스)
      sudo -u git -H psql -d gitlabhq_production
      
    2. 다음 SQL 쿼리를 사용하여 모든 아티팩트가 오브젝트 스토리지로 마이그레이션되었는지 확인합니다. objectstg의 수는 total과 같아야 합니다:

      gitlabhq_production=# SELECT count(*) AS total, sum(case when file_store = '1' then 1 else 0 end) AS filesystem, sum(case when file_store = '2' then 1 else 0 end) AS objectstg FROM ci_job_artifacts;
      
      total | filesystem | objectstg
      ------+------------+-----------
         19 |          0 |        19
      
  4. artifacts 디렉토리에 파일이 없는지 확인합니다:

    리눅스 패키지 (Omnibus)
    sudo find /var/opt/gitlab/gitlab-rails/shared/artifacts -type f | grep -v tmp | wc -l
    
    도커

    /var/opt/gitlab/srv/gitlab에 마운트 한 경우:

    sudo find /srv/gitlab/gitlab-rails/shared/artifacts -type f | grep -v tmp | wc -l
    
    셀프 컴파일 (소스)
    sudo find /home/git/gitlab/shared/artifacts -type f | grep -v tmp | wc -l
    

어떤 경우에는, 고아 아티팩트를 정리하기 위해 고아 아티팩트 파일 정리 Rake 작업을 실행해야 할 수 있습니다.

오브젝트 스토리지에서 로컬 스토리지로 마이그레이션

산출물을 로컬 스토리지로 마이그레이션하려면:

  1. gitlab-rake gitlab:artifacts:migrate_to_local를 실행합니다.

  2. gitlab.rb에서 특정 기능에 대한 아티팩트 저장소를 선택적으로 비활성화합니다.

  3. GitLab 재구성을 실행합니다.

만료 아티팩트

artifacts:expire_in를 사용하여 아티팩트의 만료를 설정하면, 해당 날짜가 지나면 삭제 대상으로 표시됩니다.

그렇지 않으면 기본 아티팩트 만료 설정에 따라 만료됩니다.

아티팩트는 Sidekiq가 7분마다 실행하는 expire_build_artifacts_worker 크론 작업에 의해 삭제됩니다 (*/7 * * * *Cron 구문입니다).

만료된 아티팩트를 삭제하는 기본 일정을 변경하려면:

리눅스 패키지 (Omnibus)
  1. /etc/gitlab/gitlab.rb를 편집하고 다음 줄을 추가합니다 (이미 존재하고 주석 처리된 경우 주석을 제거합니다). 크론 구문으로 일정을 대체합니다:

    gitlab_rails['expire_build_artifacts_worker_cron'] = "*/7 * * * *"
    
  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure
    
Helm 차트 (Kubernetes)
  1. 헬름 값을 내보냅니다:

    helm get values gitlab > gitlab_values.yaml
    
  2. gitlab_values.yaml을 편집합니다:

    global:
      appConfig:
        cron_jobs:
          expire_build_artifacts_worker:
            cron: "*/7 * * * *"
    
  3. 파일을 저장하고 새로운 값을 적용합니다:

    helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
    
도커
  1. docker-compose.yml을 편집합니다:

    version: "3.6"
    services:
      gitlab:
        environment:
          GITLAB_OMNIBUS_CONFIG: |
            gitlab_rails['expire_build_artifacts_worker_cron'] = "*/7 * * * *"
    
  2. 파일을 저장하고 GitLab을 재시작합니다:

    docker compose up -d
    
직접 컴파일 (소스)
  1. /home/git/gitlab/config/gitlab.yml을 편집합니다:

    production: &base
      cron_jobs:
        expire_build_artifacts_worker:
          cron: "*/7 * * * *"
    
  2. 파일을 저장하고 GitLab을 재시작합니다:

    # systemd를 사용하는 시스템의 경우
    sudo systemctl restart gitlab.target
    
    # SysV init을 사용하는 시스템의 경우
    sudo service gitlab restart
    

아티팩트의 최대 파일 크기 설정

아티팩트가 활성화된 경우, 관리자 영역 설정을 통해 아티팩트의 최대 파일 크기를 변경할 수 있습니다.

스토리지 통계

다음 위치에서 그룹 및 프로젝트의 작업 아티팩트에 사용된 총 스토리지를 확인할 수 있습니다:

구현 세부사항

GitLab이 아티팩트 아카이브를 수신하면, GitLab Workhorse에 의해 아카이브 메타데이터 파일도 생성됩니다. 이 메타데이터 파일은 아티팩트 아카이브 자체에 위치한 모든 항목을 설명합니다.

메타데이터 파일은 이진 형식으로 되어 있으며, 추가적인 Gzip 압축이 있습니다.

GitLab은 공간, 메모리 및 디스크 I/O를 절약하기 위해 아티팩트 아카이브를 추출하지 않습니다. 대신, 모든 관련 정보를 포함하는 메타데이터 파일을 검사합니다. 이는 아티팩트가 많은 경우나 아카이브가 매우 큰 파일인 경우에 특히 중요합니다.

특정 파일을 선택하면, GitLab Workhorse가 아카이브에서 해당 파일을 추출하고 다운로드가 시작됩니다. 이 구현은 공간, 메모리 및 디스크 I/O를 절약합니다.