ダウンタイムなしでマルチノードインスタンスをアップグレードする

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

ゼロダウンタイムでGitLab環境のマルチノードをアップグレードするプロセスには、アップグレード順序に従って各ノードを順番に処理することが含まれます。ロードバランサーとHAメカニズムは、各ノードのダウンに適切に対応します。

ゼロダウンタイムでのアップグレードを開始する前に、ダウンタイムのオプションを検討してください。

はじめに

アップグレードの一環としてゼロダウンタイムを実現することは、分散アプリケーションにとって非常に困難です。ドキュメントは、HAリファレンスアーキテクチャに対してテストされており、実質的に観測可能なダウンタイムは発生しませんでした。ただし、システムの構成によっては結果が異なる場合があることに注意してください。

さらなる確実性のため、一部の顧客は、特定のロードバランサーやインフラストラクチャの機能を使用してノードを手動でドレインするなどの追加の技術で成功を収めています。これらの技術は、基盤となるインフラストラクチャの機能に大きく依存します。

追加情報については、GitLab担当者またはサポートチームにお問い合わせください。

要件

ゼロダウンタイムアップグレードのプロセスには、ロードバランシングと、次のHAメカニズムが構成されたLinuxパッケージで構築されたマルチノードのGitLab環境が必要です:

GitLabアプリケーションノード用に構成された外部ロードバランサーと、readiness (/-/readiness) エンドポイントに対して有効化されたヘルスチェック。
PgBouncerおよびPraefectコンポーネント用に構成された内部ロードバランサーと、有効化されたTCPヘルスチェック。
存在する場合は、Consul、Postgres、およびRedisコンポーネント用に構成されたHAメカニズム。
- HA形式でデプロイされていないこれらのコンポーネントは、ダウンタイムを伴って個別にアップグレードする必要があります。
- データベースの場合、LinuxパッケージはメインのGitLabデータベースでのみHAをサポートしています。Praefectデータベースなどの他のデータベースの場合、HAを実現し、その結果ダウンタイムを回避するには、サードパーティのデータベースソリューションが必要です。

ゼロダウンタイムアップグレードの場合、次のことを行う必要があります:

one minor release at a timeをアップグレードします。したがって、16.1から16.2へであり、16.3へではありません。リリースをスキップすると、データベースの変更が誤った順序で実行され、データベースのスキーマが破損した状態になる可能性があります。
デプロイ後移行を使用します。

考慮事項

ダウンタイムなしのアップグレードを検討する場合は、以下に注意してください:

多くの場合、パッチリリースが最新でなくても、そのバージョンから次のマイナーリリースへは安全にアップグレードできます。たとえば、16.3.3がリリースされた場合でも、16.3.2から16.4.1へのアップグレードは安全です。関連するバージョン固有のアップグレードノートとアップグレードパスを確認し、必要なアップグレード停止に注意してください:
一部のリリースにはバックグラウンド移行が含まれる場合があります。これらの移行はSidekiqによってバックグラウンドで実行され、多くの場合データの移行に使用されます。バックグラウンド移行は月次リリースでのみ追加されます。
- 特定のメジャーリリースまたはマイナーリリースでは、一連のバックグラウンド移行を完了する必要がある場合があります。これにはダウンタイムは必要ありませんが（以前の条件が満たされている場合）、メジャーリリースまたはマイナーリリースのアップグレードごとに、バックグラウンド移行が完了するのを待つ必要があります。
- これらの移行を完了するために必要な時間は、background_migrationキューでジョブを処理できるSidekiqワーカーの数を増やすことで短縮できます。このキューのサイズを確認するには、アップグレードする前にバックグラウンド移行を確認してください。
ゼロダウンタイムアップグレードは、正常なリロードメカニズムによりGitalyに対して実行できます。Gitalyクラスター (Praefect)コンポーネントも、ダウンタイムなしで直接アップグレードできます。ただし、LinuxパッケージはPraefectデータベースに対するHAまたはゼロダウンタイムサポートを提供していません。ダウンタイムを回避するには、サードパーティのデータベースソリューションが必要です。
PostgreSQLメジャーバージョンアップグレードは別のプロセスであり、ゼロダウンタイムアップグレードではカバーされません。小規模なアップグレードはカバーされます。
ゼロダウンタイムアップグレードは、Linuxパッケージでデプロイした指定のGitLabコンポーネントでサポートされています。AWS RDSのPostgreSQLやGCP MemorystoreのRedisなど、サポートされているサードパーティサービスを通じて選択したコンポーネントをデプロイしている場合、それらのサービスのアップグレードは、標準プロセスに従って個別に実行する必要があります。
一般的なガイドラインとして、データ量が多ければ多いほど、アップグレードの完了にはより多くの時間が必要です。テストでは、10 GB未満のデータベースは通常1時間以上かかることはありませんが、環境によっては異なる場合があります。

