GitLab 16 の変更点

このPagesはGitLab 16のマイナーバージョンとパッチバージョンのアップグレード情報を含んでいます。これらの説明をレビューしてください：

  • インストールの種類。
  • 現在のバージョンとターゲットバージョン間のすべてのバージョン。

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

15.11 からのアップグレードで注意すべきイシュー

  • 一部のGitLabインストールでは、他のバージョンにアップグレードする前にGitLab 16.0にアップグレードする必要があります。詳しくはLong-running user type data changeをご覧ください。
  • 他のインストールでは、アップグレードパスで最初に必要なのは16.3なので、16.0、16.1、16.2をスキップすることができます。これらの中間バージョンのノートをレビューしてください。
  • GitLabインスタンスが最初に15.11.0、15.11.1、15.11.2にアップグレードした場合、データベーススキーマが正しくありません。推奨：16.xにアップグレードする前に回避策を実行してください。

16.4.0

  • グループパスを更新すると、16.3で導入されたデータベースインデックスを使用するバグ修正が適用されました。

    16.3より低いバージョンから16.4にアップグレードする場合は、使用前にデータベースでANALYZE packages_packages; 。

16.3.0

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

Linuxパッケージのインストールには特定の情報が適用されます：

  • GitLab 16.0では、新しいバージョンのOpenSSH Serverを含むアップグレードされたベースDockerイメージを発表しました。新バージョンの意図しない結果として、SSH RSA SHA-1署名をデフォルトで受け付けなくなりました。このイシューは、非常に古い SSH クライアントを使用しているユーザーにのみ影響するはずです。

    アップストリームライブラリではセキュリティ上の理由から SHA-1 シグネチャの使用を推奨していないためです。

    GITLAB_ALLOW_SHA1_RSA ユーザーがすぐにSSHクライアントをアップグレードできない移行期間を考慮し、GitLab 16.3以降では環境変数Dockerfile 。GITLAB_ALLOW_SHA1_RSA をtrue に設定すると、この非推奨のサポートが再活性化されます。

    セキュリティのベストプラクティスを育成し、アップストリームの推奨に従いたいので、この環境変数はGitLab 17.0までしか利用できません。

    詳細については

16.2.0

  • レガシー LDAP 設定により、NoMethodError: undefined method 'devise' for User:Class エラーが発生することがあります。このエラーは、tls_options ハッシュで指定されていない TLS オプション (ca_file など) があるか、レガシーのgitlab_rails['ldap_host'] オプションを使用している場合に発生します。詳細は設定の回避策を参照してください。
  • ジョブアーティファクトがオブジェクトストレージに保存されるように設定され、direct_upload が有効になっている場合、新しいジョブアーティファクトが複製されません。このバグはGitLabバージョン16.1.4、16.2.3、16.3.0以降で修正されています。
    • 影響を受けるバージョンGitLab バージョン 16.1.0 - 16.1.3 および 16.2.0 - 16.2.2.
    • 影響を受けるバージョンをデプロイした場合、修正されたGitLabバージョンにアップグレードした後、影響を受けるジョブのアーティファクトを再同期するには、以下の手順に従ってください。

  • GitLabデータベースがバージョン15.11.0～15.11.2で作成された、またはバージョン15.11.2経由でアップグレードされた場合、GitLab 16.2へのアップグレードに失敗します：

     PG::UndefinedColumn: ERROR:  column "id_convert_to_bigint" of relation "ci_build_needs" does not exist
 LINE 1: ...db_config_name:main*/ UPDATE "ci_build_needs" SET "id_conver...

    詳細と回避策をご覧ください。

  • GitLab 16.2以降へのアップグレード中に以下のエラーが発生する可能性があります：

     main: == 20230620134708 ValidateUserTypeConstraint: migrating =======================
 main: -- execute("ALTER TABLE users VALIDATE CONSTRAINT check_0dd5948e38;")
 rake aborted!
 StandardError: An error has occurred, all later migrations canceled:
 PG::CheckViolation: ERROR:  check constraint "check_0dd5948e38" of relation "users" is violated by some row

    詳細はイシュー421629をご覧ください。

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

