ダウンタイムなしのアップグレード

GitLabインスタンスをオフラインにすることなく、GitLabの新しいメジャー、マイナー、パッチバージョンにアップグレードすることが可能です。ただし、これを行うには以下の要件があります：

複数のリリースをアップグレードしたい場合や、その他の要件を満たしていない場合：

上記の要件をすべて満たしている場合は、以下の手順に順に従います。デプロイのタイプに応じて、3つのステップセットがあります：

デプロイのタイプ説明
GitalyまたはGitalyクラスタGitalyまたはGitalyクラスタのHAアーキテクチャを使用したGitLab CE/EE
マルチノード/PostgreSQL HAPostgreSQL 用の HA アーキテクチャを使用する GitLab CE/EE
マルチノード / Redis HARedisのHAアーキテクチャを利用したGitLab CE/EE
GeoGeoを有効にしたGitLab EE
Geoを使用したマルチノード/HA複数ノードのGitLab CE/EE

それぞれのタイプのデプロイでは、sidekiq アップグレード後にこれらのサービスを実行しているすべてのノードで sidekiq puma とsidekiq プロセスを sidekiqホットリロードする必要があります。sidekiq その理由は、これらのプロセスがそれぞれ GitLab Rails アプリケーションをロードし、起動時にデータベーススキーマを読み込んでメモリにロードするからです。 sidekiqデプロイ後のマイグレーションによって変更されたデータベースを再読み込みするためには、sidekiq これらのプロセスをそれぞれリロードしなければなりません ( sidekiqデプロイ後の場合はsidekiq 再起動しなければ sidekiqなりません)。

ほとんどの場合、パッチリリースが最新でなくても、パッチリリースから次のマイナーリリースに安全にアップグレードできます。例えば、14.1.1 から 14.2.0 へのアップグレードは、14.1.2 がリリースされていても安全です。万が一、マイグレーションが含まれていて、一度に1リリースずつアップグレードする必要があるかもしれませんので、現在のバージョンとターゲットバージョンの間にあるリリースのリリースポストを確認することをお勧めします。

また、あなたのアップグレードパスに関連する、バージョン固有のアップグレード手順を確認することをお勧めします。

リリースによっては、いわゆる「バックグラウンドマイグレーション」が含まれる場合があります。これらのマイグレーションはSidekiqによってバックグラウンドで実行され、多くの場合、データのマイグレーションに使用されます。バックグラウンドマイグレーションは、毎月のリリースでのみ追加されます。

特定のメジャー/マイナーリリースでは、一連のバックグラウンドマイグレーションを終了する必要があります。これを保証するために、そのようなリリースでは、アップグレード手順を続行する前に残りのジョブを処理します。これにはダウンタイムは必要ありませんが (上記の条件が満たされている場合)、各メジャー/マイナーリリースのアップグレードの間にバックグラウンドマイグレーションが完了するまでお待ちいただく必要があります。これらのマイグレーションを完了するのに必要な時間は、background_migration キューのジョブを処理できる Sidekiq ワーカーの数を増やすことで短縮できます。このキューのサイズを確認するには、アップグレード前にバックグラウンドマイグレーションをチェックしてください。

目安として、10GB未満のデータベースであれば、アップグレードにそれほど時間はかかりません。しかし、これより大きなデータベースではもっと時間がかかるかもしれませんが、これはデータベースのサイズと実行中のマイグレーションに大きく依存します。

これを説明するために、いくつかの例を見てみましょう：

例1:あなたは、13.4の最新パッチリリースであるバージョン13.4.2を使用して大規模なGitLabインストールを実行しています。GitLab 13.5.0がリリースされたとき、上記の要件が満たされていれば、このインストールはダウンタイムなしで安全に13.5.0にアップグレードできます。13.5.0をスキップしてリリース後に13.5.1にアップグレードすることもできますが、13.6.0にそのままアップグレードすることはできません。

例2:バージョン13.4.2を使用して大規模なGitLabインストールを実行しています。GitLab 13.5にはいくつかのバックグラウンドマイグレーションが含まれており、14.0ではこれらを完了させる必要があります（残っているジョブを処理します）。13.5をスキップすることはダウンタイムなしでは不可能で、バックグラウンドマイグレーションが完了するまでの時間によっては数時間のダウンタイムが必要になる可能性があります。これを回避するには、まず13.5.Zにアップグレードし、少なくとも1週間待ってから14.0にアップグレードする必要があります。

