Linuxパッケージインストールの設定オプション

GitLabを設定するには、/etc/gitlab/gitlab.rbファイルに関連オプションを設定します。

gitlab.rb.templateには、利用可能なオプションの完全なリストが含まれています。新規インストールでは、/etc/gitlab/gitlab.rbにリストされているテンプレートのすべてのオプションがデフォルトで設定されています。

デフォルト設定のリストについては、package defaultsを参照してください。

GitLabの外部URLを設定する

ユーザーに正しいリポジトリクローンリンクを表示するには、ユーザーがリポジトリにアクセスするために使用するURLをGitLabに提供する必要があります。サーバーのIPアドレスを使用することもできますが、FQDN（完全修飾ドメイン名）が推奨されます。GitLab Self-ManagedインスタンスでのDNSの使用に関する詳細は、DNS documentationを参照してください。

外部URLを変更するには:

1. オプション。外部URLを変更する前に、カスタムのホームページのURLまたはAfter sign-out pathを以前に定義したことがあるかを確認してください。これらの設定はどちらも、新しい外部URLを設定した後に意図しないリダイレクトを引き起こす可能性があります。URLを定義している場合は、完全に削除してください。

2. /etc/gitlab/gitlab.rbを編集し、external_urlをお好みのURLに変更します:

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

   または、サーバーのIPアドレスを使用することもできます:

   external_url "http://10.0.0.1"

   以前の例では、プレーンなHTTPを使用しています。HTTPSを使用したい場合は、configure SSLの方法を参照してください。

3. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

4. オプション。しばらくGitLabを使用していた場合、外部URLを変更した後、invalidate the Markdownキャッシュも行う必要があります。

インストール時に外部URLを指定する

Linuxパッケージを使用する場合、EXTERNAL_URL環境変数を使用することで、最小限のコマンドでGitLabインスタンスを設定できます。この変数が設定されている場合、自動的に検出され、その値はgitlab.rbファイルにexternal_urlとして書き込まれます。

EXTERNAL_URL環境変数は、パッケージのインストールとアップグレードのみに影響します。通常の再設定実行では、/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は手動で編集する必要があります。

これらの手順は、Linuxパッケージのインストールに関するものです。自己コンパイル（ソース）インストールについては、install GitLab under a relative URLを参照してください。

GitLabで相対URLを有効にするには:

1. /etc/gitlab/gitlab.rbでexternal_urlを設定します:

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

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

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

何かイシューがある場合は、troubleshooting sectionを参照してください。

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

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

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

1. /etc/gitlab/gitlab.rbを編集します:

   from_file "/home/admin/external_gitlab.rb"

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

from_fileを使用する場合:

• from_fileを使用して/etc/gitlab/gitlab.rbに含めるコードは、GitLabを再設定するときにroot権限で実行されます。
• from_fileが含まれた後に/etc/gitlab/gitlab.rbで設定された設定は、含まれているファイルからの設定よりも優先されます。

ファイルから証明書を読み込む

証明書は個別のファイルとして保存し、sudo gitlab-ctl reconfigureを実行するときにメモリに読み込むことができます。証明書を含むファイルはプレーンテキストである必要があります。

この例では、PostgreSQL server certificateは、/etc/gitlab/gitlab.rbに直接コピー＆ペーストするのではなく、ファイルから直接読み込まれます。

postgresql['internal_certificate'] = File.read('/path/to/server.crt')

git_data_dirsからの移行

18.0以降、git_data_dirsはGitalyのストレージ場所を設定するサポートされた手段ではなくなります。git_data_dirsを明示的に定義している場合、設定を移行する必要があります。

たとえば、Gitalyサービスの場合、/etc/gitlab/gitlab.rbの設定は次のとおりです:

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

代わりにgitaly['configuration']の下で設定を再定義する必要があります。/repositoriesサフィックスはパスに追加する必要があります。これは以前は内部で追加されていたためです。

