- 最大アタッチメントサイズ
- 最大インポートサイズ
- ネームスペースの最大保存サイズ
- リポジトリサイズ制限
- トラブルシューティング
- 個人アクセストークンの有効期限の制限
- 個人アクセストークンの有効期限の任意設定
- ユーザープロファイル名の変更の無効化
アカウントと限度額の設定
最大アタッチメントサイズ
GitLabでは、コメントや返信の添付ファイルの最大サイズを変更することができます。管理エリア(レンチアイコン)>設定>一般に移動し、アカウントと制限を展開します。 ここから、Maximum attachment size (MB)
の値を変更することで増減することができます。
最大インポートサイズ
GitLabでインポートの最大ファイルサイズを変更することができます。管理エリア(レンチアイコン)>設定>一般に移動し、アカウントと制限を展開します。 ここから、Maximum import size (MB)
の値を変更することで増減できます。
ネームスペースの最大保存サイズ
これは、各ネームスペースの最大サイズ制限を設定します。 以下のものがネームスペースのサイズに含まれます:
- リポジトリ
- Wiki
- LFSオブジェクト
- アーティファクトの構築
- パッケージ
リポジトリサイズ制限
GitLab インスタンス内のリポジトリは、特に LFS を使っている場合は急速に大きくなる可能性があります。 そのサイズは指数関数的に大きくなる可能性があり、利用可能なストレージを急速に消費します。
このような事態を避けるために、リポジトリのサイズにハードリミットを設定することができます。 このリミットはグローバル、グループ、プロジェクトごとに設定でき、プロジェクトごとのリミットが最も優先されます。
リポジトリサイズに制限を設けるユースケースは数多くあります。 例えば、次のようなワークフローを考えてみましょう:
- あなたのチームでは、アプリケーション・リポジトリに大きなファイルを保存する必要があるアプリを開発しています。
- プロジェクトで gitLFSを有効にしましたが、ストレージが大幅に増えてしまいました。
- 利用可能なストレージを超える前に、リポジトリごとに10GBの制限を設定します。
どのように動作するか
GitLab管理者だけがこれらの制限を設定することができます。制限を0
に設定すると、制限がないことを意味します。
これらの設定は
- 各プロジェクトの設定:
- プロジェクトのホームページから、「設定」>「一般」と進みます。
- 命名、トピック、アバター」セクションの「リポジトリサイズ制限」(MB)フィールドに入力します。
- 変更を保存する]をクリックします。
- 各グループの設定:
- グループのホームページから、「設定」>「一般」と進みます。
- Naming, visibilityセクションのRepository size limit(MB)フィールドに記入してください。
- 変更を保存する]をクリックします。
- GitLabのグローバル設定:
- ダッシュボードから、管理エリア > 設定 > 一般に移動します。
- アカウントと制限のセクションを展開します。
- リポジトリあたりのサイズ制限(MB)フィールドに入力します。
- 変更を保存する]をクリックします。
LFS オブジェクトを含む新しいプロジェクトの最初のプッシュは、サイズがチェックされ、それらのサイズの合計が許容される最大リポジトリサイズを超える場合は拒否されます。
注:リポジトリサイズの制限には、リポジトリファイルと LFS が含まれ、アーティファクトは含まれません。
手動でファイルをパージする方法については、Gitを使ったリポジトリサイズの削減をご覧ください。
トラブルシューティング
413 リクエスト・エンティティが大きすぎる
GitLabでコメントや返信にファイルを添付しているときに413 Request Entity Too Large
のエラーが表示される場合は、添付ファイルの最大サイズがウェブサーバーで許可されているサイズより大きいことが原因である可能性があります。
例えば、GitLabOmnibusのインストールで添付ファイルの最大サイズを200mにしたい場合は、添付ファイルの最大サイズを増やす前に/etc/gitlab/gitlab.rb
:
nginx['client_max_body_size'] = "200m"
個人アクセストークンの有効期限の制限
GitLab Ultimate12.6で導入されました。
ユーザーは、個人アクセストークンの有効期限をオプションで指定することができます。 この有効期限は必須ではなく、任意の日付を設定することができます。
個人アクセストークンはGitLabへのプログラムアクセスに必要な唯一のトークンなので、セキュリティ要件がある組織では、これらのトークンの定期的なローテーションを要求するために保護を強化したいと思うかもしれません。
制限の設定
GitLab管理者のみが制限を設定することができます。 空のままにしておくと、制限がないことを意味します。
個人アクセストークンの有効期限を設定します:
- 管理エリア > 設定 > 一般に移動します。
- アカウントと制限のセクションを展開します。
- 個人アクセストークンの最大有効期間(日)フィールドに入力します。
- 変更を保存する]をクリックします。
個人アクセストークンのライフタイムが設定されると、GitLabは以下を行います:
- 新しい個人アクセストークンに有効期間を適用し、ユーザーに有効期限と許容される有効期間より後の日付の設定を義務付けます。
- 3時間後に、有効期限のない古いトークン、または許可された有効期限よりも長い有効期限の古いトークンを失効させます。 3時間は、失効が行われる前に管理者が許可された有効期限を変更したり、削除したりできるようにするために与えられています。
個人アクセストークンの有効期限の任意設定
- GitLab Ultimate13.1で導入されました。
- 機能フラグの後ろにデプロイされ、デフォルトでは無効になっています。
- GitLab.comでは無効になっています。
- 本番での使用はお勧めできません。
- GitLabセルフマネージドインスタンスで使うには、GitLab管理者に頼んで有効にしてもらいましょう。
GitLab管理者は、個人アクセストークンが自動的に失効しないように設定することができます。 トークンは、明示的に失効されない限り、有効期限後も使用可能です。
そのためには:
- 管理エリア > 設定 > 一般に移動します。
- アカウントと制限のセクションを展開します。
- 個人アクセストークンの有効期限を強制する]チェックボックスをオフにします。
個人アクセストークンの有効期限のオプションの有効化または無効化 機能
Optional Enforcement of Personal Access Token Expiryは開発中であり、本番環境ではまだ使用できません。デフォルトでは無効になっている機能フラグの後ろにデプロイされています。 GitLab RailsコンソールにアクセスできるGitLab管理者は、railsコンソールからインスタンスに対して有効にすることができます。
有効にするには:
Feature.enable(:enforce_personal_access_token_expiration)
無効化するには:
Feature.disable(:enforce_personal_access_token_expiration)
ユーザープロファイル名の変更の無効化
GitLab 12.7から導入されました。
Audit Eventsのユーザー詳細の整合性を保つために、GitLab管理者はユーザーがプロフィール名を変更できないようにすることができます。
そのためには:
- 管理エリア > 設定 > 一般を開き、アカウントと制限を展開します。
- ユーザーがプロフィール名を変更できないようにする]チェックボックスをオンにします。