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

GitLab 18アップグレードノート

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

このページでは、GitLab 18のマイナーバージョンとパッチバージョンのアップグレード情報を提供します。以下の条件を考慮して、各手順を確認してください:

  • お使いのインストールタイプ。
  • 現在のバージョンから移行先バージョンまでのすべてのバージョン。

Helmチャートのインストールの詳細については、Helmチャート9.0のアップグレードノートを参照してください。

必須アップグレードストップ

インスタンス管理者に予測可能なアップグレードスケジュールを提供するために、必須アップグレードストップは、以下のバージョンで発生します:

  • 18.2
  • 18.5
  • 18.8
  • 18.11

17.11からのアップグレード時に注意すべき問題

  • PostgreSQL 14は、GitLab 18以降ではサポートされていません。GitLab 18.0以降にアップグレードする前に、PostgreSQLを少なくともバージョン16.8にアップグレードしてください。

    自動データベースバージョンアップグレードは、Linuxパッケージを使用している単一ノードインスタンスにのみ適用されます。それ以外のケース、たとえばGeoインスタンス、Linuxパッケージを使用した高可用性のPostgreSQLデータベース、または外部PostgreSQLデータベース（Amazon RDSなど）を使用している場合は、PostgreSQLを手動でアップグレードする必要があります。詳細な手順については、Geoインスタンスをアップグレードするを参照してください。

  • 2025年9月29日以降、Bitnamiはタグ付きのPostgreSQLおよびRedisイメージの提供を終了します。GitLabチャートを使用し、RedisまたはPostgresをバンドルしたGitLab 17.11以前をデプロイしている場合は、予期しないダウンタイムを防ぐために、レガシーリポジトリを使用するように値を手動で更新する必要があります。詳細については、イシュー6089を参照してください。

  • 既知の問題: 機能フラグci_only_one_persistent_ref_creationにより、RailsがアップグレードされてもSidekiqがバージョン17.11のままの場合、ゼロダウンタイムアップグレード中にパイプラインが失敗することがあります（詳細はイシュー558808を参照してください）。

    予防策: アップグレードする前に、Railsコンソールを開き、機能フラグを有効にします:

    $ sudo gitlab-rails console
Feature.enable(:ci_only_one_persistent_ref_creation)

    すでに影響を受けている場合: 次のコマンドを実行して、失敗したパイプラインを再試行します:

    $ sudo gitlab-rails console
Rails.cache.delete_matched("pipeline:*:create_persistent_ref_service")

18.5.0

  • 20250922202128_finalize_correct_design_management_designs_backfillは、18.4でスケジュールされたバッチバックグラウンド移行を完了させるデプロイ後の移行です。アップグレードパスで18.4をスキップした場合、この移行はデプロイ後の移行時に完全に実行されます。実行時間は、design_management_designsテーブルのサイズに直接関係します。ほとんどのインスタンスでは移行に2分以上かかることはありませんが、一部の大規模なインスタンスでは、最大で10分ほどかかる場合があります。移行プロセスを中断せず、そのままお待ちください。

18.4.2

Geoで発生していた、no implicit conversion of String into Array (TypeError)というエラーメッセージが表示されレプリケーションイベントが失敗するバグが修正されました。

18.4.1

GitLab 18.4.1、18.3.3、18.2.7では、サービス拒否攻撃を防ぐためにJSON入力に対する制限が導入されました。GitLabは、これらの制限を超えるHTTPリクエストに対して400 Bad Requestステータスで応答します。詳細については、HTTPリクエスト制限を参照してください。

18.4.0

  • Geoセカンダリサイトで、バグにより、no implicit conversion of String into Array (TypeError)というエラーメッセージが表示され、レプリケーションイベントが失敗します。再検証などの冗長性機能によって最終的な整合性は確保されますが、目標リカバリー時点が大幅に長くなります。影響を受けるバージョン: 18.4.0および18.4.1。

18.3.0

GitLab Duo

  • 新しいワーカーLdapAddOnSeatSyncWorkerが導入されました。これにより、LDAPが有効になっている場合、毎晩、GitLab Duoシートからすべてのユーザーが誤って削除される可能性がありました。この問題はGitLab 18.4.0および18.3.2で修正されました。詳細については、イシュー565064を参照してください。

Geoインストール18.3.0

  • Geoセカンダリサイトをインストールするに際に、rake gitlab:geo:checkが誤って失敗を報告する原因となっていたイシューが18.3.0で修正されました。
  • GitLab 18.3.0には、長いファイル名を持つPagesデプロイでGeo検証が失敗する可能性のあったイシュー559196の修正が含まれています。この修正により、Geoセカンダリサイトでのファイル名のトリミングが防止され、レプリケーションおよび検証時の一貫性が維持されます。

18.2.0

ゼロダウンタイムアップグレード

  • 18.1.xから18.2.xへのアップグレードでは、既知のイシュー567543の影響により、アップグレード中に既存プロジェクトへのコードのプッシュでエラーが発生します。バージョン18.1.xから18.2.xへのアップグレード中にダウンタイムを発生させないようにするには、修正を含むバージョン18.2.6に直接アップグレードします。

