構成リファレンス
顧客が編集する構成は、すべてデプロイパッケージのルートにある以下の 2 ファイルに集約されています。
config.yaml– プラットフォーム構成（ドメイン、データベース、Ingress など）passwords.yaml– 同梱データベースで使用するパスワード
インストーラーはこの 2 ファイルを読み込み、インストール時に Helm チャートの value と Kubernetes Secret にレンダリングします。インストーラーを再実行すると、その時点のファイル内容に基づいてすべてが再レンダリングされます。
必須フィールド
以下の 3 フィールドは必ず設定する必要があります。空の場合、インストーラーは処理を中止します。
openlm_system_domain: "openlm.yourcompany.com" # FQDN used to access the platform
tls_cert_path: "/etc/openlm/certs/tls.crt"
tls_key_path: "/etc/openlm/certs/tls.key"
それ以外のフィールドは、すべて単一 VM ですべて同梱版を使うデプロイ向けの既定値が設定されています。
データベースの選択肢
プラットフォームは 2 つの役割のデータベースを使用します。
- 運用（Operational） – ライブ状態、ID、アロケーション。書き込みスループットが高く、クエリは小さい。
- レポーティング（Reporting） – BI ツール向けの履歴利用データおよび ETL 出力。大規模な分析クエリを扱う。
各役割には、以下のいずれかのバックエンドを選べます。
| バックエンド | モード | 使用可能なロール | 補足 |
|---|---|---|---|
| MariaDB | 同梱 | 運用 | 運用ロールの既定値 |
| PostgreSQL | 同梱 | レポーティングのみ | レポーティングロールの既定値。運用および identity のバックエンドには使用できません。 |
| SQL Server | 外部 | 両ロール | 顧客提供 |
| MySQL | 外部 | 運用のみ | 顧客提供 |
推奨パターン
推奨する 2 つのパターン:
- すべて同梱 – 運用は MariaDB、レポーティングは PostgreSQL。自己完結型で、追加で管理すべきものはありません。SQL Server インフラや DBA チームがない場合に最適です。
- すべて外部 SQL Server – 両ロールを同一の外部 SQL Server インスタンス上の別データベースに格納します。SQL Server を既に運用している顧客に最適です。
同梱と外部を混在させる構成もサポートされていますが、一般的ではありません。
レポーティングデータベース
reporting_db_type: "PostgreSQL" # or "SqlServer_SQLServerAuth"
reporting_db_host: "postgres-postgresql.openlm-infrastructure.svc.cluster.local"
reporting_db_port: 5432
reporting_db_username: "postgres"
reporting_db_password: "GENERATED" # Substituted from passwords.yaml
reporting_db_name: "openlm_reporting_db"
外部 SQL Server を使う場合は、reporting_db_password に実際のパスワードを設定し（GENERATED のままにはしない）、データベースを事前に作成するか、ユーザーに作成権限を付与しておきます。タイプが SqlServer_SQLServerAuth のとき、同梱の PostgreSQL はインストールされません。
インストーラーがレポートスキーマのスクリプトを適用するのは、同梱の PostgreSQL に対してのみです。reporting_db_type が SqlServer_SQLServerAuth の場合、この手順は完全にスキップされるため、レポートスキーマの作成はお客様の責任となります。
運用データベース
operational_db_type: "MariaDB" # Options: MariaDB, MySQL, SqlServer_SQLServerAuth
operational_db_host: "mariadb.openlm-infrastructure.svc.cluster.local"
operational_db_port: 3306
operational_db_username: "root"
operational_db_password: "GENERATED"
operational_db_name: "openlm_operational_db"
identity_db_name: "openlm_identity_db"
dss_db_name: "openlm_dss_db"
運用ロールは、operational、identity、DSS の 3 つの論理データベースを使用します。同梱の MariaDB を使う場合、3 つとも自動的に作成されます。
_none が付きますoperational_db_name は接続先のデータベース名そのものではなく、プレフィックス です。プラットフォームが実際に接続するのは <operational_db_name>_none で、既定値の場合は openlm_operational_db_none になります。
同梱の MariaDB では、このサフィックス付きのデータベースが自動的に作成されます。外部 SQL Server では、DBA がサフィックス付きの名前で作成する必要があります。 openlm_operational_db という名前で作成した場合、プラットフォームは接続できません。
identity と DSS のデータベースは、identity_db_name と dss_db_name に設定した名前がそのまま使用され、サフィックスは付きません。
メッセージブローカー（Kafka）
kafka_bootstrap_servers: "kafka.openlm-infrastructure.svc.cluster.local:9092"
# Only set the SASL fields when connecting to an external/managed Kafka:
kafka_sasl_mechanism: "" # e.g. ScramSha512
kafka_sasl_username: ""
kafka_sasl_password: ""
kafka_security_protocol: "" # e.g. SASLSSL
kafka_ssl_endpoint_algorithm: "" # e.g. https
kafka_consumer_timeout_ms: "" # e.g. 6000
- 既定 – クラスタ内で同梱の Kafka を起動し、認証は使用しません。
- 外部 Kafka –
kafka_bootstrap_serversを外部エンドポイントに設定し、SASL フィールドを記入します。同梱の Kafka をあわせて無効化したい場合は、OpenLM サポートまでお問い合わせください。
kafka_consumer_timeout_ms は consumer の poll タイムアウトを上書きします。レイテンシの大きいマネージドブローカーで OpenLM サポートから引き上げを指示された場合を除き、空のままにしてください。
ドキュメントストア（MongoDB）
mongo_connection_string: "mongodb://admin:GENERATED@mongodb.openlm-infrastructure.svc.cluster.local:27017"
リテラル文字列 GENERATED は、インストール時に passwords.yaml の mongodb_root_password に置換されます。外部 MongoDB はサポートされていません。プラットフォームは同梱の MongoDB を前提とします。
MongoDB 接続文字列の末尾に / を付けないでください。一部のクライアントが拒否します。
キャッシュ（Redis）
redis_connection_string: "redis-master.openlm-infrastructure.svc.cluster.local:6379"
Redis はクラスタ内部で認証なしで動作します。外部 Redis はサポートされていません。
Ingress
ingress_type: "traefik" # Options: traefik, nginx, gateway-api, openshift
ingress_class_name: "traefik"
既定値は traefik で、K3s と共にインストールされます。標準的な VM デプロイでは、既定値のまま変更する必要はありません。
それ以外の選択肢は、独自の Ingress レイヤーを既に運用しているクラスタ向けです。これらを指定する場合、対応するコントローラーをインストーラー実行前に導入し、利用可能な状態にしておく必要があります。インストーラーがコントローラーをデプロイすることはありません。また K3s では、同梱の Traefik を無効化してください。無効化しないと、2 つのコントローラーがポート 80 と 443 を奪い合います。
ingress_class_name は、使用するコントローラーが実際に登録する IngressClass と一致させる必要があります（例: ingress-nginx コントローラーなら nginx）。
ノードアフィニティ
affinity_label_main_workload: ""
affinity_label_reporting_workload: ""
Platform as VM では、すべてが単一ノード上で動作するため、両方とも空のままにしてください。これらは、main ワークロードと reporting ワークロードを専用ノードプールに固定するマルチノードクラスタ向けの設定です。
ストレージクラス
k8s_storage_class: "local-path"
local-path は K3s の既定値で、永続ボリュームのデータを VM のローカルディスクに保存します。単一 VM デプロイにはこれが適切で、VM のスナップショットを取得すれば自動的にバックアップされます。
ホスト側で別のプロビジョナー（NFS、Longhorn、Ceph など）を既に導入している場合は、ここで切り替えられます。ただし、インストーラーを実行する前に導入と準備を完了させておく必要があります。
k8s_storage_class が適用されるのは、プラットフォームサービスの永続ボリューム要求（PVC）のみです。同梱の MariaDB、PostgreSQL、MongoDB、Kafka、Redis のチャートは local-path に固定されており、この設定を参照しません。そのため、ここで何を指定してもこれらのデータは VM のローカルディスクに残ります。
DNS のないエアギャップネットワーク
プラットフォームドメインをホストできる DNS サーバーがないネットワークに VM がある場合、インストーラーが K3s の内部 DNS にパッチを適用し、クラスタ内でドメインを正しく解決できるようにします。
openlm_system_domain: "openlm.internal"
tls_cert_path: "/etc/openlm/certs/tls.crt"
tls_key_path: "/etc/openlm/certs/tls.key"
add_coredns_hosts_entry: true
coredns_hosts_entry_ip: "10.20.30.40" # The VM's IP
エンドユーザーは何らかの方法で VM に到達する必要があります。IP で直接接続する、クライアントごとに hosts ファイルへエントリを追加する、もしくは社内 DNS サーバーを用意します。
passwords.yaml
postgres_password: "changeme"
mariadb_root_password: "changeme"
mongodb_root_password: "changeme"
これらのパスワードは、次の用途で使用されます。
- インストール時に同梱データベースを初期化する。
- プラットフォームサービスが同じパスワードで接続できるよう構成する。
データベースを使用しない場合（例: reporting_db_type が SqlServer_SQLServerAuth のとき）、対応するパスワードの値は無視されます。
パスワードはインストール時に組み込まれます。インストール後に passwords.yaml を変更しても、稼働中のデータベースは更新されません。以後は、各データベースのネイティブなコマンドでローテーションしてください。
構成例（全体）
パターン 1 – 既定の単一 VM、すべて同梱
最もシンプルなデプロイです。データベースを含め、すべてが 1 台の VM 上で動作します。
openlm_system_domain: "openlm.yourcompany.com"
tls_cert_path: "/etc/openlm/certs/tls.crt"
tls_key_path: "/etc/openlm/certs/tls.key"
# Everything else: defaults
パターン 2 – 両データベースロールを外部 SQL Server に配置
顧客が既存の SQL Server インスタンスを保有しているケースです。同梱の PostgreSQL と MariaDB はインストールされません。DBA は事前に 4 つのデータベースを作成するか、アプリケーションユーザーに作成権限を付与する必要があります。さらに、レポートスキーマの作成も必要です。
以下の値を使う場合、作成すべき 4 つのデータベースは次のとおりです。
| データベース | 作成する名前 |
|---|---|
| 運用 | openlm_operational_db_none（_none サフィックスに注意） |
| Identity | openlm_identity_db |
| DSS | openlm_dss_db |
| レポーティング | openlm_reporting_db |
openlm_system_domain: "openlm.yourcompany.com"
tls_cert_path: "/etc/openlm/certs/tls.crt"
tls_key_path: "/etc/openlm/certs/tls.key"
reporting_db_type: "SqlServer_SQLServerAuth"
reporting_db_host: "mssql.yourcompany.com"
reporting_db_port: 1433
reporting_db_username: "openlm_app"
reporting_db_password: "<real password>"
reporting_db_name: "openlm_reporting_db"
operational_db_type: "SqlServer_SQLServerAuth"
operational_db_host: "mssql.yourcompany.com"
operational_db_port: 1433
operational_db_username: "openlm_app"
operational_db_password: "<real password>"
operational_db_name: "openlm_operational_db"
identity_db_name: "openlm_identity_db"
dss_db_name: "openlm_dss_db"
パターン 3 – 外部 Kafka（例: AWS MSK）
既に運用しているイベントバスを OpenLM と共有させたい場合に有用です。
openlm_system_domain: "openlm.yourcompany.com"
tls_cert_path: "/etc/openlm/certs/tls.crt"
tls_key_path: "/etc/openlm/certs/tls.key"
kafka_bootstrap_servers: "b-1.mycluster.xxxxx.kafka.us-east-1.amazonaws.com:9092"
kafka_sasl_mechanism: "ScramSha512"
kafka_sasl_username: "openlm-user"
kafka_sasl_password: "<msk-password>"
kafka_security_protocol: "SASLSSL"
kafka_ssl_endpoint_algorithm: "https"
パターン 4 – 外部 DNS がないエアギャップネットワーク
VM が稼働するネットワークにプラットフォームドメインをホストできる DNS サーバーがない構成です。エンドユーザーは IP またはローカルの hosts エントリ経由でプラットフォームに到達します。
openlm_system_domain: "openlm.internal"
tls_cert_path: "/etc/openlm/certs/tls.crt"
tls_key_path: "/etc/openlm/certs/tls.key"
add_coredns_hosts_entry: true
coredns_hosts_entry_ip: "10.20.30.40"