アップグレード順序

ゼロダウンタイムでアップグレードするコンポーネントの順序については、バックトゥフロントのアプローチを取る必要があります:

ステートフルバックエンド
バックエンドの依存ノード
フロントエンド

デプロイの順序を変更することはできますが、GitLabアプリケーションコード（たとえば、RailsやSidekiq）を実行しているコンポーネントは一緒にデプロイする必要があります。可能であれば、これらのコンポーネントはメジャーリリースのバージョンアップグレードで導入された変更に依存しないため、サポートインフラストラクチャを個別にアップグレードしてください。

GitLabコンポーネントは、次の順序でアップグレードする必要があります:

Consul
PostgreSQL
PgBouncer
Redis
Gitaly
Praefect
Rails
Sidekiq

Consul、PostgreSQL、PgBouncer、およびRedisノードをアップグレードする

Consul 、PostgreSQL 、PgBouncer 、およびRedisのコンポーネントはすべて、ダウンタイムなしでアップグレードするための同じ基本プロセスに従います。

アップグレードを実行するには、各コンポーネントのノードで次のようにします:

/etc/gitlab/skip-auto-reconfigureに空のファイルを作成します。これにより、アップグレードによってgitlab-ctl reconfigureが実行されるのを防ぎます。これは、デフォルトでGitLabを自動的に停止し、すべてのデータベース移行を実行し、GitLabを再起動します:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Linuxパッケージでアップグレードしてノードをアップグレードします。
最新のコードを適用するために再構成して再起動します:
```
sudo gitlab-ctl reconfigure
```
Consulクライアントを最初に再起動し、次に他のすべてのサービスを再起動して、PostgreSQLのフェイルオーバーが正常に発生するようにします:
sudo gitlab-ctl restart consul sudo gitlab-ctl restart-except consul
sudo gitlab-ctl restart

Gitalyノードをアップグレードする

Gitalyは、アップグレードに関して同じコアプロセスに従いますが、Gitalyプロセス自体は再起動されないという重要な違いがあります。これは、最も早い機会に正常にリロードするための組み込みプロセスがあるためです。その他のコンポーネントは依然として再起動する必要があります。

このプロセスは、Gitalyシャード化設定とクラスター設定の両方に適用されます。各Gitalyノードで次の手順を順番に実行してアップグレードを実行します:

/etc/gitlab/skip-auto-reconfigureに空のファイルを作成します。これにより、アップグレードによってgitlab-ctl reconfigureが実行されるのを防ぎます。これは、デフォルトでGitLabを自動的に停止し、すべてのデータベース移行を実行し、GitLabを再起動します:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Linuxパッケージでアップグレードしてノードをアップグレードします。
reconfigureコマンドを実行して最新のコードを適用し、Gitalyに次の機会に正常にリロードするように指示します:
```
sudo gitlab-ctl reconfigure
```

最後に、Gitalyが正常にリロードされている間も、デプロイされた他のコンポーネントは再起動が必要です:

# Get a list of what other components have been deployed beside Gitaly
sudo gitlab-ctl status

# Restart each component except Gitaly. Example given for Consul, Node Exporter and Logrotate
sudo gitlab-ctl restart consul node-exporter logrotate

Gitalyクラスター (Praefect) ノードをアップグレードする

このセクションは、Praefectコンポーネントのみに焦点を当てており、必要なPostgreSQLデータベースではありません。GitLab Linuxパッケージは、Praefectデータベースに対するHAおよびゼロダウンタイムサポートを提供していません。ダウンタイムを回避するには、サードパーティのデータベースソリューションが必要です。

Gitalyクラスター (Praefect) の設定では、正常なリロードを使用して、同様の方法でPraefectをデプロイおよびアップグレードする必要があります。

アップグレードプロセスは、新しいPraefectプロセスへの正常なハンドオーバーを試みます。アップグレード前に開始された既存の長時間のGitリクエストは、このハンドオーバーが発生すると最終的にドロップされる可能性があります。将来、この機能が変更される可能性があります。詳細については、このエピックを参照してください。

