GitLab 14 の変更点

このPagesはGitLab 14のマイナーバージョンとパッチバージョンのアップグレード情報を含んでいます。現在のバージョンとターゲットバージョンの間にあるすべてのバージョンについて、これらの説明をレビューしてください。

GitLab Helm Chartのアップグレードについては、5.0のリリースノートをご覧ください。

14.10.0

  • GitLab 14.10にアップグレードする前に、インスタンスに最新の14.9.Zがインストールされている必要があります。GitLab 14.10へのアップグレードは、ci_job_artifacts データベーステーブルから不要なエントリーのインデックス削除を同時に実行します。特に、テーブルのトラフィックが多く、マイグレーションがロックを取得できない場合、この処理が数分間実行される可能性があります。再起動するとデータが失われる可能性があるため、この処理を終了させることをお勧めします。

  • 外部のPostgreSQL、特にAWS RDSを実行している場合は、データベースがクラッシュしないようにPostgreSQLのバグフィックスを行っているか確認してください。

  • パッチレベル14.10.3以降にアップグレードした場合、GitLab 14.9の実行中に完了しなかった長いデータベースデータの変更により、1時間のタイムアウトが発生する可能性があります。

     FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails]
 (gitlab::database_migrations line 51) had an error:
 [..]
 Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:

    データ変更とアップグレードを手動で完了する回避策があります。

Linux パッケージのインストール

  • GitLab 14.10では、Gitalyは新しいランタイムディレクトリを導入しました。このディレクトリは、Gitalyが正しくオペレーションするために実行時に作成する必要があるすべてのファイルとディレクトリを保持するためのものです。例えば、内部ソケット、Git実行環境、一時フック・ディレクトリなどです。

    この新しい設定は、gitaly['runtime_dir'] 。これは古いgitaly['internal_socket_dir'] 設定を置き換えるものです。内部ソケット・ディレクトリが明示的に設定されていない場合、ソケットはランタイム・ディレクトリに作成されます。

    gitaly['internal_socket_dir'] のサポートは 15.0 で削除されます。

14.9.0

  • GitLab 14.9へのアップグレードによるデータベースの変更は、大規模なGitLabインスタンスでは完了までに数時間から数日かかることがあります。これらのバッチバックグランドマイグレーションは、projects テーブルの各レコードに対応するnamespaces テーブルのレコードを確保するために、データベーステーブル全体を更新します。

    14.9.0またはそれ以降の14.9パッチバージョンにアップグレードした後、バッチドバックグラウンドマイグレーションは、それ以降のバージョンにアップグレードする前に終了する必要があります。

    マイグレーションが終了しておらず、それ以降のバージョンにアップグレードしようとすると、次のようなエラーが表示されます：

     Expected batched background migration for the given configuration to be marked as 'finished', but it is 'active':

    または

     Error executing action `run` on resource 'bash[migrate gitlab-rails database]'
 ================================================================================
   
 Mixlib::ShellOut::ShellCommandFailed
 ------------------------------------
 Command execution failed. STDOUT/STDERR suppressed for sensitive resource

  • GitLab 14.9.0はバックグラウンドマイグレーションResetDuplicateCiRunnersTokenValuesOnProjects 、保留状態で永久に立ち往生する可能性があります。

    このスタックしたジョブをクリーンアップするには、GitLab Rails Consoleで以下を実行してください：

     Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: "ResetDuplicateCiRunnersTokenValuesOnProjects").find_each do |job|
   puts Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded("ResetDuplicateCiRunnersTokenValuesOnProjects", job.arguments)
 end

  • 外部のPostgreSQL、特にAWS RDSを実行している場合は、データベースがクラッシュしないようにPostgreSQLのバグフィックスを行っているか確認してください。

