Docker インストール

概要

このページは PlantPulse Platform を Docker Compose スタックとして 手動（ステップバイステップ）インストールする方法と、閉域網（Airgap）インストール方法を説明します。

通常の環境ではワンラインインストールを推奨します。ワンラインインストールはパッケージのダウンロードから環境の自動検出、インストール、ブート検証まで一度に処理します。以下のような場合にのみ、このページの手動手順をご使用ください。

各インストールステップを直接レビュー・承認しながら進める必要がある場合（セキュリティ審査、変更管理プロセスなど）
環境変数（bin/env.sh）を自動検出値ではなく任意の値で指定する必要がある場合
インターネットが遮断された閉域網環境にインストールする場合 → 閉域網（Airgap）インストール

インストール結果 — コンテナ9個

プラットフォームは docker compose スタック1つ で動作します。正本は compose/docker-compose.yml であり、運営スクリプトもすべてこのファイルを経由してコンテナを制御します。

コンテナ	レイヤ	役割
`plantpulse-certs`	証明書	TLS 資材を焼き、終了するワンショット。正常な状態は `Exited (0)` です
`plantpulse-datalake`	インフラ	ストレージ・メッセージング・分析・CEP・SQL・モニタ
`plantpulse-server-web`	アプリケーション	ウェブコンソール
`plantpulse-batch-web`	アプリケーション	バッチ
`plantpulse-warehouse`	アプリケーション	データウェアハウス
`plantpulse-plugin-opcua-server`	アプリケーション	OPC-UA サーバプラグイン (11004 / 11005)
`plantpulse-plugin-aasx-server`	アプリケーション	AASX サーバプラグイン
`plantpulse-ha`	アプリケーション	デュプリケーションリカバリデーモン (10210)
`plantpulse-proxy`	エッジ	ユーザがアクセスする唯一のエントリポイント (80 / 443 / 1883 / 1884)

常駐コンテナは8個です

plantpulse-certs は証明書を作成して自身で終了するワンショットなので Exited (0) が正常です。docker ps には残りの8個が (healthy) として見えれば正常です。ワンショットを「死んだコンテナ」と誤解しないでください — status.sh と ops-check.sh はこのコンテナのみ終了コードで判定します。

このほか、ミラーリング用の plantpulse-mirror-maker が compose に定義されていますが、mirror プロファイルに束ねられているため デフォルトでは起動しません。

以前の単一コンテナ構成は廃止されました

2026-08-29 以前は、すべてのコンポーネントが plantpulse-platform コンテナ1つで一緒に動作する「モノリシック」構成を選択できました。この構成は廃止され、選択変数（PP_TOPOLOGY）と compose ファイルも一緒に削除されました。今は選択肢がありません — bin/up.sh が上記スタックを起動します。

旧ランブックに残る docker logs plantpulse-platform のようなコマンドは その名前のコンテナがないため動作しません。 代替コマンドは運営コマンド概要にあります。

アプリごとにコンテナを分けた第一の目的は OOM 隔離です。1つのアプリがメモリを使い切っても、他のアプリとインフラは生き続け、アプリ単位で再起動・ロールバックできます。

事前準備

インストールを開始する前に、以下の項目をご確認ください。

項目	要件
アカウント権限	root（または sudo 権限）。インストールスクリプトが OS 設定と Docker デーモンを構成します
オペレーティングシステム	RHEL/Rocky/Oracle Linux 8·9, Ubuntu 20.04+, Amazon Linux 2/2023
Docker	Compose v2 が必要です (`docker compose` — ハイフンなし形式)。`install.sh` がなければインストールします
データディスク	`/data1` パスに大容量ディスクをマウントすることを推奨 — Docker データ(`/data1/docker-data`)とプラットフォームデータボリュームがこのパスを使用します
レジストリアクセス	`docker.kopens.io` (イメージレジストリ)、`product.kopens.io` (インストールパッケージ) に HTTPS でアクセス可能である必要があります。アクセスがブロックされている環境は閉域網インストールをご使用ください
レジストリ資格	`docker.kopens.io` ログイン資格 (KOPENS 運営チームが発行)