gitaly['configuration'] = {
  storage: [
    {
      name: 'default',
      path: '/mnt/nas/git-data/repositories',
    },
  ],
}

pathの親ディレクトリもOmnibusによって管理される必要があることに注意してください。上記の例に従い、Omnibusは再設定時に/mnt/nas/git-dataの権限を変更し、ランタイム中にそのディレクトリにデータを保存する場合があります。この動作を可能にする適切なpathを選択する必要があります。

RailsおよびSidekiqクライアントの場合、/etc/gitlab/gitlab.rbの設定が次のとおりである場合:

git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://gitaly1.internal:8075"
   }
})

代わりにgitlab_rails['repositories_storages']の下で設定を再定義する必要があります:

gitlab_rails['repositories_storages'] = {
  "default" => {
    "gitaly_address" => "tcp://gitaly1.internal:8075"
  }
}

Gitデータを別のディレクトリに保存する

デフォルトでは、LinuxパッケージのインストールはGitリポジトリデータを/var/opt/gitlab/git-data/repositoriesの下に保存し、Gitalyサービスはunix:/var/opt/gitlab/gitaly/gitaly.socketでリッスンします。

ディレクトリの場所を変更するには、

1. /etc/gitlab/gitlab.rbを編集します:

   gitaly['configuration'] = {
     storage: [
       {
         name: 'default',
         path: '/mnt/nas/git-data/repositories',
       },
     ],
   }

   複数のGitデータディレクトリを追加することもできます:

   gitaly['configuration'] = {
     storage: [
       {
         name: 'default',
         path: '/var/opt/gitlab/git-data/repositories',
       },
       {
         name: 'alternative',
         path: '/mnt/nas/git-data/repositories',
       },
     ],
   }

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

3. オプション。/var/opt/gitlab/git-dataに既存のGitリポジトリがある場合は、新しい場所に移動できます:

   1. リポジトリを移動している間、ユーザーが書き込みできないようにします:

      sudo gitlab-ctl stop

   2. リポジトリを新しい場所に同期します。repositoriesの後ろにスラッシュは ありません が、git-dataの後ろにはスラッシュが あります :

      sudo rsync -av --delete /var/opt/gitlab/git-data/repositories /mnt/nas/git-data/

   3. 必要なプロセスを開始し、誤った権限を修正するために再設定します:

      sudo gitlab-ctl reconfigure

   4. /mnt/nas/git-data/のディレクトリレイアウトを再確認します。予期される出力はrepositoriesです:

      sudo ls /mnt/nas/git-data/

   5. GitLabを開始し、Webインターフェースでリポジトリを参照できることを確認します:

      sudo gitlab-ctl start

別のサーバーでGitalyを実行している場合は、the documentation on configuring Gitalyを参照してください。

すべてのリポジトリを移動するのではなく、既存のリポジトリストレージ間で特定のプロジェクトを移動したい場合は、Update Project APIエンドポイントを使用して、repository_storage属性を指定します。

Gitユーザーまたはグループの名前を変更する

デフォルトでは、Linuxパッケージのインストールは、Git Lab Shellログイン、Gitデータ自体の所有権、およびWebインターフェースでのSSH URL生成のためにユーザー名gitを使用します。同様に、gitグループはGitデータのグループ所有権に使用されます。

新しいLinuxパッケージのインストールでユーザーとグループを変更するには:

1. /etc/gitlab/gitlab.rbを編集します:

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

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

既存のインストールのユーザー名を変更する場合、再設定実行ではネストされたディレクトリの所有権は変更されないため、手動で行う必要があります。

少なくとも、リポジトリとアップロードディレクトリの所有権を変更する必要があります:

sudo chown -R gitlab:gitlab /var/opt/gitlab/git-data/repositories
sudo chown -R gitlab:gitlab /var/opt/gitlab/gitlab-rails/uploads

数値ユーザーおよびグループ識別子を指定する

