設定オプション

GitLabの設定は、/etc/gitlab/gitlab.rbで関連するオプションを設定することで行います。デフォルト設定のリストについてはパッケージのデフォルトを参照し、利用可能なオプションの完全なリストについてはgitlab.rb.templateをご覧ください。GitLab 7.6から始まる新規インストールでは、デフォルトでインストール時のテンプレートのオプションがすべて/etc/gitlab/gitlab.rb にリストされています。

GitLabの外部URLの設定

注：外部URLを変更する前に、管理エリア>設定>一般>サインインの制限で、カスタムホームページURLまたはサインアウト後のパスを以前に定義しているかどうかを確認する必要があります。 URLが定義されている場合は、それらを更新するか、完全に削除してください。 これらの設定はどちらも、新しい外部URLを設定した後に意図しないリダイレクトを引き起こす可能性があります。

GitLab がユーザーに正しいリポジトリクローンリンクを表示するためには、ユーザーが到達する URL を知る必要があります。例えば、http://gitlab.example.com。/etc/gitlab/gitlab.rbに以下の行を追加または編集します： 

external_url "http://gitlab.example.com"

を実行してください： 

sudo gitlab-ctl reconfigure
注意:外部URLを変更した後は、Markdownキャッシュも無効にすることをお勧めします。

自己管理GitLabインスタンスでのDNSの使用についての詳細は、DNSのドキュメントをご覧ください。

インストール時の外部URLの指定

最小限のコマンドで GitLab インスタンスを簡単に立ち上げられるように、omnibus-gitlab はパッケージのインストール時に環境変数EXTERNAL_URL の使用をサポートしています。この環境変数の存在を検出すると、パッケージのインストール（またはアップグレード）の一環として、その値がgitlab.rb ファイルにexternal_url として書き込まれます。

注意:EXTERNAL_URL 環境変数は、パッケージのインストール/アップグレードにのみ影響しま す。通常のsudo gitlab-ctl reconfigure の実行には、/etc/gitlab/gitlab.rb の値が使われます。
注意:パッケージアップデートの一環として、EXTERNAL_URL 変数を不用意に設 定すると、警告なしに/etc/gitlab/gitlab.rbの既存の値を置き換えてしまいます。そのため、変数をグ ローバルには設定せず、インストールコマンドに特別に渡すことをお勧めしま す：
sudo EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ee

GitLab の相対 URL の設定

注:Omnibus GitLabの相対URLサポートは実験的なもので、バージョン8.5で導入されました。ソースのインストールについては、別のドキュメントがあります。

GitLabは独自の（サブ）ドメインにインストールすることが推奨されていますが、様々な理由でそうできない場合もあります。 そのような場合、GitLabは相対URL、例えばhttps://example.com/gitlab.にインストールすることもできます。

URL を変更するとリモートの URL もすべて変更されるので、GitLab インスタンスを指すローカルリポジトリは手動で編集しなければならないことに注意しましょう。

相対URLの要件

8.17パッケージからは、アセットを再コンパイルする必要はありません。

OmnibusのGitLabパッケージには、コンパイル済みのアセット（CSS、JavaScript、フォントなど）が同梱されています。_8.17より前の_パッケージを使用していて、相対URLでOmnibusを設定した場合、アセットを再コンパイルする必要があります。 メモリ不足のエラーを回避するには、システムに2GB以上のRAMが必要です。4GBのRAM、4または8CPUコアを推奨します。

GitLab で相対 URL を有効にする

