Startanleitung

Übersicht

Nachdem Sie die PlantPulse-Plattform durch One-Line-Installation oder Docker-Installation bereitgestellt haben, befinden sich alle Betriebsskripte im Verzeichnis /opt/kopens/plantpulse-platform-docker/bin/. Diese Seite führt Sie durch den Start und Betrieb der Plattform, die als Docker Compose Stack ausgeführt wird.

Die Plattform besteht aus neun Containern — ein Zertifikat-One-Shot, ein Data Lake, sechs Apps und ein Proxy. Die gesamte Konfiguration finden Sie unter Docker-Installation — Stapelform.

Wenn Sie alte Skriptnamen verwenden

Die Namen auf der linken Seite existieren nicht mehr. Verwenden Sie bitte die gemeinsamen Verben auf der rechten Seite.

Alter Name	Jetzt verwenden
start.sh	up.sh
platform-stop.sh	down.sh
platform-update.sh	update.sh
platform-remove.sh	remove.sh
platform-bash.sh	shell.sh
platform-verify-boot.sh	stack-verify-boot.sh
worker-run.sh · worker-stop.sh · worker-update.sh · worker-bash.sh	Siehe Arbeiterverwaltung

stack-run.sh · stack-stop.sh · stack-bash.sh · stack-update.sh · stack-remove.sh funktionieren weiterhin (neue Namen werden bereitgestellt und führen dann die gleiche Aufgabe aus).

Umgebungsvariablen konfigurieren

Überprüfen Sie vor dem Start der Plattform die Umgebungsvariablen. Ressourcenwerte werden während der Installation automatisch basierend auf dem Host berechnet, daher gibt es auf den meisten Servern nur wenig zu ändern.

vi /opt/kopens/plantpulse-platform-docker/bin/env.sh

Häufig angepasste Elemente

Variable	Beschreibung	Standardwert
PP_LANG	Plattform-Gebietsschema (ko / en)	en
PP_TZ	Plattform-Zeitzone	Asia/Seoul
DOCKER_PP_CPUS	vCPU-Anzahl für Container	nproc Ergebnis
DOCKER_PP_MEMORY	Speichergrenzwert	90 % des Host-RAM
DOCKER_DATALAKE_MEMORY	Data-Lake-Speichergrenzwert	80G (90 % des RAM bei kleinem Host)
DOCKER_PP_DATA_DISK_NAME	Name der Datenfestplatte	Automatische Rückverfolgung (bei Fehler sda)
DOCKER_PP_EXTERNAL_IP	Externe Advertise-IP in NAT-Umgebung	Leerer Wert

Die vollständige Liste der Umgebungsvariablen finden Sie auf der Seite Umgebungsvariablen-Referenz.

Änderungen anwenden: Nach der Änderung von env.sh müssen Sie mit ./restart.sh neu starten, damit die neuen Einstellungen wirksam werden.

Passwörter können nicht mit env.sh geändert werden

Im Cluster ist der Secret Sidecar (/etc/kopens/plantpulse-platform.env) auf einem installierten Knoten überschreibt sowohl env.sh als auch Shell-Export. Verwenden Sie zur Passwortänderung passwd.sh unter Passwortrotation.

Plattform starten

Start nach Erstinstallation

Nach Abschluss der Installation (install.sh) wird der Stack bereits ausgeführt. Überprüfen Sie einfach den Status.

cd /opt/kopens/plantpulse-platform-docker/bin
./status.sh
./ops-check.sh

Gestoppten Stack starten

Wenn der Stack durch ./down.sh oder Neustart des Hosts gestoppt wurde, starten Sie ihn erneut.

cd /opt/kopens/plantpulse-platform-docker/bin
./up.sh

up.sh ist idempotent und wartet bis es bereit ist. Exit-Code 0 bedeutet nicht «Befehl erfolgreich», sondern «jetzt verwendbar».

Umgebungsvariable	Standardwert	Bedeutung
PP_READY_TIMEOUT	900	Bereitschafts-Wartelimit (Sekunden)
PP_READY_INTERVAL	15	Überprüfungsintervall (Sekunden)
PP_WAIT=0	—	Nicht warten (0 bedeutet nicht «bereit»)

