運用
Platform as VM デプロイの確認、バックアップ、スケール、アップグレード、削除には、このページを使用します。インストール時の問題については、トラブルシューティング を参照してください。
クラスタへのアクセス
インストーラーはホームディレクトリに kubeconfig を書き出し、~/.bashrc で KUBECONFIG をエクスポートします。VM 上で新しいシェルを開きます。これで kubectl が動作します。
kubectl get nodes
kubectl get pods -A
ノート PC からクラスタにアクセスするには、VM から kubeconfig をコピーし、サーバー URL を書き換えます。
scp <user>@<vm-ip>:~/.kube/config ./openlm-vm.kubeconfig
# macOS
sed -i '' 's|127.0.0.1|<vm-public-ip>|' ./openlm-vm.kubeconfig
# Linux
sed -i 's|127.0.0.1|<vm-public-ip>|' ./openlm-vm.kubeconfig
export KUBECONFIG=$PWD/openlm-vm.kubeconfig
kubectl get nodes
これには、手元のマシンからポート 6443 に到達できることが必要です。
ヘルスチェック
すべての Pod が動作していることを確認する
次のコマンドを実行します。
kubectl get pods -A | grep -v Running | grep -v Completed
健全なクラスタでは、出力は空になります。CrashLoopBackOff、Error、ImagePullBackOff、Pending の状態が数分以上続く Pod がある場合は調査が必要です。トラブルシューティング を参照してください。
Helm リリースを確認する
次のコマンドを実行します。
helm list -A
すべてのリリースに STATUS: deployed と表示されます。pending-install や failed のまま止まっているリリースは問題です。
Ingress を確認する
次のコマンドを実行します。
kubectl get ingress -n openlm
このコマンドは、Traefik が処理するルートをすべて一覧表示します。OpenLM Platform 自体には到達できるのに特定の URL が 404 を返す場合は、対応する Ingress がここに存在することを確認してください。
ログ
このセクションでは、1 つの Pod、サービスのすべての Pod、監査イベントのログを表示する方法を説明します。
1 つの Pod のログを表示する
次のコマンドを実行します。
kubectl logs <pod-name> -n openlm
kubectl logs <pod-name> -n openlm --tail 100 -f # follow last 100 lines
kubectl logs <pod-name> -n openlm --previous # crashed container's last logs
あるサービスのすべての Pod のログを表示する
ラベルではなく Deployment を指定します。OpenLM Platform の Pod には単純な app ラベルが付いていないため、-l app=<service> では何も一致せず、No resources found が返されます。
kubectl logs -n openlm deploy/openlm-identity --tail 50
監査イベントを表示する
監査イベントは OpenLM Platform の Pod ログには出力されません。Kafka に送信され、専用の監査サービスが処理します。監査イベントを表示するには、次のコマンドを実行します。
kubectl logs -n openlm deploy/openlm-auditservice --tail 100
デプロイパッケージにはログ集約スタックが含まれていません。kubectl logs はノードから直接読み出すため、Pod が削除またはローテーションされるとログは失われます。保持と検索が必要な場合は、お客様のログ基盤へ転送してください。
サービスをスケールする
単一 VM であるためスケールできる範囲には限りがありますが、個々のサービスは調整できます。
サービスをスケールアップする
次のコマンドを実行します。
kubectl scale deployment/openlm-licensemanager -n openlm --replicas=2
ほとんどの OpenLM Platform サービスはステートレスで、複数レプリカで問題なく動作します。一方、共有状態を保持する一部のサービスはレプリカ 1 のままにする必要があります。これまでスケールしたことのないサービスをスケールする前に、OpenLM サポートに確認してください。ステートフルなサービスを 2 レプリカで動かすと、処理が二重に実行される可能性があります。
サービスを停止する
アップグレード後も維持したい変更かどうかで、2 つの方法のいずれかを使用します。
サービスを一時的に停止するには、次のコマンドを実行します。次回のインストーラー実行で、この変更は元に戻ります。
kubectl scale deployment/<service> -n openlm --replicas=0
サービスを恒久的に停止するには、OpenLM Platform の values で該当サブチャートに enabled: false を設定し、インストーラーをもう一度実行します。
スケジュールジョブを一時停止する
次のコマンドを実行します。
kubectl patch cronjob/<name> -n openlm -p '{"spec":{"suspend":true}}'
再開するには suspend を false に戻します。
バックアップとリストア
OpenLM Platform でバックアップ対象となる主なステートは、2 種類あります。
- 永続ボリュームデータ: ディスク上の Kafka、MongoDB、PostgreSQL、MariaDB のデータ。バックアップ容量の大半を占めます。
- K3s クラスタステート: Kubernetes オブジェクト（Deployment、Secret など）を保持する組み込みデータストア。サイズが小さく、迅速に復元できます。
同梱サービスの代わりに構成した外部サービスは、本ページの対象外です。外部 SQL Server、マネージド Kafka、外部 MongoDB は、それぞれのプラットフォーム向けの通常のツールでバックアップしてください。VM スナップショットにはこれらは含まれません。
VM 単位のスナップショット
ほとんどの顧客にとって、最も簡潔で信頼性の高いバックアップは、ハイパーバイザーまたはクラウドプロバイダーによる VM 全体のスナップショットです。K3s、すべての永続ボリューム、システムステートが一貫した 1 つのイメージとして取得されます。可能な場合は VM 単位のスナップショットを使用してください。
VM プラットフォームが対応していれば、日次スナップショットをスケジュールし、目標復旧時点（RPO）と目標復旧時間（RTO）のポリシーに従って保持してください。
データベース単位のバックアップ
より細かい RPO が必要な場合、または VM 全体を復元せずにデータを抽出したい場合に使用します。
PostgreSQL（レポーティング）
次のコマンドを実行します。
kubectl port-forward -n openlm-infrastructure svc/postgres-postgresql 5432:5432 &
PGPASSWORD='<postgres-password>' pg_dump -h localhost -U postgres \
openlm_reporting_db | gzip > reporting-$(date +%F).sql.gz
kill %1
MariaDB（運用）
次のコマンドを実行します。
kubectl port-forward -n openlm-infrastructure svc/mariadb 3306:3306 &
mysqldump -h localhost -u root -p<mariadb-root-password> \
--all-databases | gzip > operational-$(date +%F).sql.gz
kill %1
MongoDB
次のコマンドを実行します。
kubectl exec -n openlm-infrastructure mongodb-0 -- \
mongodump --archive --gzip \
--uri "mongodb://admin:<mongodb-root-password>@localhost:27017/?authSource=admin" \
> mongo-$(date +%F).archive.gz
<postgres-password>、<mariadb-root-password>、<mongodb-root-password> を、passwords.yaml に設定したパスワードに置き換えます。
リストアは逆の手順をたどります。port-forward を立ち上げ、ダンプを psql、mysql、mongorestore にパイプします。リストア中に書き込みが発生しないよう、対象を利用するサービスは事前にスケールダウンしてください。
デプロイをアップグレードする
デプロイパッケージにはバージョンが付与されています。アップグレードするには、次の手順を実行します。
- OpenLM から新しいデプロイパッケージを受け取る。
- VM 上の別のパスに展開する（例:
~/platform-as-vm-2026-05/）。ロールバックに必要になる場合があるため、以前のパッケージは上書きしないでください。 - 既存の
config.yamlを新しいディレクトリにコピーし、新規オプションがあれば反映する。 passwords.yamlは以前のデプロイからそのままコピーする。同梱データベースを初期化したときと同じパスワードでなければなりません。- 新しいディレクトリから
./entrypoint.shを実行する。
playbook は冪等です。K3s、名前空間、Secret は既存のものを検出し、変更しません。Helm リリースは新しいチャートバージョンでその場でアップグレードされ、Pod は 1 つずつ順次更新されます。アップグレード中、個別サービスの短時間ダウンタイムは正常な挙動です。OpenLM Platform 全体のダウンタイムは、通常サービスごとに 1 分未満です。
データベーススキーマのマイグレーションは、新バージョンの初回起動時に AllDbUpgradeAPI サービスが自動で実行します。このサービスは削除しないでください。
複数のリリースをまたいでメジャーバージョンをアップグレードする場合は、OpenLM サポートにお問い合わせください。特定のバージョン間で、データマイグレーションの手順が必要になる場合があります。
ロールバック
アップグレードが失敗した場合や、想定外の挙動が発生した場合:
- 以前のデプロイディレクトリに
cdで移動する。 ./entrypoint.shをもう一度実行する。
これにより、各 Helm リリースが以前のチャートバージョンへダウングレードされます。
スキーマのマイグレーションは可逆ではありません。新バージョンが既に AllDbUpgradeAPI を実行している場合、データベースをロールバックすることはできません。スキーマ変更を取り消すには、バックアップからリストアしてください。
メンテナンスウィンドウ
アップグレードやデータベースレベルの操作は、メンテナンスウィンドウ内で計画してください。OpenLM Platform は Pod の再起動に強く設計されていますが、次の点に注意してください。
- アクティブなエンドユーザーセッションが一時的に中断される場合があります。
- レポーティング ETL ジョブが直近のバッチをもう一度実行する必要がある場合があります。
- 外部システム（ServiceNow など）との連携は、サービスが復旧するまで Kafka にイベントがキューイングされます。
通常のアップグレードであれば、30 分のメンテナンスウィンドウで十分です。
OpenLM Platform をアンインストールする
OpenLM Platform と K3s を VM から完全に削除するには、次のコマンドを実行します。
sudo /usr/local/bin/k3s-uninstall.sh
k3s-uninstall.sh は /var/lib/rancher/k3s 配下のすべてを削除します: クラスタ、すべての永続ボリューム（データを含む）、すべてのコンテナイメージ。元に戻す手段はありません。後で復旧したい可能性がある場合は、先に VM スナップショットを取得してください。
なお、インストーラーがホームディレクトリに配置した kubeconfig と、~/.bashrc に追記した export KUBECONFIG の行は削除されません。シェルを元の状態に戻したい場合は、~/.kube/config とその行を手動で削除してください。
証明書ディレクトリとデプロイパッケージも削除するには、次のコマンドを実行します。
sudo rm -rf /etc/openlm
rm -rf ~/platform-as-vm*
ドキュメントチームは、大規模言語モデルを使ってこのページを下書きすることがあります。公開前に、テクニカルライターがすべてのページをレビューし、製品と照らし合わせて検証します。最終的な判断は人間が行います。