例3: GitLabのデータベースとしてMySQLを使っています。新しいメジャー/マイナーリリースへのアップグレードにはダウンタイムが必要です。リリースにバックグラウンドマイグレーションが含まれている場合、データベースのサイズによっては数時間のダウンタイムが発生する可能性があります。これを回避するには、PostgreSQLを使用し、上記の他のオンラインアップグレードの要件を満たす必要があります。

複数ノード/HAデプロイ

caution
一度に1つのマイナーリリースしかアップグレードできません。つまり、15.6 から 15.7 へのアップグレードであって、15.8 へのアップグレードではありません。複数のマイナーリリースをアップグレードしようとすると、アップグレードに失敗する可能性があります。

ウェブ(Puma)ノードの前でロードバランサーを使用

Puma では、シングルノードのゼロダウンタイム更新はもはや不可能です。ゼロダウンタイムの更新で HA を実現するには、両方のノードに適切に接続を分散するロードバランサーを少なくとも2ノード使用する必要があります。

アプリケーションノードの前にあるロードバランサーは、サービスがトラフィックを受け入れているかどうかをチェックするために、適切なヘルスチェックエンドポイントをチェックするように設定する必要があります。Pumaの場合は/-/readiness 、Sidekiqやその他のサービスの場合は/readiness 。

ウェブ（Puma）ノードのアップグレードは、少なくとも1つのノードが常にトラフィックに対応できるように、順次、ローリング方式で行う必要があります。これは、ダウンタイムをゼロにするために必要です。

Pumaはアップグレードの一環としてブラックアウト期間に入り、その間ノードは接続を受け付け続けますが、それぞれのヘルスチェックエンドポイントは不健康であるとマークされます。これを確認すると、ロードバランサはそれらを潔く切断する必要があります。

Pumaは現在処理中のリクエストをすべて完了した後にのみ再起動します。これによりデータとサービスのインテグレーションが保証されます。再起動が終わると、ヘルスチェックのエンドポイントはヘルシーとマークされます。

ロードバランサーを使用するHAインスタンスを最新のGitLabバージョンに更新するには、以下の順序でノードを更新する必要があります。

  1. デプロイノードとしてアプリケーションノードを1つ選択し、そのノードで以下の手順を実行します：

    1. /etc/gitlab/skip-auto-reconfigure に空のファイルを作成します。これにより、アップグレードがgitlab-ctl reconfigure 、デフォルトでは自動的にGitLabを停止し、すべてのデータベースマイグレーションを実行し、GitLabを再起動することを防ぎます：

      sudo touch /etc/gitlab/skip-auto-reconfigure

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

    3. 定期的なマイグレーションと最新のコードを配置します。このステップを実行する前に、デプロイノードの/etc/gitlab/gitlab.rb 設定ファイルにgitlab_rails['auto_migrate'] = true があり、定期的なマイグレーションを許可している必要があります。

      sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-ctl reconfigure

    4. サービスが最新のコードを使用するようにします：

      sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq

  2. 他のPuma/Sidekiqノードで、次の手順を次々に実行します。次のノードに進む前に、そのようなノードの少なくとも1つが稼働し、ロードバランサーに接続されていることを常に確認してください。

    1. GitLabパッケージを更新し、その一部としてreconfigure 。もしそうでなければ（/etc/gitlab/skip-auto-reconfigure ファイルが存在するため）、sudo gitlab-ctl reconfigure を手動で実行してください。

    2. サービスが最新のコードを使用していることを確認してください：

      sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq

  3. デプロイノードで、デプロイ後のマイグレーションを実行します：

    sudo gitlab-rake db:migrate

GitalyまたはGitalyクラスタ

Gitalyノードは、シャード化されたセットアップの一部として、またはGitalyクラスタの一部として、独自のサーバに配置することができます。

メインのGitLabアプリケーションを更新する前に、あなたは（順番に）しなければなりません：

  1. 別のサーバーに存在するGitalyノードをアップグレードします。
  2. Gitalyクラスタを使用している場合は、Praefectをアップグレードしてください。

既知のイシューのため、GitalyおよびGitaly Clusterのアップグレードにはダウンタイムが発生します。

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

GitalyノードのGitLabパッケージを1つずつアップグレードし、Gitリポジトリへのアクセスがメンテナーされるようにします。

Praefectのアップグレード