Linuxパッケージのインストールは、GitLab、PostgreSQL、Redis、NGINXなどのユーザーを作成します。これらのユーザーの数値識別子を指定するには:

1. 後で必要になる可能性があるため、古いユーザーおよびグループ識別子を書き留めてください:

   sudo cat /etc/passwd

2. /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
   registry['uid'] = 1238
   registry['gid'] = 1238
   prometheus['uid'] = 1240
   prometheus['gid'] = 1240

3. GitLabを停止し、再設定してから起動します:

   sudo gitlab-ctl stop
   sudo gitlab-ctl reconfigure
   sudo gitlab-ctl start

4. オプション。user['uid']とuser['gid']を変更する場合、Linuxパッケージによって直接管理されていないファイル（例：ログ）のuid/guidを必ず更新してください:

   find /var/log/gitlab -uid <old_uid> | xargs -I:: chown git ::
   find /var/log/gitlab -gid <old_uid> | xargs -I:: chgrp git ::
   find /var/opt/gitlab -uid <old_uid> | xargs -I:: chown git ::
   find /var/opt/gitlab -gid <old_uid> | xargs -I:: chgrp git ::

ユーザーおよびグループアカウント管理を無効にする

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

デフォルトでは、Linuxパッケージのインストールは、以下のユーザーとグループが存在することを想定しています:

ユーザーおよびグループアカウント管理を無効にするには:

1. /etc/gitlab/gitlab.rbを編集します:

   manage_accounts['enable'] = false

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

   # GitLab
   user['username'] = "git"
   user['group'] = "git"
   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'
   
   # Prometheus
   prometheus['username'] = 'gitlab-prometheus'
   prometheus['group'] = 'gitlab-prometheus'
   prometheus['shell'] = '/bin/sh'
   prometheus['home'] = '/var/opt/gitlab/prometheus'
   
   # 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"
   
   # 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"
   
   # Consul
   consul['username'] = 'gitlab-consul'
   consul['group'] = 'gitlab-consul'
   consul['dir'] = "/var/opt/gitlab/registry"
   
   # Registry
   registry['username'] = "registry"
   registry['group'] = "registry"
   registry['dir'] = "/var/opt/gitlab/registry"
   registry['shell'] = "/usr/sbin/nologin"

3. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

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

GitLabユーザーの場合、パフォーマンス向上のため、ホームディレクトリはローカルディスクに設定し、NFSのような共有ストレージには設定しないことを推奨します。NFSに設定すると、GitリクエストがGit設定を読み込むために別のネットワークリクエストを行う必要があり、これによりGit操作のレイテンシーが増加します。

既存のホームディレクトリを移動するには、GitLabサービスを停止する必要があり、ある程度のダウンタイムが発生します:

1. GitLabを停止します:

   sudo gitlab-ctl stop

2. runitサーバーを停止します:

   sudo systemctl stop gitlab-runsvdir

3. ホームディレクトリを変更します:

   sudo usermod -d /path/to/home <username>

   既存のデータがある場合は、新しい場所に手動でコピー/rsyncする必要があります:

4. /etc/gitlab/gitlab.rbを編集します:

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

5. runitサーバーを起動します:

   sudo systemctl start gitlab-runsvdir

6. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

ストレージディレクトリ管理を無効にする

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

一部のディレクトリには大量のデータが保持されているため、特定のセットアップでは、これらのディレクトリはNFS（または他の）共有にマウントされている可能性が非常に高いです。

一部のマウントタイプでは、rootユーザー（初期設定のデフォルトユーザー）によるディレクトリの自動作成が許可されていません。たとえば、共有でroot_squashが有効になっているNFSなどです。これを回避するために、Linuxパッケージは、ディレクトリのオーナーユーザーを使用してそれらのディレクトリを作成しようとします。

/etc/gitlabディレクトリの管理を無効にする

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

1. /etc/gitlab/gitlab.rbを編集します:

   manage_storage_directories['manage_etc'] = false

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