GitLabで相対URLを有効にするには、以下の手順に従ってください：

  1. (オプション）リソースが不足した場合は、次のコマンドでPuma（またはUnicorn）とSidekiqをシャットダウンすることで、一時的にメモリを解放することができます： 

    sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq

  2. /etc/gitlab/gitlab.rbでexternal_url を設定： 

    external_url "https://example.com/gitlab"

    この例では、GitLabが提供される相対URLは/gitlab。お好みで変更してください。

  3. 変更を有効にするために GitLab を再設定します： 

    sudo gitlab-ctl reconfigure

  4. Sidekiqが変更をピックアップするように、サービスを再起動します。 

    sudo gitlab-ctl restart

何らかのイシューに遭遇した場合は、トラブルシューティングのセクションを参照してください。

GitLab で相対 URL を無効にする方法

相対URLを無効にするには、上記と同じ手順に従って、external_url 、相対パスを含まないものに設定してください。Unicornを使用している場合は、再設定タスクの終了後、明示的に再起動する必要があるかもしれません： 

sudo gitlab-ctl restart unicorn

Pumaはリコンフィギュレーション中に完全な再起動をすでに行っているので、明示的な再起動は必要ありません。

何らかのイシューに遭遇した場合は、トラブルシューティングのセクションを参照してください。

相対URLのトラブルシューティング

相対URL設定に移行した後、GitLabのアセットが壊れたように見える問題（画像がない、コンポーネントが反応しないなど）に気づいた場合は、GitLabでFrontend ラベルを付けてイシューを提起してください。

_8.17より前の_バージョンを使用していて、何らかの理由でアセットのコンパイルステップが失敗した場合（サーバがメモリ不足になった場合など）、イシューにアドレス（スワップの追加など）を設定してから手動でタスクを実行することができます： 

sudo NO_PRIVILEGE_DROP=true USE_DB=false gitlab-rake assets:clean assets:precompile
sudo chown -R git:git /var/opt/gitlab/gitlab-rails/tmp/cache

gitlab.rbでuser['username']、user['group'] 、gitlab_rails['dir'] のデフォルトを変更した場合、ユーザーとパスが異なる可能性があります。その場合、上記のchown コマンドが正しいユーザー名とグループで実行されていることを確認してください。

非 root ユーザーからの外部設定ファイルの読み込み

OmnibusのGitLabパッケージは、すべての設定を/etc/gitlab/gitlab.rb ファイルから読み込みます。このファイルは厳格なファイル権限を持っており、root ユーザーによって所有されています。厳格な権限と所有権を持つ理由は、/etc/gitlab/gitlab.rb がgitlab-ctl reconfigureの間にroot ユーザーによってRubyコードとして実行されるためです。これは、/etc/gitlab/gitlab.rb への書き込み権限を持つユーザーは、rootによってコードとして実行される設定を追加できることを意味します。

特定の組織では、設定ファイルへのアクセスは許可されていますが、rootユーザーとしては許可されていません。ファイルへのパスを指定することで、/etc/gitlab/gitlab.rb 内部に外部設定ファイルを含めることができます： 

from_file "/home/admin/external_gitlab.rb"

from_file を使用して/etc/gitlab/gitlab.rb にインクルードしたコードは、sudo gitlab-ctl reconfigureを実行する際にroot 権限で実行されることに注意してください。from_file がインクルードされた後に/etc/gitlab/gitlab.rb で設定されたコンフィギュレーションは、インクルードされたファイルからのコンフィギュレーションよりも優先されます。

代替ディレクトリへの git データの保存

デフォルトでは、Omnibus GitLab は Git リポジトリデータを/var/opt/gitlab/git-dataの下に保存します。リポジトリはサブフォルダrepositoriesに保存されます。git-data の親ディレクトリの場所を変更するには、/etc/gitlab/gitlab.rbに以下の行を追加します。 

git_data_dirs({ "default" => { "path" => "/mnt/nas/git-data" } })

/etc/gitlab/gitlab.rb に以下の行を追加することで、複数の git データ・ディレクトリを追加することもできます。 

git_data_dirs({
  "default" => { "path" => "/var/opt/gitlab/git-data" },
  "alternative" => { "path" => "/mnt/nas/git-data" }
})

Gitalyを独自のサーバーで実行している場合は、各Gitデータ・ディレクトリのgitaly_address 。 Gitalyの設定に関するドキュメントを参照してください。

ターゲット・ディレクトリとそのサブパスはシンボリックリンクであってはならないことに注意してください。

sudo gitlab-ctl reconfigure を実行して変更を有効にします。

/var/opt/gitlab/git-data にすでに Git リポジトリがある場合は、次のようにして新しい場所に移動できます： 

# Prevent users from writing to the repositories while you move them.
sudo gitlab-ctl stop

# Note there is _no_ slash behind 'repositories', but there _is_ a
# slash behind 'git-data'.
sudo rsync -av /var/opt/gitlab/git-data/repositories /mnt/nas/git-data/

# Start the necessary processes and run reconfigure to fix permissions
# if necessary
sudo gitlab-ctl upgrade

# Double-check directory layout in /mnt/nas/git-data. Expected output:
# repositories
sudo ls /mnt/nas/git-data/

# Done! Start GitLab and verify that you can browse through the repositories in
# the web interface.
sudo gitlab-ctl start

Gitユーザー／グループ名の変更

デフォルトでは、Omnibus GitLabはgit GitLab Shellのログイン、Gitデータ自体の所有権、Webインターフェイスでの gitSSgit H URL生成に gitユーザー名を使用しますgit 。 同様に、 gitグループはGitデータのグループ所有権に使用されます。

予期せぬ副作用を引き起こす可能性があるため、既存のインストールのユーザーとグループを変更することはお勧めしません。 それでもユーザーとグループを変更したい場合は、/etc/gitlab/gitlab.rbに以下の行を追加してください。 

user['username'] = "gitlab"
user['group'] = "gitlab"

sudo gitlab-ctl reconfigure を実行して変更を有効にします。

既存のインストールのユーザ名を変更する場合、reconfigure を実行しても入れ子になっているディレクトリの所有者は変更されないので、手動で変更する必要があることに注意してください。 新しいユーザがuploads ディレクトリだけでなくrepositories にもアクセスできることを確認してください。

ユーザーとグループの識別子を数値で指定します。

Omnibus GitLabは、GitLab、PostgreSQL、Redis、NGINXのユーザを作成します。これらのユーザの数値識別子は、/etc/gitlab/gitlab.rb で以下のように指定できます。 

user['uid'] = 1234
user['gid'] = 1234
postgresql['uid'] = 1235
postgresql['gid'] = 1235
redis['uid'] = 1236
redis['gid'] = 1236
web_server['uid'] = 1237
web_server['gid'] = 1237

sudo gitlab-ctl reconfigure を実行して変更を有効にします。

ユーザーとグループのアカウント管理の無効化

デフォルトでは、Omnibus GitLabはシステムユーザーとグループアカウントの作成と情報の更新を行います。 これらのシステムアカウントはパッケージの様々なコンポーネントを実行します。 ほとんどのユーザーはこの動作を変更する必要はありません。 しかし、システムアカウントがLDAPなど他のソフトウェアで管理されている場合は、パッケージが行うアカウント管理を無効にする必要があるかもしれません。

ユーザーとグループのアカウント管理を無効にするには、/etc/gitlab/gitlab.rb で設定します： 

manage_accounts['enable'] = false

警告Omnibus GitLabは、Omnibus GitLabパッケージがインストールされたシステム上にユーザーとグループが存在することを想定しています。

デフォルトでは、Omnibus GitLab パッケージは以下のユーザが存在することを想定しています： 

# GitLab user (required)
git

# Web server user (required)
gitlab-www

# Redis user for GitLab (only when using packaged Redis)
gitlab-redis

# Postgresql user (only when using packaged Postgresql)
gitlab-psql

# Prometheus user for prometheus monitoring and various exporters
gitlab-prometheus

# GitLab Mattermost user (only when using GitLab Mattermost)
mattermost

# GitLab Registry user (only when using GitLab Registry)
registry

# GitLab Consul user (only when using GitLab Consul)
gitlab-consul

デフォルトでは、Omnibus GitLabパッケージは以下のグループが存在することを想定しています： 

# GitLab group (required)
git

# Web server group (required)
gitlab-www

# Redis group for GitLab (only when using packaged Redis)
gitlab-redis

# Postgresql group (only when using packaged Postgresql)
gitlab-psql

# Prometheus user for prometheus monitoring and various exporters
gitlab-prometheus

# GitLab Mattermost group (only when using GitLab Mattermost)
mattermost

# GitLab Registry group (only when using GitLab Registry)
registry

# GitLab Consul group (only when using GitLab Consul)
gitlab-consul

異なるユーザー/グループ名を使用することもできますが、その場合は/etc/gitlab/gitlab.rbでユーザー/グループの詳細を指定する必要があります。 

# Do not manage user/group accounts
manage_accounts['enable'] = false

# GitLab
user['username'] = "custom-gitlab"
user['group'] = "custom-gitlab"
user['shell'] = "/bin/sh"
user['home'] = "/var/opt/custom-gitlab"

# Web server
web_server['username'] = 'webserver-gitlab'
web_server['group'] = 'webserver-gitlab'
web_server['shell'] = '/bin/false'
web_server['home'] = '/var/opt/gitlab/webserver'

# Postgresql (not needed when using external Postgresql)
postgresql['username'] = "postgres-gitlab"
postgresql['group'] = "postgres-gitlab"
postgresql['shell'] = "/bin/sh"
postgresql['home'] = "/var/opt/postgres-gitlab"

# Redis (not needed when using external Redis)
redis['username'] = "redis-gitlab"
redis['group'] = "redis-gitlab"
redis['shell'] = "/bin/false"
redis['home'] = "/var/opt/redis-gitlab"

# And so on for users/groups for GitLab Mattermost

ユーザのホームディレクトリの移動

注：GitLabユーザーにとって、ホームディレクトリはローカルディスク（つまりNFSではない）に設定することがパフォーマンス向上のために推奨されます。 NFSに設定すると、GitリクエストはGit設定を読み込むために別のネットワークリクエストを行う必要があり、Gitオペレーションにおけるレイテンシが増加します。

既存のホームディレクトリを移動するには、GitLabサービスを停止する必要があり、多少のダウンタイムが必要です。

  1. GitLabの停止 

    gitlab-ctl stop

  2. runitサーバーの停止 

    # Using systemctl (Debian => 9 - Stretch):
sudo systemctl stop gitlab-runsvdir

# Using upstart (Ubuntu <= 14.04):
sudo initctl stop gitlab-runsvdir

# Using systemd (CentOS, Ubuntu >= 16.04):
systemctl stop gitlab-runsvdir.service

  3. ホームディレクトリを変更します。 既存のデータがある場合は、手動で新しい場所にコピー/同期する必要があります。 

    usermod -d /path/to/home USER

  4. のコンフィギュレーション設定を変更します。gitlab.rb 

    user['home'] = "/var/opt/custom-gitlab"

  5. runitサーバーの起動 

    # Using systemctl (Debian => 9 - Stretch):
sudo systemctl start gitlab-runsvdir

# Using upstart (Ubuntu <= 14.04):
sudo initctl start gitlab-runsvdir

# Using systemd (CentOS, Ubuntu >= 16.04):
systemctl start gitlab-runsvdir.service

  6. 再設定の実行 

    gitlab-ctl reconfigure

runnitサービスが停止しておらず、ユーザーのホームディレクトリが手動で移動されていない場合、GitLabは再設定中にエラーに遭遇します： 

account[GitLab user and group] (gitlab::users line 28) had an error: Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab user and group] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/account.rb line 51) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '8'
---- Begin output of ["usermod", "-d", "/var/opt/gitlab", "git"] ----
STDOUT:
STDERR: usermod: user git is currently used by process 1234
---- End output of ["usermod", "-d", "/var/opt/gitlab", "git"] ----
Ran ["usermod", "-d", "/var/opt/gitlab", "git"] returned 8

