InfoGrab Docs

작업 아티팩트 관리

요약

이것은 관리 문서입니다. 아티팩트는 작업이 완료된 후 작업에 첨부되는 파일 및 디렉토리 목록입니다. 사이트 전체에서 아티팩트를 비활성화하려면: /etc/gitlab/gitlab.rb를 편집합니다: 파일을 저장하고 GitLab을 재구성합니다:

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

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

작업 아티팩트 비활성화#

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

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    gitlab_rails['artifacts_enabled'] = false

  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

  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

  1. docker-compose.yml을 편집합니다:

    version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['artifacts_enabled'] = false

  2. 파일을 저장하고 GitLab을 재시작합니다:

    docker compose up -d

  1. /home/git/gitlab/config/gitlab.yml을 편집합니다:

    production: &base
  artifacts:
    enabled: false

  2. 파일을 저장하고 GitLab을 재시작합니다:

    # For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

작업 아티팩트 저장#

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

대부분의 아티팩트는 코디네이터로 전송되기 전에 GitLab Runner에 의해 압축됩니다. 예외는 업로드 후 압축되는 보고서 아티팩트입니다.

로컬 저장소 사용#

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

Note

Docker 설치의 경우 데이터가 마운트되는 경로를 변경할 수 있습니다. Helm 차트의 경우 개체 저장소를 사용합니다.

아티팩트는 기본적으로 /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

아티팩트는 기본적으로 /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을 재시작합니다:

    # For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

개체 저장소 사용#

GitLab이 설치된 로컬 디스크를 사용하여 아티팩트를 저장하지 않으려면 AWS S3와 같은 개체 저장소를 대신 사용할 수 있습니다.

GitLab이 개체 저장소에 아티팩트를 저장하도록 구성하는 경우 작업 로그의 로컬 디스크 사용을 제거할 수도 있습니다. 두 경우 모두 작업 로그는 작업이 완료될 때 아카이브되어 개체 저장소로 이동됩니다.

Warning

다중 서버 설정에서는 작업 로그의 로컬 디스크 사용을 제거하기 위한 옵션 중 하나를 사용해야 합니다. 그렇지 않으면 작업 로그가 손실될 수 있습니다.

모든 개체 유형에 대한 통합 개체 저장소 설정을 사용해야 합니다.

개체 저장소로 마이그레이션#

작업 아티팩트를 로컬 저장소에서 개체 저장소로 마이그레이션할 수 있습니다. 처리는 백그라운드 작업자에서 수행되며 다운타임이 필요하지 않습니다.

  1. 개체 저장소를 구성합니다.

  2. 아티팩트를 마이그레이션합니다:

   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
  1. 선택 사항. PostgreSQL 콘솔을 사용하여 진행 상황을 추적하고 모든 작업 아티팩트가 성공적으로 마이그레이션되었는지 확인합니다.

    1. PostgreSQL 콘솔을 엽니다:

      sudo gitlab-psql
      ```

</div>

<div class="tab-panel" data-tab-index="1">

```shell
      sudo docker exec -it <container_name> /bin/bash
      gitlab-psql
      ```

</div>

<div class="tab-panel" data-tab-index="2">

```shell
      sudo -u git -H psql -d gitlabhq_production
      ```

</div>

</div>

   1. 다음 SQL 쿼리로 모든 아티팩트가 개체 저장소로 마이그레이션되었는지 확인합니다. `objectstg` 수는 `total`과 동일해야 합니다:

      ```shell
      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 p_ci_job_artifacts;

      total | filesystem | objectstg
      ------+------------+-----------
         19 |          0 |        19
      ```

1. `artifacts` 디렉토리의 디스크에 파일이 없는지 확인합니다:

   <div class="tabs-container" data-tabs><div class="tabs-nav"><button class="tab-button active" data-tab-index="0">Linux package (Omnibus)</button><button class="tab-button" data-tab-index="1">Docker</button><button class="tab-button" data-tab-index="2">Self-compiled (source)</button></div><div class="tab-panel active" data-tab-index="0">

```shell
   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
  1. Geo가 활성화된 경우 모든 작업 아티팩트를 다시 확인합니다.

