작업 아티팩트 관리
이 문서는 관리 문서입니다. GitLab CI/CD 파이프라인에서 작업 아티팩트를 사용하는 방법을 알아보려면 작업 아티팩트 구성 문서를 참조하세요.
아티팩트는 작업이 완료된 후에 작업에 첨부된 파일 및 디렉터리의 디렉터리입니다. 이 기능은 모든 GitLab 설치에서 기본적으로 활성화되어 있습니다.
작업 아티팩트 비활성화
사이트 전체에서 아티팩트를 비활성화하려면:
-
/etc/gitlab/gitlab.rb
를 편집합니다:gitlab_rails['artifacts_enabled'] = false
-
파일을 저장하고 GitLab을 다시 구성합니다:
sudo gitlab-ctl reconfigure
-
Helm 값 내보내기:
helm get values gitlab > gitlab_values.yaml
-
gitlab_values.yaml
을 편집합니다:global: appConfig: artifacts: enabled: false
-
새 값 적용:
helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
-
docker-compose.yml
을 편집합니다:version: "3.6" services: gitlab: environment: GITLAB_OMNIBUS_CONFIG: | gitlab_rails['artifacts_enabled'] = false
-
파일을 저장하고 GitLab을 재시작합니다:
docker compose up -d
-
/home/git/gitlab/config/gitlab.yml
을 편집합니다:production: &base artifacts: enabled: false
-
파일을 저장하고 GitLab을 재시작합니다:
# systemd가 실행 중인 시스템의 경우 sudo systemctl restart gitlab.target # SysV init이 실행 중인 시스템의 경우 sudo service gitlab restart
작업 아티팩트 저장
GitLab 러너는 작업 아티팩트를 포함하는 아카이브를 GitLab에 업로드할 수 있습니다. 기본적으로 작업이 성공한 경우에만 수행되지만, 실패한 경우나 항상 artifacts:when
매개변수를 사용하여 항상 수행될 수도 있습니다.
대부분의 아티팩트는 GitLab 러너에 의해 조정된 후 코디네이터로 전송됩니다. 이에는 보고서 아티팩트가 포함되지 않으며, 이는 업로드 후에 압축됩니다.
로컬 리포지터리 사용
Linux 패키지를 사용하거나 자체 컴파일된 설치를 사용하는 경우, 아티팩트가 로컬에 저장된 위치를 변경할 수 있습니다.
아티팩트는 기본적으로 /var/opt/gitlab/gitlab-rails/shared/artifacts
에 저장됩니다.
-
스토리지 경로를 변경하려면, 예를 들어
/mnt/storage/artifacts
로 변경하려면/etc/gitlab/gitlab.rb
를 편집하고 다음 라인을 추가합니다:gitlab_rails['artifacts_path'] = "/mnt/storage/artifacts"
-
파일을 저장하고 GitLab을 다시 구성합니다:
sudo gitlab-ctl reconfigure
아티팩트는 기본적으로 /home/git/gitlab/shared/artifacts
에 저장됩니다.
-
스토리지 경로를 변경하려면, 예를 들어
/mnt/storage/artifacts
로 변경하려면/home/git/gitlab/config/gitlab.yml
을 편집하고 다음 라인을 추가하거나 수정합니다:production: &base artifacts: enabled: true path: /mnt/storage/artifacts
-
파일을 저장하고 GitLab을 재시작합니다:
# systemd가 실행 중인 시스템의 경우 sudo systemctl restart gitlab.target # SysV init이 실행 중인 시스템의 경우 sudo service gitlab restart
객체 리포지터리 사용
GitLab이 설치된 로컬 디스크를 사용하지 않고 아티팩트를 저장하려면 AWS S3와 같은 객체 리포지터리를 사용할 수 있습니다.
GitLab을 구성하여 아티팩트를 객체 리포지터리에 저장하도록 설정하면 작업 로그의 로컬 디스크 사용 방지도 설정해야 합니다. 두 경우 모두 작업 로그가 아카이브되어 작업이 완료될 때 객체 리포지터리로 이동됩니다.
통합된 객체 리포지터리 설정을 사용해야 합니다.
객체 리포지터리로 이전
작업 아티팩트를 로컬 리포지터리에서 객체 리포지터리로 이전할 수 있습니다. 처리는 배경 작업자에 의해 수행되며 다운타임이 필요하지 않습니다.
- 객체 리포지터리 구성.
-
아티팩트를 이전합니다:
Linux 패키지 (Omnibus)sudo gitlab-rake gitlab:artifacts:migrate
Dockersudo docker exec -t <container name> gitlab-rake gitlab:artifacts:migrate
Self-compiled (source)sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
- 선택 사항. PostgreSQL 콘솔을 사용하여 진행 상황을 추적하고 모든 작업 아티팩트가 성공적으로 이전되었는지 확인합니다.
-
PostgreSQL 콘솔 열기:
Linux 패키지 (Omnibus)sudo gitlab-psql
Dockersudo docker exec -it <container_name> /bin/bash gitlab-psql
Self-compiled (source)sudo -u git -H psql -d gitlabhq_production
-
다음 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
-
-
디스크에 파일이 없는지 확인합니다:
Linux 패키지 (Omnibus)sudo find /var/opt/gitlab/gitlab-rails/shared/artifacts -type f | grep -v tmp | wc -l
Docker/var/opt/gitlab
을/srv/gitlab
로 마운트했다고 가정합니다.sudo find /srv/gitlab/gitlab-rails/shared/artifacts -type f | grep -v tmp | wc -l
Self-compiled (source)sudo find /home/git/gitlab/shared/artifacts -type f | grep -v tmp | wc -l
특정 경우에는 고아 아티팩트 파일 정리 Rake 작업을 실행하여 고아 아티팩트를 정리해야 할 수 있습니다.
객체 리포지터리에서 로컬 리포지터리로 이주
아티팩트를 로컬 리포지터리로 다시 이주하려면:
-
gitlab-rake gitlab:artifacts:migrate_to_local
을 실행합니다. -
gitlab.rb
에서 아티팩트의 리포지터리를 선택적으로 비활성화합니다. - GitLab을 다시 구성합니다.
아티팩트 만료
만약 artifacts:expire_in
을 사용하여 아티팩트의 만료를 설정했다면 해당 날짜가 지난 후에 아티팩트는 삭제됩니다. 그렇지 않은 경우 기본 아티팩트 만료 설정에 따라 만료됩니다.
아티팩트는 Sidekiq가 매 7분마다 실행하는 expire_build_artifacts_worker
크론 작업에 의해 삭제됩니다 (*/7 * * * *
의 Cron 구문).
만료된 아티팩트가 삭제되는 기본 일정을 변경하려면:
-
/etc/gitlab/gitlab.rb
를 편집하고 다음 줄을 추가하세요 (이미 존재하고 주석 처리된 경우 주석 처리를 제거하고 cron 구문을 대체합니다):gitlab_rails['expire_build_artifacts_worker_cron'] = "*/7 * * * *"
-
파일을 저장하고 GitLab을 다시 구성합니다:
sudo gitlab-ctl reconfigure
-
Helm 값들을 내보냅니다:
helm get values gitlab > gitlab_values.yaml
-
gitlab_values.yaml
을 편집하세요:global: appConfig: cron_jobs: expire_build_artifacts_worker: cron: "*/7 * * * *"
-
파일을 저장하고 새 값들을 적용하세요:
helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
-
docker-compose.yml
를 편집하세요:version: "3.6" services: gitlab: environment: GITLAB_OMNIBUS_CONFIG: | gitlab_rails['expire_build_artifacts_worker_cron'] = "*/7 * * * *"
-
파일을 저장하고 GitLab을 다시 시작하세요:
docker compose up -d
-
/home/git/gitlab/config/gitlab.yml
을 편집하세요:production: &base cron_jobs: expire_build_artifacts_worker: cron: "*/7 * * * *"
-
파일을 저장하고 GitLab을 다시 시작하세요:
# systemd를 실행 중인 시스템의 경우 sudo systemctl restart gitlab.target # SysV init를 실행 중인 시스템의 경우 sudo service gitlab restart
아티패트의 최대 파일 크기 설정
만약 아티패트가 활성화된 경우, 관리 영역 설정을 통해 아티패트의 최대 파일 크기를 변경할 수 있습니다.
리포지터리 통계
그룹 및 프로젝트의 작업 아티팩트에 사용된 총 리포지터리를 확인할 수 있습니다:
구현 세부 정보
GitLab이 아티팩트 아카이브를 받으면 GitLab Workhorse에 의해 아카이브 메타데이터 파일도 생성됩니다. 이 메타데이터 파일은 아티팩트 아카이브 자체에 있는 모든 항목을 설명합니다. 메타데이터 파일은 이진 형식으로 되어 있으며 추가적인 Gzip 압축이 적용됩니다.
GitLab은 공간, 메모리 및 디스크 I/O를 저장하기 위해 아티팩트 아카이브를 해제하지 않습니다. 대신 관련 정보가 모두 포함된 메타데이터 파일을 검사합니다. 이는 특히 많은 아티팩트가 있는 경우 또는 아카이브가 매우 큰 파일인 경우에 중요합니다.
특정 파일을 선택할 때 GitLab Workhorse는 그것을 아카이브에서 추출하고 다운로드가 시작됩니다. 이 구현은 공간, 메모리 및 디스크 I/O를 저장합니다.