このイシューを回避するため、必ず上記の手順に従ってください。

ストレージ・ディレクトリ管理の無効化

OmnibusのGitLabパッケージは、正しい所有者と権限で必要なディレクトリをすべて作成し、これを更新し続けます。

これらのディレクトリの中には大容量のデータを保持するものもあるため、特定のセットアップでは、これらのディレクトリはNFS（またはその他の）共有にマウントされることがほとんどでしょう。

マウントの種類によっては、rootユーザー（初期設定のデフォルトユーザー）によるディレクトリの自動作成が許可されないことがあります。例えば、共有上でroot_squash が有効になっているNFSなどです。これを回避するために、Omnibus GitLabパッケージはディレクトリのオーナーユーザーを使ってディレクトリの作成を試みます。

/etc/gitlab ディレクトリをマウントしている場合、そのディレクトリの管理をオフにすることができます。

/etc/gitlab/gitlab.rb セットで： 

manage_storage_directories['manage_etc'] = false

GitLabのすべてのストレージディレクトリをそれぞれ別のマウントにマウントしている場合は、ストレージディレクトリの管理を完全に無効にしてください。

これらのディレクトリの管理を無効にするには、/etc/gitlab/gitlab.rb set： 

manage_storage_directories['enable'] = false

警告Omnibus GitLabパッケージは、これらのディレクトリがファイルシステム上に存在することを期待します。 この設定が設定されている場合、正しい権限を作成し設定するのは管理者次第です。