14.8.0

  • 14.6.5、14.7.4、14.8.2より前のバージョンからアップグレードする場合は、Critical Security Releaseをレビューしてください： 14.8.2、14.7.4、14.6.5のブログ記事を確認してください。14.8.2以降にアップデートすると、グループとプロジェクトのRunner登録トークンがリセットされます。

  • Kubernetes用のエージェントサーバーは、Omnibusインストールではデフォルトで有効になっています。リファレンスアーキテクチャのように GitLab を大規模に実行する場合、エージェントが不要であれば、以下のサーバータイプでエージェントを無効にする必要があります。

    • Praefect
    • Gitaly
    • Sidekiq
    • Redis (roles 経由ではなく、redis['enable'] = true を使って設定する場合)
    • コンテナレジストリ
    • GitLab Rails ノードなど、roles(['application_role']) に基づくその他のサーバータイプ

    リファレンスアーキテクチャは、この設定変更とスタンドアロン Redis サーバー用の特定のロールを追加して更新されました。

    エージェントを無効にする手順

    1. gitlab.rb にgitlab_kas['enable'] = false を追加します。
    2. サーバーがすでに14.8にアップグレードされている場合は、gitlab-ctl reconfigure を実行してください。

  • GitLab 14.8.0にはバックグラウンドマイグレーションPopulateTopicsNonPrivateProjectsCount が含まれていますが、このマイグレーションは永久にペンディング状態で止まっている可能性があります。

    このスタックしたジョブをクリーンアップするには、GitLab Rails Consoleで以下を実行してください：

     Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: "PopulateTopicsNonPrivateProjectsCount").find_each do |job|
   puts Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded("PopulateTopicsNonPrivateProjectsCount", job.arguments)
 end
  • 14.3.0より前のバージョンからアップグレードする場合は、ジョブの再試行によるイシューを避けるために、まずGitLab 14.7.xにアップグレードし、すべてのバッチマイグレーションが終了していることを確認してください。
  • バージョン14.3.0以降からのアップグレードの場合、BackfillNamespaceIdForNamespaceRoute という名前のバッチマイグレーションが失敗していることに気づくかもしれません。これは無視してかまいません。バージョン14.9.xにアップグレードした後に再試行してください。
  • 外部のPostgreSQL、特にAWS RDSを実行している場合は、データベースがクラッシュしないようにPostgreSQLのバグフィックスを行っているか確認してください。

14.7.0

  • GitLab 14.6.0 から 14.7.2 への LFS オブジェクトのインポートとミラーのイシューを参照してください。
  • 14.6.5、14.7.4、14.8.2より前のバージョンからアップグレードする場合は、クリティカルセキュリティリリースをレビューしてください： 14.8.2、14.7.4、14.6.5のブログ記事をご覧ください。14.7.4以降にアップデートすると、グループとプロジェクトのRunner登録トークンがリセットされます。

  • GitLab 14.7では、Gitalyが/tmp ディレクトリに永続ファイルを期待する変更が導入されました。Gitalyが稼働しているノードで/tmp 、noatime マウントオプションを使用すると、ほとんどのディストリビューションでGitサーバーフックが削除されるというイシューが発生します。これらの条件はAmazon Linuxのデフォルト設定にも存在します。

    ディストリビューションが/tmp のファイルをサービスで管理している場合、Gitaly ファイルのtmpfiles.d 動作をオーバーライドして tmpfiles.dこのイシューを回避することができます：

     sudo printf "x /tmp/gitaly-%s-*\n" hooks git-exec-path >/etc/tmpfiles.d/gitaly-workaround.conf

    このイシューはGitLab 14.10以降で、Gitalyランタイムディレクトリを使って永続ファイルを保存する場所を指定した場合に修正されました。

Linux パッケージのインストール

  • GitLab 14.8では、Redisを6.0.16から6.2.6にアップグレードします。このアップグレードは完全な後方互換性が期待されます。

    もしあなたのインスタンスがRedis HA with Sentinelを利用しているなら、Redis HA (using Sentinel)に記載されているアップグレード手順に従ってください。

14.6.0

