GitLab アプリケーションの設定 (Rails)
このセクションでは、GitLabアプリケーション(Rails)コンポーネントの設定方法について説明します。
-
必要に応じて、以下のコマンドを使用してNFSクライアント・ユーティリティ・パッケージをインストールします:
# Ubuntu/Debian apt-get install nfs-common # CentOS/Red Hat yum install nfs-utils nfs-utils-lib
-
必要なNFS exporterを
/etc/fstab
.NFSに/etc/fstab
指定します。 .NFS/etc/fstab
の正確な内容は/etc/fstab
、NFSサーバーの構成方法によって異なります。 例と各種オプションについては、NFSのドキュメントを参照してください。 -
共有ディレクトリを作成します。 これらは、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
- GitLabのダウンロードページのステップ1と2を使用して、Omnibus GitLabをダウンロード/インストールします。 ダウンロードページの他のステップは完了しないでください。
-
/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
-
注意: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サーバーの後に設定されたサーバー)には、追加の設定が必要です。
-
共有シークレットを設定します。これらの値は、プライマリ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'
-
touch /etc/gitlab/skip-auto-reconfigure
を実行して、アップグレード時にデータベース移行が実行されないようにします。プライマリの GitLab アプリケーションサーバーだけが移行を処理するようにします。 -
推奨ホスト鍵の構成 プライマリアプリケーションサーバ上の
/etc/ssh/
の内容(秘密鍵と公開鍵)を、すべてのセカンダリサーバ上の/etc/ssh
にコピーします。これにより、ロードバランサの背後にあるHigh Availabilityクラスタ内のサーバにアクセスする際に、中間者攻撃による誤った警告が発せられるのを防ぐことができます。 -
sudo gitlab-ctl reconfigure
を実行して設定をコンパイルします。
モニタリングの有効化
GitLab 12.0から導入されました。
モニタリングを有効にする場合は、すべてのGitLabサーバーで有効にする必要があります。
-
次のステップのために、ConsulサーバーノードのIPアドレスまたはDNSレコードである
CONSUL_SERVER_NODES
を収集しておいてください。Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z
-
/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']
-
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マルチノードアップグレードドキュメントを参照してください。
高可用性構成の詳細を読む