この設定を有効にすると、以下のディレクトリが作成されなくなります：

デフォルトの場所 権限 所有権 目的
/var/opt/gitlab/git-data 0700 git:root リポジトリディレクトリを保持します。
/var/opt/gitlab/git-data/repositories 2770 git:git Git リポジトリの保持
/var/opt/gitlab/gitlab-rails/shared 0751 git:gitlab-www 大きなオブジェクト・ディレクトリを保持
/var/opt/gitlab/gitlab-rails/shared/artifacts 0700 git:root CIアーティファクトを保持
/var/opt/gitlab/gitlab-rails/shared/lfs-objects 0700 git:root LFS オブジェクトを保持
/var/opt/gitlab/gitlab-rails/uploads 0700 git:root ユーザーの添付ファイルを保持
/var/opt/gitlab/gitlab-rails/shared/pages 0750 git:gitlab-www ユーザーページの保持
/var/opt/gitlab/gitlab-ci/builds 0700 git:root CI のビルドログを保持
/var/opt/gitlab/.ssh 0700 git:git 作成者のキーを保持

指定したファイルシステムがマウントされた後、Omnibus GitLab サービスのみを開始します。

指定したファイルシステムがマウントされる前に Omnibus GitLab サービス（NGINX、Redis、Puma など）が起動しないようにするには、/etc/gitlab/gitlab.rbに以下を追加します： 