일부 경우에는 고아 아티팩트를 정리하기 위해 고아 아티팩트 파일 정리 Rake 작업을 실행해야 합니다.

개체 저장소에서 로컬 저장소로 마이그레이션#

아티팩트를 로컬 저장소로 다시 마이그레이션하려면:

  1. gitlab-rake gitlab:artifacts:migrate_to_local을 실행합니다.
  2. gitlab.rb에서 아티팩트 저장소를 선택적으로 비활성화합니다.
  3. GitLab을 재구성합니다.

GitLab 18.6 이전에는 원격에서 로컬 저장소로의 마이그레이션이 잘못된 파일 이름으로 아티팩트가 복사될 수 있었습니다.

아티팩트 만료#

아티팩트의 만료를 설정하는 데 artifacts:expire_in이 사용된 경우 해당 날짜가 지난 직후 삭제 대상으로 표시됩니다. 그렇지 않으면 기본 아티팩트 만료 설정에 따라 만료됩니다.

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

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

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

    gitlab_rails['expire_build_artifacts_worker_cron'] = "*/7 * * * *"

  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

  1. Helm 값을 내보냅니다:

    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을 재시작합니다:

    # For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

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

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

저장소 통계#

그룹 및 프로젝트의 작업 아티팩트에 사용된 전체 저장소를 다음에서 볼 수 있습니다:

구현 세부 사항#

GitLab이 아티팩트 아카이브를 받으면 GitLab Workhorse에 의해 아카이브 메타데이터 파일도 생성됩니다. 이 메타데이터 파일은 아티팩트 아카이브 자체에 있는 모든 항목을 설명합니다. 메타데이터 파일은 추가 Gzip 압축이 적용된 바이너리 형식입니다.

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

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

작업 아티팩트 관리

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

이것은 관리 문서입니다. 아티팩트는 작업이 완료된 후 작업에 첨부되는 파일 및 디렉토리 목록입니다. 사이트 전체에서 아티팩트를 비활성화하려면: /etc/gitlab/gitlab.rb를 편집합니다: 파일을 저장하고 GitLab을 재구성합니다:

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

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

작업 아티팩트 비활성화#

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

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    gitlab_rails['artifacts_enabled'] = false

  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

  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

  1. docker-compose.yml을 편집합니다:

    version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['artifacts_enabled'] = false

  2. 파일을 저장하고 GitLab을 재시작합니다:

    docker compose up -d

  1. /home/git/gitlab/config/gitlab.yml을 편집합니다:

    production: &base
  artifacts:
    enabled: false

  2. 파일을 저장하고 GitLab을 재시작합니다:

    # For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

작업 아티팩트 저장#

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

대부분의 아티팩트는 코디네이터로 전송되기 전에 GitLab Runner에 의해 압축됩니다. 예외는 업로드 후 압축되는 보고서 아티팩트입니다.

로컬 저장소 사용#

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

Note

Docker 설치의 경우 데이터가 마운트되는 경로를 변경할 수 있습니다. Helm 차트의 경우 개체 저장소를 사용합니다.

아티팩트는 기본적으로 /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

아티팩트는 기본적으로 /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을 재시작합니다:

    # For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

개체 저장소 사용#

GitLab이 설치된 로컬 디스크를 사용하여 아티팩트를 저장하지 않으려면 AWS S3와 같은 개체 저장소를 대신 사용할 수 있습니다.

GitLab이 개체 저장소에 아티팩트를 저장하도록 구성하는 경우 작업 로그의 로컬 디스크 사용을 제거할 수도 있습니다. 두 경우 모두 작업 로그는 작업이 완료될 때 아카이브되어 개체 저장소로 이동됩니다.

Warning