14.5.0

  • make を実行すると、Gitaly ビルドは_build/bin に作成され、ソース・ディレクトリのルート・ディレクトリには作成されなくなりました。セルフ・コンパイル・インストールを使用している場合は、ドキュメントに従って、systemdユニット・ファイルまたはinitスクリプトで、これらのバイナリへのパスを更新してください。

  • Workhorse と Gitaly 間の接続は、デフォルトで Gitalybackchannel プロトコルを使用します。WorkhorseとGitalyの間にgRPCプロキシをデプロイした場合、Workhorseは接続できなくなります。回避策として、一時的にworkhorse_use_sidechannel 機能フラグを無効にしてください。WorkhorseとGitalyの間にプロキシが必要な場合は、TCPプロキシを使用してください。この変更についてフィードバックがある場合は、このイシューにアクセスしてください。

  • 14.1ではバックグラウンドマイグレーションを導入し、マージリクエストの差分コミットを保存する方法を変更し、必要なストレージの量を大幅に削減しました。14.5では、merge_request_diff_commits テーブルに対する残りのジョブがすべて完了したことを確認することで、このプロセスをまとめるマイグレーションを導入しました。これらのジョブは、ほとんどの場合すでに処理されているので、14.5へのアップグレードの際に余分な時間は必要ありません。しかし、残りのジョブがある場合や、まだ14.1にアップグレードしていない場合は、デプロイの完了に数時間かかることがあります。

    すべてのマージリクエストの差分コミットにはこれらの変更が自動的に組み込まれ、アップグレードを実行するための追加要件はありません。VACUUM FULL merge_request_diff_commits を実行するまで、merge_request_diff_commits テーブルの既存のデータはアンパックされたままです。しかし、VACUUM FULL のオペレーションは、merge_request_diff_commits テーブル全体をロックして書き換えるため、オペレーションが完了するまでに時間がかかり、プロセスが終了するまでこのテーブルへのアクセスがブロックされます。このコマンドは、GitLabがアクティビティで使われていない間だけ実行するか、処理の間だけオフラインにすることをお勧めします。完了までにかかる時間はテーブルのサイズに依存します。テーブルのサイズはselect pg_size_pretty(pg_total_relation_size('merge_request_diff_commits'));を使って取得できます。

    詳細については、このイシューを参照してください。

  • GitLab 14.5.0 にはバックグラウンドマイグレーションUpdateVulnerabilityOccurrencesLocation が含まれていますが、インスタンスにマイグレーションのターゲットに一致するレコードがない場合、ペンディング状態で永久に止まったままになることがあります。

    このスタックしたジョブをクリーンアップするには、GitLab Rails Consoleで以下を実行してください：

     Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: "UpdateVulnerabilityOccurrencesLocation").find_each do |job|
   puts Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded("UpdateVulnerabilityOccurrencesLocation", job.arguments)
 end

  • 14.5 (またはそれ以降) にアップグレードすると、長時間実行中のデータベースデータの変更によって1 時間のタイムアウトが発生する可能性があります。

     FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails]
 (gitlab::database_migrations line 51) had an error:
 [..]
 Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:

    データ変更とアップグレードを手動で行う回避策があります。

  • リアルタイムのイシュー担当者を有効にする一環として、アクション・ケーブルがデフォルトで有効になりました。セルフコンパイル（ソース）インストールでは、config/cable.yml 。

    以下を実行して設定してください：

     cd /home/git/gitlab
 sudo -u git -H cp config/cable.yml.example config/cable.yml
   
 # Change the Redis socket path if you are not using the default Debian / Ubuntu configuration
 sudo -u git -H editor config/cable.yml

14.4.4

  • WebノードとAPIノードが分かれているGitLabクラスターでゼロダウンタイムのアップグレードを行うには、GitLab Webノードを14.4にアップグレードする_前に_ paginated_tree_graphql_query 機能フラグを有効にする必要があります。これは、14.4でpaginated_tree_graphql_query をデフォルトで有効にしているためで、GitLab UI が 14.4 で API が 14.3 の場合、フロントエンドではこの機能が有効になっていますが、バックエンドでは無効になっています。その結果、次のようなエラーになります：

     bundle.esm.js:63 Uncaught (in promise) Error: GraphQL error: Field 'paginatedTree' doesn't exist on type 'Repository'

14.4.0