Praefectノードから、Praefectデプロイノードとして使用するノードを1つ選択します。まず、デプロイノードに新しい Omnibus パッケージをインストールし、データベースのマイグレーションを実行します。

  1. Praefect デプロイノードで、次の操作を行います：

    1. /etc/gitlab/skip-auto-reconfigure に空のファイルを作成します。gitlab-ctl reconfigureデフォルトでは、GitLabを自動的に停止し、すべてのデータベースマイグレーションを実行し、GitLabを再起動します：

      sudo touch /etc/gitlab/skip-auto-reconfigure

    2. /etc/gitlab/gitlab.rb にpraefect['auto_migrate'] = true が設定されていることを確認してください。

  2. 残りのすべてのPraefect ノードで、reconfigure が自動的にデータベースマイグレーションを実行しないように、/etc/gitlab/gitlab.rb にpraefect['auto_migrate'] = false が設定されていることを確認します。

  3. Praefect デプロイノードで、次の操作を行います：

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

    2. Praefectデータベースマイグレーションを適用し、Praefectを再起動するには、以下を実行します：

      sudo gitlab-ctl reconfigure

  4. 残りのすべてのPraefectノードで以下を実行します：

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

    2. ノードが最新のコードを実行していることを確認します：

      sudo gitlab-ctl reconfigure

PostgreSQL

Deploy Node になるノードを選んでください。どのアプリケーションノードでもかまいませんが、終始同じノードでなければなりません。

ノードのデプロイ

  • /etc/gitlab/skip-auto-reconfigure に空のファイルを作成します。gitlab-ctl reconfigureデフォルトでは、自動的にGitLabを停止し、すべてのデータベースマイグレーションを実行し、GitLabを再起動します。

     sudo touch /etc/gitlab/skip-auto-reconfigure

デプロイノードを_含む_全てのノード

  • reconfigure が自動的にデータベースマイグレーションを実行しないようにするには、gitlab_rails['auto_migrate'] = false が/etc/gitlab/gitlab.rb に設定されていることを確認します。

PostgreSQL 専用ノード

ノードのデプロイ

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

  • PgBouncerを使っている場合：

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

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

    リーダーノードを見つけるには、データベースノード上で以下を実行します：

     sudo gitlab-ctl patroni members

    次に、デプロイノードのgitlab.rb ファイルで、gitlab_rails['db_host'] とgitlab_rails['db_port'] をデータベースリーダーのホストとポートで更新します。

  • 通常のデータベースマイグレーションと最新のコードを配置するには、以下を実行します。

     sudo gitlab-ctl reconfigure
 sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate

デプロイノードを_除く_全ノード

ノードのデプロイ

  • デプロイノードでデプロイ後のデータベースマイグレーションを実行し、マイグレーションを完了します。

     sudo gitlab-rake db:migrate

PumaまたはSidekiqを実行するノードの場合

  • puma およびsidekiq サービスをホット・リロードします。

     sudo gitlab-ctl hup puma
 sudo gitlab-ctl restart sidekiq

  • PgBouncerを使っている場合：

    gitlab.rb 、PgBouncerを指すように変更し、実行してください：

     sudo gitlab-ctl reconfigure

将来的にゼロダウンタイムのアップグレードを実行したくない場合は、/etc/gitlab/skip-auto-reconfigure を削除し、/etc/gitlab/gitlab.rb のgitlab_rails['auto_migrate'] = false の設定を元に戻してください。

Redis HA (Sentinelを使用)

パッケージのアップグレードには、バンドルされているRedisサービスのバージョン更新が含まれることがあります。Redisをスケーリングに使用しているインスタンスでは、ダウンタイムを最小限に抑えるために、アップグレードは適切な順序に従う必要があります。このドキュメントでは、公式ガイドに従ってRedis HAをセットアップしていることを前提としています。

アプリケーションノードで

Redisの公式ドキュメントによると、Sentinelを使用してHAインスタンスを更新する最も簡単な方法は、セカンダリを次々にアップグレードし、現在のプライマリ（古いバージョンを実行）から最近アップグレードされたセカンダリ（新しいバージョンを実行）に手動でフェイルオーバーを実行し、それから元のプライマリをアップグレードすることです。そのためには、現在のRedisプライマリのアドレスを知っておく必要があります。

  • アプリケーションノードがGitLab 12.7.0以降であれば、以下のコマンドを使って現在のRedisプライマリのアドレスを取得することができます。

     sudo gitlab-ctl get-redis-master

  • アプリケーションノードがGitLab 12.7.0より古いバージョンで動作している場合は、プライマリに関する情報を取得するために（get-redis-master コマンドが使用する）基盤となるredis-cli コマンドを実行する必要があります。

    1. でgitlab_rails['redis_sentinels'] として指定したセンチネルノードのアドレスを取得します。/etc/gitlab/gitlab.rb

    2. でredis['master_name'] として指定された Redis メイン名を取得します。/etc/gitlab/gitlab.rb

    3. 次のコマンドを実行します。

      sudo /opt/gitlab/embedded/bin/redis-cli -h <sentinel host> -p <sentinel port> SENTINEL get-master-addr-by-name <redis master name>