Die Daten in Volumes (pp-data, pp-temp, pp-backup, pp-security, pp-proxy-certs) werden beibehalten. Vorlagen/Konfigurationen werden durch Host-Bind-Mounts (/etc/kopens/conf) verwaltet.

Startreihenfolge

Container werden in der durch depends_on der Compose definierten Reihenfolge gestartet. Dies ist eine service_healthy-Bedingung, daher wird auf «verwendbar» gewartet, nicht nur darauf, dass der Prozess läuft.

plantpulse-certs        (완료까지 — 원샷)
      │
plantpulse-datalake     (healthy 까지)
      │
plantpulse-server-web   (healthy 까지) ──── plantpulse-proxy
      │
plantpulse-batch-web    (healthy 까지)
      │
      ├── plantpulse-warehouse
      ├── plantpulse-plugin-opcua-server
      ├── plantpulse-plugin-aasx-server
      └── plantpulse-ha        (이 넷은 서로 순서가 없습니다)

Infrastrukturkomponenten werden im Data-Lake-Container wieder in Reihenfolge gestartet.

Reihenfolge	Kategorie	Komponente
1	Speicher	Valkey (Redis), PostgreSQL, Cassandra, MinIO
2	Analyse	Spark, Hadoop, Hive, Kyuubi, Gravitino
3	Zeitreihe	Zeitreihe-Engine, Zeitreihe-UI
4	Messaging	Kafka, MQTT
5	Workflow	Temporal, Kestra
6	Verarbeitung	CEP, Data Gateway, SQL, Monitor

Zeitaufwand

Der Prozessstart selbst dauert 3–5 Minuten (JVM-Aufwärmphase), aber eine saubere Installation braucht 15–18 Minuten, bis alle Komponenten stabil sind. Cassandra-Schemamigration und Stabilisierung sind am langsamsten.

Gemessene Werte (31.08.2026, 32 vCPU / 128GiB): Data Lake 217 Sekunden, Web-Server 316 Sekunden. Ein Neustart mit bereits vorhandenen Daten ist viel schneller.

Boot-Validierung

cd /opt/kopens/plantpulse-platform-docker/bin
./stack-verify-boot.sh

stack-verify-boot.sh bewertet den gesamten Stack, nicht nur einen Container — ob der One-Shot ordnungsgemäß beendet wurde, ob Data Lake und Apps im Status running·healthy sind und ob der Proxy Port 443 bedient. Das Skript erkennt die Node-Stufe (PP_TIER — FULL / DATALAKE / APP) und validiert nur die dieser Stufe entsprechenden Komponenten.

up.sh und restart.sh warten mit Polling auf dieses Skript, daher bedeutet das Exit-Code 0 dieser beiden Befehle «verwendbar».

Normalen Start überprüfen

# 서비스 / health / 볼륨 요약 (0 = 정상 / 2 = 비정상)
./status.sh

# 운영 health + 최근 critical log 점검
./ops-check.sh

# 헬스체크 엔드포인트 직접 호출
curl -kfsS https://<server-ip>:4950/api/health | jq

# Docker 상태
docker ps

Wenn acht von docker ps den Status (healthy) haben und plantpulse-certs den Status Exited (0) hat, ist alles normal. Der Status Exited (0) des One-Shot ist ein Erfolgszustand, keine Störung.

Plattform stoppen

cd /opt/kopens/plantpulse-platform-docker/bin
./down.sh

Den Stack sicher stoppen. Daten werden in Docker-Volumes beibehalten, daher wird der vorherige Zustand wiederhergestellt, wenn Sie mit ./up.sh neu starten.

Warnung: docker kill oder erzwungenes Herunterfahren des Hosts können die Datenkonsistenz beeinträchtigen. Verwenden Sie unbedingt ./down.sh.

Plattform neu starten

cd /opt/kopens/plantpulse-platform-docker/bin
./restart.sh

Interne Komponenten werden elegant beendet (Drain), der Stack wird in umgekehrter Abhängigkeitsreihenfolge gestoppt, dann in depends_on-Reihenfolge neu gestartet und warten auf Bereitschaft.

