メインコンテンツまでスキップ

デプロイ

Platform as VM デプロイでは、単一のスクリプトを使って、クリーンな RHEL 系 OS を完全に動作する OpenLM Platform へ変換します。スクリプトは、K3s のインストール、データベースのプロビジョニング、スキーマの初期化、Kafka トピックの作成、プラットフォームサービスのデプロイをすべて自動的に行います。

開始する前に、要件 ページの内容を必ず完了させてください。

スクリプトが行うこと​

インストーラーは Ansible playbook を実行し、次の処理を行います。

  1. 前提条件（OS ファミリー、RAM、CPU）を検証します。
  2. firewalld をインストールして構成し、Kubernetes API ポート（6443）を開放します。
  3. 軽量な Kubernetes 環境として K3s をインストールし、Traefik を Ingress コントローラーとして構成します。
  4. クラスタの名前空間を作成し、TLS 証明書を Kubernetes Secret として保存するとともに、同じ証明書を全サービスがマウントするクラスタ内トラストバンドルに読み込みます。
  5. インフラサービス（Redis、Kafka、MongoDB、運用データベース、レポーティングデータベース）をデプロイします。
  6. 運用データベースのスキーマを初期化します。レポーティングスキーマは、レポーティングデータベースが同梱の PostgreSQL である場合に初期化します。
  7. プラットフォームが必要とする Kafka トピックを作成します。
  8. OpenLM API ゲートウェイと OpenLM Platform サービスをデプロイします。
注意

手順 6 でレポートスキーマのスクリプトが適用されるのは、同梱の PostgreSQL に対してのみです。レポーティング用に外部 SQL Server を構成した場合は、スキーマをお客様側で作成する必要があります。構成リファレンス を参照してください。

インストール全体に要する時間は 20〜40 分 で、その大半は初回のコンテナイメージ取得に費やされます。

デプロイ手順​

1. デプロイパッケージをダウンロードする​

OpenLM からリリースアーカイブを直接ダウンロードします: platform-as-vm-20260514-171145-1b03d94.zip。ファイル名は platform-as-vm-<date>-<commit>.zip のパターンに従い、<date> はビルド日、<commit> はソースのリビジョンを表します。

バージョン固定のリンクです

このリンクは特定のビルドを指しており、「latest」を指すエイリアスは存在しません。デプロイ前に、インストール対象が最新リリースであることと、そのリリースノートを OpenLM に確認してください。アップグレードは新しいバンドルを取得してインストーラーを再実行する方式のため、どのビルドをデプロイしたかを記録しておいてください。

ワークステーション上で展開します。

unzip platform-as-vm-*.zip

展開すると、インストーラースクリプト、Helm チャート、Ansible playbook、データベーススキーマを含む platform-as-vm/ ディレクトリが生成されます。

（任意）アーカイブの SHA-256 チェックサムを表示し、インストール前に OpenLM に確認できるようにします。

sha256sum platform-as-vm-*.zip

2. デプロイパッケージを転送する​

展開した platform-as-vm/ ディレクトリを対象 VM にコピーします。

scp -r platform-as-vm/ <user>@<vm-ip>:~/

3. TLS 証明書を配置する​

VM に SSH 接続し、config.yaml で参照するパスに証明書と鍵を配置します。既定の配置場所は次のとおりです。

sudo mkdir -p /etc/openlm/certs
sudo cp tls.crt /etc/openlm/certs/tls.crt
sudo cp tls.key /etc/openlm/certs/tls.key
sudo chmod 600 /etc/openlm/certs/tls.key

ファイルは任意の場所に保存できます。config.yaml 側の対応するパスを更新するだけで問題ありません。

4. config.yaml を編集する​

~/platform-as-vm/config.yaml を開き、必須の 3 フィールドを設定します。

openlm_system_domain: "openlm.yourcompany.com"        # Your OpenLM FQDN
tls_cert_path:        "/etc/openlm/certs/tls.crt"    # Path to the TLS certificate
tls_key_path:         "/etc/openlm/certs/tls.key"    # Path to the TLS private key

それ以外のフィールドは、単一 VM デプロイ向けに適切な既定値が設定されています。外部 SQL Server、外部 Kafka、エアギャップ環境などの応用パターンについては、構成リファレンス を参照してください。

5. passwords.yaml を編集する​

~/platform-as-vm/passwords.yaml を開き、同梱の 3 つのデータベース用に強力なパスワードを設定します。