# wait for /var/opt/gitlab to be mounted
high_availability['mountpoint'] = '/var/opt/gitlab'

sudo gitlab-ctl reconfigure を実行して変更を有効にします。

ランタイムディレクトリの設定

Prometheusのモニタリングを有効にすると、GitLab Exporterは各Pumaプロセスの測定（Railsメトリクス）を行います。 各Pumaプロセスは、コントローラリクエストごとにメトリクスファイルを一時的な場所に書き込む必要があります。 Prometheusはこれらのファイルをすべて収集し、値を処理します。

ディスクI/Oの発生を避けるため、Omnibus GitLabパッケージはランタイムディレクトリを使用します。

reconfigureの間、パッケージは/run がtmpfs マウントであるかどうかをチェックします。そうでない場合、警告が表示されます： 

Runtime directory '/run' is not a tmpfs mount.

とRailsメトリクスが無効になります。

Railsメトリクスを再び有効にするには、tmpfs マウントを作成し、/etc/gitlab/gitlab.rbで指定します： 

runtime_dir '/path/to/tmpfs'
注：= の設定はありませんのでご注意ください。

設定を有効にするには、sudo gitlab-ctl reconfigure を実行してください。

ラックアタックの設定

不正なクライアントによる被害を防ぐために、GitLabではRack Attack gemを使用しています。 詳しくはこちらのページをご覧ください。

インストール時の自動キャッシュクリーニングの無効化

GitLabのインストールが大規模な場合、rake cache:clean タスクを実行したくないかもしれません。終了までに時間がかかることがあるからです。 デフォルトでは、キャッシュクリアタスクは再設定中に自動的に実行されます。

/etc/gitlab/gitlab.rbを編集します： 

# This is an advanced feature used by large gitlab deployments where loading
# whole RAILS env takes a lot of time.
gitlab_rails['rake_cache_clear'] = false

この行の先頭にある# のコメント文字を削除することを忘れないでください。

ラックアタックの有効化/無効化と基本的な認証スロットリングの設定

次のコンフィギュレーション設定でラックアタックをコントロールします： 

gitlab_rails['rack_attack_git_basic_auth'] = {
  'enabled' => true, # Enable/Disable Rack Attack
  'ip_whitelist' => ["127.0.0.1"], # Whitelisted urls
  'maxretry' => 10, # Limit the number of Git HTTP authentication attempts per IP
  'findtime' => 60, # Reset the auth attempt counter per IP after 60 seconds
  'bantime' => 3600 # Ban an IP for one hour (3600s) after too many auth attempts
}

なりすましの無効化

なりすましを無効にする方法は、APIドキュメントに記載されています。

Sentryによるエラーレポートとロギング

Sentryは、SaaSまたはオンプレミスで使用できるエラーレポートとロギングツールです。 オープンソースで、ソースコードリポジトリはこちらから閲覧できます。

Sentryを設定するには、以下の設定を使用できます： 