Verwenden Sie dies bei env.sh-Änderungen, zur Behebung vorübergehender Probleme während des Betriebs oder für regelmäßige Neustarts.

Servicestatus überprüfen

Gesamtübersicht

./status.sh

Zeigt Service-Liste, Container-Status, Health-Ergebnisse und Volume-Informationen auf einmal an. Der Exit-Code ist vertraglich — 0 ist normal, 2 ist abnormal, daher können Sie ihn direkt in der Überwachungsautomatisierung verwenden.

Betriebsprüfung

./ops-check.sh

Überprüft Container-Health, Health-API-Antworten und aktuelle Critical-Logs zusammen. Durchsucht alle acht Container.

Host-seitige Ressourcenprüfung

docker stats --no-stream        # 컨테이너별 CPU / 메모리
docker ps                       # 컨테이너 상태

Jeder Container hat separate mem_limit-Grenzen, daher können Sie für jeden Container einzeln überprüfen, welcher die Grenze erreicht hat. Die Grenzen pro App finden Sie in der Umgebungsvariablen-Referenz.

In Container einsteigen

cd /opt/kopens/plantpulse-platform-docker/bin
./shell.sh                          # 인자가 없으면 데이터레이크
./shell.sh plantpulse-server-web    # 특정 컨테이너

Die Liste der zugänglichen Services überprüfen Sie mit ./status.sh.

Cluster-Worker befinden sich nicht auf dieser Liste

shell.sh interpretiert nur Services des Standard-Stacks nach Namen. Worker befinden sich in den generierten Overlays (compose/docker-compose.worker.yml), daher greifen Sie mit docker exec -ti plantpulse-worker-<n> /bin/bash zu.

Komponentenweise Neustarts

Da Container aufgeteilt sind, gibt es zwei Möglichkeiten zum Neustart.

Sechs Apps — Container-weise neu starten

Apps laufen jeweils in ihrem eigenen Container, daher ist das Neustart des Containers gleichbedeutend mit dem Neustart dieser App. Andere Apps und die Infrastruktur sind nicht betroffen.

cd /opt/kopens/plantpulse-platform-docker
docker compose -f compose/docker-compose.yml restart plantpulse-server-web

Container	Was läuft
plantpulse-server-web	Web-Konsole
plantpulse-batch-web	Batch
plantpulse-warehouse	Data Warehouse
plantpulse-plugin-opcua-server	OPC-UA-Plugin
plantpulse-plugin-aasx-server	AASX-Plugin
plantpulse-ha	Redundanzwiederherstellungs-Daemon

docker compose restart beachtet Abhängigkeitsreihenfolge nicht

Wenn Sie mehrere Apps zusammen neu starten müssen, ist es sicherer, mit ./restart.sh den gesamten Stack neu zu starten. Die Startreihenfolge ist plantpulse-server-web → plantpulse-batch-web → die übrigen vier.

Komponenten im Data Lake — Interne Container-Skripte

Infrastrukturkomponenten wie Speicher, Analyse und Messaging laufen in einem einzigen plantpulse-datalake-Container zusammen, daher greifen Sie auf den Container zu und verwenden einzelne Skripte.

# 호스트에서 데이터레이크 진입
./shell.sh

# 컨테이너 내부에서
/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd restart storage
exit

Skript	Ziel
pd restart storage	Cassandra, PostgreSQL, Valkey, MinIO
pd restart analytics	Spark, Hive, Kyuubi, Gravitino
pd restart messaging	Kafka, MQTT
pd restart timeseries	Zeitreihe-Engine und UI
pd restart workflow	Temporal, Kestra
pd restart cep	CEP-Engine
pd restart data-gateway	Data-Query-Gateway
pd restart sql	SQL-Query-Tool
restart-monitor.sh	Systemüberwachung

Hinweis: Wenn Sie eine Infrastrukturkomponente neu starten, sollten Sie auch die abhängigen App-Container neu starten.

Führen Sie App-Neustartskripte nicht im Data Lake aus