postgres_password:     "<a strong password>"
mariadb_root_password: "<a different strong password>"
mongodb_root_password: "<another strong password>"
警告

これらのパスワードは、データベース初期化時に組み込まれます。初回インストール後に passwords.yaml で変更しても、稼働中のデータベースは更新されません。一度きりの設定値として扱い、以後はそれぞれのデータベースのネイティブなコマンドでローテーションしてください。

6. インストーラーを実行する​

デプロイディレクトリの中から実行します。

cd ~/platform-as-vm
chmod +x entrypoint.sh
./entrypoint.sh

スクリプトは sudo パスワードを 2 回 要求します。

  1. 実行直後。OS パッケージの更新と Python のインストールを行うときです。
  2. Ansible playbook の起動時。BECOME password: という別のプロンプトが表示されます。パッケージ、pip、Helm のインストールが終わった後になるため、数分後になることがあります。

playbook が動き出すまでは端末の前を離れないでください。2 回目のプロンプト以降は、追加の入力なしで一連の処理を最後まで実行します。

途中でインストーラーが失敗した場合は、原因を修正してから ./entrypoint.sh を再実行してください。playbook は冪等です。各手順を再確認し、すでに完了している作業はスキップするため、最初からやり直しにはなりません。中断位置を保存して再開する仕組みではないため、序盤の手順は毎回（短時間で）再評価されます。

デプロイの検証​

Pod を確認する​

kubectl get pods -A

次のようになっているはずです。

  • kube-system – すべての Pod が Running（CoreDNS、Traefik、metrics-server、local-path-provisioner）。
  • openlm-infrastructure – すべての Pod が Running（Redis、Kafka、MongoDB、MariaDB、PostgreSQL）。
  • openlm – 約 100 個の Pod があり、ほとんどが Running。一部はインストーラー終了後も数分間 Init や ContainerCreating の状態にとどまることがあります。サービスがイメージを取得し、依存サービスを待っている間の正常な挙動です。

15 分経過しても CrashLoopBackOff から抜けない Pod がある場合は、トラブルシューティング を参照してください。

Helm リリースを確認する​

helm list -A

7 つのリリースが存在し、それぞれ STATUS: deployed と表示されているはずです。

Namespaceリリース
openlm-infrastructureredis、mariadb、mongodb、postgres、kafka
openlmopenlm-gateway、openlm-platform

リリース数がこれより少ない場合、または deployed 以外の状態のリリースがある場合は、いずれかの手順が失敗しています。トラブルシューティング を確認してください。

プラットフォームを開く​

ブラウザで https://<your-domain>/ を開きます。OpenLM のログインページが表示されます。

ブラウザに TLS 警告が表示される場合は、証明書が自己署名であるか、ブラウザが信頼していない CA が発行したものであることを示します。そのような構成では想定どおりの挙動です。

初回ログイン​

ログインページが表示されればデプロイは成功していますが、この時点ではまだサインインできません。インストーラーはユーザーやロールを作成せず、管理者の既定パスワードも設定しません。認証は OpenLM Identity Service が担います。

ログインページから実際に使える状態にするには、次の手順を実施します。

  1. デプロイ用の初期管理者アカウントの資格情報について OpenLM にお問い合わせください。
  2. 組織に合わせて Identity Service を構成します。Active Directory、LDAP、SSO プロバイダーとの連携については OpenLM Identity Service の構成ガイド を参照してください。
  3. プラットフォームの管理 UI から、自組織のユーザーとロールを作成します。

Power BI と接続する（任意）​

Power BI などの BI ツールをレポーティングデータベースに接続するには、次の設定を使用します。

設定項目値
Server<vm-ip-or-fqdn>:30432
Databaseopenlm_reporting_db
Usernamepostgres
Passwordpasswords.yaml で設定した postgres_password

Power BI Desktop では、データの取得 → PostgreSQL データベース を選択し、サーバーとデータベース名を入力したうえで認証情報を指定します。

次のステップ​

  • プラットフォームの運用 – 運用 でヘルスチェック、ログ、バックアップ、アップグレードを説明しています。
  • 構成のチューニング – 構成リファレンス で外部 SQL Server、外部 Kafka などのパターンを説明しています。
  • 問題が発生した場合 – トラブルシューティング によくある問題と対処法をまとめています。
にDaniel Rasが最終更新