正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

ダウンタイムを設けてマルチノードインスタンスをアップグレードする

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

ダウンタイムを伴うマルチノードGitLabインスタンスをアップグレードするには、次の手順に従います:

  1. GitLabアプリケーションを停止します。
  2. Consulサーバーをアップグレードします。
  3. Gitaly、Rails、PostgreSQL、Redis、およびPgBouncerを任意の順序でアップグレードします。クラウドプロバイダーのPostgreSQLまたはRedisを使用しており、アップグレードが必要な場合は、これらの手順をクラウドプロバイダーの手順に置き換えてください。
  4. GitLabアプリケーション（Sidekiq、Puma）をアップグレードし、アプリケーションを起動します。

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

GitLabアプリケーションを停止する

アップグレードする前に、GitLabアプリケーションを停止してデータベースへの書き込みを停止する必要があります。プロセスは、インストール方法によって異なります。

これらのプロセスを実行しているすべてのサーバーで、PumaとSidekiqを停止します:

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

Helmチャートインスタンスの場合:

  1. 後続の再起動のために、データベースクライアントの現在のレプリカ数を書き留めます:
kubectl get deploy -n <namespace> -l release=<helm release name> -l 'app in (prometheus,webservice,sidekiq)' -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.replicas}{"\n"}{end}'
  1. データベースのクライアントを停止します:
kubectl scale deploy -n <namespace> -l release=<helm release name> -l 'app in (prometheus,webservice,sidekiq)' --replicas=0

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

Consulノードのアップグレードの手順に従います。要約:

  1. Consulノードがすべて正常であることを確認します。

  2. すべてのConsulサーバーでGitLabをアップグレードします。

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

    sudo gitlab-ctl restart

Consulクラスターのプロセスは、独自のサーバー上に存在しない可能性があり、Redis高可用性やPatroniなどの別のサービスと共有されています。この場合、これらのサーバーをアップグレードするとき:

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

GitalyとGitalyクラスター（Praefect）のアップグレード

Gitalyクラスター（Praefect）の一部ではないGitalyサーバーの場合は、GitLabをアップグレードします。複数のGitalyシャードがある場合は、Gitalyサーバーを任意の順序でアップグレードできます。

Gitalyクラスター（Praefect）を実行している場合は、Gitalyクラスター（Praefect）のゼロダウンタイムアップグレードプロセスに従ってください。

Amazon Web Services Machine Imagesを使用する場合

AWSでAmazon Web Services Machine Images（AMI）を使用している場合は、AMI再デプロイプロセスを使用してGitalyノードをアップグレードできます。このプロセスを使用するには、Elasticネットワーキング（ENI）を使用する必要があります。Gitalyクラスター（Praefect）は、サーバーのホスト名でGitリポジトリのレプリカを追跡します。ENIは、インスタンスが再デプロイされるときにプライベートドメイン名サービス名が同じままであることを保証できます。ストレージが同じであっても、ノードが新しいホスト名で再デプロイされる場合、Gitalyクラスター（Praefect）は機能しません。

ENIを使用していない場合は、Linuxパッケージを使用してGitalyノードをアップグレードする必要があります。

AMI再デプロイプロセスを使用してGitalyクラスター（Praefect）ノードをアップグレードするには:

  1. AMI再デプロイプロセスにはgitlab-ctl reconfigureを含める必要があります。すべてのノードがこれを取得するように、AMIでpraefect['auto_migrate'] = falseを設定します。この設定により、reconfigureがデータベースの移行を自動的に実行できなくなります。
  2. アップグレードされたイメージで再デプロイされる最初のノードは、デプロイノードである必要があります。
  3. デプロイされたら、praefect['auto_migrate'] = trueをgitlab.rbに設定し、gitlab-ctl reconfigureを適用します。
  4. このコマンドは、データベースの移行を実行します。
  5. 他のGitalyクラスター（Praefect）ノードを再デプロイします。

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

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

  1. GitLabをアップグレードします。

  2. アップグレードプロセスではバイナリのアップグレード時にPostgreSQLが再起動されないため、再起動して新しいバージョンを読み込むます:

    sudo gitlab-ctl restart

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

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

PostgreSQLのメジャーバージョンのアップグレードが必要な場合は、メジャーバージョンのプロセスに従ってください。

他のすべてのバージョンのアップグレードプロセスは、最初にすべてのレプリカで実行されます。レプリカがアップグレードされると、リーダーからアップグレードされたレプリカの1つにクラスターフェイルオーバーが発生します。このプロセスにより、必要なフェイルオーバーが1つだけで、完了すると、新しいリーダーがアップグレードされます。

Patroniノードをアップグレードするには:

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

    sudo gitlab-ctl patroni members

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

  3. 再起動して新しいバージョンを読み込むます:

    sudo gitlab-ctl restart

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

  5. 他のレプリカについて、アップグレード、再起動、ヘルスチェックの手順を繰り返します。

  6. リーダーノードを、レプリカと同じLinuxパッケージアップグレードに従ってアップグレードします。

  7. リーダーノード上のすべてのサービスを再起動して、新しいバージョンを読み込むと同時に、クラスターフェイルオーバーをトリガーします:

    sudo gitlab-ctl restart

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

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

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

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

RedisノードでGitLabをアップグレードして、スタンドアロンRedisサーバーをアップグレードします。

Redis高可用性（Sentinelを使用）のアップグレード

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

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

GitLabアプリケーションコンポーネントのアップグレード

GitLabアプリケーションのアップグレードプロセスは、インストール方法によって異なります。

PumaプロセスとSidekiqプロセスはすべて、以前に停止されました。各GitLabアプリケーションノードで:

  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

すべてのステートフルコンポーネントがアップグレードされたら、GitLabチャートのアップグレード手順に従って、ステートレスコンポーネント（Webservice、Sidekiq、その他のサポートサービス）をアップグレードします。

GitLabチャートのアップグレードを実行したら、データベースクライアントを再開します:

kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=<value>
kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=<value>
kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=<value>

モニターノードのアップグレード

スタンドアロンのモニタリングノードとして機能するようにPrometheusを構成している場合があります。たとえば、60 RPSまたは3,000人のユーザー参照アーキテクチャを構成する一部として。

モニターノードをアップグレードするには、ノードでGitLabをアップグレードします。