restart-server.sh · restart-batch.sh · restart-warehouse.sh · restart-opcua-server.sh · restart-aasx-server.sh haben zwar noch Skriptdateien, aber sind nur im jeweiligen App-Container selbst sinnvoll. Im Data-Lake-Container gibt es nicht die ausführbaren Dateien dieser App, daher endet es mit dem Fehler «Modul nicht gefunden». Verwenden Sie für Apps den obigen Container-weise-Neustart.

Plattform aktualisieren

Wenn ein neues Image veröffentlicht wird, aktualisieren Sie mit dem folgenden Befehl.

cd /opt/kopens/plantpulse-platform-docker/bin
./update.sh

Automatische Abfolge:

1. Neues Image docker pull
2. Bestehende Container elegant beenden
3. Container mit neuem Image neu erstellen
4. Health-Validierung — bei Fehler automatischer Rollback auf vorheriges Image

Das Ziel-Tag wird durch PP_IMAGE_TAG (Standard latest) bestimmt. Daten werden separat in Volumes gespeichert, daher werden sie während des Updates sicher beibehalten.

Logverwaltung

Logs anzeigen — logs.sh

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

./logs.sh                             # 전체 컨테이너를 한 화면에 (서비스 이름 접두, 시간순)
./logs.sh plantpulse-server-web       # 그 컨테이너의 로그
./logs.sh cassandra                   # 데이터레이크 안 컴포넌트 로그 파일
./logs.sh --list                      # 볼 수 있는 대상 전체 목록
./logs.sh -n 500 cep                  # 500줄만
./logs.sh -f plantpulse-server-web    # 계속 따라가기 (Ctrl-C 로 종료)

Standard ist «einmal drucken und fertig»

logs.sh druckt die letzten N Zeilen (Standard 200) und beendet sich. Um kontinuierlich zu folgen, fügen Sie -f an. --no-follow wird aus Kompatibilitätsgründen akzeptiert, aber da dies jetzt der Standard ist, ist es nicht erforderlich.

Wenn Sie nicht wissen, welcher Container es ist

Wenn ein Problem auftritt, ist es schwer zu wissen, in welchem Container es sich befindet. Wenn Sie ohne Argumente ausführen, werden die Logs von acht Containern zeitlich vermischt, daher verpassen Sie nicht die eigentliche Ursache, wenn Sie nur einen Container verfolgen.

--list liest Servicelisten aus Compose und Komponentenlog-Verzeichnisse direkt aus dem Data-Lake-Container. Es zeigt die tatsächliche Liste zu diesem Zeitpunkt, nicht eine manuell verwaltete Liste.

Log-Verzeichnisse im Container

Log-Pfade für Komponenten im Data-Lake-Container. (Nach Eintritt mit ./shell.sh überprüfen)

Modul	Log-Pfad
Valkey	plantpulse-storage/cache/valkey/logs/system.log
PostgreSQL	plantpulse-storage/db/postgres/logs/system.log
Cassandra	plantpulse-storage/db/cassandra/logs/system.log
MinIO	plantpulse-storage/object/minio/logs/system.log
Gravitino	plantpulse-analytics/gravitino/logs/system.log
Hive	plantpulse-analytics/hive/logs/system.log
Spark	plantpulse-analytics/spark/logs/system.log
Kyuubi	plantpulse-analytics/kyuubi/logs/system.log
Zeitreihe-Engine	plantpulse-timeseries/engine/logs/system.log
Kafka	plantpulse-messaging/kafka/logs/server.log
MQTT	plantpulse-messaging/mqtt/logs/hivemq.log
Temporal	plantpulse-workflow/temporal/logs/system.log
Kestra	plantpulse-workflow/kestra/logs/system.log
CEP	plantpulse-cep/logs/system.log
Data Gateway	plantpulse-data-gateway/logs/system.log
SQL	plantpulse-sql/logs/system.log
Monitor	plantpulse-monitor/logs/system.log

Referenzpfad ist /opt/kopens/plantpulse-platform/. Die Logs der sechs Apps befinden sich jeweils in ihren eigenen Containern, daher ist es schneller, mit ./logs.sh <컨테이너> zu schauen.