Linuxパッケージのインストールには特定の情報が適用されます：

  • 16.2 では、Redis を 6.2.11 から 7.0.12 にアップグレードします。このアップグレードには完全な後方互換性があります。

    Redisはgitlab-ctl reconfigure の一部として自動的に再起動されるわけではありません。したがって、新しいRedisバージョンが使用されるように、ユーザーはreconfigureの実行後にsudo gitlab-ctl restart redis を手動で実行する必要があります。インストールされているRedisのバージョンが実行中のものと異なることを示す警告は、再起動が実行されるまで、reconfigureの実行の最後に表示されます。

    インスタンスにSentinel付きのRedis HAがある場合は、Zero Downtimeドキュメントに記載されているアップグレード手順に従ってください。

セルフコンパイルによるインストール

16.1.0

  • BackfillPreparedAtMergeRequests バックグラウンドマイグレーションは、FinalizeBackFillPreparedAtMergeRequests ポストデプロイマイグレーションで確定されます。GitLab 15.10.0では、prepared_at の値をmerge_requests テーブルに埋め戻すバッチバックグラウンドマイグレーションを導入しました。このマイグレーションは、大規模なGitLabインスタンスでは完了までに数日かかることがあります。16.1.0にアップグレードする前に、マイグレーションが正常に完了したことを確認してください。
  • ジョブアーティファクトがオブジェクトストレージに保存されるように設定され、direct_upload が有効になっている場合、新しいジョブアーティファクトが複製されません。このバグはGitLabバージョン16.1.4、16.2.3、16.3.0以降で修正されています。
    • 影響を受けるバージョンGitLab バージョン 16.1.0 - 16.1.3 および 16.2.0 - 16.2.2.
    • 影響を受けるバージョンをデプロイした場合、修正されたGitLabバージョンにアップグレードした後、影響を受けるジョブのアーティファクトを再同期するには、以下の手順に従ってください。

セルフコンパイルによるインストール

  • puma.rb 設定ファイルから Puma ワーカーキラーに関連する設定が削除されているため、削除する必要があります。詳しくは、puma.rb.example ファイルを参照してください。

Geo インストール

特定の情報は、Geoを使用したインストールに適用されます：

  • いくつかのプロジェクトインポートはプロジェクト作成時にWikiリポジトリを初期化しません。プロジェクトWikiのSSFへのマイグレーションにより、見つからないWikiリポジトリが検証失敗として誤ってフラグされます。このイシューは実際のレプリケーション/検証の失敗の結果ではなく、Geo内部でこれらの欠落したリポジトリの内部状態が無効であるため、ログや検証の進捗でこれらのWikiリポジトリの失敗状態を報告するエラーが発生します。プロジェクトをインポートしていない場合は、このイシューの影響を受けません。
    • 影響を受けるバージョンGitLab バージョン 15.11.x、16.0.x、16.1.0 - 16.1.2。
    • 修正を含むバージョン：GitLab 16.1.3 以降。
  • プロジェクト設計の SSF へのマイグレーションにより、設計リポジトリが見つからない場合、検証に失敗したものとして誤ってフラグが立てられます。このイシューは、実際のレプリケーション/検証の失敗の結果ではなく、Geo 内部のこれらの欠落したリポジトリの内部状態が無効であるため、ログや検証の進捗でこれらのデザイン・リポジトリの失敗状態を報告するエラーになります。プロジェクトをインポートしていなくても、このイシューの影響を受ける可能性があります。
    • 影響を受けるバージョンGitLab バージョン 16.1.0 - 16.1.2
    • 修正を含むバージョン：GitLab 16.1.3 以降。