Geoインストール18.2.0

  • このバージョンでは、ci_job_artifact_statesの主キーの変更により、VerificationStateBackfillServiceの実行時に発生する既知の問題があります。解決するには、GitLab 18.2.2以降にアップグレードしてください。
  • GitLab 18.2.0には、長いファイル名を持つPagesデプロイでGeo検証が失敗する可能性のあったイシュー559196の修正が含まれています。この修正により、Geoセカンダリサイトでのファイル名のトリミングが防止され、レプリケーションおよび検証時の一貫性が維持されます。

18.1.0

  • Elasticsearchバージョン7では、Elasticsearchのインデックス作成時にstrict_dynamic_mapping_exceptionエラーが発生して失敗する可能性があります。解決するには、イシュー566413の「Possible fixes」セクションを参照してください。
  • GitLabバージョン18.1.0および18.1.1では、PostgreSQLログにERROR: relation "ci_job_artifacts" does not exist at ...のようなエラーが表示されることがあります。これらのログ上のエラーは無視しても問題ありませんが、Geoサイトを含め、モニタリングアラートがトリガーされる可能性があります。この問題を解決するには、GitLab 18.1.2以降にアップデートしてください。

Geoインストール18.1.0

  • GitLabバージョン18.1.0には、セカンダリGeoサイトからプロキシされたGit操作がHTTP 500エラーで失敗するという既知の問題があります。解決するには、GitLab 18.1.1以降にアップグレードしてください。
  • このバージョンでは、ci_job_artifact_statesの主キーの変更により、VerificationStateBackfillServiceの実行時に発生する既知の問題があります。解決するには、GitLab 18.1.4にアップグレードしてください。
  • GitLab 18.1.0には、長いファイル名を持つPagesデプロイでGeo検証が失敗する可能性のあったイシュー559196の修正が含まれています。この修正により、Geoセカンダリサイトでのファイル名のトリミングが防止され、レプリケーションおよび検証時の一貫性が維持されます。

18.0.0

git_data_dirsからstorageにGitaly設定を移行する

GitLab 18.0以降では、git_data_dirs設定を使用してGitalyストレージの場所を設定できなくなりました。

依然としてgit_data_dirsを使用している場合は、GitLab 18.0にアップグレードする前にGitaly設定を移行する必要があります。

Geoインストール18.0.0

  • GitLab Enterprise Editionをデプロイした後にGitLab Community Editionに戻した場合、データベーススキーマがGitLabアプリケーションで想定されているスキーマと異なることがあり、移行エラーが発生する可能性があります。18.0.0へのアップグレード時には、このバージョンで追加された移行によって特定の列のデフォルトが変更されるため、4種類のエラーが発生する可能性があります。

    発生するエラーは次のとおりです:

    • No such column: geo_nodes.verification_max_capacity
    • No such column: geo_nodes.minimum_reverification_interval
    • No such column: geo_nodes.repos_max_capacity
    • No such column: geo_nodes.container_repositories_max_capacity

    この移行には、これらの列が欠落している場合に追加するためのパッチがGitLab 18.0.2で適用されました。イシュー543146を参照してください。

    影響を受けるリリース:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    18.018.0.0 - 18.0.118.0.2

  • GitLabバージョン18.0から18.0.2には、セカンダリGeoサイトからプロキシされたGit操作がHTTP 500エラーで失敗するという既知の問題があります。解決するには、GitLab 18.0.3以降にアップグレードしてください。

  • このバージョンでは、ci_job_artifact_statesの主キーの変更により、VerificationStateBackfillServiceの実行時に発生する既知の問題があります。解決するには、GitLab 18.0.6にアップグレードしてください。

DockerインストールでのPRNG is not seededエラー

FIPSが有効なホスト上でDockerインストール環境のGitLabを実行している場合、SSHキーの生成やOpenSSHサーバー（sshd）の起動が失敗し、次のエラーメッセージが表示されることがあります:

PRNG is not seeded

GitLab 18.0では、ベースイメージをUbuntu 22.04から24.04に更新しました。このエラーは、Ubuntu 24.04でFIPSホストが非FIPS OpenSSLプロバイダーを使用できなくなったことが原因で発生します。

この問題を解決するには、いくつかのオプションがあります:

  • ホストシステムでFIPSを無効にする。
  • GitLab Dockerコンテナ内でFIPSベースのカーネルの自動検出を無効にする。これは、GitLab 18.0.2以降でOPENSSL_FORCE_FIPS_MODE=0環境変数を設定することで実行できます。
  • GitLab Dockerイメージを使用する代わりに、ホスト上にネイティブのFIPSパッケージをインストールする。

最後のオプションが、FIPS要件を満たすための推奨手順です。レガシーインストールの場合は、最初の2つのオプションを一時的な対処方法として使用できます。