Linuxパッケージインストールにおける設定オプション

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

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

デフォルト設定の一覧については、パッケージのデフォルトを参照してください。

GitLabの外部URLを設定する

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

外部URLを変更するには:

1. オプション。外部URLを変更する前に、以前にカスタムホームページのURLまたはサインアウト後のパスを定義したかどうかを確認します。これらの設定はどちらも、新しい外部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を使用する場合は、SSLを設定する方法を参照してください。

3. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

4. オプション。GitLabをしばらく使用していた場合は、外部URLを変更した後、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は、たとえばhttps://example.com/gitlabのように、相対URLの下にインストールすることもできます。

URLを変更すると、すべてのリモートURLも変更されるため、GitLabインスタンスを指すローカルリポジトリで手動で編集する必要があります。

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

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

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

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

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

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

何か問題が発生した場合は、トラブルシューティングセクションを参照してください。

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

Linuxパッケージインストールは、/etc/gitlab/gitlab.rbファイルからすべての設定を読み込みます。このファイルには厳密なファイル権限があり、rootユーザーが所有しています。厳密な権限と所有権の理由は、/etc/gitlab/gitlab.rbがgitlab-ctl reconfigure中にrootユーザーによってRubyコードとして実行されているためです。これは、/etc/gitlab/gitlab.rbへの書き込みアクセス権を持つユーザーが、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データベースサーバー証明書は、/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を実行している場合は、Gitalyの設定に関するドキュメントを参照してください。

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

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

デフォルトでは、Linuxパッケージインストールは、Git GitLab 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
   mattermost['uid'] = 1239
   mattermost['gid'] = 1239
   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/識別子を必ず更新してください（ログなど）:

   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"
   
   # Mattermost
   mattermost['username'] = 'mattermost'
   mattermost['group'] = 'mattermost'
   mattermost['home'] = '/var/opt/gitlab/mattermost'

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_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およびコンテナレジストリに対して認証失敗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/）として使用することも、自分でホストすることもできる、オープンソースのエラーレポートおよびログ記録ツールです。

Sentryを構成するには、次の手順に従います:

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

2. 作成したプロジェクトのデータソース名（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環境を使用して、ラボ、開発、ステージング、本番環境など、デプロイされた複数のGitLab環境全体でエラーとイシューを追跡できます。

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

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

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

   stageタグにmainの値が追加されます。

5. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

CDN URLを設定する

gitlab_rails['cdn_host']を使用して、コンテンツ配信ネットワーク（CDN）またはアセットホストで静的アセットをサービスします。これにより、Railsアセットホストが構成されます。

CDN/アセットホストを設定するには、次の手順に従います:

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

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

2. GitLabを再設定します:

   sudo gitlab-ctl reconfigure

アセットホストとして機能するように共通サービスを構成するための追加ドキュメントは、このイシューで追跡されます。

コンテンツセキュリティポリシーを設定する

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

インラインJavaScriptを使用したCSPとnonce-sourceは、GitLab.comで利用できます。GitLabセルフマネージドでは、デフォルトで構成されていません。

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ホストヘッダー攻撃に対する多層防御のために推奨されます。

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

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を実行します。

関連トピック

• 代理の無効化
• LDAPサインインを設定
• スマートカード認証
• 次のようなもののためにNGINXを設定します:
  • HTTPSを設定
  • HTTPリクエストをHTTPSにリダイレクト
  • デフォルトのポートとSSL証明書の場所を変更
  • NGINX listen-addressまたはアドレスを設定
  • カスタムNGINX設定をGitLabサーバーブロックに挿入
  • カスタム設定をNGINX設定に挿入
  • nginx_statusを有効にする
• パッケージ化されていないWebサーバーを使用
• パッケージ化されていないPostgreSQLデータベース管理サーバーを使用
• パッケージ化されていないRedisインスタンスを使用
• GitLabランタイム環境にENV変数を追加
• gitlab.ymlとapplication.yml設定を変更
• SMTP経由でアプリケーションメールを送信
• OmniAuth（Google、Twitter、GitHubログイン）を設定
• Pumaの設定を調整

トラブルシューティング

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

相対URL設定（画像がない、応答しないコンポーネントなど）への移動後にGitLabアセットの表示が壊れていることに気付いた場合は、GitLabでFrontendラベルが付いたイシューを提起してください。

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

ユーザーのホームディレクトリを移動するときに、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を返す

既存のインストールでGitユーザーまたはグループの名前を変更した場合、これにより多くの副次効果が発生する可能性があります。

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

gitlab gitlab-ctl tail -f