Redisセカンダリノードで

  1. gitlab.rb にgitlab_rails['rake_cache_clear'] = false を設定してください。そうしないと、新しいパッケージのインストール後の再設定でRedis::CommandError: READONLY You can't write against a read only replica. というエラーが表示される可能性があります。

  2. 新しいバージョンのパッケージをインストールしてください。

  3. インストールの一部として reconfigure が実行されない場合 (/etc/gitlab/skip-auto-reconfigure ファイルが存在するため)、sudo gitlab-ctl reconfigure を実行します。

  4. reconfigureが保留中のRedis/Sentinelの再起動について警告する場合は、対応するサービスを再起動します。

    sudo gitlab-ctl restart redis
sudo gitlab-ctl restart sentinel

Redisのプライマリノードで

Redisプライマリノードをアップグレードする前に、最近アップグレードしたセカンダリノードの1つが新しいプライマリノードになるようにフェイルオーバーを実行する必要があります。フェイルオーバーが完了したら、元のプライマリノードをアップグレードします。

  1. RedisプライマリノードのRedisサービスを停止し、セカンダリノードにフェイルオーバーさせます。

    sudo gitlab-ctl stop redis

  2. フェイルオーバーが完了するまで待ちます。現在のRedisプライマリノードの詳細を定期的にチェックすることで確認できます（前述のとおり）。新しいIPをレポーターし始めたら、フェイルオーバーは完了です。

  3. そのノードでRedisを再度起動し、現在のプライマリノードに従って開始するようにします。

    sudo gitlab-ctl start redis

  4. 新しいバージョンに対応するパッケージをインストールします。

  5. インストールの一部として reconfigure が実行されない場合 (/etc/gitlab/skip-auto-reconfigure ファイルが存在するため)、sudo gitlab-ctl reconfigure を実行します。

  6. reconfigureが保留中のRedis/Sentinelの再起動について警告する場合は、対応するサービスを再起動します。

    sudo gitlab-ctl restart redis
sudo gitlab-ctl restart sentinel

アプリケーションノードの更新

新しいバージョンのパッケージをインストールし、通常のパッケージのアップグレード手順に従ってください。

Geo デプロイ

caution
一度にアップグレードできるのは 1 つのマイナーリリースのみです。

ステップの順序はインポートです。これらの手順を実行する際には、正しいノードで正しい順序で実行するようにしてください。

Geo プライマリサイトの更新

プライマリノードにログインし、以下を実行します：

  1. /etc/gitlab/skip-auto-reconfigureに空のファイルを作成します。これにより、アップグレードがgitlab-ctl reconfigure 、デフォルトでは自動的にGitLabを停止し、すべてのデータベースマイグレーションを実行し、GitLabを再起動することを防ぎます：

    sudo touch /etc/gitlab/skip-auto-reconfigure

  2. /etc/gitlab/gitlab.rb を編集し、以下が存在することを確認します：

    gitlab_rails['auto_migrate'] = false

  3. GitLab を再設定します：

    sudo gitlab-ctl reconfigure

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

  5. データベースのマイグレーションと最新のコードを取得するには、以下を実行してください：

    sudo gitlab-ctl reconfigure

  6. ノードの更新と再構成が正常に終了したら、マイグレーションを完了します：

    sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate

  7. プライマリ・サイトとセカンダリ・サイトが異なる場合は、/etc/gitlab/gitlab-secrets.json ファイルをプライマリ・サイトからセカンダリ・サイトにコピーします。このファイルは、サイトのすべてのノードで同じである必要があります。

Geo セカンダリサイトを更新します。