Praefectは、既存のデータをアップグレードするためにデータベース移行も実行する必要があります。競合を避けるため、移行は1つのPraefectノードでのみ実行する必要があります。これを行うには、移行を実行するPraefect deploy nodeを指定します:

Praefect deploy nodeで:
1. /etc/gitlab/skip-auto-reconfigureに空のファイルを作成します。これにより、アップグレードによってgitlab-ctl reconfigureが実行されるのを防ぎます。これは、デフォルトでGitLabを自動的に停止し、すべてのデータベース移行を実行し、GitLabを再起動します:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
2. Linuxパッケージでアップグレードしてノードをアップグレードします。
3. データベース移行が実行されるように、/etc/gitlab/gitlab.rbにpraefect['auto_migrate'] = trueが設定されていることを確認します。
4. reconfigureコマンドを実行して最新のコードを適用し、Praefectデータベース移行を適用して正常に再起動します:
```
sudo gitlab-ctl reconfigure
```
すべてのremaining Praefect nodesで:
1. /etc/gitlab/skip-auto-reconfigureに空のファイルを作成します。これにより、アップグレードによってgitlab-ctl reconfigureが実行されるのを防ぎます。これは、デフォルトでGitLabを自動的に停止し、すべてのデータベース移行を実行し、GitLabを再起動します:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
2. Linuxパッケージでアップグレードしてノードをアップグレードします。
3. reconfigureによるデータベース移行の自動実行を防ぐために、/etc/gitlab/gitlab.rbにpraefect['auto_migrate'] = falseが設定されていることを確認します。
4. reconfigureコマンドを実行して最新のコードを適用し、正常に再起動します:
```
sudo gitlab-ctl reconfigure
```

最後に、Praefectが正常にリロードされている間も、デプロイされた他のコンポーネントは再起動が必要です。すべてのPraefect nodesで:

# Get a list of what other components have been deployed beside Praefect
sudo gitlab-ctl status

# Restart each component except Praefect. Example given for Consul, Node Exporter and Logrotate
sudo gitlab-ctl restart consul node-exporter logrotate

GitLabアプリケーション (Rails) ノードをアップグレードする

ウェブサーバーとしてのRailsは、主にPuma、Workhorse、およびNGINXで構成されています。

これらのコンポーネントはそれぞれ、ライブアップグレードを行う際に異なる動作をします。Pumaは正常なリロードを許可できますが、Workhorseは許可しません。最善のアプローチは、ロードバランサーを使用するなど、他の手段でノードのトラフィックを正常にドレインすることです。ノードでNGINXの正常シャットダウン機能を使用することでもこれを行うことができます。このセクションではNGINXのアプローチについて説明します。

上記に加えて、Railsは主要なデータベース移行を実行する必要がある場所です。Praefectと同様に、最善のアプローチはデプロイノードを使用することです。現在PgBouncerが使用されている場合、Railsは移行の実行を試みる際にアドバイザリロックを使用するため、同時に実行される移行が同じデータベースで実行されるのを防ぐために、これもバイパスする必要があります。これらのロックはトランザクション間で共有されず、トランザクションプールモードでPgBouncerを使用してデータベース移行を実行すると、ActiveRecord::ConcurrentMigrationErrorやその他の問題が発生します。

Rails deploy nodeで:
1. ノードのトラフィックを正常にドレインします。これにはさまざまな方法がありますが、1つのアプローチは、NGINXにQUITシグナルを送信し、サービスを停止することです。例として、次のシェルスクリプトを使用してこれを行うことができます:
```
# Send QUIT to NGINX master process to drain and exit
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID

# Wait for drain to complete
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done

# Stop NGINX service to prevent automatic restarts
gitlab-ctl stop nginx
```
2. /etc/gitlab/skip-auto-reconfigureに空のファイルを作成します。これにより、アップグレードによってgitlab-ctl reconfigureが実行されるのを防ぎます。これは、デフォルトでGitLabを自動的に停止し、すべてのデータベース移行を実行し、GitLabを再起動します:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
3. LinuxパッケージでアップグレードしてGitLabをアップグレードします。
4. /etc/gitlab/gitlab.rb設定ファイルでgitlab_rails['auto_migrate'] = trueを設定して、通常の移行が実行されるように構成します。
  - デプロイノードがPgBouncerを介してデータベースにアクセスする場合、移行を実行する前にそれをバイパスしてデータベースリーダーに直接接続する必要があります。
  - データベースリーダーを見つけるには、任意のデータベースノードで次のコマンドを実行できます。sudo gitlab-ctl patroni members
