작업 아티팩트 관리
이 문서는 관리 문서입니다. 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
매개 변수를 사용하여 실패했을 때 또는 항상 수행할 수도 있습니다.
대부분의 아티팩트는 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을 객체 저장소에 아티팩트를 저장하도록 구성한 경우, 작업 로그에 대한 로컬 디스크 사용 방지를 원할 수도 있습니다. 양쪽 경우 모두, 작업 로그는 작업이 완료될 때 객체 저장소로 아카이브되고 이동합니다.
경고: 다중 서버 설정에서 로컬 디스크 사용 방지 옵션 중 하나를 사용해야합니다. 그렇지 않으면 작업 로그가 손실될 수 있습니다.
통합된 객체 저장소 설정을 사용해야합니다.
객체 저장소로 마이그레이션
작업 아티팩트를 로컬 저장소에서 객체 저장소로 마이그레이션할 수 있습니다. 처리는 백그라운드 워커에서 진행되며 다운타임이 필요하지 않습니다.
- 객체 저장소를 구성합니다.
-
아티팩트를 마이그레이션합니다:
Linux 패키지 (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 콘솔을 엽니다:
Linux 패키지 (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
-
-
디스크에 파일이 없는지 확인합니다:
Linux 패키지 (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을 다시 구성합니다(GitLab 다시 시작).
아티팩트 만료
만약 artifacts:expire_in
을 사용하여 아티팩트의 만료일을 설정했다면, 해당 날짜가 지난 후 즉시 삭제됩니다. 그렇지 않으면, 기본 아티팩트 만료 설정에 따라 만료됩니다.
아티팩트는 expire_build_artifacts_worker
크론 작업에 의해 삭제됩니다. 이는 Sidekiq이 7분마다 실행합니다(*/7 * * * *
Cron 구문 사용).
만료된 아티팩트를 삭제하는 기본 일정을 변경하려면:
-
/etc/gitlab/gitlab.rb
를 편집하고 다음 라인을 추가합니다(이미 존재하고 주석 처리되어 있다면 주석 처리를 해제하고), 크론 구문으로 사용할 일정을 대체합니다: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 워크호스에 의해 아카이브 메타데이터 파일이 생성됩니다. 이 메타데이터 파일은 아티팩트 아카이브 자체에 있는 모든 항목을 설명합니다. 메타데이터 파일은 이진 형식으로 되어 있으며, 추가 Gzip 압축이 적용되어 있습니다.
GitLab은 공간, 메모리 및 디스크 I/O를 절약하기 위해 아티팩트 아카이브를 추출하지 않습니다. 대신, 모든 관련 정보가 포함된 메타데이터 파일을 검사합니다. 아티팩트가 많거나 아카이브가 매우 큰 파일인 경우 특히 중요합니다.
특정 파일을 선택할 때 GitLab 워크호스는 아카이브에서 해당 파일을 추출하고 다운로드가 시작됩니다. 이 구현 방식은 공간, 메모리 및 디스크 I/O를 절약합니다.