작업 아티팩트 관리
이 문서는 아티팩트를 관리하는 문서입니다.
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 Runner는 작업 아티팩트를 포함하는 아카이브를 GitLab에 업로드할 수 있습니다.
기본적으로, 이 작업은 작업이 성공할 때 수행되지만 실패할 때 또는 항상 수행할 수도 있습니다,
artifacts:when
매개변수를 사용합니다.
대부분의 아티팩트는 Coordinator에 전송되기 전에 GitLab Runner에 의해 압축됩니다.
예외는 리포트 아티팩트로, 이는 업로드 후에 압축됩니다.
로컬 스토리지 사용
Linux 패키지를 사용하거나 소스에서 컴파일한 설치를 사용하는 경우에,
아티팩트를 로컬에 저장할 위치를 변경할 수 있습니다.
Helm 차트의 경우, 오브젝트 스토리지를 사용하세요.
아티팩트는 기본적으로 /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을 오브젝트 스토리지에 아티팩트를 저장하도록 구성하면, 작업 로그에 대한 로컬 디스크 사용을 없애는 것을 고려할 수도 있습니다.
두 가지 경우 모두, 작업이 완료되면 작업 로그가 아카이브되어 오브젝트 스토리지로 이동됩니다.
경고: 멀티 서버 설정에서는 작업 로그에 대한 로컬 디스크 사용을 없애는 옵션 중 하나를 사용해야 하며, 그렇지 않으면 작업 로그가 손실될 수 있습니다.
통합 오브젝트 스토리지 설정을 사용해야 합니다.
오브젝트 스토리지로 마이그레이션하기
로컬 스토리지에서 오브젝트 스토리지로 작업 아티팩트를 마이그레이션할 수 있습니다. 처리는 백그라운드 작업자에서 수행되며 다운타임이 필요 없습니다.
- 오브젝트 스토리지 구성하기.
-
아티팩트 마이그레이션:
리눅스 패키지 (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
- 선택 사항. PostgreSQL 콘솔을 사용하여 모든 작업 아티팩트가 성공적으로 마이그레이션되었는지 진행 상황을 추적하고 확인하세요.
-
PostgreSQL 콘솔을 엽니다:
리눅스 패키지 (Omnibus)sudo gitlab-psql
도커sudo docker exec -it <container_name> /bin/bash gitlab-psql
셀프 컴파일 (소스)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
-
-
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 작업을 실행해야 할 수 있습니다.
오브젝트 스토리지에서 로컬 스토리지로 마이그레이션
산출물을 로컬 스토리지로 마이그레이션하려면:
-
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
를 편집하고 다음 줄을 추가합니다 (이미 존재하고 주석 처리된 경우 주석을 제거합니다). 크론 구문으로 일정을 대체합니다:gitlab_rails['expire_build_artifacts_worker_cron'] = "*/7 * * * *"
-
파일을 저장하고 GitLab을 재구성합니다:
sudo gitlab-ctl reconfigure
-
헬름 값을 내보냅니다:
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를 절약합니다.