ジョブアーティファクトの管理

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

これは管理者向けのドキュメントです。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を再起動します:

# 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パッケージまたは自己コンパイルでインストールしている場合は、アーティファクトをローカルに保存する場所を変更できます。

Dockerインストールの場合、データがマウントされるパスを変更できます。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を再起動します:

# For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

オブジェクトストレージを使用する

GitLabがインストールされているローカルディスクにアーティファクトを保存したくない場合は、代わりにAWS S3などのオブジェクトストレージを使用できます。

オブジェクトストレージにアーティファクトを保存するようGitLabを設定する場合は、ジョブログによるローカルディスクの使用を回避することもあわせて検討するとよいでしょう。どちらの場合も、ジョブが完了するとジョブログはアーカイブされ、オブジェクトストレージに移動されます。

マルチサーバーのセットアップでは、ジョブログをローカルディスクに保存しないようにするいずれかのオプションを必ず使用してください。そうしないと、ジョブログが失われる可能性があります。

統合されたオブジェクトストレージ設定を使用する必要があります。

オブジェクトストレージに移行する

ジョブアーティファクトをローカルストレージからオブジェクトストレージに移行できます。この処理はバックグラウンドワーカーで実行され、no downtime（ダウンタイムは不要）です。

オブジェクトストレージを設定します。

アーティファクトを移行します:

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コンソールを使用して、進行状況を追跡し、すべてのジョブアーティファクトを正常に移行したことを確認します。
1. PostgreSQLコンソールを開きます:
  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 p_ci_job_artifacts;

total | filesystem | objectstg
------+------------+-----------
   19 |          0 |        19
```
ディスク上のartifactsディレクトリにファイルがないことを確認します:
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
Geoが有効になっている場合は、すべてのジョブアーティファクトを再検証してください。

場合によっては、孤立したアーティファクトファイルのクリーンアップ用Rakeタスクを実行して、孤立したアーティファクトのクリーンアップが必要となることがあります。

オブジェクトストレージからローカルストレージに移行する

アーティファクトをローカルストレージに戻すには、次の手順に従います:

gitlab-rake gitlab:artifacts:migrate_to_localを実行します。
gitlab.rbで、必要に応じてアーティファクトのストレージを無効にします。
GitLabを再設定します。

アーティファクトの有効期限を設定する

artifacts:expire_inを使用してアーティファクトの有効期限を設定した場合、その期限を過ぎるとすぐに削除対象としてマークされます。設定していない場合は、デフォルトのアーティファクトの有効期限設定に従って期限切れとなります。

Sidekiqが7分ごとに実行するexpire_build_artifacts_worker cronジョブが、アーティファクトを削除します（Cron構文*/7 * * * *）。

期限切れのアーティファクトを削除するデフォルトのスケジュールを変更するには、次の手順に従います:

/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を再起動します:

# For systems running systemd
sudo systemctl restart gitlab.target

# For systems running SysV init
sudo service gitlab restart

アーティファクトの最大ファイルサイズを設定する

アーティファクトが有効になっている場合は、管理者エリアの設定からアーティファクトの最大ファイルサイズを変更できます。

ストレージ統計

グループおよびプロジェクトごとのジョブアーティファクトの合計ストレージ使用量は、次の手段で確認できます:

管理者エリア
グループ APIおよびプロジェクト API

実装の詳細

GitLabがアーティファクトのアーカイブを受信すると、GitLab Workhorseによってアーカイブメタデータファイルも生成されます。このメタデータファイルには、アーティファクトアーカイブ内のすべてのエントリに関する情報が含まれています。メタデータファイルはバイナリ形式で、さらにGzip圧縮が施されています。

GitLabは、容量、メモリ、およびディスクI/Oを節約するために、アーティファクトアーカイブを展開することはありません。代わりに、すべての関連情報を含むメタデータファイルを調べます。これは、アーティファクトが大量にある場合や、アーカイブが非常に大きなファイルである場合に特に重要です。

特定のファイルを選択すると、GitLab Workhorseはアーカイブからそのファイルを抽出し、ダウンロードを開始します。この実装により、容量、メモリ、およびディスクI/Oを節約できます。