다중 서버 설정에서는 작업 로그의 로컬 디스크 사용을 제거하기 위한 옵션 중 하나를 사용해야 합니다. 그렇지 않으면 작업 로그가 손실될 수 있습니다.

모든 개체 유형에 대한 통합 개체 저장소 설정을 사용해야 합니다.

개체 저장소로 마이그레이션#

작업 아티팩트를 로컬 저장소에서 개체 저장소로 마이그레이션할 수 있습니다. 처리는 백그라운드 작업자에서 수행되며 다운타임이 필요하지 않습니다.

  1. 개체 저장소를 구성합니다.

  2. 아티팩트를 마이그레이션합니다:

   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
  1. 선택 사항. PostgreSQL 콘솔을 사용하여 진행 상황을 추적하고 모든 작업 아티팩트가 성공적으로 마이그레이션되었는지 확인합니다.

    1. PostgreSQL 콘솔을 엽니다:

      sudo gitlab-psql
      ```

</div>

<div class="tab-panel" data-tab-index="1">

```shell
      sudo docker exec -it <container_name> /bin/bash
      gitlab-psql
      ```

</div>

<div class="tab-panel" data-tab-index="2">

```shell
      sudo -u git -H psql -d gitlabhq_production
      ```

</div>

</div>

   1. 다음 SQL 쿼리로 모든 아티팩트가 개체 저장소로 마이그레이션되었는지 확인합니다. `objectstg` 수는 `total`과 동일해야 합니다:

      ```shell
      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 p_ci_job_artifacts;

      total | filesystem | objectstg
      ------+------------+-----------
         19 |          0 |        19
      ```

1. `artifacts` 디렉토리의 디스크에 파일이 없는지 확인합니다:

   <div class="tabs-container" data-tabs><div class="tabs-nav"><button class="tab-button active" data-tab-index="0">Linux package (Omnibus)</button><button class="tab-button" data-tab-index="1">Docker</button><button class="tab-button" data-tab-index="2">Self-compiled (source)</button></div><div class="tab-panel active" data-tab-index="0">

```shell
   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
  1. Geo가 활성화된 경우 모든 작업 아티팩트를 다시 확인합니다.

일부 경우에는 고아 아티팩트를 정리하기 위해 고아 아티팩트 파일 정리 Rake 작업을 실행해야 합니다.

개체 저장소에서 로컬 저장소로 마이그레이션#

아티팩트를 로컬 저장소로 다시 마이그레이션하려면:

  1. gitlab-rake gitlab:artifacts:migrate_to_local을 실행합니다.
  2. gitlab.rb에서 아티팩트 저장소를 선택적으로 비활성화합니다.
  3. GitLab을 재구성합니다.

GitLab 18.6 이전에는 원격에서 로컬 저장소로의 마이그레이션이 잘못된 파일 이름으로 아티팩트가 복사될 수 있었습니다.

아티팩트 만료#

아티팩트의 만료를 설정하는 데 artifacts:expire_in이 사용된 경우 해당 날짜가 지난 직후 삭제 대상으로 표시됩니다. 그렇지 않으면 기본 아티팩트 만료 설정에 따라 만료됩니다.

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

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

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

    gitlab_rails['expire_build_artifacts_worker_cron'] = "*/7 * * * *"

  2. 파일을 저장하고 GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

  1. Helm 값을 내보냅니다:

    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을 재시작합니다:

    # For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

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

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

저장소 통계#

그룹 및 프로젝트의 작업 아티팩트에 사용된 전체 저장소를 다음에서 볼 수 있습니다:

구현 세부 사항#

GitLab이 아티팩트 아카이브를 받으면 GitLab Workhorse에 의해 아카이브 메타데이터 파일도 생성됩니다. 이 메타데이터 파일은 아티팩트 아카이브 자체에 있는 모든 항목을 설명합니다. 메타데이터 파일은 추가 Gzip 압축이 적용된 바이너리 형식입니다.

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

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