16.0.0

  • /etc/gitlab/gitlab.rb ファイルに非 ASCII 文字があると、Sidekiq がクラッシュしました。イシュー 412767の回避策に従ってください。
  • Sidekiqジョブは、デフォルトでdefault およびmailers キューにのみルーティングされ、その結果、すべてのSidekiqプロセスは、すべてのジョブがすべてのキューで処理されるように、これらのキューもリッスンします。ルーティングルールを設定した場合は、この動作は適用されません。
  • GitLab Dockerイメージを実行するには、Docker 20.10.10以降が必要です。それ以前のバージョンでは起動時にエラーが発生します。
  • 16.0から、GitLabセルフマネージドインストールはデフォルトで2つのデータベース接続を持つようになりました。この変更により、PostgreSQLの接続数が2倍になりました。これにより、GitLabのセルフマネージドバージョンはGitLab.comと同様の動作をするようになり、GitLabのセルフマネージドバージョンのCI機能のために別のデータベースを有効にするための一歩となります。16.0にアップグレードする前に、PostgreSQLの最大接続数を増やす必要があるかどうかを判断してください。
    • この変更は、Linuxパッケージ（Omnibus）、GitLab Helmチャート、GitLab Operator、GitLab Dockerイメージ、セルフコンパイルによるインストール方法に適用されます。

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

Linuxパッケージのインストールには特定の情報が適用されます：

  • PostgreSQL 12のバイナリは削除されました。

    Linux パッケージインストールの管理者は、アップグレードする前に、インストールがPostgreSQL 13 を使用していることを確認する必要があります。

  • バンドルされていたGrafanaは非推奨となり、サポートされなくなりました。GitLab 16.3で削除されました。

    詳しくは非推奨ノートをご覧ください。

  • これにより、openssh-server が1:8.9p1-3 にアップグレードされます。

    古い OpenSSH クライアントでssh-keyscan -t rsa を使って公開鍵情報を取得することは、OpenSSH 8.7 リリースノートに記載されている非推奨事項のため、もはや実行できません。

    回避策としては、別の鍵タイプを使うか、クライアントの OpenSSH をバージョン >= 8.7 にアップグレードすることです。

Geo インストール

特定の情報は、Geoを使用したインストールに適用されます：

  • いくつかのプロジェクトインポートはプロジェクト作成時にWikiリポジトリを初期化しません。プロジェクトWikiのSSFへのマイグレーションにより、見つからないWikiリポジトリが検証失敗として誤ってフラグされます。このイシューは実際のレプリケーション/検証の失敗の結果ではなく、Geo内部でこれらの欠落したリポジトリの内部状態が無効であるため、ログや検証の進捗でこれらのWikiリポジトリの失敗状態を報告するエラーが発生します。プロジェクトをインポートしていない場合は、このイシューの影響を受けません。

    • 影響を受けるバージョンGitLab バージョン 15.11.x、16.0.x、16.1.0 - 16.1.2。
    • 修正を含むバージョン：GitLab 16.1.3 以降。

長く続いたユーザータイプのデータ変更

GitLab 16.0は、users テーブルに多くのレコードがある大規模なGitLabインスタンスには必須停止です。

しきい値は30,000ユーザーで、これには以下が含まれます：

  • アクティブ、ブロック、承認待ちを含む、あらゆる状態の開発者やその他のユーザ。
  • プロジェクトやグループのアクセストークン用のボットアカウント。

GitLab 16.0では、 user_type の値をNULL から0にマイグレーションするバッチバックグラウンドマイグレーションが導入されました。 このマイグレーションは、大規模なGitLabインスタンスでは完了までに複数日かかる場合があります。16.1.0以降にアップグレードする前に、マイグレーションが正常に完了したことを確認してください。

GitLab 16.1では、FinalizeUserTypeMigration マイグレーションが導入され、16.0のMigrateHumanUserType バックグラウンドマイグレーションが完了していることを確認し、完了していない場合はアップグレード中に16.0の変更を同期させます。

GitLab 16.2はNOT NULL データベース制約 を実装し、16.0 マイグレーションが完了していないと失敗します。

16.0がスキップされた場合（または16.0のマイグレーションが完了していない場合）、その後のLinuxパッケージ（Omnibus）とDockerのアップグレードが1時間後に失敗する可能性があります：

FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails]
[..]
Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:

このイシューにはフィックスフォワード・ワークアラウンドがあります。

