起動・停止・再起動

データレイクを起動・停止する場所は2つあります。コンテナ自体はホストで、コンテナ内のサービス1つは**pd**で扱います。どちらを使うべきか先に決めてください。

行いたい操作	場所	コマンド
プラットフォーム全体を起動・停止	ホスト	`up.sh` · `down.sh` · `restart.sh`
設定・パスワードを変更した後、データレイクのみ再作成	ホスト	`restart-datalake.sh`
アプリ1つ（サーバー・バッチ・ウェアハウス）だけ再起動	ホスト	`restart-server.sh` · `restart-batch.sh` · `restart-warehouse.sh` · `restart-one.sh <서비스>`
データレイク内のサービス1つ（CEP・ワークフローなど）だけ再起動	コンテナ内	`pd restart <서비스>`
状態確認	ホスト / コンテナ内	`status.sh` / `pd status`

ホストの動詞

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

./up.sh                 # 기동 — 준비될 때까지 기다린다. 종료 코드 0 = 쓸 수 있다
./down.sh               # 정지 — 컨테이너 · 볼륨은 남는다
./restart.sh            # 전체 재시작 — graceful drain → 재기동 → 준비 대기. 인자를 받지 않는다
./restart-datalake.sh   # 데이터레이크만 — drain → 재생성 → 준비 대기 → 의존 앱 판정
./status.sh             # 컨테이너 · 헬스 · 볼륨 요약. 0 = 정상 / 2 = 비정상

動詞	終了コード0の意味	知っておくべきこと
`up.sh`	「使用可能」 — コマンド成功ではありません。準備判定が通るまで再確認します（デフォルト900秒、15秒間隔）	`PP_WAIT=0` の場合は待たず、その時の0は準備を意味しません
`restart.sh`	再起動後の準備完了	アプリ6つ・プロキシ・証明書コンテナまで全て。言語・タイムゾーンなどアプリにも影響する値を変更した時
`restart-datalake.sh`	データレイクが再びhealthy、その依存アプリも	コンテナ1つですがスタックイベントです — アプリ全てがここに接続を持っているため、終了後にアプリを判定し、自分で戻れないものだけもう一度restartします。起動と同じくらい時間がかかります
`status.sh`	正常	ボリューム・confは参照のみで終了コードに含めません

値を変更した場合はdocker restartではなくrestart-datalake.shです

サイドカー・ノードファイルの値はcomposeがコンテナを再作成する時に環境変数として入ります。docker restart plantpulse-datalakeは同じ環境変数で再起動するだけで、新しい値は入りません。

起動順序

コンテナ間

plantpulse-certs（TLS資材）→ plantpulse-datalake → アプリ6つ・プロキシ。アプリはデータレイクがhealthyになった後にのみ起動します。データレイクの起動猶予は900秒で、初回起動はAster TSDBスキーマ生成によりそれだけ時間がかかる場合があります。

データレイク内

コンテナが起動するとpd startが自動で動作します。

コアポート（6379・5432・9042）が既に開いている場合は「already running」として拒否。
必須シークレット15個（ワーカーは+1）が全て揃っているか確認。なければ名前を全て列挙してexit 3。
TLS資材確認（/var/security/plantpulse）。
設定レンダリング — テンプレート全てをPP_HOME配下の実ファイルへ。毎回、例外なく。
storage → analytics → messaging → timeseries → cep → workflow → data-gateway → admin-apiの順に起動し、それぞれヘルスチェックUPを待ちます。

最後の行が結果です。

datalake started: 8 service(s) ready. Logs: pd logs                                  # exit 0
datalake started with 1 service(s) not ready (7 ready). Check: pd status              # exit 6

停止順序

ホストのdown.sh・restart.shはアプリを先に停止し、データレイクをdrainします — コンテナ内でpd stopが逆順（admin-api → … → storage）でサービスを停止し、それぞれ「停止した」ことを証明します（30秒待機 → SIGTERM 15秒 → SIGKILL 10秒）。コンテナの停止猶予（stop_grace_period）は180秒です。

storageだけ停止して残りを残さないでください

上記の全サービスがstorageに接続しています。停止するなら全体を逆順に停止するpd stopが正しく、そうするならコンテナ自体を停止するホストのdown.shがより適切です。pd stop全体を「一時的に静かにするために」実行すると、コンテナのHEALTHCHECKが数分以内にunhealthyになり、ホスト側の監視が反応します。

サービス1つだけ — `pd`

docker exec plantpulse-datalake pd status            # 어느 것이 STOPPED 인가
docker exec plantpulse-datalake pd logs --lines 100 cep
docker exec plantpulse-datalake pd restart cep       # stop → 정지 증명 → 5초 → start

サービス	再起動すると
`storage`	依存する全てが接続を失います。可能ならホストの`restart-datalake.sh`で全体を
`analytics`	実行中のSQL・Sparkジョブが全て中断されます。アーカイブジョブが実行中なら終了後に
`messaging`	数秒間全てのメッセージ受信が停止します。コンシューマー（サーバー・CEP・バッチ）は自動再接続します
`timeseries` · `cep` · `workflow` · `data-gateway` · `admin-api`	そのサービスだけ。アプリは自動再接続

pd restartは停止を先に証明します。停止に失敗すると（exit 7）そこで停止します — その場合はpd kill --dry-run → pd kill → pd status → pd start。

状態確認を1行ずつ

./status.sh                                            # 호스트: 0 정상 / 2 비정상
docker ps --format 'table {{.Names}}\t{{.Status}}'      # 컨테이너와 (healthy)
docker exec plantpulse-datalake pd status              # 서비스 포트 표
curl -kfsS https://<server-ip>:4950/api/health | jq .status   # 콘솔 헬스 API

「Upなのに死んでいる」 — メモリOOM

コンテナ内のPID 1がsystemdのため、JavaプロセスだけがcgroupでOOM-killされ、docker psはしばらくUp (healthy)を表示した後に遅れてunhealthyになります。pd statusが全てSTOPPEDなのにコンテナが生きている場合は、まずこれを疑ってください。

dmesg -T | grep -i "memory cgroup"                                   # 호스트
docker inspect plantpulse-datalake --format '{{.State.OOMKilled}}'

上限を引き上げる方法は設定変更方法 — メモリにあります。

自動起動

コンテナはrestart: alwaysのため、ホストが再起動するとDockerデーモンが自動的に起動します。別途systemdユニットは不要です。ただしdown.shで意図的に停止したスタックは再起動後も停止したままです — up.shで起動してください。

ホストの動詞​

起動順序​

コンテナ間​

データレイク内​

停止順序​

サービス1つだけ — pd​

状態確認を1行ずつ​

自動起動​

関連ドキュメント​