各セカンダリノードで以下を実行します：

  1. /etc/gitlab/skip-auto-reconfigure に空のファイルを作成します。gitlab-ctl reconfigureデフォルトでは、自動的にGitLabを停止し、すべてのデータベースマイグレーションを実行し、GitLabを再起動します。

    sudo touch /etc/gitlab/skip-auto-reconfigure

  2. /etc/gitlab/gitlab.rb を編集し、以下が存在することを確認します：

    gitlab_rails['auto_migrate'] = false

  3. GitLab を再設定します：

    sudo gitlab-ctl reconfigure

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

  5. データベースのマイグレーションと最新のコードを取得するには、以下を実行してください：

    sudo gitlab-ctl reconfigure

  6. Geo データベースに固有のデプロイ後のデータベースマイグレーションを実行します：

    sudo gitlab-rake db:migrate:geo

アップデートの最終確認

すべてのセカンダリノードの更新が完了したら、プライマリノードの更新を確定します：

  • デプロイ後のデータベースマイグレーションの実行

     sudo gitlab-rake db:migrate

  • プライマリ・ノードで更新が完了したら、puma をホット・リロードし、すべてのプライマリ・ノードとセカンダリ・ノードで sidekiq とgeo-logcursor サービスを再起動します：

     sudo gitlab-ctl hup puma
 sudo gitlab-ctl restart sidekiq
 sudo gitlab-ctl restart geo-logcursor

すべてのノード（プライマリノードと セカンダリノードのすべて）を更新した後、ステータスを確認します：

  • Geo 設定と依存関係の確認

     sudo gitlab-rake gitlab:geo:check

将来的にゼロダウンタイムのアップグレードを実行したくない場合は、/etc/gitlab/skip-auto-reconfigure を削除し、/etc/gitlab/gitlab.rb のgitlab_rails['auto_migrate'] = false の設定を元に戻してください。

Geo を使用したマルチノード/HA デプロイ

caution
一度にアップグレードできるのは1つのマイナーリリースのみです。また、最初に Gitaly クラスターから始めて、1 ノードずつ Gitaly を更新する必要があります。こうすることで、残りのアップグレード作業で Git リポジトリにアクセスできるようになります。

このセクションでは、Geoを使った複数ノード/HAデプロイのアップグレードに必要な手順を説明します。いくつかの手順は特定のノードで実行する必要があります。このノードは「デプロイノード」と呼ばれ、以下の手順で説明します。

アップデートは以下の順序で実行する必要があります：

  1. Geoプライマリマルチノード デプロイを更新します。
  2. Geoセカンダリマルチノードデプロイの更新。
  3. デプロイ後のマイグレーションとチェック。

ステップ1: デプロイごとに「デプロイノード」を選択します。

ここで選択する必要があります：

  • Geoプライマリマルチノード デプロイのプライマリ「デプロイ ノード」として使用するインスタンスを 1 つ選択します。
  • 各 Geoセカンダリ・マルチノード・デプロイの セカンダリ「デプロイノード」として使用するインスタンス。

デプロイノードは Puma、Sidekiq、またはgeo-logcursor デーモンを実行するように設定する必要があります。ダウンタイムを避けるため、更新中は使用しないでください：

  • Pumaを実行している場合は、ロードバランサーからデプロイノードを削除します。

  • Sidekiqを実行している場合、デプロイノードがジョブを処理していないことを確認してください：

     sudo gitlab-ctl stop sidekiq

  • geo-logcursor デーモンを実行している場合、デプロイノードがイベントを処理していないことを確認してください：

     sudo gitlab-ctl stop geo-logcursor

ダウンタイムをゼロにするには、更新中にPuma、Sidekiq、geo-logcursor が他のノードで実行されている必要があります。

ステップ2: Geoプライマリマルチノードデプロイの更新

プライマリ “デプロイノード “を_含む_すべてのプライマリノードで以下を行います。

  1. /etc/gitlab/skip-auto-reconfigure に空のファイルを作成します。gitlab-ctl reconfigureデフォルトでは、自動的にGitLabを停止し、すべてのデータベースマイグレーションを実行し、GitLabを再起動します。
sudo touch /etc/gitlab/skip-auto-reconfigure

  1. reconfigure が自動的にデータベースマイグレーションを実行しないようにするには、gitlab_rails['auto_migrate'] = false が/etc/gitlab/gitlab.rb に設定されていることを確認します。

  2. ノードが最新のコードを実行していることを確認します。

    sudo gitlab-ctl reconfigure

プライマリノードのみ

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

  2. ノードが最新のコードを実行していることを確認します。

    sudo gitlab-ctl reconfigure