/var/opt/gitlabディレクトリの管理を無効にする

すべてのGitLabストレージディレクトリをそれぞれ別々にマウントしている場合は、ストレージディレクトリの管理を完全に無効にする必要があります。

Linuxパッケージのインストールでは、これらのディレクトリがファイルシステム上に存在することを想定しています。この設定が有効になっている場合、正しい権限を作成および設定するのはユーザーの責任です。

この設定を有効にすると、以下のディレクトリの作成が防止されます:

ストレージディレクトリの管理を無効にするには:

1. /etc/gitlab/gitlab.rbを編集します:

   manage_storage_directories['enable'] = false

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

指定されたファイルシステムがマウントされた後にのみLinuxパッケージのインストールサービスを開始する

Linuxパッケージのインストールサービス（NGINX、Redis、Pumaなど）が指定されたファイルシステムがマウントされる前に起動するのを防ぎたい場合、high_availability['mountpoint']設定を設定できます:

1. /etc/gitlab/gitlab.rbを編集します:

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

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

   マウントポイントが存在しない場合、GitLabは再設定に失敗します。

ランタイムディレクトリを設定する

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

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

reconfigure中に、パッケージは/runがtmpfsマウントであるかどうかを確認します。そうでない場合、次の警告が表示され、Railsメトリクスは無効になります:

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

Railsメトリクスを再度有効にするには:

1. /etc/gitlab/gitlab.rbを編集してtmpfsマウントを作成します（設定には=がないことに注意してください）:

   runtime_dir '/path/to/tmpfs'

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

失敗した認証のBANを設定する

Gitとコンテナレジストリに対して、failed authentication banを設定できます。クライアントがBANされると、403エラーコードが返されます。

次の設定を設定できます:

Gitとコンテナレジストリの認証BANを設定するには:

1. /etc/gitlab/gitlab.rbを編集します:

   gitlab_rails['rack_attack_git_basic_auth'] = {
     'enabled' => true,
     'ip_whitelist' => ["127.0.0.1"],
     '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
   }

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

インストール中の自動キャッシュクリーニングを無効にする

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

インストール中の自動キャッシュクリーニングを無効にするには:

1. /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

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

Sentryによるエラー報告とログ記録

Sentryは、SaaS（https://sentry.io/welcome/）として、またはhost it yourselfとして使用できるオープンソースのエラー報告およびログ記録ツールです。

Sentryを設定するには:

1. Sentryでプロジェクトを作成します。

2. 作成したプロジェクトのData Source Name (DSN)を見つけます。

3. /etc/gitlab/gitlab.rbを編集します:

   gitlab_rails['sentry_enabled'] = true
   gitlab_rails['sentry_dsn'] = 'https://<public_key>@<host>/<project_id>'            # value used by the Rails SDK
   gitlab_rails['sentry_clientside_dsn'] = 'https://<public_key>@<host>/<project_id>' # value used by the Browser JavaScript SDK
   gitlab_rails['sentry_environment'] = 'production'

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

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

   たとえば、次のように設定すると:

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

   mainの値を持つstageタグが追加されます。

5. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

CDN URLを設定する

gitlab_rails['cdn_host']を使用して、CDN（Content Delivery Network）またはアセットホストで静的アセットをサービスします。これにより、Rails asset hostを設定します。

CDN/アセットホストを設定するには:

1. /etc/gitlab/gitlab.rbを編集します:

   gitlab_rails['cdn_host'] = 'https://mycdnsubdomain.fictional-cdn.com'

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

アセットホストとして機能する共通サービスを設定するための追加ドキュメントは、this issueで追跡されます。

Content-Security-Policyを設定する

コンテンツセキュリティポリシー（CSP）を設定することは、JavaScriptクロスサイトスクリプティング（XSS）攻撃を阻止するのに役立ちます。詳細については、the Mozilla documentation on CSPを参照してください。

