- 15.11 からのアップグレードで注意すべきイシュー
- 16.4.0
- 16.3.0
- 16.2.0
- 16.1.0
- 16.0.0
- 長く続いたユーザータイプのデータ変更
- 16.2以降へのアップグレードで未定義列エラー
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
-
Goアプリケーションでは、
crypto/tls
: 大きなRSAキーを含む証明書チェーンの検証に時間がかかる(CVE-2023-29409) 、RSAキーに8192ビットというハードリミットが導入されました。GitLabのGoアプリケーションの設定では、RSAキーは以下のように設定できます:アップグレードする前に、上記のアプリケーションの RSA 鍵 (
openssl rsa -in <your-key-file> -text -noout | grep "Key:"
) のサイズを確認してください。
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までしか利用できません。
詳細については
- OpenSSH 8.8 リリースノート をご覧ください。
- 非公式な説明です。
-
omnibus-gitlab
マージリクエスト 7035で環境変数が導入されました。
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ドキュメントに記載されているアップグレード手順に従ってください。
セルフコンパイルによるインストール
- GitalyではGit 2.41.0以降が必要です。Gitalyが提供するGitバージョンをご利用ください。
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.10 | 15.10 |
15.11 | 15.11 |
ほとんどのインスタンスでは15.9の手続きを使用します。15.10または15.11プロシージャが必要なのは、ごく新しいインスタンスだけです。バックアップと復元を使用してGitLabをマイグレーションした場合、データベーススキーマは元のインスタンスに由来します。移行元のインスタンスに基づいて回避策を選択してください。
以下のセクションのコマンドはLinuxパッケージインストール用のもので、他のインストールタイプでは異なります:
- 省略
sudo
-
GitLab コンテナにシェルで入り、同じコマンドを実行します:
docker exec -it <container-id> bash
- の代わりに
sudo -u git -H bundle exec rake
を使用します。sudo gitlab-rake
- PostgreSQLデータベースコンソールでSQLを実行します。
-
sudo
を省略してください。 - Rakeコマンドを実行するために、
toolbox
ポッドにShellを入れます。gitlab-rake
がPATH
にない場合は、/usr/local/bin
にあります。- 詳細はKubernetesチートシートを参照してください。
- PostgreSQLデータベースコンソールでSQLを実行します。
回避策: 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');"