- GitLabの外部URLの設定
- GitLab の相対 URL の設定
- 非 root ユーザーからの外部設定ファイルの読み込み
- 代替ディレクトリへの git データの保存
- Gitユーザー/グループ名の変更
- ユーザーとグループの識別子を数値で指定します。
- ユーザーとグループのアカウント管理の無効化
- ストレージ・ディレクトリ管理の無効化
- 指定したファイルシステムがマウントされた後、Omnibus GitLab サービスのみを開始します。
- ランタイムディレクトリの設定
- ラックアタックの設定
- インストール時の自動キャッシュクリーニングの無効化
- なりすましの無効化
- Sentryによるエラーレポートとロギング
- コンテンツセキュリティポリシー
- インストール時の root 初期パスワードの設定
- LDAPサインインの設定
- スマートカード認証
- HTTPSの有効化
- パッケージ化されていないウェブサーバーを使用
- パッケージ化されていないPostgreSQLデータベース管理サーバーの使用
- パッケージ化されていないRedisインスタンスの使用
- GitLabランタイム環境へのENVバーの追加
- GitLab.yml の設定の変更
- SMTP経由でのアプリケーションメールの送信
- OmniAuth (Google、Twitter、GitHubログイン)
- プーマの設定の調整
- ユニコーンの設定の調整
- NGINXのリッスンアドレスまたはアドレスの設定
- カスタムのNGINX設定をGitLabサーバーブロックに挿入します。
- NGINX設定へのカスタム設定の挿入
- nginx_status を有効にします。
- 匿名化の設定
設定オプション
GitLabの設定は、/etc/gitlab/gitlab.rb
で関連するオプションを設定することで行います。デフォルト設定のリストについてはパッケージのデフォルトを参照し、利用可能なオプションの完全なリストについてはgitlab.rb.template
をご覧ください。GitLab 7.6から始まる新規インストールでは、デフォルトでインストール時のテンプレートのオプションがすべて/etc/gitlab/gitlab.rb
にリストされています。
GitLabの外部URLの設定
GitLab がユーザーに正しいリポジトリクローンリンクを表示するためには、ユーザーが到達する URL を知る必要があります。例えば、http://gitlab.example.com
。/etc/gitlab/gitlab.rb
に以下の行を追加または編集します:
external_url "http://gitlab.example.com"
を実行してください:
sudo gitlab-ctl reconfigure
自己管理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 の設定
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を有効にするには、以下の手順に従ってください:
-
(オプション)リソースが不足した場合は、次のコマンドでPuma(またはUnicorn)とSidekiqをシャットダウンすることで、一時的にメモリを解放することができます:
sudo gitlab-ctl stop puma sudo gitlab-ctl stop sidekiq
-
/etc/gitlab/gitlab.rb
でexternal_url
を設定:external_url "https://example.com/gitlab"
この例では、GitLabが提供される相対URLは
/gitlab
。お好みで変更してください。 -
変更を有効にするために GitLab を再設定します:
sudo gitlab-ctl reconfigure
-
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インターフェイスでの git
SSgit
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サービスを停止する必要があり、多少のダウンタイムが必要です。
-
GitLabの停止
gitlab-ctl stop
-
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
-
ホームディレクトリを変更します。 既存のデータがある場合は、手動で新しい場所にコピー/同期する必要があります。
usermod -d /path/to/home USER
-
のコンフィギュレーション設定を変更します。
gitlab.rb
user['home'] = "/var/opt/custom-gitlab"
-
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
-
再設定の実行
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 のドキュメントを参照してください。