GitLab CI/CDインスタンスの設定

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

GitLabの管理者は、インスタンスのGitLab CI/CD設定を管理できます。

新規プロジェクトでGitLab CI/CDを無効にする

GitLab CI/CDは、インスタンス上のすべての新しいプロジェクトでデフォルトで有効になっています。CI/CDが新しいプロジェクトでデフォルトで無効になるように設定を変更できます:

自己コンパイルによるインストールの場合: gitlab.yml。
Linuxパッケージインストールの場合: gitlab.rb。

すでにCI/CDが有効になっている既存のプロジェクトは変更されません。また、この設定はプロジェクトのデフォルトのみを変更するため、プロジェクトオーナーはプロジェクト設定でCI/CDを有効にすることができます。

自己コンパイルによるインストールの場合:

エディタでgitlab.ymlを開き、buildsをfalseに設定します:

## Default project features settings
default_projects_features:
  issues: true
  merge_requests: true
  wiki: true
  snippets: false
  builds: false

gitlab.ymlファイルを保存します。
GitLabを再起動します:
```
sudo service gitlab restart
```

Linuxパッケージインストールの場合:

/etc/gitlab/gitlab.rbを編集し、次の行を追加します:

gitlab_rails['gitlab_default_projects_features_builds'] = false

/etc/gitlab/gitlab.rbファイルを保存します。
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

`needs`ジョブ制限を設定する

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

needsで定義できるジョブの最大数は、デフォルトで50です。

GitLab RailsコンソールにアクセスできるGitLab管理者は、カスタム制限を選択できます。たとえば、制限を100に設定するには、次のようにします:

Plan.default.actual_limits.update!(ci_needs_size_limit: 100)

needs依存関係を無効にするには、制限を0に設定します。needsを使用するように構成されたジョブを持つパイプラインは、エラーjob can only need 0 othersを返します。

スケジュールされたパイプラインの最大頻度を変更する

パイプラインスケジュールは任意のcron値で設定できますが、スケジュールどおりに正確に実行されるとは限りません。内部プロセスである_パイプラインスケジュールワーカー_は、スケジュールされたすべてのパイプラインをキューに入れますが、継続的には実行されません。ワーカーは独自のスケジュールで実行され、開始する準備ができているスケジュールされたパイプラインは、ワーカーが次に実行されるときにのみキューに入れられます。スケジュールされたパイプラインは、ワーカーよりも頻繁に実行することはできません。

パイプラインスケジュールワーカーのデフォルトの頻度は、3-59/10 * * * *（10分ごと、0:03、0:13、0:23などで開始）です。GitLab.comのデフォルトの頻度は、GitLab.comの設定にリストされています。

パイプラインスケジュールワーカーの頻度を変更するには、次のようにします:

インスタンスのgitlab.rbファイルで、gitlab_rails['pipeline_schedule_worker_cron']の値を編集します。
変更を有効にするには、GitLabを再設定します。

たとえば、パイプラインの最大頻度を1日に2回に設定するには、pipeline_schedule_worker_cronを0 */12 * * * (00:00および12:00毎日) のcron値に設定します。

パイプラインスケジュールの多くが同時に実行されると、遅延が発生する可能性があります。パイプラインスケジュールワーカーは、システム負荷を分散するために、各バッチ間に短い遅延を置いてバッチでパイプラインを処理します。これにより、システム負荷に応じて、スケジュールされた時刻より数分から1時間以上遅れてパイプラインスケジュールが開始される可能性があります。

ディザスターリカバリー

継続的なダウンタイム中にデータベースへのストレスを軽減するために、アプリケーションの計算コストの高い重要な部分を無効にすることができます。

インスタンスRunnerでのフェアスケジューリングを無効にする

大量のバックログのジョブをクリアするときに、一時的にci_queueing_disaster_recovery_disable_fair_scheduling 機能フラグを有効にすることができます。この機能フラグは、インスタンスRunnerでのフェアスケジューリングを無効にし、jobs/requestエンドポイントでのシステムリソースの使用量を削減します。

有効にすると、ジョブは、多くのプロジェクト間でバランスが取られるのではなく、システムに投入された順に処理されます。

コンピューティングクォータの適用を無効にする

インスタンスRunnerでのコンピューティング時間クォータの適用を無効にするには、一時的にci_queueing_disaster_recovery_disable_quota 機能フラグを有効にすることができます。この機能フラグは、jobs/requestエンドポイントでのシステムリソースの使用量を削減します。

有効にすると、過去1時間に作成されたジョブは、クォータを超えているプロジェクトで実行できます。以前のジョブは、定期的なバックグラウンドワーカー (StuckCiJobsWorker) によってすでにキャンセルされています。