カスタム環境変数を設定する

必要に応じて、Puma、Sidekiq、Rails、およびRakeで使用するカスタム環境変数を/etc/gitlab/gitlab.rb経由で設定できます。これは、インターネットにアクセスするためにプロキシを使用する必要がある場合や、外部でホストされているリポジトリをGitLabに直接クローンする必要がある場合に役立ちます。/etc/gitlab/gitlab.rbで、gitlab_rails['env']にハッシュ値を指定します。例:

gitlab_rails['env'] = {
    "http_proxy" => "http://<USERNAME>:<PASSWORD>@example.com:8080",
    "https_proxy" => "http://<USERNAME>:<PASSWORD>@example.com:8080"
#    "no_proxy" => ".yourdomain.com"  # Wildcard syntax if you need your internal domain to bypass proxy. Do not specify a port.
}

プロキシの背後にある場合に必要となる可能性のある、他のGitLabコンポーネントからの環境変数をオーバーライドすることもできます:

# Needed for proxying Git clones
gitaly['env'] = {
    "http_proxy" => "http://<USERNAME>:<PASSWORD>@example.com:8080",
    "https_proxy" => "http://<USERNAME>:<PASSWORD>@example.com:8080"
}

gitlab_workhorse['env'] = {
    "http_proxy" => "http://<USERNAME>:<PASSWORD>@example.com:8080",
    "https_proxy" => "http://<USERNAME>:<PASSWORD>@example.com:8080"
}

gitlab_pages['env'] = {
    "http_proxy" => "http://<USERNAME>:<PASSWORD>@example.com:8080",
    "https_proxy" => "http://<USERNAME>:<PASSWORD>@example.com:8080"
}

# If you use the docker registry
registry['env'] = {
    "http_proxy" => "http://<USERNAME>:<PASSWORD>@example.com:8080",
    "https_proxy" => "http://<USERNAME>:<PASSWORD>@example.com:8080"
}

プロキシURLにユーザー名とパスワードが含まれている場合、GitLabはHTTP Basic認証を使用しようとします。

プロキシ設定では、グロビングに.構文を使用します。

プロキシに独自のSSL証明書とSSLが有効になっていない限り、プロキシURL値は一般的にhttp://のみである必要があります。これは、https_proxy値の場合でも、通常はhttp://<USERNAME>:<PASSWORD>@example.com:8080として値を指定する必要があることを意味します。

変更の適用

環境変数に加えられた変更は、有効にするために再構成が必要です。

再構成を実行します:

sudo gitlab-ctl reconfigure

注目すべき環境変数

TMPDIR

Rubyおよびその他のコンポーネントは、一時ファイルを保存する場所を決定するためにTMPDIR環境変数を使用します。デフォルトでは、これは/tmpです。

次の場合には、カスタム一時ディレクトリを構成する必要があるかもしれません:

• お使いの/tmpが限られたスペースのtmpfsとしてマウントされている場合。
• 大きなファイル（LFSオブジェクトやCIアーティファクトなど）によって/tmpがいっぱいになる場合。
• Geoセカンダリサイトは、オブジェクトストレージのレプリケーション中に/tmp内で容量が不足します。

カスタム一時ディレクトリを構成するには:

1. ディレクトリを作成し、パーミッションを設定します:

   sudo mkdir -p /var/opt/gitlab/tmp
   sudo chown git:git /var/opt/gitlab/tmp
   sudo chmod 700 /var/opt/gitlab/tmp

2. RailsとWorkhorseの両方にTMPDIRを設定するために/etc/gitlab/gitlab.rbを編集します:

   gitlab_rails['env'] = { 'TMPDIR' => '/var/opt/gitlab/tmp' }
   gitlab_workhorse['env'] = { 'TMPDIR' => '/var/opt/gitlab/tmp' }

   両方の値は、同じディレクトリを指定している必要があります。オブジェクトストレージを有効にしてCI/CDアーティファクトをアップロードする際、WorkhorseはTMPDIRにメタデータファイルを生成し、そのパスをRailsに渡します。Railsは、ファイルが許可されたディレクトリ（自身のTMPDIRを含む）にあることを検証します。これらの値が異なる場合、アーティファクトのアップロードは400 Bad Requestで失敗します。

3. GitLabを再構成して再起動します:

   sudo gitlab-ctl reconfigure
   sudo gitlab-ctl restart

4. 設定を検証します:

   sudo gitlab-rails runner "puts ENV['TMPDIR']"

   出力には、構成されたパスが表示されるはずです。

トラブルシューティング

環境変数が設定されていません

同じ['env']に複数のエントリが存在しないことを確認してください。最後のエントリが前のエントリをオーバーライドします。この例では、NTP_HOSTは設定されません:

gitlab_rails['env'] = { 'NTP_HOST' => "<DOMAIN_OF_NTP_SERVICE>" }

gitlab_rails['env'] = {
    "http_proxy" => "http://<USERNAME>:<PASSWORD>@example.com:8080",
    "https_proxy" => "http://<USERNAME>:<PASSWORD>@example.com:8080"
}

TMPDIRの変更後、CI/CDアーティファクトのアップロードが400 Bad Requestで失敗する

もしカスタムTMPDIRを構成した後にCI/CDアーティファクトのアップロードがContent-Type: text/plainとともに400 Bad Requestを返す場合、最も可能性が高い原因は、RailsとWorkhorseのTMPDIRの値の不一致です。

これを解決するには、次の手順に従います:

1. /etc/gitlab/gitlab.rbで両方の値が一致していることを確認してください:

   gitlab_rails['env'] = { 'TMPDIR' => '/var/opt/gitlab/tmp' }
   gitlab_workhorse['env'] = { 'TMPDIR' => '/var/opt/gitlab/tmp' }

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

Workhorseログで失敗した相関IDをチェックすることで、不一致を確認できます。構成済みのTMPDIRとは異なるディレクトリを指すlocal_temp_pathを持つmetadata.gzエントリを探してください。

エラー: リポジトリのミラーリング時にConnection reset by peer

no_proxy値にURLのポート番号が含まれている場合、DNS解決が失敗する可能性があります。この問題を解決するには、no_proxy URLからポート番号を削除してください。