プッシュ通知
新記事をすぐにお知らせ
🎙️ 音声: ずんだもん / 春日部つむぎ(VOICEVOX)
.gitlab-ci.ymlのartifacts: exclude設定も併用すると効率的です自己ホスト型GitLabでアーティファクトサイズの上限を引き上げるには、Admin Areaの設定変更が最も簡単です。プラン制限の制約がないため、サーバーリソースの許す限り自由に上限を設定できますが、ディスク容量やメモリの監視が重要になります。
GitLab.com(SaaS版)とセルフマネージド版(自己ホスト型)では、アーティファクトサイズ上限の扱いが大きく異なります。
**GitLab.com(SaaS版)**では、サブスクリプションプランごとに上限が決められています。例えば、Freeプランでは256MB、Premiumプランでは2GBなど、プランに応じた制限が存在します。
一方、自己ホスト型GitLabではこのようなプラン制限が存在しません。つまり、サーバーのリソース(ディスク容量やメモリ)が許す限り、アーティファクトサイズの上限を自由に設定できるということです。これは大規模なビルド成果物を扱う組織にとって大きなメリットになります。
アーティファクトサイズの上限を変更する最も標準的な方法は、GitLabの管理画面から行います。
GitLabインスタンスの管理者権限を持つアカウントでログインし、管理者エリア(Admin Area)を開きます。通常、画面左上のメニューから「Admin」を選択するか、URLで /admin にアクセスします。
Admin Areaの左側メニューから Settings > CI/CD を選択します。このページには、CIパイプライン全体に関わる設定が集約されています。
ページ内で 「Maximum artifact size (MB)」 という項目を探します。デフォルト値が表示されていますので、これを希望のサイズに変更してください。
例えば、現在の上限が100MBで、5GBまで対応したい場合は、5120(5GB = 5120MB)と入力します。
画面下部の 「Save changes」 ボタンをクリックして、設定を保存します。この変更はGitLabインスタンス全体に即座に適用されます。
既に実行中のパイプラインがある場合、新しい上限を適用するためにパイプラインを再実行してください。新規ジョブから新しい上限が有効になります。
GitLabのアーティファクト制限は、複数のレベルで設定されています。正確に理解することが、トラブルシューティングに役立ちます。
Admin Areaで設定する値です。パイプラインで生成されるアーティファクトアーカイブ全体の上限を指定します。これが最も広範な制限になります。
デフォルトでは、圧縮後の単一ファイルあたり100MBという制限があります。これはアーカイブ全体の上限とは別の制約です。
さらに細かい制御が必要な場合、Railsコンソールを使用して、特定のアーティファクトタイプ(junit、sast、archiveなど)ごとに上限を設定できます。
より高度な設定が必要な場合、GitLabのRailsコンソールを使用して、アーティファクトタイプごとの上限を個別に設定できます。
自己ホスト型GitLabのサーバーにSSH接続し、以下のコマンドを実行します:
sudo gitlab-rails console
例えば、archiveタイプのアーティファクト上限を1GB(1024MB)に設定する場合:
Plan.default.actual_limits.update!(ci_max_artifact_size_archive: 1024)
他のタイプの例:
# JUnit形式のレポート上限を512MBに
Plan.default.actual_limits.update!(ci_max_artifact_size_junit: 512)
# SAST形式のレポート上限を2GBに
Plan.default.actual_limits.update!(ci_max_artifact_size_sast: 2048)
**デフォルト値は0**で、これはプロジェクト全体の上限(Admin Areaで設定した値)が適用されることを意味します。
設定が正しく適用されたか確認するには:
Plan.default.actual_limits
このコマンドで、全アーティファクトタイプの制限値が表示されます。
アーティファクトサイズの上限を引き上げる際に、注意すべき点があります。
ディスク容量がサイズ上限を超えないよう注意してください。アーティファクトは通常、GitLabサーバーの/var/opt/gitlab/gitlab-rails/shared/artifactsディレクトリに保存されます。ディスク使用率を定期的に監視し、必要に応じてストレージを拡張してください。
また、メモリ使用量も考慮が必要です。大容量のアーティファクトを圧縮・解凍する際にメモリが消費されるため、サーバーのRAM容量が不足していないか確認しましょう。
サイズ超過時には以下のエラーが発生します:
ERROR: Job failed: artifact size limit exceeded
このエラーが頻繁に発生する場合、単に上限を引き上げるのではなく、後述の除外設定で不要なファイルを削減することも検討してください。
上限を引き上げるだけでなく、アーティファクトに含めるファイルを厳選することも重要です。
.gitlab-ci.ymlで、アーティファクトから特定のファイルやディレクトリを除外できます:
build_job:
script:
- npm run build
artifacts:
paths:
- dist/
- build/
exclude:
- dist/**/*.map # ソースマップを除外
- build/temp/**/* # 一時ファイルを除外
- "**/*.log" # ログファイルを除外
この方法で、実際に必要なファイルだけをアーティファクトに含めることで、ストレージ効率を大幅に改善できます。
大容量のテキストファイルが多い場合、gzip圧縮を活用してサイズを削減できます:
build_job:
script:
- npm run build
- tar -czf reports.tar.gz reports/
artifacts:
paths:
- reports.tar.gz
いきなり大幅に上限を引き上げるのではなく、段階的に増やしながら動作を確認することをお勧めします。例えば、100MB → 500MB → 1GB というように、様子を見ながら進めてください。
上限を引き上げた後も、ディスク使用率を定期的に確認してください。GitLabには、古いアーティファクトを自動削除する設定もあります(artifacts_expire_in)。これを活用して、不要なアーティファクトを自動的に削除するようにしましょう。
チーム内で、なぜこの上限に設定したのか、どのような運用ルールを決めたのかをドキュメント化しておくことが、将来的なトラブルシューティングに役立ちます。
設定を変更した後、既に実行中のジョブには新しい上限が適用されません。新しいパイプラインを実行して、変更が反映されたか確認してください。
以下の点を確認してください:
上限を大幅に引き上げた後、GitLabのパフォーマンスが低下した場合、アーティファクト保存用のストレージをSSDからより高速なストレージに変更する、またはネットワークストレージを使用することを検討してください。
自己ホスト型GitLabでアーティファクトサイズの上限を引き上げることは、SaaS版のような制限がないため、比較的簡単に実現できます。ただし、サーバーリソースの監視と、不要ファイルの除外設定を組み合わせることで、安定した運用が可能になります。
段階的に上限を調整しながら、チームの実際のニーズに合わせた最適な設定を見つけていくことが、長期的な成功の鍵となるでしょう。
記事数の多いカテゴリから探す