バンドルされているConsulサービスとの連携

高可用性スタックの一部として、GitLab Premiumは/etc/gitlab/gitlab.rbConsulはサービスネットワーキングソリューションです。 GitLab Architectureに関しては、Consulの利用が設定にサポートされています:

  1. スケーラブルで可用性の高い環境でのモニタリング
  2. Omnibus による PostgreSQL 高可用性

Consulクラスターは、複数のサーバーエージェントと、Consulクラスターと通信する必要がある他のノード上で動作するクライアントエージェントで構成されます。

前提条件

まず、各ノードにOmnibus GitLabをダウンロード/インストールしてください。

インストール方法を選択し、手順を完了させてください:

  1. 必要な依存関係をインストールして設定します。
  2. GitLabパッケージリポジトリを追加し、パッケージをインストールします。

GitLabパッケージをインストールする際は、EXTERNAL_URL

Consulノードの設定

各Consulノードで以下を実行します:

  1. 次のステップを実行する前に、ConsulサーバーノードのIPアドレスまたはDNSレコードであるCONSUL_SERVER_NODESを収集していることを確認してください。

  2. # 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 で導入されました。

  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

すべてのノードがaliveStatus を持つのが理想的です。

クラスターの再起動

注意:このセクションはサーバエージェントにのみ適用されます。 クライアントエージェントは必要なときにいつでも再起動しても問題ありません。

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

安全のため、クラスターが無傷であることを確認するために、一度に1つのサーバエージェントのみを再起動することをお勧めします。

より大きなクラスターでは、一度に複数のエージェントを再起動することが可能です。 何回の故障に耐えられるかについては、Consulのコンセンサスドキュメントを参照してください。 これは、同時に再起動できる数です。

バンドルされているConsulのアップグレード

GitLabがバンドルされたConsulを実行しているノードである必要があります:

  • Omnibus GitLabパッケージをアップグレードする前の健全なクラスターのメンバー。
  • 一度に1つのノードをアップグレード。
注:どのConsulノードからでもcurl http://127.0.0.1:8500/v1/health/state/critical を実行すると、クラスターの内部健全性の問題が特定されます。クラスターが健全な場合、コマンドは空の配列を返します。

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

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

注:GitLabはConsulを簡単に再生成できる一時的なデータの保存にしか使っていません。 バンドルされたConsulがGitLab自身以外のプロセスで使われていないのであれば、クラスターをゼロから再構築しても問題ありません。

トラブルシューティング

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

これを解決するには

  1. 各ノードで、他のすべてのノードがこのノードに到達できるアドレスを選びます。
  2. アップデート/etc/gitlab/gitlab.rb

    consul['configuration'] = {
      ...
      bind_addr: 'IP ADDRESS'
    }
    
  3. 走る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.

これを解決するには

  1. 他のすべてのノードがこのノードに到達できるノードのアドレスを選びます。
  2. アップデート/etc/gitlab/gitlab.rb

    consul['configuration'] = {
      ...
      bind_addr: 'IP ADDRESS'
    }
    
  3. 走るgitlab-ctl reconfigure

障害復旧

クォーラムが壊れるほどクラスタ内のサーバエージェントが失われた場合、クラスターは失敗したとみなされ、手動で介入しない限り機能しなくなります。

ゼロから作り直し

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

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

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

故障したクラスターの復旧

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