5. 通常の移行を実行し、最新のコードを適用します:
```
sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-ctl reconfigure
```
6. このノードは、後でデプロイ後移行を実行するためにそのままにしておきます。
すべてのother Rails nodeで順番に:
1. ノードのトラフィックを正常にドレインします。これにはさまざまな方法がありますが、1つのアプローチは、NGINXにQUITシグナルを送信し、サービスを停止することです。例として、次のシェルスクリプトを使用してこれを行うことができます:
```
# Send QUIT to NGINX master process to drain and exit
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID

# Wait for drain to complete
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done

# Stop NGINX service to prevent automatic restarts
gitlab-ctl stop nginx
```
2. /etc/gitlab/skip-auto-reconfigureに空のファイルを作成します。これにより、アップグレードによってgitlab-ctl reconfigureが実行されるのを防ぎます。これは、デフォルトでGitLabを自動的に停止し、すべてのデータベース移行を実行し、GitLabを再起動します:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
3. LinuxパッケージでアップグレードしてGitLabをアップグレードします。
4. reconfigureによるデータベース移行の自動実行を防ぐために、/etc/gitlab/gitlab.rbにgitlab_rails['auto_migrate'] = falseが設定されていることを確認します。
5. reconfigureコマンドを実行して最新のコードを適用し、再起動します:
```
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
```
Rails deploy nodeでデプロイ後移行を実行します:
1. デプロイノードが引き続きデータベースリーダーに直接ポイントしていることを確認します。ノードがPgBouncerを介してデータベースにアクセスする場合、移行を実行する前にそれをバイパスしてデータベースリーダーに直接接続する必要があります。
  - データベースリーダーを見つけるには、任意のデータベースノードで次のコマンドを実行できます。sudo gitlab-ctl patroni members
2. デプロイ後移行を実行します:
```
sudo gitlab-rake gitlab:db:configure
```
  このタスクは、ClickHouse移行も実行し、スキーマを読み込むことによってその状態に基づいてデータベースを構成します。
3. /etc/gitlab/gitlab.rb設定ファイルでgitlab_rails['auto_migrate'] = falseを設定して、構成を通常に戻します。
  - PgBouncerを使用している場合は、データベース構成が再度それにポイントするように設定されていることを確認してください。
4. 通常の構成を再適用するために、もう一度再構成を実行し、再起動します:
```
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
```

Sidekiqノードをアップグレードする

Sidekiqは、ダウンタイムなしでアップグレードするために他のコンポーネントと同じ基本プロセスに従います。

アップグレードを実行するには、各コンポーネントノードで次の手順を順番に実行します:

/etc/gitlab/skip-auto-reconfigureに空のファイルを作成します。これにより、アップグレードによってgitlab-ctl reconfigureが実行されるのを防ぎます。これは、デフォルトでGitLabを自動的に停止し、すべてのデータベース移行を実行し、GitLabを再起動します:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
Linuxパッケージでアップグレードしてノードをアップグレードします。
reconfigureコマンドを実行して最新のコードを適用し、再起動します:
```
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
```

マルチノードGeoインスタンスをアップグレードする

プラン: Premium、Ultimate
提供形態: GitLab Self-Managed

このセクションでは、GeoをデプロイしたライブGitLab環境をアップグレードするために必要な手順について説明します。

全体として、アプローチは通常のプロセスとほぼ同じですが、各セカンダリサイトに必要な追加の手順がいくつかあります。必要な順序は、プライマリを最初にアップグレードし、次にセカンダリをアップグレードすることです。また、すべてのセカンダリが更新された後、プライマリでデプロイ後の移行を実行する必要があります。

GeoをデプロイしたライブGitLab環境のアップグレードには、同じ要件と考慮事項が適用されます。

プライマリサイト

プライマリサイトのアップグレードプロセスは通常のプロセスと同じですが、すべてのセカンダリが更新されるまでデプロイ後の移行を実行しないという例外が1つあります。

説明されているプライマリサイトと同じ手順を実行しますが、Railsノードのデプロイ後移行を実行する手順で停止します。

セカンダリサイト

すべてのセカンダリサイトのアップグレードプロセスは、Railsノードを除いて、通常のプロセスと同じ手順に従います。プライマリサイトとセカンダリサイトの両方でアップグレードプロセスは同じです。ただし、セカンダリサイトのRailsノードについては、次の追加手順を実行する必要があります。

Rails

