# GitLab のアップグレード
GitLab Operatorは、GitLabのバージョン間のアップグレードを管理することができます。このドキュメントには、GitLabのアップグレードを行う手順とともに、アップグレードフローがどのように機能するかについての背景的な背景が含まれています。
## Operator による GitLab アップグレードの処理方法
コントローラの照合ループの最初に、Operatorは現在のバージョンが希望のバージョンと一致するかどうかをチェックします。
- これらのバージョンが一致する場合、通常の照合ループが実行され、CR仕様で指定された設定を満たすオブジェクトが存在することが確認されます。
- これらのバージョンが一致_しない_場合、通常の照合ループは実行されますが、 アップグレードフローを処理するための追加のブランチが実行されます。
アップグレードフローは次のようになります：
- コントローラはすべてのデプロイを調整します。
- WebserviceとSidekiqのデプロイは調整されますが、「一時停止」されます。これは、新しいデプロイが一時停止解除されるまで、「古い」ポッドが起動したままになることを意味します。
- プレマイグレーションが実行されます。
- これは事実上マイグレーションのジョブを実行するだけで、デプロイ後のマイグレーションをスキップします。
- コントローラはWebserviceとSidekiqデプロイを一時停止しません。
- コントローラは、新しいWebserviceとSidekiqポッドが実行されるのを待ちます。
- ポストマイグレーションが実行されます。
- これは（デプロイ後のマイグレーションをスキップせずに）マイグレーションジョブを実行します。
- コントローラは、WebserviceとSidekiqデプロイのローリングアップデートを実行します。
- コントローラは、再起動されたWebserviceとSidekiqポッドが実行されるのを待ちます。
今後の照合ループでは、目的のバージョン(
spec.chart.version)が現在のバージョン(
status.version)と一致するため、このロジックのブランチはスキップされます。
## GitLab の更新方法
以下は、GitLab Operatorを使ってGitLabインスタンスをアップグレードする手順です。
### ステップ 1
GitLab CR の
spec.chart.version フィールドを新しいバージョンに更新してください。例えば
apiVersion: apps.gitlab.com/v1beta1
metadata:
name: gitlab
spec:
chart:
- version: "5.0.6"
+ version: "5.1.1"
values:
...
### ステップ 2
変更したGitLab CRをクラスターに適用します：
kubectl -n gitlab-system apply -f mygitlab.yaml
以下のようなメッセージが表示されるはずです：
### ステップ3
コントローラのログで進捗状況を確認できます：
上記のアップグレードフローに従ったログエントリが表示されます。
また、クラスター内の GitLab CR ステータスを確認することもできます：
NAME STATUS VERSION
gitlab Preparing 5.2.4
アプリケーションの準備が整い、新しいバージョンにアップグレードされると、
STATUS 列に反映されます。
gitlab Running 5.2.4
GitLabオブジェクト自体のステータス状況は、アプリケーションに関するより詳細な情報を表示します。
## アップグレードに関するその他の注意事項
以下は、GitLab インスタンスをアップグレードする前に考慮すべきその他のトピックです。