Linux パッケージのインストール

  • GitLab 14.4では、提供されるGrafanaのバージョンは7.5で、これはGitLab 14.3で導入されたGrafana 8.1からのダウングレードです。これは、より新しいAGPLライセンスのリリースの影響を検討する時間を確保するために、ApacheライセンスのGrafanaリリースに戻されました。

    プラグインやライブラリパネルでGrafanaインストールをカスタマイズしているユーザーは、ダウングレード後にGrafanaでエラーが発生する可能性があります。Grafanaの再起動後もエラーが続く場合は、Grafanaのデータベースをリセットし、カスタマイズを追加し直す必要があるかもしれません。Grafana データベースはsudo gitlab-ctl reset-grafana でリセットできます。

14.3.0

  • 14.0.0～14.0.4を実行しているインスタンスは、GitLab 14.2以降に直接アップグレードしないでください。
  • 以前のGitLab 14リリースから14.3.Zにアップグレードする前に、バッチバックグラウンドマイグレーションが終了していることを確認してください。
  • Ruby 2.7.4 が必要です。Ruby のインストール手順を参照してください。

  • GitLab 14.3.0はデプロイ後のマイグレーションで、以下のテーブルのPKが整数であるプライマリキーのオーバーフローリスクに対応しています：

    マイグレーションがノーダウンタイムのデプロイの一部として実行された場合、アプリケーションロジックとのロックの競合によって失敗し、ロックのタイムアウトやデッドロックが発生するリスクがあります。いずれの場合も、これらのマイグレーションは成功するまで安全に再実行できます：

     # For Omnibus GitLab
 sudo gitlab-rake db:migrate
   
 # For source installations
 sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production

  • 14.3にアップグレードした後、GitLab 14.5以降へのアップグレードを続ける前に、MigrateMergeRequestDiffCommitUsers のバックグラウンドマイグレーションジョブがすべて完了したことを確認してください。GitLabインスタンスに大きなmerge_request_diff_commits テーブルがある場合、これは特にインポートです。保留中のMigrateMergeRequestDiffCommitUsers バックグラウンドマイグレーションジョブはGitLab 14.5ではフォアグラウンドになり、完了までに時間がかかることがあります MigrateMergeRequestDiffCommitUsers。PostgreSQLコンソール（またはsudo gitlab-psql）を使って、保留MigrateMergeRequestDiffCommitUsers 中のジョブの数を確認することができます MigrateMergeRequestDiffCommitUsers：

     select status, count(*) from background_migration_jobs
 where class_name = 'MigrateMergeRequestDiffCommitUsers' group by status;

    ジョブが完了すると、データベースのレコードは0 (pending) から1 に変わります。しばらくしても保留中のジョブの数が減らない場合は、MigrateMergeRequestDiffCommitUsers バックグラウンドマイグレーションジョブが失敗した可能性があります。Sidekiqログでエラーを確認できます：

     sudo grep MigrateMergeRequestDiffCommitUsers /var/log/gitlab/sidekiq/current | grep -i error

    必要であれば、GitLab Railsコンソールで MigrateMergeRequestDiffCommitUsers バックグラウンドマイグレーションジョブを手動で実行してみることができます。これはSidekiqを非同期に使うか、Railsプロセスを直接使うことで実行できます：

    • Sidekiqを使ってジョブを非同期にスケジュールする方法：

       # For the first run, only attempt to execute 1 migration. If successful, increase
 # the limit for subsequent runs
 limit = 1
      
 jobs = Gitlab::Database::BackgroundMigrationJob.for_migration_class('MigrateMergeRequestDiffCommitUsers').pending.to_a
      
 pp "#{jobs.length} jobs remaining"
      
 jobs.first(limit).each do |job|
   BackgroundMigrationWorker.perform_in(5.minutes, 'MigrateMergeRequestDiffCommitUsers', job.arguments)
 end
      note
      キューに入れられたジョブは、Sidekiqの管理パネルを使用して監視することができます。Sidekiqの管理パネルには、/admin/sidekiq のエンドポイントURIでアクセスできます。

    • Railsプロセスを使って同期的にジョブを実行します：

       def process(concurrency: 1)
   queue = Queue.new
      
   Gitlab::Database::BackgroundMigrationJob
     .where(class_name: 'MigrateMergeRequestDiffCommitUsers', status: 0)
     .each { |job| queue << job }
      
   concurrency
     .times
     .map do
       Thread.new do
         Thread.abort_on_exception = true
      
         loop do
           job = queue.pop(true)
           time = Benchmark.measure do
             Gitlab::BackgroundMigration::MigrateMergeRequestDiffCommitUsers
               .new
               .perform(*job.arguments)
           end
      
           puts "#{job.id} finished in #{time.real.round(2)} seconds"
         rescue ThreadError
           break
         end
       end
     end
     .each(&:join)
 end
      
 ActiveRecord::Base.logger.level = Logger::ERROR
 process
      note
      Railsを使ってこれらのバックグラウンドマイグレーションを同期的に実行する場合は、プロセスを実行しているマシンにタスクを処理するのに十分なリソースがあることを確認してください。プロセスが終了してしまう場合は、利用可能なメモリが不足している可能性があります。しばらくしてSSHセッションがタイムアウトした場合は、screen やtmux のようなターミナルマルチプレクサを使って前のコードを実行する必要があるかもしれません。

  • GitLab 13.9から14.4のメンテナンスモードのイシューをご覧ください。

  • LDAPパスワードを使用して認証するアカウントに二要素認証（2FA）を設定する際に、以下のエラーが表示されることがあります：

     You must provide a valid current password
    • このエラーは、LDAPパスワードではなく、アカウントのGitLab内部でランダムに生成されたパスワードに対して検証が誤って行われたために発生します。
    • これはGitLab 14.5.0で修正され、14.4.3にバックポートされました。
    • 回避策
      • GitLab 14.3.xにアップグレードする代わりに、サポートされているアップグレードパスに従います：
        1. 14.4.5にアップグレードしてください。
        2. MigrateMergeRequestDiffCommitUsers バックグラウンドマイグレーション が終了していることを確認してください。
        3. GitLab 14.5 以降にアップグレードしてください。

      • Rake タスクを使用して、影響を受けるアカウントのランダムパスワードをリセットします：

         sudo gitlab-rake "gitlab:password:reset[user_handle]"
  • アプリケーションの起動時にI18n::InvalidLocale: :en is not a valid locale というエラーが発生した場合は、パッチの適用手順に従ってください。mr_iidとして122978を使用してください。