CSP and nonce-source withインラインJavaScriptはGitLab.comで利用可能です。GitLab Self-Managedインスタンスでは、not configured by defaultです。

CSPを追加するには:

1. /etc/gitlab/gitlab.rbを編集します:

   gitlab_rails['content_security_policy'] = {
       enabled: true,
       report_only: false
   }

   CSPの安全なデフォルト値は、GitLabにより自動的に提供されます。ディレクティブの<default_value>値を明示的に設定することは、値を設定しないことと同等であり、デフォルト値を使用します。

   カスタムCSPを追加するには、次のようにします。

   gitlab_rails['content_security_policy'] = {
       enabled: true,
       report_only: false,
       directives: {
         default_src: "'none'",
         script_src: "https://example.com"
       }
   }

   明示的に設定されていないディレクティブには、セキュアなデフォルト値が使用されます。

   CSPディレクティブを解除するには、falseの値を設定します。

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

ホストヘッダー攻撃を防ぐために許可されたホストを設定する

GitLabが意図しないホストヘッダーを受け入れるのを防ぐには:

1. /etc/gitlab/gitlab.rbを編集します:

   gitlab_rails['allowed_hosts'] = ['gitlab.example.com']

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

allowed_hostsを設定しないことによって引き起こされるGitLabの既知のセキュリティイシューはありませんが、潜在的なHTTP Host header attacksに対する多層防御のために推奨されます。

Apacheのようなカスタム外部プロキシを使用する場合、localhostアドレスまたは名前（localhostまたは127.0.0.1）を追加する必要があるかもしれません。プロキシを介してworkhorseに渡される潜在的なHTTP Hostヘッダー攻撃を軽減するために、外部プロキシにフィルターを追加する必要があります。

gitlab_rails['allowed_hosts'] = ['gitlab.example.com', '127.0.0.1', 'localhost']

セッションクッキーの設定

生成されるWebセッションクッキー値のプレフィックスを変更するには:

1. /etc/gitlab/gitlab.rbを編集します:

   gitlab_rails['session_store_session_cookie_token_prefix'] = 'custom_prefix_'

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

デフォルト値は空の文字列""です。

プレーンテキストストレージなしでコンポーネントに機密設定を提供する

一部のコンポーネントは、gitlab.rbにextra_config_commandオプションを公開しています。これにより、外部スクリプトがプレーンテキストストレージから読み取るのではなく、シークレットを動的に提供できるようになります。

利用可能なオプションは次のとおりです:

これらのオプションのいずれかに割り当てられる値は、必要な形式で機密設定をSTDOUTに書き込む実行可能スクリプトへの絶対パスである必要があります。コンポーネント:

1. 提供されたスクリプトを実行します。
2. ユーザーおよびデフォルト設定ファイルによって設定された値を、スクリプトによって出力された値で置き換えます。

RedisサーバーおよびクライアントコンポーネントにRedisパスワードを提供する

例として、以下のスクリプトとgitlab.rbスニペットを使用して、RedisサーバーおよびRedisに接続する必要があるコンポーネントのパスワードを指定できます。

1. 以下のスクリプトを/opt/generate-redis-confとして保存します。

   #!/opt/gitlab/embedded/bin/ruby
   
   require 'json'
   require 'yaml'
   
   class RedisConfig
     REDIS_PASSWORD = `echo "toomanysecrets"`.strip # Change the command inside backticks to fetch Redis password
   
     class << self
       def server
         puts "requirepass '#{REDIS_PASSWORD}'"
         puts "masterauth '#{REDIS_PASSWORD}'"
       end
   
       def rails
         puts YAML.dump({
           'password' => REDIS_PASSWORD
         })
       end
   
       def kas
         puts YAML.dump({
           'redis' => {
             'password' => REDIS_PASSWORD
           }
         })
       end
   
       def workhorse
         puts JSON.dump({
           redis: {
             password: REDIS_PASSWORD
           }
         })
       end
   
       def gitlab_exporter
         puts YAML.dump({
           'probes' => {
             'sidekiq' => {
               'opts' => {
                 'redis_password' => REDIS_PASSWORD
               }
             }
           }
         })
       end
     end
   end
   
   def print_error_and_exit
     $stdout.puts "Usage: generate-redis-conf <COMPONENT>"
     $stderr.puts "Supported components are: server, rails, kas, workhorse, gitlab_exporter"
   
     exit 1
   end
   
   print_error_and_exit if ARGV.length != 1
   
   component = ARGV.shift
   begin
     RedisConfig.send(component.to_sym)
   rescue NoMethodError
     print_error_and_exit
   end

