- オムニバス・パッケージ
- ソースからのインストール
- Dockerを使ったインストール
- ダウンタイムなしのアップグレード
- アップグレード前のバックグラウンド移行のチェック
- 新しいメジャーバージョンへのアップグレード
- エディション間のアップグレード
- バージョン別のアップグレード手順
- その他
GitLab のアップデート
インストール方法やGitLabのバージョンによって、複数のアップデートガイドがあります。
GitLabをインストールするには、現在3つの公式な方法があります：
インストールに応じて、以下のセクションの中からニーズに合ったものを選択してください。
オムニバス・パッケージ
- Omnibusアップデートガイドには、Omnibus GitLabパッケージのアップデートに必要な手順が記載されています。
ソースからのインストール
- Community EditionとEnterprise Editionをソースからアップグレードする- Community EditionとEnterprise Editionをソースからアップグレードするためのガイドラインです。
- パッチバージョンガイドには、6.2.0から6.2.1のようなパッチバージョンに必要な手順が含まれており、Community EditionとEnterprise Editionの両方に適用されます。
以前はアップグレードの手順について別々の文書を使用していましたが、現在はひとつの文書に統一しています。 古いアップグレードガイドラインは、まだ Git リポジトリにあります：
Dockerを使ったインストール
GitLabはCommunity版とEnterprise版の両方で公式のDockerイメージを提供しています。 これらはOmnibusパッケージをベースにしており、アップデート方法は別のドキュメントに記載されています。
ダウンタイムなしのアップグレード
GitLab 9.1.0からは、GitLabインスタンスをオフラインにすることなく、GitLabの新しいメジャーバージョン、マイナーバージョン、パッチバージョンにアップグレードすることができるようになりました。 しかし、これを行うには以下の要件があります：
- 一度にアップグレードできるのは1つのマイナーリリースだけなので、9.1から9.2へのアップグレードは可能ですが、9.3へのアップグレードはできません。
- デプロイ後のマイグレーションを使用する必要があります。
- GitLab12.1からMySQLはサポートされなくなりました。
- マルチノードのGitLabインスタンス。 シングルノードのインスタンスでは、サービスが再起動する際に短時間の中断が発生する可能性があります。
ほとんどの場合、パッチリリースが最新でなくても、パッチリリースから次のマイナーリリースに安全にアップグレードできます。 例えば、9.1.1 から 9.2.0 へのアップグレードは、9.1.2 がリリースされていても安全です。 現在のバージョンとターゲットバージョンの間に、1 リリースずつアップグレードする必要のある移行が含まれている可能性があるので、リリースポストを確認することをお勧めします。
バックグラウンドマイグレーションは、Sidekiqによってバックグラウンドで実行され、データの移行によく使用されます。 バックグラウンドマイグレーションは、毎月のリリースでのみ追加されます。
特定のメジャー/マイナーリリースでは、バックグラウンドマイグレーションを終了する必要がある場合があります。 これを保証するために、そのようなリリースではアップグレード手順を続行する前に残っているジョブを処理します。 (上記の条件が満たされていれば)ダウンタイムは必要ありませんが、メジャー/マイナーリリースのアップグレードの間隔を少なくとも1週間空けて、バックグラウンドマイグレーションが終了するようにすることをお勧めします。これらのマイグレーションを完了するのに必要な時間は、background_migration キュー内のジョブを処理できる Sidekiq ワーカーの数を増やすことで短縮できます。このキューのサイズを確認するには、アップグレード前にバックグラウンドマイグレーションをチェックします。
経験則では、10 GB 未満のデータベースであれば、アップグレードにそれほど時間はかかりません。 マイナーリリースごとにせいぜい 1 時間程度です。 それ以上のサイズのデータベースでは、さらに時間がかかることがありますが、これはデータベースのサイズと実行する移行に大きく依存します。
使用例
これを説明するために、いくつかの例を見てみましょう。
例1:9.4の最新パッチリリースであるバージョン9.4.2を使用して大規模なGitLabインストールを実行しています。 GitLab 9.5.0がリリースされたとき、上記の要件が満たされていれば、このインストールはダウンタイムなしで安全に9.5.0にアップグレードできます。 9.5.0をスキップして9.5.1にアップグレードすることもできますが、9.6.0にそのままアップグレードすることはできません; 最初に9.5.xリリースにアップグレードする_必要があります_。
例2:あなたはバージョン9.4.2を使って大規模なGitLabインストールを実行しています。 GitLab 9.5にはいくつかのバックグラウンドマイグレーションが含まれており、10.0ではこれらを完了させる必要があります（あなたに代わって残りのジョブを処理します）。 9.5をスキップすることはダウンタイムなしでは不可能であり、バックグラウンドマイグレーションが完了するまでの時間によっては数時間のダウンタイムが必要になる可能性があります。 これを回避するには、まず9.5.xにアップグレードし、少なくとも1週間待ってから10.0にアップグレードする必要があります。
例3:GitLabのデータベースとしてMySQLを使用している場合。 新しいメジャー/マイナーリリースへのアップグレードにはダウンタイムが必要です。 リリースにバックグラウンドマイグレーションが含まれている場合、データベースのサイズによっては数時間のダウンタイムが発生する可能性があります。 これを回避するには、PostgreSQLを使用し、上記の他のオンラインアップグレード要件を満たす必要があります。
ステップ
ダウンタイムなしでアップグレードする手順
アップグレード前のバックグラウンド移行のチェック
特定のメジャー/マイナーリリースでは、バックグラウンドマイグレーションを終了する必要がある場合があります。 残りのマイグレーションジョブの数は、次のコマンドを実行することで確認できます：
オムニバス・インストール用
GitLab 12.9以降をお使いの場合は、以下を実行してください：
sudo gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
GitLab 12.8以前を使っている場合は、Railsコンソールを使って以下を実行してください：
puts Sidekiq::Queue.new("background_migration").size
Sidekiq::ScheduledSet.new.select { |r| r.klass == 'BackgroundMigrationWorker' }.size
ソースからのインストールの場合
GitLab 12.9以降をお使いの場合は、以下を実行してください：
cd /home/git/gitlab
sudo -u git -H bundle exec rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
GitLab 12.8以前を使っている場合は、Railsコンソールを使って以下を実行してください：
puts Sidekiq::Queue.new("background_migration").size
Sidekiq::ScheduledSet.new.select { |r| r.klass == 'BackgroundMigrationWorker' }.size
バックグラウンド移行がうまくいかない場合はどうすればよいですか？
オムニバス・インストール用
# Start the rails console
sudo gitlab-rails c
# Execute the following in the rails console
scheduled_queue = Sidekiq::ScheduledSet.new
pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq
pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }
ソースからのインストールの場合
# Start the rails console
sudo -u git -H bundle exec rails RAILS_ENV=production
# Execute the following in the rails console
scheduled_queue = Sidekiq::ScheduledSet.new
pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq
pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }
新しいメジャーバージョンへのアップグレード
メジャーバージョンは、後方互換性のない変更のために予約されています。 メジャーバージョン内で利用可能な最新のマイナーバージョンに最初にアップグレードすることをお勧めします。 サポートされているアップグレードパスを確認するには、アップグレードの推奨事項に従ってください。
新しいメジャーバージョンにアップグレードする前に、以前のリリースからのバックグラウンド移行ジョブが完了していることを確認する必要があります。background_migration キューの現在のサイズを確認するには、アップグレード前にバックグラウンド移行をチェックしてください。
エディション間のアップグレード
GitLabには、MITライセンスのCommunity Editionと、Community Editionの上に構築され、主に100人以上のユーザーを持つ組織向けの追加機能を含むEnterprise Editionがあります。
以下に、エディションを簡単に変更するためのガイドをいくつかご紹介します。
コミュニティ版からエンタープライズ版へ
注：以下のガイドは、Enterprise Editionをご契約の方のみを対象としています。
GitLabのインストールをCommunity EditionからEnterprise Editionにアップグレードしたい場合は、インストール方法に応じて以下のガイドに従ってください：
- ソース CE から EE への更新ガイド- 手順は、バージョンアップと非常によく似ています。サーバを停止し、コードを取得し、新機能の設定ファイルを更新し、ライブラリをインストールしてマイグレーションを行い、init スクリプトを更新し、アプリケーションを起動してステータスを確認します。
- Omnibus CE to EE- このガイドに従って、Omnibus GitLab Community EditionをEnterprise Editionにアップデートしてください。
エンタープライズ版からコミュニティ版へ
Enterprise EditionのインストールをCommunity Editionにダウングレードする必要がある場合は、このガイドに従ってください。
バージョン別のアップグレード手順
13.2.0
複数の Web ノードを持つ GitLab インストールは、13.2 (およびそれ以降) にアップグレードする前に、13.1 にアップグレードする必要があります。これは Rails の変更により作成者のイシューが発生する可能性があるためです。
13.1.0
13.1.0では、どちらかにアップグレードする必要があります：
- Git v2.24以上（以前はGit v2.22以上が必要でした）。
- 推奨 git v2.26.
これを行わないと、新しい--end-of-options Gitフラグを使用するため、一部のRPCでGitalyサービスの内部エラーが発生します。
さらに、GitLab 13.1.0では、Railsのバージョンが6.0.3から6.0.3.1にアップグレードされました。Railsのアップグレードには、後方互換性のないCSRFトークン生成の変更が含まれています。新しいRailsバージョンのGitLabサーバーでは、古いRailsバージョンのGitLabサーバーでは認識できないCSRFトークンが生成されるため、複数ノードのGitLabインストールでGET以外のリクエストが失敗する可能性があります。
そのため、複数のRailsサーバを使用していて、特に13.0からアップグレードする場合は、それ以降のバージョンにアップグレードする前に、まずすべてのサーバを13.1.0にアップグレードする必要があります：
- すべてのGitLabウェブノードがGitLab 13.1.0であることを確認します。
-
オプションで、
global_csrf_token機能フラグを有効にして、CSRF トークン生成の新しい方法を有効にします：Feature.enable(:global_csrf_token) - その時だけ、GitLabの新しいバージョンへのアップグレードを続けてください。
12.2.0
12.2.0では、Railsの認証済みCookie暗号化を有効にしました。 古いセッションは自動的にアップグレードされます。
しかし、セッションクッキーのダウングレードはサポートされていません。 そのため、12.2.0にアップグレードした後、ダウングレードを行うと、すべてのセッションが無効になり、ユーザーはログアウトされます。
12.0.0
12.0.0では、データベースに関連する様々な変更を行いました。 これらの変更には、まずユーザが最新の11.11パッチリリースにアップグレードする必要があります。 11.11.xにアップグレードした後、ユーザは12.0.xにアップグレードすることができます。
また、12.0.x 以降のバージョンに移行する前に、12.0.x にアップグレードする必要があります。
例1：現在GitLab 11.11.8を使っています。これは11.11.xの最新パッチリリースです。
例2：現在GitLab 10.xを使っています。アップグレードするには、まず10.xの最後のリリース（10.8.7）にアップグレードし、次に11.xの最後のリリース（11.11.8）にアップグレードします。 11.11.8にアップグレードしたら、安全に12.0.xにアップグレードできます。
詳しくはアップグレードパスのドキュメントをご覧ください。
その他
- MySQLからPostgreSQLへのデータベース移行をガイドします。
- アップグレード失敗後のバックアップからのリストア
- PostgreSQL データベースを最小限のダウンタイムでアップグレードするためのSlony を使った PostgreSQL のアップグレード。