14.2.0

14.1.0

  • 14.0.0～14.0.4を実行しているインスタンスは、GitLab 14.2以降に直接アップグレードすべきではありませんが、14.1.Zにアップグレードすることは可能です。

    すでに14.0.5（またはそれ以降）が稼働しているインスタンスは、14.1.Zで停止する必要はありません。14.1は、セルフマネージドインストールとの幅広い互換性のためにアップグレードパスに含まれており、14.0.0～14.0.4のインストールがバッチバックグラウンドマイグレーションで問題が発生しないようにしています。

  • GitLab14.5(またはそれ以降) へのアップグレードは、少なくとも 14.1 に最初にアップグレードしないと、かなり時間がかかるかもしれません。14.1のマージリクエスト差分コミットデータベースマイグレーションは実行に数時間かかることがありますが、GitLabが使用されている間はバックグラウンドで実行されます。14.0から14.5以降に直接アップグレードされたGitLabインスタンスはフォアグラウンドでマイグレーションを実行しなければならず、そのため完了までに多くの時間がかかります。

  • GitLab 13.9から14.4のメンテナンスモードのイシューをご覧ください。

  • アプリケーションの起動時にI18n::InvalidLocale: :en is not a valid locale というエラーが発生した場合は、パッチの適用手順に従ってください。mr_iidとして123475を使用してください。

14.0.0

前提条件：

