起動・停止・再起動

データレイクの操作は2つの場所で行います。コンテナ自体はホストから、コンテナ内のサービスは**pd**で操作します。どちらを使うか最初に決めてください。

作業内容	実行場所	コマンド
プラットフォーム全体の起動・停止	ホスト	`up.sh` · `down.sh` · `restart.sh`
設定またはパスワード変更後、データレイクのみ再構築	ホスト	`restart-datalake.sh`
単一アプリ(サーバ・バッチ・ウェアハウス)のみ再起動	ホスト	`restart-server.sh` · `restart-batch.sh` · `restart-warehouse.sh` · `restart-one.sh <서비스>`
データレイク内の単一サービス(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、依存するアプリも	単一コンテナですがスタックイベントです — 全アプリがここに接続を持っているため、完了後にアプリを判定し、自動復旧できなかったものだけ再度restartします。起動時間と同程度かかります
`status.sh`	正常	ボリューム・設定は報告のみで終了コードには含まれません

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

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

起動順序

コンテナ間

plantpulse-certs(TLS資材) → plantpulse-datalake → 6つのアプリ・プロキシ。アプリはデータレイクがhealthyになってから起動します。データレイクの起動猶予は900秒で、初回起動時はCassandraスキーマ作成に同程度の時間がかかる場合があります。

データレイク内

コンテナが起動すると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になり、ホスト側の監視が反応します。

単一サービスのみ — `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で起動してください。

ホストコマンド​

起動順序​

コンテナ間​

データレイク内​

停止順序​

単一サービスのみ — pd​

状態確認 (1行単位)​

自動起動​

関連ドキュメント​