Operatorを使用したGitLabインスタンスのアップグレード

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

GitLab Operatorを使用すると、GitLab Operatorでインストールされたインスタンスをアップグレードできます。

前提要件

GitLab Operatorでアップグレードする前に:

アップグレードする前に必要な情報を確認してください。
必要なGitLabのバージョンに必要なGitLab Operatorのバージョンを特定します。GitLabのバージョン、GitLab Helmチャートのバージョン、およびGitLab Operatorのバージョン間のマッピングについては、GitLab Operatorのリリースを参照してください。

GitLab Operatorを使用したGitLabのアップグレード

GitLab Operatorを使用してGitLabをアップグレードするには:

ワークフローを妨げないように、アップグレード中にメンテナンスモードをオンにすることを検討して、書き込み操作からユーザーを制限します。
ターゲットのGitLabバージョンと同じバージョンにGitLab Runnerをアップグレードします。
GitLab Operatorをアップグレードします。
GitLab Operatorを使用してGitLabをアップグレードします。

アップグレード後:

有効になっている場合は、メンテナンスモードをオフにします。
アップグレードヘルスチェックを実行します。

GitLab Operatorのアップグレード

GitLab Operatorをアップグレードするには:

バックアップを実行します。
kubectlを使用して、必要なGitLab Operatorのバージョンのマニフェストを適用して、必要なバージョンをインストールします。
```
VERSION=X.Y.Z
kubectl apply -f \
  https://gitlab.com/api/v4/projects/18899486/packages/generic/gitlab-operator/${VERSION}/gitlab-operator-kubernetes-${VERSION}.yaml
```
このコマンドは、使用する新しいデプロイイメージを含む、関連するマニフェストに対する変更を適用します。
新しいGitLab Operatorのバージョンがリーダーになることを確認します。GitLab Operatorのデプロイは、この変更により新しいReplicaSetを作成し、新しいGitLab Operatorポッドを起動する必要があります。一方、以前のGitLab Operatorポッドがシャットダウンし、リーダーのステータスを放棄します。これが発生すると、新しいGitLab Operatorポッドがリーダーになります。
GitLabカスタムリソース(CR)のチャートバージョンを更新します。ほとんどの場合、使用可能なチャートのバージョンは、GitLab Operatorのバージョン間で同一ではありません。新しいバージョンのGitLab Operatorが起動すると、既存のGitLabカスタムリソース（CR）を調整しようとします。次のようなエラーが表示されることがあります:
```
Configuration error detected: chart version 5.7.0 not supported; please use one of the following: 5.7.1, 5.6.4, 5.5.4
```
これに対処するには、そのリリースの使用可能なチャートバージョンから有効なバージョンを特定します。たとえば、Operator 0.4.0から0.4.1にアップグレードする場合は、GitLab CRを5.7.0に最も近い使用可能なチャートバージョンに更新します。この場合は5.7.1です。
GitLab OperatorがGitLabを期待どおりに調整することを確認します。新しいOperatorポッドからのログをチェックして、Operatorポッドが定義されたチャートのバージョンにアップグレードされたかどうかを確認します。
アップグレードが成功したことを確認するには、GitLab CRのステータスを取得します:
```
$ kubectl get gitlabs -n gitlab-system
NAME     STATUS    VERSION
gitlab   Running   5.7.1
```
ステータスRunningは、GitLab Operatorがインスタンスへの変更を調整できることを意味します。バージョンは、GitLab Operatorのアップグレード後に指定されたチャートのバージョンと一致する必要があります。

トラブルシューティング

エラーが発生した場合は、まずトラブルシューティングドキュメントを参照してください。そこに回答がない場合は、既存のイシューを確認するか、イシュートラッカーで新しいイシューを開いてください。

GitLab Operatorを使用したGitLabのアップグレード

GitLab Operatorをアップグレードした後、GitLabインスタンスをアップグレードするには:

GitLabカスタムリソースのspec.chart.versionフィールドを新しいバージョンに更新します。例:

apiVersion: apps.gitlab.com/v1beta1
kind: GitLab
metadata:
  name: gitlab
spec:
  chart:
-   version: "5.0.6"
+   version: "5.1.1"
    values:
      ...

変更されたGitLabカスタムリソースをクラスターに適用します:

kubectl -n gitlab-system apply -f mygitlab.yaml

次のメッセージが表示されます:

gitlab.apps.gitlab.com/gitlab created

コントローラーログで進行状況を監視できます。例:

$ kubectl -n gitlab-system logs deployment/gitlab-controller-manager -c manager -f
2021-09-14T20:59:12.342Z        INFO    controllers.GitLab      Reconciling GitLab    {"gitlab": "gitlab-system/gitlab"}
2021-09-14T20:59:12.344Z        DEBUG   controllers.GitLab      version information   {"gitlab": "gitlab-system/gitlab", "upgrade": true, "current version": "", "desired version": "5.0.6"}
2021-09-14T20:59:18.168Z        INFO    controllers.GitLab      reconciling Webservice and Sidekiq Deployments (paused) {"gitlab": "gitlab-system/gitlab"}
...

上記のアップグレード手順に従ってログエントリが表示されます。クラスター内のGitLabカスタムリソースステータスを表示することもできます:

$ kubectl -n gitlab-system get gitlab
NAME     STATUS        VERSION
gitlab   Preparing     5.2.4

アプリケーションの準備が完了し、新しいバージョンにアップグレードされると、STATUS列に反映されます。

$ kubectl -n gitlab-system get gitlab
NAME     STATUS      VERSION
gitlab   Running     5.2.4

GitLabオブジェクト自体のステータス状態は、アプリケーションに関するより詳細な情報を示しています。

GitLab OperatorがGitLabをアップグレードする方法

コントローラー調整ループの開始時に、GitLab Operatorは、現在のバージョンが必要なバージョンと一致するかどうかを確認します。

これらのバージョンが一致する場合、通常の調整ループが実行され、カスタムリソース（CR）仕様で提供される設定を満たすオブジェクトが存在することを確認します。
これらのバージョンが一致しない場合でも、通常の調整ループは実行されますが、アップグレードを処理するためのロジックの追加ブランチが実行されます。

アップグレードでは:

コントローラーは、すべてのデプロイを調整します。WebserviceとSidekiqのデプロイは調整されますが、一時停止されます。古いポッドは、新しいデプロイが再開されるまで起動したままになります。
事前移行が実行され、移行ジョブが実行されますが、デプロイ後の移行はスキップされます。
コントローラーは、WebserviceとSidekiqのデプロイを再開します。
コントローラーは、新しいWebserviceおよびSidekiqポッドが実行されるのを待ちます。
デプロイ後の移行が実行され、デプロイ後の移行をスキップせずに移行ジョブが実行されます。
コントローラーは、WebserviceとSidekiqのデプロイに対してローリングアップデートを実行します。
コントローラーは、再起動されたWebserviceおよびSidekiqポッドが実行されるのを待ちます。

将来の調整ループでは、（spec.chart.versionから）目的のバージョンが（status.versionから）現在のバージョンと一致するため、このロジックのブランチはスキップされます。

Operatorを使用したGitLabインスタンスのアップグレード

前提要件

GitLab Operatorを使用したGitLabのアップグレード

GitLab Operatorのアップグレード

トラブルシューティング

GitLab Operatorを使用したGitLabのアップグレード

GitLab OperatorがGitLabをアップグレードする方法

関連トピック