バックグラウンドデータベースのマイグレーションを長時間バッチ処理できるようになりました：

  • GitLab 14.0へのアップグレードによるデータベースの変更は、大規模なGitLabインスタンスでは完了までに数時間から数日かかることがあります。これらのバッチバックグラウンドマイグレーションは、プライマリキーのオーバーフローを緩和するためにデータベースのテーブル全体を更新し、GitLab 14.2以降にアップグレードする前に終了する必要があります。

  • BatchedBackgroundMigrationWorkers 、セルフマネージドインスタンスで動作しないイシューがあったため、少なくとも14.0.5へのアップデートを必要とする修正が作成されました。この修正は14.1.0でもリリースされました。

    14.0.5またはそれ以降の14.0パッチバージョンにアップデートした後、バッチバックグランドマイグレーションを終了してから、それ以降のバージョンにアップグレードする必要があります。

    マイグレーションが終了しておらず、それ以降のバージョンにアップグレードしようとすると、次のようなエラーが表示されます：

     Expected batched background migration for the given configuration to be marked as 'finished', but it is 'active':

    このエラーの解決方法を参照してください。

その他のイシュー

Linux パッケージのインストール

  • GitLab 13.0では、sidekiq-cluster がデフォルトで有効になっており、sidekiq サービスがsidekiq-cluster をアンダーグラウンドで実行していました。しかし、ユーザーはsidekiq['cluster'] の設定を使ってこの動作を制御し、代わりにSidekiqを直接実行することができます。また、gitlab.rbで利用可能な様々なsidekiq_cluster[*] 設定を使って、sidekiq-cluster を個別に実行することもできました。しかし、これらの機能は非推奨となり、現在は削除されています。

    GitLab 14.0から、sidekiq-cluster 、LinuxパッケージインストールでSidekiqを実行する唯一の方法になります。このプロセスの一環として、gitlab.rb の以下の設定のサポートが削除されます：

    • sidekiq['cluster'] 設定。Sidekiqは現在sidekiq-cluster 。
    • sidekiq_cluster[*] 設定を変更する必要があります。これらの設定は、それぞれのsidekiq[*] 。
    • sidekiq['concurrency'] 設定。リミットはsidekiq['min_concurrency'] とsidekiq['max_concurrency'] の2つの設定を使用して制御する必要があります。

  • GitLab 13.0では、PumaがGitLabのデフォルトのウェブサーバーとなりましたが、ユーザーは必要に応じてUnicornを使い続けることができました。GitLab 14.0から、UnicornはGitLabのウェブサーバーとしてサポートされなくなり、Linuxパッケージには同梱されなくなりました。

    ユーザーはGitLab 14.0にアップグレードするためのドキュメントに従ってPumaにマイグレーションする必要があります。

  • Geoと複数ノードのPostgreSQLインストール用に、Consulのバージョンが1.6.10から1.9.6に更新されました。Consulノードのアップグレードと再起動は1つずつ行うことがインポートです。

    詳細は Consul ノードのアップグレード を参照してください。

  • GitLab 14.0 から、GitLab は初期管理者ユーザー (root) のパスワードを自動的に生成し、この値を/etc/gitlab/initial_root_password に保存します。

    詳しくは、初期パスワードの設定をご覧ください。

  • PostgreSQL 11 と repmgr のバイナリが削除されました。アップグレードの前に、Linux パッケージインストールの管理者は次のことを行う必要があります：
    1. インストールがPostgreSQL 12 を使用していることを確認してください。
    2. repmgrを使用している場合は、patroniを使用するように変換してください。

  • Redisの2つの設定オプションはGitLab 13で非推奨となり、GitLab 14では削除されました：

    • redis_slave_role はredis_replica_role に置き換えてください。
    • redis['client_output_buffer_limit_slave'] はredis['client_output_buffer_limit_replica'] に置き換えてください。

    GitLab 13.12 から 14.0 にアップグレードする Redis Cache ノードで、gitlab.rb のredis_slave_role を参照している場合、gitlab-ctl reconfigure の出力でエラーが発生します：

     There was an error running gitlab-ctl reconfigure:
   
 The following invalid roles have been set in 'roles': redis_slave_role

14.Y以降のリリースへのアップグレード