ディスクパス案内: 別のデータディスクがない場合は、ルートディスクに /data1 ディレクトリを作成しても動作しますが、運用環境では専用ディスクを /data1 にマウントすることをお勧めします。

手動インストール手順

ステップ1：インストールパッケージをダウンロード

ダウンロードサーバからインストールパッケージ(tar.gz)を取得し、標準パスに展開します。Git クローンや別のツールインストールは必要ありません。

sudo -i

# 표준 설치 경로 생성 후 패키지 다운로드 + 압축 해제
mkdir -p /opt/kopens/plantpulse-platform-docker
curl -fsSL "https://product.kopens.io/plantpulse-platform/plantpulse-platform-docker.tar.gz" \
  | tar -xz -C /opt/kopens/plantpulse-platform-docker --strip-components=1

cd /opt/kopens/plantpulse-platform-docker/bin
chmod +x *.sh tools/*.sh

パッケージの中で実際に使用する場所は2箇所です。

位置	内容
`bin/`	インストール・運営スクリプト全体
`compose/`	スタック正本 `docker-compose.yml` とクラスタワーカーオーバーレイ

ステップ2：事前点検 (preflight)

preflight.sh は システムをまったく変更せず インストール可能性のみ確認します。

./preflight.sh

点検項目：

Docker インストール/デーモン動作状況 (未インストールでも問題なし — install.shがインストールします)
Docker data-root 親パス(/data1) 存在確認
シークレットサイドカー(/etc/kopens/plantpulse-platform.env) 存在確認
主要な運営ポート(80, 443, 7443, 4949, 4950) 使用状況

OK のみが出力されれば次のステップに進みます。ERROR がある場合はトラブルシューティングを参照してください。(WARN は参考用であり、インストールを阻止しません。)

ステップ3：環境変数の確認 (env.sh)

bin/env.sh が ホスト側 設定の正本です。コンテナが実際に参照する値は compose/docker-compose.yml が決めます — 詳細な関係は環境変数リファレンスをご参照ください。

vi env.sh

リソース値はほとんど「計算」されます — 変更することはほぼありません

env.sh はホストを調査して CPU・メモリ・ディスクを自動的に決定します。固定デフォルト値ではなく、手を加えなくても小さいボックスでは小さい値が設定されます。ボックスごとに指定された値が常に優先されます。

変数	どのように決定されるか	いつ変更するか
`DOCKER_PP_CPUS`	`nproc` (読み取り失敗時 `8`)	コンテナに割り当てるコアを減らしたいとき
`DOCKER_PP_CLUSTER_CORES`	`DOCKER_PP_CPUS - 2`、最小4・最大30	通常そのままにします
`DOCKER_PP_MEMORY`	ホスト RAM の 90%、最小 `8G`	OS 用により多く確保したいとき
`DOCKER_DATALAKE_MEMORY`	`80G`。ホストがそれより小さい場合は RAM の 90%	データレイク上限調整
`DOCKER_PP_DATA_DISK_NAME`	`/` を支える実際のディスクを自動逆推探 (失敗時 `sda`)	自動検出が間違っているとき
`PP_LANG`	`en`	日本語運用の場合 `ko`
`PP_TZ`	`Asia/Seoul`	海外ボックス
`DOCKER_PP_EXTERNAL_IP`	空の値	NAT 環境で外部グローバル IP を指定する必要がある場合のみ

DOCKER_PP_EXTERNAL_IP に無効な IP を設定しないでください

この値は PP_SERVICE_IP を経由して TLS 証明書の SAN リストに入ります。形式が一致しない IP が1つでも混在すると、openssl は拡張ファイル全体を拒否し、証明書が1つも生成されず、スタックが起動できません。NAT 背後でなければ、空のままにしてください — それがデフォルト値です。

現在のサーバの値は、以下のコマンドで確認できます。

hostname -I | awk '{print $1}'          # 서버 IP
free -g | awk '/^Mem:/{print $2"G"}'    # 전체 메모리
nproc                                    # CPU 코어 수
lsblk                                    # 디스크 이름 (sda, sdb, nvme0n1 …)

日本語運用のボックスで通常変更するのは2行だけです。

export PP_LANG=ko
export PP_TZ=Asia/Seoul

ロケールはブート時点にのみ反映されます

PP_LANG / PP_TZ は JVM ブート時間に固定されます。既に動作しているスタックで変更する場合は ./restart.sh が必要です。また、Cassandra 時系列が KST epoch で格納されるため、日本語運用では Asia/Seoul を維持してください。

ステップ4：インストール実行 (install.sh)

sudo ./install.sh

install.sh 1つでインストール全体を自動実行します。

OS 検出およびシステム設定 — ファイル制限(limits)、カーネルパラメータ(sysctl)、時間同期(chrony)、SELinux permissive 切り替え、swap 無効化
Docker Engine インストール — OS 別パッケージマネージャでインストール + data-root を /data1/docker-data に設定 (Compose v2 がなければ一緒にインストール)
ファイアウォール設定 — 公開ポート(80/443/7443/4949/4950)を開き、内部ポートはプライベートネットワーク範囲のみからアクセス可能に制限
サービス資格生成 — /etc/kopens/plantpulse-platform.env シークレットサイドカー生成 (権限 0600、再実行しても既存値を上書きしない)
レジストリログイン — docker.kopens.io 資格入力 (既にログイン済みなら自動スキップ)
スタック起動 — ネットワーク/ボリューム作成 → イメージ pull → 設定テンプレートシード → docker compose up -d

インストール時の一度限りのオプション (必要に応じて環境変数で指定):

オプション	効果
`SKIP_OS=1`	OS 設定・Docker インストールをスキップ (Docker が既にインストール・運用中の場合)
`SKIP_LOGIN=1`	レジストリログインをスキップ (既にログイン済みまたはイメージがローカルにある場合)
`SKIP_FW=1`	ファイアウォール設定をスキップ (ファイアウォールを別途管理する場合)
`DOCKER_DATA_DIR=<path>`	Docker data-root 変更 (デフォルト `/data1/docker-data`)

# 예: Docker가 이미 설치된 서버
SKIP_OS=1 sudo -E ./install.sh

資格情報を交換する場合は「インストール前」に行う必要があります

シークレットサイドカー(/etc/kopens/plantpulse-platform.env)は export VAR=값 形式の無条件代入なので、シェル export を上書きします。 インストール完了後のノードで PP_PG_PASSWORD=... ./up.sh は静かに無視されます。納品時の交換はインストール前に export PP_*_PASSWORD=... で、インストール完了後はパスワードローテーションの passwd.sh で行ってください。

ステップ5：起動とブート検証

install.sh はスタックを起動して戻ります。ブートが完了したかは別途確認する必要があります。

./up.sh

up.sh は冪等なので、既に起動していても安全であり、準備できるまで待ちます。 終了コード 0 は「コマンドが成功した」ではなく、「これで使用できる」 という意味です。

環境変数	デフォルト値	意味
`PP_READY_TIMEOUT`	`900`	準備待機上限(秒)
`PP_READY_INTERVAL`	`15`	確認間隔(秒)
`PP_WAIT=0`	—	待機しない。このときの `0` は準備完了を意味しません

最初のクリーンインストールは15～18分かかります

プロセス起動自体は3～5分(JVM ウォームアップ)ですが、すべてのコンポーネントが安定するまでには15～18分かかります。Cassandra スキーママイグレーションと安定化が最も遅いです。再起動はスキーマが既にあるため、ずっと速いです。

実測基準(2026-08-31, 32 vCPU / 128GiB): データレイク 217秒、ウェブサーバ 316秒。

準備判定を直接実行することもできます。

./stack-verify-boot.sh

このスクリプトは 1つのコンテナではなく、スタック全体を確認します — ワンショットが正常に終了したか、データレイクとアプリが running·healthy か、プロキシが 443 をサービスしているかまで確認します。

ステップ6：状態・運用確認

./status.sh      # 0 = 정상 / 2 = 비정상
./ops-check.sh

status.sh はサービスリスト・コンテナ状態・health・ボリュームを要約します。終了コードが仕様です — 自動化でそのまま使用できます。

判定	何を異常と見なすか
サービスリストが読めない	compose 解析失敗または docker アクセス不可
compose が宣言したサービスにコンテナがない	起動されていない
常駐コンテナが `running` ではない	ワンショット(`plantpulse-certs`)は除外
常駐コンテナの health が `unhealthy`	`starting` / `none` は判定保留
ヘルス API が OK ではない	データレイク内の probe

ボリュームと conf は 報告のみで終了コードに含めません — 2ノード分離インストール(PP_TIER=APP)では一部が存在しないのが正常だからです。

ops-check.sh はこれに加えて最近の致命的ログ(OOM、FATAL、SSL エラーなど)もスキャンします。

ヘルス確認

モニタ API は plantpulse-datalake コンテナがサービスします。どこから問い合わせるかによってコマンドが異なります。

# 컨테이너 안에서 — 어떤 구성에서도 동작하는 방법
docker exec plantpulse-datalake curl -kfsS https://127.0.0.1:4950/api/health | jq

# 호스트/외부에서 — 4950 이 publish 되어 있습니다
curl -kfsS https://<server-ip>:4950/api/health | jq

"status" が OK または WARN なら正常範囲であり、FAIL なら障害です。

別のポートではヘルスを見ることはできません

コンソールとヘルス API は 両ポートすべてでサービスされます — 4950(HTTPS)と 4949(平文 HTTP)。同じコンソール・同じ API で、スキームだけが異なります。4949 はもはや 4950 にリダイレクトしません。

4949 は平文です — ログインパスワードとセッションクッキーがそのまま流れます。信頼できないネットワークでは 4950 を使用してください。4949 は自己署名証明書の警告が実際に運用者を止めてしまうボックス向けの選択肢です。

インストール結果

ネットワークとボリューム

リソース	名前	用途
ネットワーク	`pp-net`	プラットフォーム専用 Docker ネットワーク (デフォルト `10.99.0.0/24`、ゲートウェイ `10.99.0.1`)
ボリューム	`pp-data`	データ永続化保存 (Cassandra、PostgreSQL、Kafka など)
ボリューム	`pp-temp`	一時データ (Spark、Hive 作業スペース)
ボリューム	`pp-backup`	バックアップ保存庫
ボリューム	`pp-security`	TLS 証明書・キーストア。`plantpulse-certs` が書き込み、残りは読み取り専用でマウントします
ボリューム	`pp-proxy-certs`	プロキシが 443 に書き込む証明書

ボリュームはコンテナを停止または削除してもアップデート・再インストール時にも 常に保存されるため、データが保持されます。

ホストディレクトリ

パス	用途
`/opt/kopens/plantpulse-platform-docker`	インストール・運営スクリプトと compose 正本
`/etc/kopens/conf`	プラットフォーム設定テンプレート (ホストバインドマウント)。最初の実行時にイメージから自動シードされ、以降運用者がホストから直接編集でき、再インストール時も保存されます
`/etc/kopens/plantpulse-platform.env`	サービス資格シークレットサイドカー (権限 0600)
`/etc/kopens/platform.node.env`	ノード別アイデンティティ(`PP_TIER` など)。ノード間のコピー禁止
`/etc/kopens/ca`	共有クラスタ CA (2ノード分離インストールで使用)

アクセスアドレス

用途	アドレス
ウェブコンソール	`http://<server-ip>/` · `https://<server-ip>/` — `plantpulse-proxy` が受け取ります
管理 UI	`https://<server-ip>:7443`
モニタ UI · ヘルス	`https://<server-ip>:4950/api/health`
MQTT	`<server-ip>:1883` (平文) · `<server-ip>:1884` (TLS)
OPC-UA	`<server-ip>:11004` · `<server-ip>:11005`

セキュリティ案内: ウェブコンソール初回ログイン後は、必ずデフォルト管理者パスワードを変更してください。→ 初期パスワード

運営コマンド概要

日常運営に使用するコマンドです。すべて /opt/kopens/plantpulse-platform-docker/bin/ で実行します。すべての動詞が --help をサポートしています。

作業	コマンド	備考
状態確認	`./status.sh`	サービス / health / ボリューム概要。0=正常 / 2=異常
運営確認	`./ops-check.sh`	コンテナ health + ヘルス API + 最近の致命的ログ
起動	`./up.sh`	冪等。0 = 準備完了
停止	`./down.sh`	状態保存
再起動	`./restart.sh`	graceful drain → 停止 → 起動 → 準備待機
ログ表示	`./logs.sh [서비스]`	最後の 200 行を出力して終了。追従するには `-f`。引数がなければすべてのコンテナ。リストは `--list`
コンテナ進入	`./shell.sh [서비스]`	引数がなければデータレイク
イメージ更新	`./update.sh`	pull + 再作成。失敗時は以前のイメージに自動ロールバック
完全削除	`./remove.sh`	コンテナのみ削除 (ボリューム・設定保存)。`RM_IMAGE=1` / `RM_NETWORK=1`
バックアップ	`./backup.sh [볼륨 …]`	デフォルト `pp-data` · `pp-security`
ブート検証	`./stack-verify-boot.sh`	スタック全体準備判定
診断バンドル	`./doctor.sh`	サポートリクエスト用 tarball。シークレット値はマスキングされます
パスワード変更	`./passwd.sh --list`	変更可能なキーリスト

# 운영 중 빠른 점검 루틴
cd /opt/kopens/plantpulse-platform-docker/bin
./status.sh
./ops-check.sh

# 문제가 의심되면 진단 번들 생성
./doctor.sh

古い名前も引き続き動作します

stack-run.sh · stack-stop.sh · stack-bash.sh · stack-update.sh · stack-remove.sh は削除されていません。直接実行すると新しい名前を1行で案内するだけで、動作は同じです。既存カスタマーランブックを一括修正する必要はありません。

注意 — ボリューム全体削除: ./tools/remove-all-volumes.sh はすべてのデータを永久に削除します。必ずバックアップ完了後にのみ使用してください。

閉域網(Airgap)インストール

インターネットが遮断されている環境では、3つのステップでインストールします：バンドル確保 → メディアで移動 → 閉域網サーバでロード。

ステップ1：バンドル確保

推奨される方法は KOPENS が発行したバンドルをダウンロードすることです。

https://product.kopens.io/plantpulse-platform/plantpulse-platform-images-<version>.tar.gz

インターネットが利用できるサーバで直接作成する必要がある場合は、以下を使用してください。

cd /opt/kopens/plantpulse-platform-docker/bin
./airgap-bundle.sh

# 옵션
INCLUDE_DATALAKE=1 ./airgap-bundle.sh    # datalake 이미지까지 포함
OS_TARGET=both ./airgap-bundle.sh        # 대상 서버가 Ubuntu인 경우 deb 패키지도 포함 (기본은 RHEL rpm)

出力物は plantpulse-platform-images-<version>.tar.gz 1つのファイルであり、次のすべてが含まれます。

Docker Engine オフラインインストールパッケージ (rpm / deb)
プラットフォームイメージ (docker save の結果)
repo/ — インストール・運営スクリプトと compose/ 全体

ステップ2：閉域網サーバへの移動

USB、内部ファイルサーバ、scp など許可されたメディアで .tar.gz ファイルをターゲットサーバに転送します。

ステップ3：閉域網サーバでのロードおよびインストール

sudo -i
mkdir -p /opt/kopens/plantpulse-platform-docker
tar -xzf plantpulse-platform-images-*.tar.gz -C /opt/kopens/plantpulse-platform-docker

cd /opt/kopens/plantpulse-platform-docker/repo/bin
vi env.sh                  # 3단계 환경 변수 검토와 동일하게 수정
./airgap-load.sh

airgap-load.sh が自動的に実行します。

Docker Engine オフラインインストール (rpm -ivh / dpkg -i) — 既にインストール済みならスキップ
プラットフォームイメージ docker load
install.sh 呼び出し (SKIP_LOGIN=1 — イメージが既にローカルにあるため、レジストリログイン不要)

インストール後のブート検証(./up.sh または ./stack-verify-boot.sh)と運営確認(./ops-check.sh)は手動インストールと同じ方法で進めてください。

閉域網更新

新しいバージョンイメージを含むバンドルを同じ手順で作成し、転送・ロードした後、既存コンテナを ./update.sh で再作成します。

トラブルシューティング

preflight 点検に失敗する場合

メッセージ	対処
`docker is installed but daemon is not ready while SKIP_OS=1`	Docker デーモンを先に起動してください：`systemctl start docker`。または `SKIP_OS` なしで実行すれば `install.sh` が Docker を構成します
ポートが既に使用中 (WARN)	そのポートが別のサービスで使用されています。`ss -tlnp \| grep :<port>` でプロセスを確認し、プラットフォームインストール前にクリアしてください
Docker data-root 親パスなし (WARN)	`/data1` ディレクトリがありません。データディスクを `/data1` にマウントするか、ディレクトリを作成してください

スタックが起動しない場合

docker compose up -d は depends_on 条件をすべて待つため、ヘルスチェックに合格しないコンテナが1つあれば、全体コマンドが1行だけ残して失敗します。

dependency failed to start: container plantpulse-server-web is unhealthy

この1行はコンテナ名以外のことを何も知らせません。運営スクリプトはこの時点でコンテナリスト・状態・health probe 出力・各ログテールを自動的に一緒に出力するため、まずその出力をお読みください。直接確認する場合は：

cd /opt/kopens/plantpulse-platform-docker/bin

# 어떤 컨테이너가 어떤 상태인가
./status.sh

# 문제가 있는 컨테이너의 로그
./logs.sh --list                       # 볼 수 있는 서비스 목록
./logs.sh plantpulse-server-web -n 200

# 자원 상황
df -h
docker stats --no-stream

よく確認される原因：

原因	確認
メモリ不足(OOM)	`docker inspect <컨테이너> --format '{{.State.OOMKilled}}'`。アプリ別 `mem_limit` は環境変数リファレンスを参照
ディスク満杯	`/data1` 空きスペース
必須資格情報なし	compose がパスワードを `:?` で要求します。空の場合、スタックは半分立ち上がらず、まったく立ち上がりません — `install.sh` を先に実行してサイドカーを作成してください
DB 初期化遅延	最初のインストールはスキーマ作成のため時間がかかります。ログにエラーなく進行中なら、もう少しお待ちください

原因の特定が難しい場合は、./doctor.sh で診断バンドルを生成してテクニカルサポートに添付してください。診断バンドルはすべてのコンテナの状態とログを含みます。

TLS ハンドシェイクが `TimeoutException` に見える場合

アプリがバックエンドに接続するときに使用する名前が証明書 SAN リストにない場合、エラーメッセージに証明書について何も表示されず、タイムアウトのように見えます。コンテナ名を変更したか、バックエンドホストを直接指定した場合は、このケースを疑ってください。証明書を再焼成する方法はセキュリティ管理にあります。

レジストリ認証失敗

# unauthorized 오류 시 재로그인
docker login docker.kopens.io

ログイン資格がないか有効期限切れの場合は、KOPENS 運営チームに発行をリクエストしてください。
社内ファイアウォールがレジストリアクセスをブロックしている可能性があります。ネットワーク管理者に docker.kopens.io、product.kopens.io ドメインの HTTPS アクセス許可をリクエストしてください。
外部アクセスが原点からブロックされている環境の場合は閉域網(Airgap)インストールをご使用ください。

テクニカルサポート

インストールおよび運営プロセス中に支援が必要な場合は、いつでもお気軽にお問い合わせください：webmaster@kopens.com

概要​

インストール結果 — コンテナ9個​

事前準備​

手動インストール手順​

ステップ1：インストールパッケージをダウンロード​

ステップ2：事前点検 (preflight)​

ステップ3：環境変数の確認 (env.sh)​

ステップ4：インストール実行 (install.sh)​

ステップ5：起動とブート検証​

ステップ6：状態・運用確認​

ヘルス確認​

インストール結果​

ネットワークとボリューム​

ホストディレクトリ​

アクセスアドレス​

運営コマンド概要​

閉域網(Airgap)インストール​

ステップ1：バンドル確保​

ステップ2：閉域網サーバへの移動​

ステップ3：閉域網サーバでのロードおよびインストール​

閉域網更新​

トラブルシューティング​

preflight 点検に失敗する場合​

スタックが起動しない場合​

TLS ハンドシェイクが TimeoutException に見える場合​

レジストリ認証失敗​

テクニカルサポート​

概要