Log auf Host kopieren

cd /opt/kopens/plantpulse-platform-docker/bin
./tools/copy-log-to-local.sh

Fehlerbehebung

cd /opt/kopens/plantpulse-platform-docker/bin
./doctor.sh

Erstellt ein Diagnose-Tarball (/tmp/pp-doctor-<호스트>-<타임스탬프>.tar.zst). Es enthält Status, Health-Probe-Ausgaben und Logs aller Container sowie Konfiguration und Host-Umgebung, wobei Passwörter und Schlüssel maskiert sind. Das System wird überhaupt nicht geändert.

Übergeben Sie das generierte Tarball dem KOPENS-Supportteam für schnelle Analyse.

Arbeiterverwaltung (Cluster-Umgebung)

Wenn Sie von einem Master-Knoten ausgehend Durchsatzexpansion benötigen, fügen Sie Worker-Container hinzu. Die autorisierte Quelle ist compose/workers.roster (eine pro Zeile mit <id> <ip>), und die Overlay-Compose-Datei wird hiervon generiert.

cd /opt/kopens/plantpulse-platform-docker

# 추가 — roster 등록 → 오버레이 재생성 → 볼륨 → pull → up → 링 조인 확인
bin/worker-add.sh                  # 빈 id·주소 자동 선택
bin/worker-add.sh 3                # id 지정
bin/worker-add.sh 3 10.99.0.103    # id·주소 지정

# 진입
docker exec -ti plantpulse-worker-3 /bin/bash

# 제거 — 반드시 이 순서
bin/worker-decommission.sh 3       # 데이터 이관 + 링 이탈 확인 + 복제 슬롯 정리
bin/worker-remove.sh               # 그 다음에 컨테이너 제거

docker rm auf einem lebenden Worker ist «Verwahrlosung», nicht Entfernung

Cassandra hält weiterhin den Token-Bereich und die Host-ID dieses Knotens (mit RF=3 ist QUORUM weiterhin erfüllt — es wird keine Warnung angezeigt), und der Master gibt den physischen Replikations-Slot dieser Worker nicht frei, daher wird WAL bis zum Vollschreiben der Festplatte festgehalten. Führen Sie zunächst worker-decommission.sh aus — worker-remove.sh verweigert, wenn der Container läuft.

Gelöschte Worker-Skripte

worker-run.sh · worker-stop.sh · worker-update.sh · worker-bash.sh wurden am 31.08.2026 gelöscht. Sie wurden auf Basis manuell verwalteter Worker-Listen erstellt und wurden bei der Umstellung auf Roster-Methode entfernt. Ersatz sind jeweils worker-add.sh (mit Pull) · Compose-Verb · Compose pull+up -d · docker exec.

Weitere Informationen finden Sie unter Cluster-Installation.

Anfänglicher Zugriff nach Installation

Element	Wert
Web-Konsolen-URL	https://[서버IP] (80/443)
Admin-UI-URL	https://[서버IP]:7443
Monitor-UI-URL	https://[서버IP]:4950
Standard-Admin-ID	admin
Standardpasswort	admin123!

Sicherheitsmitteilung: Nach der ersten Anmeldung wird dringend empfohlen, das Standardpasswort aus Sicherheitsgründen zu ändern. → Anfängliches Passwort

Node-Verwaltungsskripte (im Data-Lake-Container)

Cassandra- und Datenbankverwaltung wird von pd CLI (/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd) im Container plantpulse-datalake durchgeführt. Verwenden Sie sie nach dem Eintritt mit ./shell.sh.

Cassandra-Verwaltung

