バンドルされている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つのノードをアップグレード。

注:どの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

これを解決するには

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

アップデート/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のガイドに従って障害クラスターを復元してください。

クリエーションラインについて

私たちクリエーションラインは、日本で最も古く2017年にGitLabサービスの提供を開始し、2022年には「Asia-Pacific Partner of the Year」も獲得。GitLabのサブスクリプション販売やテクニカルサポートだけでなく、GitLab Enterpriseの導入支援やGitLabトレーニングなど多様なサービスを提供し、エンタープライズを中心に豊富な実績を誇ります。GitLabに関するお悩みがありましたら、ぜひお気軽にお問い合わせください。日本で唯一、3度にわたるMVPを獲得したGitLabエバンジェリストをはじめとしたエキスパートチームが、あなたの課題解決をご支援します。