Rails deploy nodeで:
1. ノードのトラフィックを正常にドレインします。これにはさまざまな方法がありますが、1つのアプローチは、NGINXにQUITシグナルを送信し、サービスを停止することです。例として、次のシェルスクリプトを使用してこれを行うことができます:
```
# Send QUIT to NGINX master process to drain and exit
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID

# Wait for drain to complete
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done

# Stop NGINX service to prevent automatic restarts
gitlab-ctl stop nginx
```
2. Geo Log Cursorプロセスを停止して、別のノードへのフェイルオーバーを確実にします:
```
gitlab-ctl stop geo-logcursor
```
3. /etc/gitlab/skip-auto-reconfigureに空のファイルを作成します。これにより、アップグレードによってgitlab-ctl reconfigureが実行されるのを防ぎます。これは、デフォルトでGitLabを自動的に停止し、すべてのデータベース移行を実行し、GitLabを再起動します:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
4. LinuxパッケージでアップグレードしてGitLabをアップグレードします。
5. プライマリサイトのRailsノードとセカンダリサイトのRailsノードが異なる場合、/etc/gitlab/gitlab-secrets.jsonファイルをコピーします。このファイルは、サイトのすべてのノードで同じでなければなりません。
6. /etc/gitlab/gitlab.rb設定ファイルでgitlab_rails['auto_migrate'] = falseおよびgeo_secondary['auto_migrate'] = falseを設定して、移行が自動的に実行されないようにします。
7. reconfigureコマンドを実行して最新のコードを適用し、再起動します:
```
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
```
8. 通常のGeo追跡移行を実行し、最新のコードを適用します:
```
sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate:geo
```
すべてのother Rails nodeで順番に:
1. ノードのトラフィックを正常にドレインします。これにはさまざまな方法がありますが、1つのアプローチは、NGINXにQUITシグナルを送信し、サービスを停止することです。例として、次のシェルスクリプトを使用してこれを行うことができます:
```
# Send QUIT to NGINX master process to drain and exit
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID

# Wait for drain to complete
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done

# Stop NGINX service to prevent automatic restarts
gitlab-ctl stop nginx
```
2. Geo Log Cursorプロセスを停止して、別のノードへのフェイルオーバーを確実にします:
```
gitlab-ctl stop geo-logcursor
```
3. /etc/gitlab/skip-auto-reconfigureに空のファイルを作成します。これにより、アップグレードによってgitlab-ctl reconfigureが実行されるのを防ぎます。これは、デフォルトでGitLabを自動的に停止し、すべてのデータベース移行を実行し、GitLabを再起動します:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
4. LinuxパッケージでアップグレードしてGitLabをアップグレードします。
5. /etc/gitlab/gitlab.rb設定ファイルでgitlab_rails['auto_migrate'] = falseおよびgeo_secondary['auto_migrate'] = falseを設定して、移行が自動的に実行されないようにします。
6. reconfigureコマンドを実行して最新のコードを適用し、再起動します:
```
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
```

Sidekiq

メインプロセスに従い、残りのタスクはSidekiqをアップグレードすることです。

メインセクションで説明されているのと同じ方法でSidekiqをアップグレードします。

デプロイ後移行

最後に、プライマリサイトに戻り、デプロイ後移行を実行してアップグレードを完了します:

プライマリサイトのRails deploy nodeでデプロイ後移行を実行します:
1. デプロイノードが引き続きデータベースリーダーに直接ポイントしていることを確認します。ノードがPgBouncerを介してデータベースにアクセスする場合、移行を実行する前にそれをバイパスしてデータベースリーダーに直接接続する必要があります。
  - データベースリーダーを見つけるには、任意のデータベースノードで次のコマンドを実行できます。sudo gitlab-ctl patroni members
2. デプロイ後移行を実行します:
```
sudo gitlab-rake gitlab:db:configure
```
3. Geo構成と依存関係を確認します。
```
sudo gitlab-rake gitlab:geo:check
```
4. /etc/gitlab/gitlab.rb設定ファイルでgitlab_rails['auto_migrate'] = falseを設定して、構成を通常に戻します。
  - PgBouncerを使用している場合は、データベース構成が再度それにポイントするように設定されていることを確認してください。
5. 通常の構成を再適用するために、もう一度再構成を実行し、再起動します:
```
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
```
セカンダリサイトのRails deploy nodeで、デプロイ後Geo追跡移行を実行します:
1. デプロイ後Geo追跡移行を実行します:
```
sudo gitlab-rake db:migrate:geo
```
2. Geoステータスを確認します:
```
sudo gitlab-rake geo:status
```