• 前提条件
• Consulノードの設定
• Consul ノードのアップグレード
• Consulのトラブルシューティング
  • クラスタ・メンバーシップの確認
  • Consulの再起動
  • Consul ノードが通信できません
  • Consulが起動しない - 複数の非公開IP
  • 障害復旧
    • ゼロから再作成
    • 障害ノードの復旧

領事の設定方法

Consulクラスターは、サーバーエージェントとクライアントエージェントの両方で構成されます。サーバはそれぞれのノードで動作し、クライアントは他のノードで動作し、サーバと通信します。

GitLabプレミアムには、/etc/gitlab/gitlab.rb を使って管理できるサービスネットワーキングソリューションであるConsulがバンドルされています。

前提条件

Consulを設定する前に：

1. リファレンスアーキテクチャのドキュメントをレビューして、Consulサーバーノードの数を決定してください。
2. 必要に応じて、ファイアウォールで適切なポートが開いていることを確認してください。

Consulノードの設定

_各Consul_サーバーノードで

1. GitLabをインストールする手順に従って、お好みのプラットフォームを選択してください。ただし、EXTERNAL_URL の値は入力しないでください。

2. /etc/gitlab/gitlab.rb を編集し、retry_join セクションにある値を置き換えて以下を追加します。以下の例では、3つのノードがあり、2つはIP、1つはFQDNで示されています：

   # Disable all components except Consul
   roles ['consul_role']
      
   # Consul nodes: can be FQDN or IP, separated by a whitespace
   consul['configuration'] = {
     server: true,
     retry_join: %w(10.10.10.1 consul1.gitlab.example.com 10.10.10.2)
   }
      
   # Disable auto migrations
   gitlab_rails['auto_migrate'] = false
   

3. GitLabを再設定して変更を反映させます。

4. 以下のコマンドを実行して、Consulが正しく設定されていることと、すべてのサーバーノードが通信していることを確認します：

   sudo /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つのノードのいずれかが欠けている場合は、トラブルシューティングのセクションを参照してください。

Consul ノードのアップグレード

Consulノードをアップグレードするには、GitLabパッケージをアップグレードします。

ノードは

• Linux パッケージをアップグレードする前の健全なクラスターのメンバーであること。
• 1ノードずつアップグレード。

各ノードで次のコマンドを実行して、クラスターの既存の健全性の問題を特定します。クラスターが正常な場合、コマンドは空の配列を返します：

curl "http://127.0.0.1:8500/v1/health/state/critical"

Consulのバージョンが変更された場合、gitlab-ctl reconfigure の最後に、新しいバージョンを使用するにはConsulを再起動する必要があることを通知するメッセージが表示されます。

Consulを1ノードずつ再起動してください：

sudo gitlab-ctl restart consul

Consulのノードは筏プロトコルで通信します。現在のリーダーがオフラインになった場合、リーダー選挙が必要です。リーダーノードはクラスター全体の同期を促進するために存在する必要があります。多くのノードが同時にオフラインになると、クラスターはクォーラムを失い、コンセンサスが壊れてリーダーが選出されません。

アップグレード後にクラスターが回復しない場合は、トラブルシューティングのセクションを参照してください。特に停電の回復に関心があるかもしれません。

GitLabはConsulを使用して、簡単に再生成できる一時的なデータのみを保存します。バンドルされたConsulがGitLab自身以外のプロセスで使用されていなかった場合、クラスターをゼロから再構築することができます。

Consulのトラブルシューティング

以下はイシューをデバッグするためのオペレーションです。を実行することでエラーログを見ることができます：

sudo gitlab-ctl tail consul

クラスタ・メンバーシップの確認

どのノードがクラスターの一部であるかを確認するには、クラスター内の任意のメンバーで以下を実行します：

sudo /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の再起動

Consulを再起動する必要がある場合は、クォーラムを維持するために制御された方法で行うことが重要です。クォーラムが失われた場合、クラスターを回復するには、Consulの障害回復プロセスに従います。

安全のため、クラスターが無傷であることを確認するために、一度に1つのノードでのみConsulを再起動することをお勧めします。大規模なクラスターの場合は、一度に複数のノードを再起動することが可能です。Consulが許容できる障害数については、Consulのコンセンサスドキュメントを参照してください。これはConsulが耐えられる同時再起動の数です。

Consulを再起動するには

sudo gitlab-ctl restart consul

Consul ノードが通信できません

デフォルトでは、Consulは0.0.0.0 にバインドしようとしますが、他のConsulノードが通信できるように、ノードの最初の非公開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

この問題を解決するには

1. 各ノードで、他のすべてのノードがこのノードに到達できるアドレスを選びます。

2. 各ノードの/etc/gitlab/gitlab.rb

   consul['configuration'] = {
     ...
     bind_addr: 'IP ADDRESS'
   }
   

3. GitLab を再設定します；

   gitlab-ctl reconfigure
   

それでもエラーが表示される場合は、Consulデータベースを消去し、影響を受けるノードで再初期化する必要があるかもしれません。

Consulが起動しない - 複数の非公開IP

ノードが複数の非公開IPを持っている場合、Consulはどの非公開アドレスをアドバタイズすべきかわからず、起動時にすぐに終了してしまいます。

次のようなメッセージが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.

この問題を解決するには

1. 他のすべてのノードがこのノードに到達できるアドレスを選びます。

2. 各ノードの/etc/gitlab/gitlab.rb

   consul['configuration'] = {
     ...
     bind_addr: 'IP ADDRESS'
   }
   

3. GitLab を再設定します；

   gitlab-ctl reconfigure
   

障害復旧

クォーラムが壊れるほどクラスタ内のConsulノードが失われた場合、クラスターは故障したとみなされ、手動介入なしでは機能しなくなります。この場合、ノードをゼロから再作成するか、リカバリを試みます。

ゼロから再作成

デフォルトでは、GitLabは再作成できないものをConsulノードに保存しません。Consulデータベースを消去して再初期化するには、以下の手順を実行します：

sudo gitlab-ctl stop consul
sudo rm -rf /var/opt/gitlab/consul/data
sudo gitlab-ctl start consul

この後、ノードが起動し、残りのサーバーエージェントが再参加します。その後すぐに、クライアントエージェントも再参加します。

もし再参加しない場合は、クライアントのConsulデータを消去する必要があるかもしれません：

sudo rm -rf /var/opt/gitlab/consul/data

障害ノードの復旧

他のデータを保存するためにConsulを利用していて、障害が発生したノードを復旧したい場合は、Consulのガイドに従って障害が発生したクラスターを復旧してください。