回避策によってデータベースの変更が完了している間、GitLabは使用できない状態になり、500 エラーが発生する可能性があります。このエラーは、SidekiqとPumaがデータベーススキーマと互換性のないアプリケーションコードを実行しているために発生します。

回避プロセスの最後に、SidekiqとPumaを再起動してイシューを解決します。

16.2以降へのアップグレードで未定義列エラー

GitLab 15.11 のバグにより、セルフマネージドインスタンスでデータベースの変更が不正に無効化されていました。詳細については、イシュー 408835 を参照してください。

GitLabインスタンスが最初に15.11.0、15.11.1、15.11.2にアップグレードされた場合、データベーススキーマが正しくなく、GitLab 16.2以降へのアップグレードがエラーで失敗します。データベースの変更には、以前の変更が必要です：

PG::UndefinedColumn: ERROR:  column "id_convert_to_bigint" of relation "ci_build_needs" does not exist
LINE 1: ...db_config_name:main*/ UPDATE "ci_build_needs" SET "id_conver...

GitLab 15.11.3ではこのバグが修正されましたが、すでに15.11以前のリリースを実行しているインスタンスではこの問題は修正されません。

インスタンスが影響を受けているかどうかわからない場合は、データベースコンソールでカラムを確認してください：

select pg_typeof (id_convert_to_bigint) from public.ci_build_needs limit 1;

回避策が必要な場合、このクエリは失敗します：

ERROR:  column "id_convert_to_bigintd" does not exist
LINE 1: select pg_typeof (id_convert_to_bigintd) from public.ci_buil...

影響を受けないインスタンスが返されます：

 pg_typeof
-----------
 bigint

GitLabインスタンスのデータベーススキーマが最近作成されたものである場合、このイシューの回避策は異なります：

インストールバージョン回避策
15.9以前15.9
15.1015.10
15.1115.11

ほとんどのインスタンスでは15.9の手続きを使用します。15.10または15.11プロシージャが必要なのは、ごく新しいインスタンスだけです。バックアップと復元を使用してGitLabをマイグレーションした場合、データベーススキーマは元のインスタンスに由来します。移行元のインスタンスに基づいて回避策を選択してください。

以下のセクションのコマンドはLinuxパッケージインストール用のもので、他のインストールタイプでは異なります：

Docker
  • 省略sudo

  • GitLab コンテナにシェルで入り、同じコマンドを実行します：

     docker exec -it <container-id> bash
Self-compiled (source)
Helm chart (Kubernetes)

回避策: 15.9 以前で作成されたインスタンス 

# Restore schema
sudo gitlab-psql -c "DELETE FROM schema_migrations WHERE version IN ('20230130175512', '20230130104819');"
sudo gitlab-rake db:migrate:up VERSION=20230130175512
sudo gitlab-rake db:migrate:up VERSION=20230130104819

# Re-schedule background migrations
sudo gitlab-rake db:migrate:down VERSION=20230130202201
sudo gitlab-rake db:migrate:down VERSION=20230130110855
sudo gitlab-rake db:migrate:up VERSION=20230130202201
sudo gitlab-rake db:migrate:up VERSION=20230130110855

回避策：15.10で作成されたインスタンス 

# Restore schema for sent_notifications
sudo gitlab-psql -c "DELETE FROM schema_migrations WHERE version = '20230130175512';"
sudo gitlab-rake db:migrate:up VERSION=20230130175512

# Re-schedule background migration for sent_notifications
sudo gitlab-rake db:migrate:down VERSION=20230130202201
sudo gitlab-rake db:migrate:up VERSION=20230130202201

# Restore schema for ci_build_needs
sudo gitlab-rake db:migrate:down VERSION=20230321163547
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230321163547');"

回避策：15.11で作成したインスタンス 

# Restore schema for sent_notifications
sudo gitlab-rake db:migrate:down VERSION=20230411153310
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230411153310');"

# Restore schema for ci_build_needs
sudo gitlab-rake db:migrate:down VERSION=20230321163547
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230321163547');"