GitLab 15特有の変更点

note
新しいメジャーバージョンにアップグレードする際には、まずバックグラウンドマイグレーションをチェックすることを忘れないでください。

15.11

PostgreSQL 13のアップグレード

GitLab 15.11では、以下の場合を除き、PostgreSQLは自動的に13.xにアップグレードされます:

  • Patroni を使用してデータベースを高可用性で実行している場合。
  • データベースノードはGitLab Geo設定の一部です。
  • あなたは特にオプトアウトしています。
  • postgresql['version'] = 12gitlab.rb

フォールトトレラントおよびGeoインストールはPostgreSQL 13への手動アップグレードをサポートしています。

15.6

PostgreSQLのバージョン更新

GitLab 15.6 では、omnibus-gitlab パッケージ](https://docs.gitlab.com/ee/administration/package_information/postgresql_versions.html) に同梱されている[PostgreSQL のバージョンが 12.12 と 13.8 にアップグレードされました。明示的にオプトアウトしない限り、これはPostgreSQLサービスの自動再起動を引き起こし、ダウンタイムを引き起こす可能性があります。

15.0

PostgreSQLのバージョン更新

GitLab 15.0では、Linuxパッケージのインストールにはアップグレード用のPostgreSQLバージョン12.10と新規インストール用のPostgreSQLバージョン13.6が同梱されています。根本的な構造が変更されたため、実行中のPostgreSQLプロセスは プロセスはを再起動する必要があります。自動再起動をスキップする場合は、マイグレーションを実行する前に以下のコマンドを実行する必要があります:

# If using PostgreSQL
sudo gitlab-ctl restart postgresql

# If using Patroni for Database replication
sudo gitlab-ctl restart patroni

PostgreSQLが再起動されない場合、ライブラリの読み込みに関するエラーに直面する可能性があります。

バージョン変更時のPostgreSQLサービスの自動再起動

GitLab 15.0から、PostgreSQLのバージョンが変更されると、postgresqlgeo-postgresql サービスが自動的に再起動されるようになりました。PostgreSQLサービスを再起動すると、一時的にデータベースをオペレーションに利用できなくなるため、ダウンタイムが発生します。この再起動はDatabaseサービスを適切に機能させるためには必須ですが、PostgreSQLが再起動されるタイミングをもっと制御したいと思うかもしれません。そのためには、gitlab-ctl reconfigure の一部として自動再起動をスキップし、手動でサービスを再起動することができます。

GitLab 15.0 アップグレードの一部として自動再起動をスキップするには、アップグレードの前に以下の手順を実行してください:

  1. /etc/gitlab/gitlab.rb を編集し、以下の行を追加します:

    # For PostgreSQL/Patroni
    postgresql['auto_restart_on_version_change'] = false
       
    # For Geo PostgreSQL
    geo_postgresql['auto_restart_on_version_change'] = false
    
  2. GitLab を再設定します:

    sudo gitlab-ctl reconfigure
    
note
必要なライブラリのロードに関連するような、ダウンタイムの原因となるエラーを避けるために、PostgreSQLの基礎となるバージョンが変更された際には、PostgreSQLを再起動することが必須です。そのため、上記の方法で自動再起動をスキップした場合、GitLab 15.0にアップグレードする前に手動でサービスを再起動するようにしてください。

NGINXでAES256-GCM-SHA384 SSL暗号がデフォルトで許可されなくなりました。

GitLab 15.0から、AES256-GCM-SHA384 SSL暗号はNGINXによってデフォルトで許可されなくなりました。この暗号が必要な場合(AWSのClassic Load Balancerを使用している場合など)、以下の手順で暗号を許可リストに戻すことができます:

  1. /etc/gitlab/gitlab.rb を編集し、次の行を追加します:

    nginx['ssl_ciphers'] = "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:AES256-GCM-SHA384"
    
  2. sudo gitlab-ctl reconfigure を実行してください。

Gitaly内部ソケットパスのサポートの削除

GitLab 14.10で、GitalyはGitalyが正しくオペレーションするために必要なすべてのランタイムデータを保持する新しいディレクトリを導入しました。この新しいディレクトリは古い内部ソケットディレクトリを置き換えるもので、その結果、gitaly['internal_socket_dir'] の使用は非推奨となり、gitaly['runtime_dir'] の使用が推奨されるようになりました。

古いgitaly['internal_socket_dir'] の設定は、このリリースで削除されました。

PostgreSQL 13.6のサポート

PostgreSQL 13.6は新規インストールのデフォルトバージョンとして出荷されます。

ユーザはアップグレードのドキュメントに従って手動で13.6にアップグレードすることができます。

オブジェクトストレージのバックグラウンドアップロード設定を削除しました。

オブジェクトストレージは直接アップロードを優先的に使用するようになりました。

以下のキーはgitlab.rb でサポートされなくなりました:

  • gitlab_rails['artifacts_object_store_direct_upload']
  • gitlab_rails['artifacts_object_store_background_upload']
  • gitlab_rails['external_diffs_object_store_direct_upload']
  • gitlab_rails['external_diffs_object_store_background_upload']
  • gitlab_rails['lfs_object_store_direct_upload']
  • gitlab_rails['lfs_object_store_background_upload']
  • gitlab_rails['uploads_object_store_direct_upload']
  • gitlab_rails['uploads_object_store_background_upload']
  • gitlab_rails['packages_object_store_direct_upload']
  • gitlab_rails['packages_object_store_background_upload']
  • gitlab_rails['dependency_proxy_object_store_direct_upload']
  • gitlab_rails['dependency_proxy_object_store_background_upload']