バンドルされているConsulサービスとの連携
高可用性スタックの一部として、GitLab Premiumは/etc/gitlab/gitlab.rb
。Consulはサービスネットワーキングソリューションです。 GitLab Architectureに関しては、Consulの利用が設定にサポートされています:
Consulクラスターは、複数のサーバーエージェントと、Consulクラスターと通信する必要がある他のノード上で動作するクライアントエージェントで構成されます。
前提条件
まず、各ノードにOmnibus GitLabをダウンロード/インストールしてください。
インストール方法を選択し、手順を完了させてください:
- 必要な依存関係をインストールして設定します。
- GitLabパッケージリポジトリを追加し、パッケージをインストールします。
GitLabパッケージをインストールする際は、EXTERNAL_URL
。
Consulノードの設定
各Consulノードで以下を実行します:
-
次のステップを実行する前に、ConsulサーバーノードのIPアドレスまたはDNSレコードである
CONSUL_SERVER_NODES
を収集していることを確認してください。 -
# START user configuration
セクションに記載されている値を置き換えて/etc/gitlab/gitlab.rb
を編集します:# Disable all components except Consul roles ['consul_role'] # START user configuration # Replace placeholders: # # Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z # with the addresses gathered for CONSUL_SERVER_NODES consul['configuration'] = { server: true, retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z) } # Disable auto migrations gitlab_rails['auto_migrate'] = false # # END user configuration
consul_role
は GitLab 10.3 で導入されました。 -
変更を有効にするために GitLab を再設定します。
領事のチェックポイント
次に進む前に、Consulが正しく設定されていることを確認してください。 以下のコマンドを実行して、すべてのサーバーノードが通信していることを確認してください:
/opt/gitlab/embedded/bin/consul members
出力は以下のようになるはずです:
Node Address Status Type Build Protocol DC
CONSUL_NODE_ONE XXX.XXX.XXX.YYY:8301 alive server 0.9.2 2 gitlab_consul
CONSUL_NODE_TWO XXX.XXX.XXX.YYY:8301 alive server 0.9.2 2 gitlab_consul
CONSUL_NODE_THREE XXX.XXX.XXX.YYY:8301 alive server 0.9.2 2 gitlab_consul
いずれかのノードがalive
、または3つのノードのいずれかが欠けている場合は、先に進む前に「トラブルシューティング」のセクションを確認してください。
オペレーション
クラスタメンバーシップの確認
どのノードがクラスターの一部であるかを確認するには、クラスター内の任意のメンバーで以下を実行します。
$ /opt/gitlab/embedded/bin/consul members
Node Address Status Type Build Protocol DC
consul-b XX.XX.X.Y:8301 alive server 0.9.0 2 gitlab_consul
consul-c XX.XX.X.Y:8301 alive server 0.9.0 2 gitlab_consul
consul-c XX.XX.X.Y:8301 alive server 0.9.0 2 gitlab_consul
db-a XX.XX.X.Y:8301 alive client 0.9.0 2 gitlab_consul
db-b XX.XX.X.Y:8301 alive client 0.9.0 2 gitlab_consul
すべてのノードがalive
のStatus
を持つのが理想的です。
クラスターの再起動
サーバクラスタを再起動する必要がある場合は、クォーラムを維持するために、制御された方法で行うことが重要です。 クォーラムが失われた場合は、Consulの障害復旧プロセスに従ってクラスタを復旧する必要があります。
安全のため、クラスターが無傷であることを確認するために、一度に1つのサーバエージェントのみを再起動することをお勧めします。
より大きなクラスターでは、一度に複数のエージェントを再起動することが可能です。 何回の故障に耐えられるかについては、Consulのコンセンサスドキュメントを参照してください。 これは、同時に再起動できる数です。
バンドルされているConsulのアップグレード
GitLabがバンドルされたConsulを実行しているノードである必要があります:
- Omnibus GitLabパッケージをアップグレードする前の健全なクラスターのメンバー。
- 一度に1つのノードをアップグレード。
curl http://127.0.0.1:8500/v1/health/state/critical
を実行すると、クラスターの内部健全性の問題が特定されます。クラスターが健全な場合、コマンドは空の配列を返します。Consulクラスタはraftプロトコルを使って通信します。 現在のリーダーがオフラインになった場合、リーダー選挙が必要です。 クラスタ全体の同期を促進するためにリーダーノードが存在する必要があります。 同時に多くのノードがオフラインになると、クラスタはクォーラムを失い、コンセンサスが壊れてリーダーを選出できなくなります。
アップグレード後にクラスターが回復しない場合は、トラブルシューティングのセクションを参照してください。 特に、障害回復に関心があるかもしれません。
トラブルシューティング
Consulサーバーエージェントが通信不能
デフォルトでは、サーバエージェントは’0.0.0.0’にバインドしようとしますが、他のエージェントが通信できるようにノードの最初の非公開IPアドレスをアドバタイズします。 他のノードがこのアドレスのノードと通信できない場合、クラスターのステータスは失敗となります。
このイシューが発生した場合、gitlab-ctl tail consul
の出力に以下のようなメッセージが表示されます:
2017-09-25_19:53:39.90821 2017/09/25 19:53:39 [WARN] raft: no known peers, aborting election
2017-09-25_19:53:41.74356 2017/09/25 19:53:41 [ERR] agent: failed to sync remote state: No cluster leader
これを解決するには
- 各ノードで、他のすべてのノードがこのノードに到達できるアドレスを選びます。
-
アップデート
/etc/gitlab/gitlab.rb
consul['configuration'] = { ... bind_addr: 'IP ADDRESS' }
- 走る
gitlab-ctl reconfigure
それでもエラーが表示される場合は、Consulデータベースを消去し、影響を受けるノードで再初期化する必要があるかもしれません。
Consulエージェントが起動しない - 複数の非公開IP
ノードが複数の非公開IPを持っている場合、エージェントはどの非公開アドレスをアドバタイズすべきか混乱し、起動時に即座に終了します。
このイシューが発生した場合、gitlab-ctl tail consul
の出力に以下のようなメッセージが表示されます:
2017-11-09_17:41:45.52876 ==> Starting Consul agent...
2017-11-09_17:41:45.53057 ==> Error creating agent: Failed to get advertise address: Multiple private IPs found. Please configure one.
これを解決するには
- 他のすべてのノードがこのノードに到達できるノードのアドレスを選びます。
-
アップデート
/etc/gitlab/gitlab.rb
consul['configuration'] = { ... bind_addr: 'IP ADDRESS' }
- 走る
gitlab-ctl reconfigure
障害復旧
クォーラムが壊れるほどクラスタ内のサーバエージェントが失われた場合、クラスターは失敗したとみなされ、手動で介入しない限り機能しなくなります。
ゼロから作り直し
デフォルトでは、GitLabは再作成できないものをConsulクラスターに保存しません。 Consulデータベースを消去して再初期化するには、以下の手順に従います。
gitlab-ctl stop consul
rm -rf /var/opt/gitlab/consul/data
gitlab-ctl start consul
この後、クラスターが起動し、サーバエージェントが再参加します。 その後すぐに、クライアントエージェントも再参加します。
故障したクラスターの復旧
他のデータを保存するためにConsulを利用し、障害が発生したクラスターを復元したい場合は、Consulのガイドに従って障害クラスターを復元してください。