• データベースへの書き込みを停止
• Consul ノードのアップグレード
• Gitalyノードのアップグレード (Praefect / Gitalyクラスタ)
• クラスターに含まれないGitalyノードのアップグレード
• PostgreSQLノードのアップグレード
• Patroniノードのアップグレード
• PgBouncerノードのアップグレード
• Redisノードのアップグレード
• Redis HA のアップグレード（Sentinel を使用）
• Railsノード（Puma / Sidekiq）のアップグレード
• Monitorノードのアップグレード

ダウンタイムを伴う複数ノードのアップグレード

複数ノードの GitLab デプロイをダウンタイムなしでアップグレードできますが、いくつかの制約があります。特に、一度に一つのマイナーリリースにしかアップグレードできません。例えば、14.6から14.7、そして14.8といった具合です。

一度に複数のマイナーリリースにアップグレードしたい場合（例えば、14.6から14.9へ）、GitLabインスタンスをオフラインにしなければなりません。このプロセスを開始する前に、あなたのアップグレードパスに関連するバージョン別のアップグレード手順を確認してください。

シングルノードインストールの場合、GitLabパッケージだけをアップグレードする必要があります。

複数ノードの GitLab インストールの複数のコンポーネントをアップグレードする手順は、ゼロダウンタイムのアップグレードと同じです。違いは、Rails（Puma/Sidekiq）を実行しているサーバーとイベントの順番に関するものです。

大まかな流れとしては

1. GitLabアプリケーションをシャットダウンします。
2. Consul サーバーをアップグレードします。
3. その他のバックエンドコンポーネントをアップグレードしてください：
   • Gitaly、Rails PostgreSQL、Redis、PgBouncer: これらはどの順番でもアップグレードできます。
   • クラウドプラットフォームの PostgreSQL や Redis を使っていてアップグレードが必要な場合は、Omnibus GitLab の説明をクラウドプロバイダの説明に置き換えてください。
4. GitLabアプリケーション（Sidekiq、Puma）をアップグレードし、アプリケーションを起動します。

データベースへの書き込みを停止

これらのプロセスを実行しているすべてのサーバーでPumaとSidekiqをシャットダウンします：

sudo gitlab-ctl stop sidekiq
sudo gitlab-ctl stop puma

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

Consulのドキュメントを参照してください。

まとめると

1. Consulノードがすべて健全であることを確認してください。
2. すべてのConsulサーバーでGitLabパッケージをアップグレードしてください。

3. すべてのGitLabサービスを1ノードずつ再起動します：

   sudo gitlab-ctl restart
   

もしConsulクラスタのプロセスが独自のサーバ上になく、Redis HAやPatroniのような他のサービスと共有されている場合、それらのサーバをアップグレードする際には以下の原則に従ってください：

• 一度に複数のサーバを再起動しないでください。
• サービスをアップグレードまたは再起動する前に、Consulクラスターが正常であることを確認してください。

Gitalyノードのアップグレード (Praefect / Gitalyクラスタ)

Gitalyクラスタを稼働させている場合は、Gitalyクラスタのゼロダウンタイムプロセスに従ってください。

AWSのAmazon Machine Images (AMI)を利用している場合、AMIプロセスを通してGitalyノードをアップグレードするか、パッケージ自体をアップグレードすることができます：

• Elastic network interfaces(ENI) を使用している場合、AMI プロセスを通じてアップグレードできます。ENIを使用すると、AMIインスタンスの変更を通じて非公開DNS名を維持することができます。
• ENIを使っていない場合、GitalyをGitLabパッケージを使ってアップグレードする必要があります。Gitaly ClusterはGitリポジトリのレプリカをサーバーのホスト名で追跡しており、AMIを使った再デプロイメントでは新しいホスト名のノードが発行されるからです。ストレージが同じでも、ホスト名が変わるとGitaly Clusterは動作しません。

しかし、Praefectノードは、AMI再デプロイメントプロセスを介してアップグレードすることができます：

1. AMI 再展開プロセスにはgitlab-ctl reconfigure を含める必要があります。AMI 再展開プロセスには、praefect['auto_migrate'] = false を含める必要があります。こ れに よ り 、reconfigure で自動的にデー タ ベース のマイ グ レーシ ョ ンが実行 さ れな く な り ます。
2. アップグレードされたイメージで最初に再デプロイされるノードは、デプロイノードでなければなりません。
3. デプロイ後、gitlab.rb でpraefect['auto_migrate'] = true を設定し、gitlab-ctl reconfigure で適用します。これでデータベースのマイグレーションが実行されます。
4. 他の Praefect ノードを再デプロイします。

クラスターに含まれないGitalyノードのアップグレード

Gitalyクラスターに参加していないGitalyサーバーは、GitLabパッケージをアップグレードしてください。

複数のGitalyシャードを持っていたり、NFSを使って複数のGitalyノードを負荷分散している場合、Gitalyサーバをアップグレードする順番は関係ありません。

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

クラスタ化されていないPostgreSQLサーバの場合：