Skript	Beschreibung	Verwendung
pd node status	Cluster-Status prüfen	Regelmäßige Inspektion, Problemüberprüfung
pd node info	Node-Details	Node-Konfiguration überprüfen
pd node compact	Manuelle Kompaktierung ausführen	Festplattenplatz freigeben
pd node compactionstats	Kompaktierungsfortschritt prüfen	Leistungsprüfung
pd node flush	Memtable leeren	Arbeitsspeicher bereinigen
pd node drain	Node Drain (sichere Beendigung vorbereiten)	Vor Node-Beendigung
pd node repair	Node-Daten wiederherstellen/synchronisieren	Bei Datenkonsistenzproblemen
pd node repair-table	Spezifische Tabelle wiederherstellen	Tabellengestützte Wiederherstellung
pd node cleanup	Node bereinigen (unnötige Daten löschen)	Nach Node-Änderung
pd node remove	Node aus Cluster entfernen	Bei Node-Lösung
pd node add	Node zu Cluster hinzufügen	Bei Erweiterung
pd node upgrade	Node-Upgrade	Bei Versionsaktualisierung
pd node tpstats	Thread-Pool-Statistik	Leistungsanalyse
pd node proxyhistograms	Proxy-Histogramm	Latenz-Analyse
pd node table-histograms	Tabellen-Histogramm	Tabellenleistungsanalyse
pd node table-stats	Tabellen-Statistik	Datengröße/Anzahl prüfen
pd node sstable-size	SSTable-Größe prüfen	Festplattennutzung prüfen
pd node cache-clear	Cache leeren	Bei Cache-Problemen
pd node topic	Kafka-Topic-Verwaltung	Messaging-Prüfung
pd node disk	Festplattennutzung prüfen	Kapazitätsprüfung
pd node errors	Fehler-Logs überprüfen	Fehlerdiagnose
pd node train-zstd	ZStandard-Kompression trainieren	Kompressionsoptimierung
pd node init-cms	CMS initialisieren	Anfängliche Einrichtung

Datenbankzugriff

Skript	Beschreibung
pd node psql	PostgreSQL Shell-Zugriff (Metadaten-DB)
pd node cql	Cassandra CQL Shell-Zugriff (Zeitreihen-DB)

Konfigurationsskripte

Skript	Beschreibung
configure.sh	Data-Lake-Konfiguration generieren (automatische Dienstkonfiguration auf Basis von Env)
prepared.sh	Umgebung vor Start validieren und vorbereiten (erforderliche Verzeichnisse, Berechtigungen usw. prüfen)

Führen Sie env-reset.sh nicht im Container aus

env-reset.sh ist ein entwicklungsspezifisches Tool, das alle PP_* zurücksetzt und dann env.sh erneut liest. Wenn Sie es im Data-Lake-Container ausführen, gehen die von Compose eingefügten Werte verloren und werden auf die im Image eingebauten Standardwerte zurückgesetzt.

Native Installationsumgebung

Die aktuelle Version unterstützt keine native Installation (Binärdateien)

Die aktuelle Ausgabe ist nur der oben genannte Docker Compose Stack. Betriebsbefehle für bestehende Systeme mit nativer Installation befinden sich auf der Seite Native Installation — bitte siehe dort. Verwenden Sie dies nicht für neue Bereitstellungen.

Häufig verwendete Befehle zusammengefasst

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

./preflight.sh            # 설치 전 비파괴 사전 점검
./install.sh              # 최초 설치 (OS+Docker+방화벽+스택)
./up.sh                   # 기동 — 준비될 때까지 대기 (0 = 준비 완료)
./down.sh                 # 정지 (상태 보존)
./restart.sh              # graceful 재시작 (drain + 준비 대기)
./status.sh               # 서비스 / health / 볼륨 요약 (0=정상 / 2=비정상)
./logs.sh [서비스]        # 로그 보기 — 1회 출력. -f 로 따라가기 (인자 없으면 전체, 목록은 --list)
./shell.sh [서비스]       # 컨테이너 bash 진입
./ops-check.sh            # 운영 health + critical log 점검
./update.sh               # 이미지 갱신 (pull + recreate + rollback)
./remove.sh               # 컨테이너 제거 (볼륨은 보존)
./backup.sh               # 볼륨 백업 (기본 pp-data · pp-security)
./doctor.sh               # 장애 진단 tarball 생성
./passwd.sh --list        # 바꿀 수 있는 비밀번호 목록
./stack-verify-boot.sh    # 스택 전체 준비 판정

Alle Verben unterstützen --help.