プライマリ “デプロイノード “で

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

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

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

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

    リーダーノードを見つけるには、データベースノード上で以下を実行します：

    sudo gitlab-ctl patroni members

    次に、デプロイノードのgitlab.rb ファイルで、gitlab_rails['db_host'] とgitlab_rails['db_port'] をデータベースリーダーのホストとポートで更新します。

  3. 通常のデータベースマイグレーションと最新のコードを配置するには、以下を実行します。

    sudo gitlab-ctl reconfigure
sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate

  4. このデプロイノードがリクエストの処理またはジョブの処理に使用されている場合は、この時点でサービスに戻すことができます。

    • リクエストに応答するには、デプロイノードをロードバランサに追加します。

    • Sidekiqジョブを再び処理するには、Sidekiqを起動します：

       sudo gitlab-ctl start sidekiq

プライマリ “デプロイノード “を_除く_すべてのプライマリノードで

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

  2. ノードが最新のコードを実行していることを確認します。

    sudo gitlab-ctl reconfigure

プライマリ “デプロイノード “を_含む、_PumaまたはSidekiqを実行するすべてのプライマリノードについて

ホットリロードpuma およびsidekiq サービス：

sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq
  1. プライマリサイトとセカンダリサイトが異なる場合は、/etc/gitlab/gitlab-secrets.json ファイルをプライマリサイトからセカンダリサイトにコピーします。ファイルは、サイトのすべてのノードで同じである必要があります。

ステップ 3: 各 Geo セカンダリ マルチノード デプロイを更新します。

Geoプライマリマルチノード デプロイですべての手順を正常に完了した場合のみ、次に進みます。

セカンダリ “デプロイ ノード” を_含む_すべてのセカンダリ ノードで

  1. /etc/gitlab/skip-auto-reconfigure に空のファイルを作成します。gitlab-ctl reconfigureデフォルトでは、自動的にGitLabを停止し、すべてのデータベースマイグレーションを実行し、GitLabを再起動します。
sudo touch /etc/gitlab/skip-auto-reconfigure

  1. reconfigure が自動的にデータベースマイグレーションを実行しないようにするには、geo_secondary['auto_migrate'] = false が/etc/gitlab/gitlab.rb に設定されていることを確認します。

  2. ノードが最新のコードを実行していることを確認します。

    sudo gitlab-ctl reconfigure

セカンダリのみのノードでは

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

  2. ノードが最新のコードを実行していることを確認します。

    sudo gitlab-ctl reconfigure

セカンダリ “デプロイノード” で

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

  2. 通常のデータベースマイグレーションと最新のコードを配置するには、以下を実行します。

    sudo gitlab-ctl reconfigure
sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate:geo

  3. このデプロイノードがリクエストの処理またはバックグラウンド処理の実行に使用されている場合は、この時点でサービスに戻すことができます。

    • リクエストに応答するには、デプロイノードをロードバランサに追加します。

    • Sidekiqジョブを再び処理するには、Sidekiqを起動します：

       sudo gitlab-ctl start sidekiq

    • Geoイベントを再び処理するには、geo-logcursor デーモンを起動してください：

       sudo gitlab-ctl start geo-logcursor

セカンダリ “デプロイノード “を_除く_すべてのセカンダリノードで。

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

  2. ノードが最新のコードを実行していることを確認します。

    sudo gitlab-ctl reconfigure

Puma、Sidekiq、またはセカンダリ “デプロイノード “を_含む_ geo-logcursor デーモンを実行するすべてのセカンダリノードについて

puma 、sidekiq 、geo-logcursor サービスをホットリロードします：

sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq
sudo gitlab-ctl restart geo-logcursor

ステップ4：デプロイ後のマイグレーションとチェックの実行

プライマリ “デプロイノード “で

  1. デプロイ後のデータベースマイグレーションを実行します：

    sudo gitlab-rake db:migrate

  2. Geo 設定と依存関係の確認

    sudo gitlab-rake gitlab:geo:check

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

    gitlab.rb 、PgBouncerを指すように変更し、実行してください：

    sudo gitlab-ctl reconfigure

すべてのセカンダリ “デプロイノード”

  1. Geo データベースに固有のデプロイ後のデータベースマイグレーションを実行します：

    sudo gitlab-rake db:migrate:geo

  2. Geo 設定と依存関係の確認

    sudo gitlab-rake gitlab:geo:check

  3. Geo ステータスの確認

    sudo gitlab-rake geo:status