gitlab_rails['sentry_enabled'] = true
gitlab_rails['sentry_dsn'] = 'https://<key>@sentry.io/<project>'
gitlab_rails['sentry_clientside_dsn'] = 'https://<key>@sentry.io/<project>'
gitlab_rails['sentry_environment'] = 'production'

Sentry環境は、ラボ、開発者、ステージング、本番環境など、複数のデプロイされたGitLab環境にわたってエラーやイシューを追跡するために使用できます。

特定のサーバから送信されるすべてのイベントにカスタムSentryタグを設定するには、GITLAB_SENTRY_EXTRA_TAGS環境変数を設定します。これは、そのサーバからのすべての例外に対してSentryに渡すべきタグを表すJSONエンコードされたハッシュです。

インスタンス： 

gitlab_rails['env'] = {
  'GITLAB_SENTRY_EXTRA_TAGS' => '{"stage": "main"}'
}

ステージ’タグに’main’を追加します。

コンテンツセキュリティポリシー

Content Security Policy(CSP) を設定することで、JavaScript のクロスサイトスクリプティング(XSS) 攻撃を阻止することができます。 詳細はCSP に関する Mozilla のドキュメントを参照してください。

GitLab 12.2では、インラインJavaScriptによるCSPとnoncesのサポートが追加されました。デフォルトではまだオンに設定されていません。 GitLabのほとんどのインストールで動作する設定例を以下に示します： 

gitlab_rails['content_security_policy'] = {
    enabled: true,
    report_only: false,
    directives: {
      default_src: "'self'",
      script_src: "'self' 'unsafe-inline' 'unsafe-eval' https://www.recaptcha.net https://apis.google.com",
      frame_ancestor: "'self'",
      frame_src: "'self' https://www.recaptcha.net/ https://content.googleapis.com https://content-compute.googleapis.com https://content-cloudbilling.googleapis.com https://content-cloudresourcemanager.googleapis.com",
      img_src: "* data: blob:",
      style_src: "'self' 'unsafe-inline'"
    }
}

CSPルールを不適切に設定すると、GitLabが正常に動作しなくなる可能性があります。 ポリシーをロールアウトする前に、report_only をtrue に変更して設定をテストすることもできます。

インストール時の root 初期パスワードの設定

ユーザroot の初期パスワードは、インストール時に環境変数 `GITLAB_ROOT_PASSWORD.

使用例： 

GITLAB_ROOT_PASSWORD="<strongpassword>" EXTERNAL_URL="http://gitlab.exmaple.com" apt install gitlab-ee

LDAPサインインの設定

LDAPセットアップのドキュメントを参照してください。

スマートカード認証

スマートカードのドキュメントを参照してください。

HTTPSの有効化

NGINXドキュメントを参照してください。

HTTP リクエストを次のようにリダイレクトします。HTTPS

NGINXドキュメントを参照してください。

デフォルトのポートとSSL証明書の場所を変更します。

NGINXドキュメントを参照してください。

パッケージ化されていないウェブサーバーを使用

既存のNGINX、Passenger、またはApache Webサーバーを使用する場合は、NGINXのドキュメントを参照してください。

パッケージ化されていないPostgreSQLデータベース管理サーバーの使用

外部のPostgreSQL DBMSに接続するには、doc/settings/database.mdを参照してください。

パッケージ化されていないRedisインスタンスの使用

Redis のドキュメントを参照してください。

GitLabランタイム環境へのENVバーの追加

doc/settings/environment-variables.mdを参照してください。

GitLab.yml の設定の変更

gitlab.yml ドキュメントをご覧ください。

SMTP経由でのアプリケーションメールの送信

SMTP設定ドキュメントを参照してください。

OmniAuth (Google、Twitter、GitHubログイン)

OmniAuth のドキュメントを参照してください。

プーマの設定の調整

Puma のドキュメントを参照してください。

ユニコーンの設定の調整

Unicornのドキュメントを参照してください。

NGINXのリッスンアドレスまたはアドレスの設定

NGINXドキュメントを参照してください。

カスタムのNGINX設定をGitLabサーバーブロックに挿入します。

NGINXドキュメントを参照してください。

NGINX設定へのカスタム設定の挿入

NGINXドキュメントを参照してください。

nginx_status を有効にします。

NGINXドキュメントを参照してください。

匿名化の設定

Pseudonymizer のドキュメントを参照してください。