1. GitLabパッケージをアップグレードしてください。

2. バイナリをアップグレードしてもPostgreSQLは再起動しません。新しいバージョンをロードするために再起動してください：

   sudo gitlab-ctl restart
   

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

PatroniはPostgreSQLで高可用性を実現するために使用されます。

PostgreSQLのメジャーバージョンアップが必要な場合は、メジャーバージョンアップの手順に従ってください。

他のすべてのバージョンのアップグレード処理は、まずすべてのレプリカに対して実行されます。これらのレプリカがアップグレードされた後、クラスターはリーダーからアップグレードされたレプリカの1つにフェイルオーバーされます。これにより、フェイルオーバーは1回で済み、完了すると新しいリーダーがアップグレードされます。

以下の手順に従ってください：

1. リーダノードとレプリカノードを特定し、クラスターが健全であることを確認します。データベース・ノードで実行します：

   sudo gitlab-ctl patroni members
   

2. レプリカノードの1つでGitLabパッケージをアップグレードします。

3. 新しいバージョンをロードするために再起動します：

   sudo gitlab-ctl restart
   

4. クラスターが正常であることを確認します。
5. アップグレード、再起動、ヘルスチェックの手順を繰り返します。
6. レプリカと同じパッケージのアップグレードに従って、リーダーノードをアップグレードします。

7. リーダーノードのすべてのサービスを再起動して新しいバージョンをロードし、クラスターのフェイルオーバーをトリガします：

   sudo gitlab-ctl restart
   

8. クラスターが正常であることを確認します。

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

Rails（アプリケーション）ノードでPgBouncerを実行する場合、PgBouncerはアプリケーションサーバのアップグレードの一部としてアップグレードされます。

PgBouncerノードでGitLabパッケージをアップグレードします。

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

GitLabパッケージをアップグレードすることで、スタンドアロンのRedisサーバーをアップグレードします。

Redis HA のアップグレード（Sentinel を使用）

Redis HAクラスターをアップグレードするためのゼロダウンタイムの手順に従ってください。

Railsノード（Puma / Sidekiq）のアップグレード

PumaとSidekiqのプロセスはすべてシャットダウンされています。各ノードで

1. /etc/gitlab/skip-auto-reconfigure が存在しないことを確認します。

2. PumaとSidekiqがシャットダウンされていることを確認してください：

   ps -ef | egrep 'puma: | puma | sidekiq '
   

Pumaを実行しているノードを1つ選択します。これはデプロイノードであり、すべてのデータベースマイグレーションを実行します。デプロイノードで

1. サーバーが通常のマイグレーションを許可するように設定されていることを確認します。/etc/gitlab/gitlab.rb にgitlab_rails['auto_migrate'] = false が含まれていないことを確認します。特にgitlab_rails['auto_migrate'] = true に設定するか、デフォルトの動作 (true) のために省略します。

2. PgBouncerを使っている場合：

   マイグレーションを実行する前に、PgBouncerをバイパスしてPostgreSQLに直接接続する必要があります。

   Railsはマイグレーションを実行しようとするときにアドバイザリロックを使用して、同じデータベース上でマイグレーションが同時に実行されるのを防ぎます。これらのロックはトランザクション間で共有されないため、トランザクションプーリングモードでPgBouncerを使用してデータベースマイグレーションを実行すると、ActiveRecord::ConcurrentMigrationError やその他のイシューが発生します。

   1. Patroniを実行している場合、リーダーノードを見つけます。データベースノードで実行します：

      sudo gitlab-ctl patroni members
      

   2. デプロイノードのgitlab.rb を更新します。gitlab_rails['db_host'] とgitlab_rails['db_port'] のどちらかを変更します：

      • データベース・サーバ（クラスタ化されていないPostgreSQL）のホストとポート。
      • Patroni を実行している場合はクラスタリーダのホストとポート。

   3. 変更を適用します：

      sudo gitlab-ctl reconfigure
      

3. GitLabパッケージをアップグレードしてください。

4. PgBouncerをバイパスするためにデプロイノードのgitlab.rb ：
   1. デプロイノードのgitlab.rb 。gitlab_rails['db_host'] とgitlab_rails['db_port'] をPgBouncerの設定に戻します。

   2. 変更を適用します：

      sudo gitlab-ctl reconfigure
      

5. すべてのサービスがアップグレードされたバージョンで実行され、（該当する場合）PgBouncerを使用してデータベースにアクセスしていることを確認するために、デプロイノードのすべてのサービスを再起動します：

   sudo gitlab-ctl restart
   

次に、他のすべてのPumaノードとSidekiqノードをアップグレードします。設定gitlab_rails['auto_migrate'] は、これらのノードのgitlab.rb で任意に設定できます。

これらのノードは並行してアップグレードできます：

1. GitLabパッケージをアップグレードしてください。

2. 全てのサービスが再起動されていることを確認します：

   sudo gitlab-ctl restart
   

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

GitLabパッケージをアップグレードしてください。