2. 上記で作成したスクリプトが実行可能であることを確認してください:

   chmod +x /opt/generate-redis-conf

3. 以下のスニペットを/etc/gitlab/gitlab.rbに追加します:

   redis['extra_config_command'] = '/opt/generate-redis-conf server'
   
   gitlab_rails['redis_extra_config_command'] = '/opt/generate-redis-conf rails'
   gitlab_workhorse['extra_config_command'] = '/opt/generate-redis-conf workhorse'
   gitlab_kas['extra_config_command'] = '/opt/generate-redis-conf kas'
   gitlab_exporter['extra_config_command'] = '/opt/generate-redis-conf gitlab_exporter'

4. sudo gitlab-ctl reconfigureを実行します。

PostgreSQLユーザーパスワードをGitLab Railsに提供する

例として、以下のスクリプトと設定を使用して、GitLab RailsがPostgreSQLサーバーへの接続に使用すべきパスワードを提供できます。

1. 以下のスクリプトを/opt/generate-db-configとして保存します:

   #!/opt/gitlab/embedded/bin/ruby
   
   require 'yaml'
   
   db_password = `echo "toomanysecrets"`.strip # Change the command inside backticks to fetch DB password
   
   puts YAML.dump({
    'main' => {
      'password' => db_password
    },
    'ci' => {
      'password' => db_password
    }
   })

2. 上記で作成したスクリプトが実行可能であることを確認してください:

   chmod +x /opt/generate-db-config

3. 以下のスニペットを/etc/gitlab/gitlab.rbに追加します:

   gitlab_rails['db_extra_config_command'] = '/opt/generate-db-config'

4. sudo gitlab-ctl reconfigureを実行します。

関連トピック

• 代理の無効化
• Set up LDAP sign-in
• スマートカードauthentication
• 次のようなことのためにSet up NGINX:
  • HTTPSを設定します
  • HTTPリクエストをHTTPSにリダイレクトします。
  • デフォルトポートとSSL証明書の場所を変更します。
  • NGINXのlisten-addressまたはアドレスを設定します。
  • GitLabサーバーブロックにカスタムNGINX設定を挿入します。
  • NGINX設定にカスタム設定を挿入します。
  • nginx_statusを有効にします。
• Use a non-packaged web-server
• Use a non-packaged PostgreSQLデータベースmanagement server
• Use a non-packaged Redisインスタンス
• ENV変数をGitLabランタイム環境に追加する
• gitlab.ymlおよびapplication.yml設定を変更する
• Send application email via SMTP
• Set up OmniAuth (Google, Twitter, GitHub login)
• Adjust Puma settings

トラブルシューティング

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

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

エラー: Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab user and group]

moving the home directory for a userの際、runitサービスが停止しておらず、ユーザーのホームディレクトリが手動で移動されていない場合、GitLabは再設定中にエラーに遭遇します:

account[GitLab user and group] (package::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

ホームディレクトリを移動する前に、必ずrunitを停止してください。

Gitユーザーまたはグループの名前を変更した後、GitLabが502で応答する

既存のインストールでname of the Git user or groupを変更した場合、多くの副次効果を引き起こす可能性があります。

アクセスできないファイルに関連するエラーを確認し、その権限を修正してみてください:

gitlab gitlab-ctl tail -f