アップグレード

既存の OpenLM Platform デプロイをアップグレードするには、このページの手順に従います。

初回インストール

初回インストールの場合は、まず デプロイパス で導入方法を選び、その後 プラットフォームのインストール に進んでください。

Platform as VM のアップグレード方法は異なります

Platform as VM でデプロイした場合、このページの Helm コマンドは使用しないでください。このデプロイのリリース名は openlm-platform であるため、helm upgrade monohelm は release: not found で失敗します。また正しいリリース名を指定したとしても、helm upgrade を直接実行すると、インストーラーによる values のレンダリング、パスワードの処理、Kafka トピックの作成、アップグレード後のロールアウトがスキップされます。

アップグレードは、新しいデプロイパッケージを展開して ./entrypoint.sh を再実行する方式で行います。Platform as VM のアップグレード を参照してください。

次の手順は、手動で Kubernetes にデプロイするパス（オンプレミスマシン、AWS、Azure）に適用されます。

アップグレード前

アップグレードを開始する前に、次の手順を完了します。

• 新しいデプロイパッケージと、そのバージョンのリリースノートを OpenLM から入手します。破壊的変更、移行手順、必須のデータベース変更がないか確認します
• アップグレード前にデータベースをバックアップします。バックアップがあると、ロールバックで説明するロールバックが可能になります。
  • マネージドデータベース（RDS、Azure SQL）はプロバイダー側でスナップショットを取得します。
  • クラスタ内のデータベースについては、Platform as VM の運用 のダンプコマンドがどの Kubernetes デプロイでも利用できます。
• 開始前にすべての Pod が正常であることを確認します（kubectl get pods -n openlm）

アップグレードの実行

次のコマンドを実行します。

helm upgrade monohelm openlm_mono-<new-version>.tgz \
  -f mono-values.yaml \
  -n openlm \
  --timeout 20m

リリース名はインストール時と同じものを使用し、values ファイルは現在のデプロイのものを使用してください。タイムアウトを長めに設定しているのは意図的です。サービス数が 100 を超えるため、既定の 5 分では不足することがよくあります。

アップグレード後

アップグレードの完了後に、次の手順を完了します。

• Pod の起動を監視します: kubectl get pods -n openlm -w
• 主要サービスが正常に応答していることを確認します
• データフロー（ライセンスイベント、レポートパイプライン、directory sync）を検証します
• OpenLM Platform UI にエラーがないか確認します

ロールバック

問題が発生した場合、Helm でリリースを直前のリビジョンに戻せます。

helm rollback monohelm -n openlm

helm rollback はスキーママイグレーションを取り消しません

AllDbUpgradeAPI サービスは、新しいバージョンの起動時にデータベースのスキーママイグレーションを自動的に適用します。このマイグレーションは元に戻せません。helm rollback が戻すのは Kubernetes オブジェクトのみであるため、マイグレーション済みのスキーマに対して以前のバージョンのアプリケーションが動作する状態になります。

新しいバージョンがすでにスキーマをマイグレーションしている場合は、アップグレード前に取得したバックアップからデータベースをリストアしてください。