• 最初の GitLab アプリケーションサーバー
• GitLabアプリケーションサーバーの追加設定
• モニタリングの有効化
• トラブルシューティング
• GitLab HA のアップグレード

GitLab アプリケーションの設定 (Rails)

このセクションでは、GitLabアプリケーション（Rails）コンポーネントの設定方法について説明します。

1. 必要に応じて、以下のコマンドを使用してNFSクライアント・ユーティリティ・パッケージをインストールします：

   # Ubuntu/Debian
   apt-get install nfs-common
   
   # CentOS/Red Hat
   yum install nfs-utils nfs-utils-lib
   

2. 必要なNFS exporterを/etc/fstab.NFSに /etc/fstab指定します。 .NFS/etc/fstabの正確な内容は /etc/fstab、NFSサーバーの構成方法によって異なります。 例と各種オプションについては、NFSのドキュメントを参照してください。

3. 共有ディレクトリを作成します。 これらは、NFSマウントの場所によって異なる場合があります。

   mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data
   

4. GitLabのダウンロードページのステップ1と2を使用して、Omnibus GitLabをダウンロード/インストールします。 ダウンロードページの他のステップは完了しないでください。

5. /etc/gitlab/gitlab.rb を作成／編集し、以下の設定を使用してください。external_url は、最終的な GitLab フロントエンドの URL と一致するように変更してください。 NFS の設定によっては、GitLab のデータロケーションの一部を変更する必要があるかもしれません。様々なシナリオに対応する/etc/gitlab/gitlab.rbの設定値については、NFS のドキュメントを参照してください。以下の例では、デフォルトのデータロケーションに NFS マウントを追加していることを前提としています。さらに、指定されている UID と GID は単なる例であり、お好みの値で設定してください。

   external_url 'https://gitlab.example.com'
   
   # Prevent GitLab from starting if NFS data mounts are not available
   high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
   
   # Disable components that will not be on the GitLab application server
   roles ['application_role']
   nginx['enable'] = true
   
   # PostgreSQL connection details
   gitlab_rails['db_adapter'] = 'postgresql'
   gitlab_rails['db_encoding'] = 'unicode'
   gitlab_rails['db_host'] = '10.1.0.5' # IP/hostname of database server
   gitlab_rails['db_password'] = 'DB password'
   
   # Redis connection details
   gitlab_rails['redis_port'] = '6379'
   gitlab_rails['redis_host'] = '10.1.0.6' # IP/hostname of Redis server
   gitlab_rails['redis_password'] = 'Redis Password'
   
   # Ensure UIDs and GIDs match between servers for permissions via NFS
   user['uid'] = 9000
   user['gid'] = 9000
   web_server['uid'] = 9001
   web_server['gid'] = 9001
   registry['uid'] = 9002
   registry['gid'] = 9002
   

6. モニタリングの有効化

   注意：HAクラスター間でリンクの統一性を保つために、最初のアプリケーションサーバーと追加のアプリケーションサーバーのexternal_urlは、ユーザーがGitLabにアクセスするために使う外部URLを指すようにします。典型的なHAセットアップでは、これはHAクラスター内のすべてのGitLabアプリケーションサーバーにトラフィックをルーティングするロードバランサーのURLになります。
   注意: 上記の例のようにexternal_urlにhttps を指定した場合、GitLab は/etc/gitlab/ssl/に SSL 証明書があるものとみなします。 証明書がない場合、NGINX は起動に失敗します。 詳細はNGINX のドキュメントを参照してください。
   注意：GitLabを最初に再設定する前に、uid とgidを設定するのがベストです。最初の再設定後に設定した場合、Omnibusは再帰的にchown ディレクトリを設定しません。

最初の GitLab アプリケーションサーバー

最初のアプリケーション・サーバーで

sudo gitlab-ctl reconfigure

次のステップに進むまで、追加のアプリケーション・サーバでは実行しないでください。

GitLabアプリケーションサーバーの追加設定

追加のGitLabサーバー（最初のGitLabサーバーの後に設定されたサーバー）には、追加の設定が必要です。

1. 共有シークレットを設定します。これらの値は、プライマリGitLabサーバーから/etc/gitlab/gitlab-secrets.json。上記のステップで最初のreconfigure を実行する前に、このファイルをセカンダリサーバーにコピーします。

   gitlab_shell['secret_token'] = 'fbfb19c355066a9afb030992231c4a363357f77345edd0f2e772359e5be59b02538e1fa6cae8f93f7d23355341cea2b93600dab6d6c3edcdced558fc6d739860'
   gitlab_rails['otp_key_base'] = 'b719fe119132c7810908bba18315259ed12888d4f5ee5430c42a776d840a396799b0a5ef0a801348c8a357f07aa72bbd58e25a84b8f247a25c72f539c7a6c5fa'
   gitlab_rails['secret_key_base'] = '6e657410d57c71b4fc3ed0d694e7842b1895a8b401d812c17fe61caf95b48a6d703cb53c112bc01ebd197a85da81b18e29682040e99b4f26594772a4a2c98c6d'
   gitlab_rails['db_key_base'] = 'bf2e47b68d6cafaef1d767e628b619365becf27571e10f196f98dc85e7771042b9203199d39aff91fcb6837c8ed83f2a912b278da50999bb11a2fbc0fba52964'
   

2. touch /etc/gitlab/skip-auto-reconfigure を実行して、アップグレード時にデータベース移行が実行されないようにします。プライマリの GitLab アプリケーションサーバーだけが移行を処理するようにします。

3. 推奨ホスト鍵の構成 プライマリアプリケーションサーバ上の/etc/ssh/ の内容（秘密鍵と公開鍵）を、すべてのセカンダリサーバ上の/etc/ssh にコピーします。これにより、ロードバランサの背後にあるHigh Availabilityクラスタ内のサーバにアクセスする際に、中間者攻撃による誤った警告が発せられるのを防ぐことができます。

4. sudo gitlab-ctl reconfigure を実行して設定をコンパイルします。

モニタリングの有効化

GitLab 12.0から導入されました。

モニタリングを有効にする場合は、すべてのGitLabサーバーで有効にする必要があります。

1. 次のステップのために、ConsulサーバーノードのIPアドレスまたはDNSレコードであるCONSUL_SERVER_NODESを収集しておいてください。Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z

2. /etc/gitlab/gitlab.rb を作成/編集し、以下の設定を追加します：

   # Enable service discovery for Prometheus
   consul['enable'] = true
   consul['monitoring_service_discovery'] =  true
   
   # Replace placeholders
   # Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z
   # with the addresses of the Consul server nodes
   consul['configuration'] = {
      retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z),
   }
   
   # Set the network addresses that the exporters will listen on
   node_exporter['listen_address'] = '0.0.0.0:9100'
   gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
   sidekiq['listen_address'] = "0.0.0.0"
   puma['listen'] = '0.0.0.0'
   
   # Add the monitoring node's IP address to the monitoring whitelist and allow it to
   # scrape the NGINX metrics. Replace placeholder `monitoring.gitlab.example.com` with
   # the address and/or subnets gathered from the monitoring node(s).
   gitlab_rails['monitoring_whitelist'] = ['monitoring.gitlab.example.com', '127.0.0.0/8']
   nginx['status']['options']['allow'] = ['monitoring.gitlab.example.com', '127.0.0.0/8']
   

3. sudo gitlab-ctl reconfigure を実行して設定をコンパイルします。

   警告：ユニコーンを実行している場合、gitlab.rbでunicorn['listen'] を変更した後、sudo gitlab-ctl reconfigureを実行すると、HUPを受信した後、ユニコーンの再読み込みが完了するまでに長時間かかることがあります。詳細については、イシューを参照してください。

トラブルシューティング

• mount: wrong fs type, bad option, bad superblock on

必要なNFSクライアント・ユーティリティがインストールされていません。 上記のステップ1を参照してください。

• mount: mount point /var/opt/gitlab/... does not exist

この特定のディレクトリがNFSサーバー上に存在しません。 共有がエクスポートされ、NFSサーバー上に存在することを確認し、再マウントを試みてください。

GitLab HA のアップグレード

GitLab HAインストールはダウンタイムなしでアップグレードできますが、失敗を避けるためにアップグレードプロセスを注意深く調整する必要があります。 詳細はOmnibus GitLabマルチノードアップグレードドキュメントを参照してください。

高可用性構成の詳細を読む

1. データベースの設定
2. Redisの設定
3. NFSの設定
4. ロードバランサーの設定