Docker-Installation

Übersicht

Diese Seite beschreibt die manuelle (schrittweise) Installation der PlantPulse Platform als Docker Compose Stack sowie die Installation im Air-Gap-Netzwerk.

Für gängige Umgebungen empfehlen wir die Ein-Zeilen-Installation. Sie erledigt alles in einem Schritt — vom Paket-Download über die automatische Erkennung der Umgebung, die Installation bis zur Bootvalidierung. Verwenden Sie das manuelle Verfahren auf dieser Seite nur in folgenden Fällen.

Wenn jeder Installationsschritt einzeln geprüft und freigegeben werden muss (Sicherheitsprüfung, Change-Management-Prozess usw.)
Wenn Umgebungsvariablen (bin/env.sh) nicht auf die automatisch erkannten Werte, sondern manuell gesetzt werden müssen
Bei Installation in einem Air-Gap-Netzwerk ohne Internetzugang → Installation im Air-Gap-Netzwerk

Installierte Struktur — neun Container

Die Platform läuft als ein einziger docker compose Stack. Die maßgebliche Datei ist compose/docker-compose.yml, und auch alle Betriebsskripte greifen ausschließlich über diese Datei auf die Container zu.

Container	Schicht	Rolle
`plantpulse-certs`	Zertifikat	Erzeugt TLS-Material und beendet sich als One-Shot. Der normale Status ist `Exited (0)`
`plantpulse-datalake`	Infrastruktur	Storage, Messaging, Analyse, CEP, SQL, Monitor
`plantpulse-server-web`	Anwendung	Web-Konsole
`plantpulse-batch-web`	Anwendung	Batch
`plantpulse-warehouse`	Anwendung	Data Warehouse
`plantpulse-plugin-opcua-server`	Anwendung	OPC-UA-Server-Plugin (11004 / 11005)
`plantpulse-plugin-aasx-server`	Anwendung	AASX-Server-Plugin
`plantpulse-ha`	Anwendung	Redundanz-Recovery-Daemon (10210)
`plantpulse-proxy`	Edge	einziger für Benutzer erreichbarer Eingang (80 / 443 / 1883 / 1884)

Acht Container laufen dauerhaft

plantpulse-certs erzeugt Zertifikate und beendet sich selbst als One-Shot, daher ist Exited (0) normal. In docker ps ist es normal, wenn die übrigen acht als (healthy) erscheinen. Verwechseln Sie den One-Shot-Container nicht mit einem «toten Container» — status.sh und ops-check.sh bewerten ausschließlich diesen Container anhand des Exit-Codes.

Zusätzlich ist ein plantpulse-mirror-maker für Spiegelung in compose definiert, ist aber an das Profil mirror gebunden und startet standardmäßig nicht.

Die frühere Ein-Container-Konfiguration existiert nicht mehr

Vor dem 29.08.2026 konnte man eine «Monolith»-Konfiguration wählen, bei der alle Komponenten zusammen in einem einzigen plantpulse-platform-Container liefen. Diese Konfiguration wurde abgeschafft, und die Auswahlvariable (PP_TOPOLOGY) sowie die zugehörige compose-Datei wurden ebenfalls entfernt. Es gibt jetzt nichts mehr auszuwählen — bin/up.sh startet den obigen Stack.

Befehle wie docker logs plantpulse-platform, die in alten Runbooks noch vorkommen, funktionieren nicht, da kein Container mit diesem Namen existiert. Die Ersatzbefehle finden Sie unter Zusammenfassung der Betriebsbefehle.

Der Hauptzweck der Aufteilung in einzelne Container pro Anwendung ist die OOM-Isolierung. Selbst wenn eine Anwendung den gesamten Speicher verbraucht, bleiben andere Anwendungen und die Infrastruktur am Leben, und Neustart bzw. Rollback können pro Anwendung erfolgen.

Vorbereitung

Prüfen Sie vor Beginn der Installation Folgendes.

Punkt	Anforderung
Kontoberechtigung	root (oder sudo-Berechtigung). Das Installationsskript konfiguriert OS-Einstellungen und den Docker-Daemon
Betriebssystem	RHEL/Rocky/Oracle Linux 8·9, Ubuntu 20.04+, Amazon Linux 2/2023
Docker	Compose v2 wird benötigt (`docker compose` — Form ohne Bindestrich). Falls `install.sh` fehlt, wird es installiert
Datenfestplatte	Es wird empfohlen, eine großvolumige Festplatte unter `/data1` zu mounten — Docker-Daten (`/data1/docker-data`) und die Datenvolumes der Platform nutzen diesen Pfad
Registry-Zugriff	HTTPS-Zugriff auf `docker.kopens.io` (Image-Registry) und `product.kopens.io` (Installationspaket) muss möglich sein. In Umgebungen mit blockiertem Zugriff nutzen Sie bitte die Installation im Air-Gap-Netzwerk
Registry-Zugangsdaten	Login-Zugangsdaten für `docker.kopens.io` (ausgestellt vom KOPENS-Betriebsteam)

Hinweis zum Datenträgerpfad: Ohne separate Datenfestplatte funktioniert es auch mit einem erstellten /data1-Verzeichnis auf der Root-Festplatte, in Produktivumgebungen wird jedoch empfohlen, eine dedizierte Festplatte unter /data1 zu mounten.

Manuelles Installationsverfahren

Schritt 1: Installationspaket herunterladen

Laden Sie das Installationspaket (tar.gz) vom Download-Server herunter und entpacken Sie es in den Standardpfad. Ein Git-Clone oder die Installation zusätzlicher Tools ist nicht erforderlich.

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

Im Paket werden tatsächlich nur zwei Orte verwendet.

Ort	Inhalt
`bin/`	sämtliche Installations- und Betriebsskripte
`compose/`	maßgebliche Stack-Datei `docker-compose.yml` und Cluster-Worker-Overlay

Schritt 2: Vorabprüfung (Preflight)

preflight.sh prüft ohne jegliche Änderung des Systems lediglich, ob die Installation möglich ist.

./preflight.sh

Geprüfte Punkte:

Ob Docker installiert ist / der Daemon läuft (keine Voraussetzung — install.sh installiert es)
Ob der übergeordnete Pfad des Docker-data-root (/data1) existiert
Ob der Secret-Sidecar (/etc/kopens/plantpulse-platform.env) existiert
Belegung der wichtigsten Betriebsports (80, 443, 7443, 4949, 4950)

Wenn nur OK erscheint, fahren Sie mit dem nächsten Schritt fort. Bei ERROR konsultieren Sie bitte die Fehlerbehebung. (WARN dient nur zur Information und blockiert die Installation nicht.)

Schritt 3: Überprüfung der Umgebungsvariablen (env.sh)

bin/env.sh ist die maßgebliche Datei für die Einstellungen auf Host-Seite. Die tatsächlich von den Containern gesehenen Werte werden durch compose/docker-compose.yml festgelegt — Details zum Zusammenhang finden Sie in der Referenz der Umgebungsvariablen.

vi env.sh

Ressourcenwerte werden größtenteils «berechnet» — es gibt kaum etwas zu korrigieren

env.sh ermittelt CPU, Speicher und Festplatte selbst anhand des Hosts. Da es keine fest kodierten Standardwerte sind, werden auf kleinen Systemen ohne manuellen Eingriff auch kleine Werte gesetzt. Ein pro System festgelegter Wert hat immer Vorrang.

Variable	Wie wird sie festgelegt	Wann anpassen
`DOCKER_PP_CPUS`	`nproc` (bei Lesefehler `8`)	wenn dem Container weniger Kerne zugeteilt werden sollen
`DOCKER_PP_CLUSTER_CORES`	`DOCKER_PP_CPUS - 2`, minimal 4 · maximal 30	üblicherweise unverändert lassen
`DOCKER_PP_MEMORY`	90% des Host-RAM, minimal `8G`	um mehr Anteil für das OS zu reservieren
`DOCKER_DATALAKE_MEMORY`	`80G`. Falls der Host kleiner ist, 90% des RAM	Anpassung der Data-Lake-Obergrenze
`DOCKER_PP_DATA_DISK_NAME`	automatische Rückverfolgung der physischen Festplatte hinter `/` (bei Fehler `sda`)	wenn die automatische Erkennung falsch ist
`PP_LANG`	`en`	bei Betrieb auf Koreanisch `ko`
`PP_TZ`	`Asia/Seoul`	für Systeme im Ausland
`DOCKER_PP_EXTERNAL_IP`	leerer Wert	nur wenn in einer NAT-Umgebung die öffentliche externe IP bekannt gegeben werden muss

Tragen Sie unter DOCKER_PP_EXTERNAL_IP keine ungültige IP ein

Dieser Wert gelangt über PP_SERVICE_IP in die SAN-Liste des TLS-Zertifikats. Ist auch nur eine IP im falschen Format enthalten, verwirft openssl die gesamte Extension-Datei, sodass kein einziges Zertifikat erzeugt wird und der Stack nicht startet. Wenn Sie nicht hinter NAT sind, lassen Sie es leer — das ist der Standardwert.

Die aktuellen Werte des Servers lassen sich mit folgendem Befehl prüfen.

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

Auf koreanischen Betriebssystemen werden üblicherweise nur zwei Zeilen angepasst.

export PP_LANG=ko
export PP_TZ=Asia/Seoul

Die Locale wird nur beim Bootzeitpunkt übernommen

PP_LANG / PP_TZ werden zum JVM-Boot-Zeitpunkt fixiert. Um sie in einem bereits laufenden Stack zu ändern, ist ./restart.sh erforderlich. Da außerdem die Cassandra-Zeitreihen mit KST-Epoch geladen werden, behalten Sie bei koreanischem Betrieb Asia/Seoul bei.

Schritt 4: Installation ausführen (install.sh)

sudo ./install.sh

Ein einziges install.sh übernimmt den gesamten Installationsvorgang automatisch.

OS-Erkennung und Systemkonfiguration — Dateibeschränkungen (limits), Kernel-Parameter (sysctl), Zeitsynchronisation (chrony), Umschaltung von SELinux auf permissive, Deaktivierung von Swap
Installation der Docker Engine — Installation über den OS-spezifischen Paketmanager + Konfiguration von data-root als /data1/docker-data (Compose v2 wird mitinstalliert, falls nicht vorhanden)
Firewall-Konfiguration — Öffnung der öffentlichen Ports (80/443/7443/4949/4950), interne Ports nur aus dem privaten Netzbereich erreichbar
Erzeugung der Service-Zugangsdaten — Erstellung des /etc/kopens/plantpulse-platform.env Secret-Sidecars (Berechtigung 0600, bestehende Werte werden bei erneuter Ausführung nicht überschrieben)
Registry-Login — Eingabe der docker.kopens.io-Zugangsdaten (wird automatisch übersprungen, falls bereits eingeloggt)
Stack-Start — Erstellung von Netzwerk/Volumes → Image-Pull → Seeding der Konfigurationsvorlagen → docker compose up -d

Einmalige Optionen bei der Installation (nur bei Bedarf als Umgebungsvariable angeben):

Option	Effekt
`SKIP_OS=1`	OS-Konfiguration/Docker-Installation überspringen (falls Docker bereits installiert und in Betrieb ist)
`SKIP_LOGIN=1`	Registry-Login überspringen (falls bereits eingeloggt oder Images bereits lokal vorhanden sind)
`SKIP_FW=1`	Firewall-Konfiguration überspringen (falls die Firewall separat verwaltet wird)
`DOCKER_DATA_DIR=<path>`	Docker data-root ändern (Standard `/data1/docker-data`)

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

Zugangsdaten müssen «vor der Installation» ersetzt werden

Der Secret-Sidecar (/etc/kopens/plantpulse-platform.env) besteht aus bedingungsloser Zuweisung der Form export VAR=값 und hat Vorrang vor Shell-Exports. Auf einem bereits installierten Knoten wird PP_PG_PASSWORD=... ./up.sh stillschweigend ignoriert. Ersetzen Sie Zugangsdaten bei der Auslieferung vor der Installation über export PP_*_PASSWORD=..., nach der Installation über passwd.sh aus Passwortrotation.

Schritt 5: Start und Bootvalidierung

install.sh startet den Stack und kehrt zurück. Ob der Boot-Vorgang abgeschlossen ist, muss separat geprüft werden.

./up.sh

up.sh ist idempotent und daher auch bei bereits laufendem Stack sicher, und es wartet, bis alles bereit ist. Der Exit-Code 0 bedeutet nicht «Befehl erfolgreich», sondern «jetzt einsatzbereit».

Umgebungsvariable	Standardwert	Bedeutung
`PP_READY_TIMEOUT`	`900`	Obergrenze der Wartezeit auf Bereitschaft (Sekunden)
`PP_READY_INTERVAL`	`15`	Prüfintervall (Sekunden)
`PP_WAIT=0`	—	keine Wartezeit. `0` bedeutet in diesem Fall nicht, dass alles bereit ist

Die erste Neuinstallation dauert 15–18 Minuten

Der eigentliche Prozessstart dauert nur 3–5 Minuten (JVM-Warmup), aber bis alle Komponenten stabil laufen, dauert es 15–18 Minuten. Am langsamsten sind die Cassandra-Schema-Migration und die Stabilisierung. Ein Neustart ist deutlich schneller, da das Schema bereits existiert.

Messwerte (31.08.2026, 32 vCPU / 128GiB): Data Lake 217 Sekunden, Webserver 316 Sekunden.

Die Bereitschaftsprüfung können Sie auch direkt ausführen.

./stack-verify-boot.sh

Dieses Skript betrachtet nicht nur einen einzelnen Container, sondern den gesamten Stack — es prüft, ob der One-Shot-Container normal beendet wurde, ob Data Lake und Anwendungen running·healthy sind und ob der Proxy Port 443 bedient.

Schritt 6: Status- und Betriebsprüfung

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

status.sh fasst Service-Liste, Container-Status, Health und Volumes zusammen. Der Exit-Code ist ein Vertrag — er kann direkt in der Automatisierung verwendet werden.

Beurteilung	Was als abnormal gilt
Service-Liste kann nicht gelesen werden	Compose-Auflösung fehlgeschlagen oder kein Docker-Zugriff
Kein Container zu einem in compose deklarierten Service	nicht gestartet
Dauerhafter Container ist nicht `running`	One-Shot (`plantpulse-certs`) ausgenommen
Health eines dauerhaften Containers ist `unhealthy`	`starting` / `none` Beurteilung zurückgestellt
Health-API meldet nicht OK	Probe innerhalb des Data Lake

Volumes und Konfiguration werden nur gemeldet, aber nicht in den Exit-Code einbezogen — bei der 2-Knoten-getrennten Installation (PP_TIER=APP) ist es normal, dass einiges fehlt.

ops-check.sh durchsucht darüber hinaus auch aktuelle kritische Logs (OOM, FATAL, SSL-Fehler usw.).

Health-Prüfung

Die Monitor-API wird vom Container plantpulse-datalake bereitgestellt. Der Befehl unterscheidet sich je nach Abfrageort.

# 컨테이너 안에서 — 어떤 구성에서도 동작하는 방법
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" liegt im normalen Bereich, wenn es OK oder WARN ist, und ist eine Störung bei FAIL.

Über andere Ports kann der Health-Status nicht abgerufen werden

Konsole und Health-API werden über beide Ports bereitgestellt — 4950 (HTTPS) und 4949 (Klartext-HTTP). Es handelt sich um dieselbe Konsole und dieselbe API, nur mit anderem Schema. 4949 leitet nicht mehr zu 4950 weiter.

4949 ist Klartext — Anmeldepasswort und Session-Cookie fließen unverschlüsselt. In nicht vertrauenswürdigen Netzen verwenden Sie 4950. 4949 ist eine Option für Systeme, bei denen die Warnung wegen selbstsignierter Zertifikate Betreiber tatsächlich behindert.

Installationsergebnisse

Netzwerk und Volumes

Ressource	Name	Verwendung
Netzwerk	`pp-net`	dediziertes Docker-Netzwerk der Platform (Standard `10.99.0.0/24`, Gateway `10.99.0.1`)
Volume	`pp-data`	dauerhafte Datenspeicherung (Cassandra, PostgreSQL, Kafka usw.)
Volume	`pp-temp`	temporäre Daten (Spark-, Hive-Arbeitsbereich)
Volume	`pp-backup`	Backup-Speicher
Volume	`pp-security`	TLS-Zertifikate·Keystores. `plantpulse-certs` schreibt, alle übrigen greifen nur lesend zu
Volume	`pp-proxy-certs`	Zertifikate, die der Proxy auf 443 verwendet

Volumes bleiben auch beim Stoppen oder Entfernen von Containern stets erhalten, sodass Daten auch bei Updates oder Neuinstallation bewahrt bleiben.

Host-Verzeichnisse

Pfad	Verwendung
`/opt/kopens/plantpulse-platform-docker`	Installations-·Betriebsskripte und maßgebliche compose-Datei
`/etc/kopens/conf`	Konfigurationsvorlagen der Platform (Host-Bind-Mount). Werden beim ersten Start automatisch aus dem Image geseedet, danach können Betreiber sie direkt auf dem Host bearbeiten; sie bleiben auch bei Neuinstallation erhalten
`/etc/kopens/plantpulse-platform.env`	Secret-Sidecar der Service-Zugangsdaten (Berechtigung 0600)
`/etc/kopens/platform.node.env`	knotenspezifische Identität (u. a. `PP_TIER`). Kopieren zwischen Knoten verboten
`/etc/kopens/ca`	gemeinsame Cluster-CA (verwendet bei 2-Knoten-getrennter Installation)

Zugangsadressen

Verwendung	Adresse
Web-Konsole	`http://<server-ip>/` · `https://<server-ip>/` — bedient durch `plantpulse-proxy`
Verwaltungs-UI	`https://<server-ip>:7443`
Monitor-UI · Health	`https://<server-ip>:4950/api/health`
MQTT	`<server-ip>:1883` (Klartext) · `<server-ip>:1884` (TLS)
OPC-UA	`<server-ip>:11004` · `<server-ip>:11005`

Sicherheitshinweis: Ändern Sie nach dem ersten Login in die Web-Konsole unbedingt das Standard-Administratorpasswort. → Anfangspasswort

Zusammenfassung der Betriebsbefehle

Die im täglichen Betrieb verwendeten Befehle. Alle werden unter /opt/kopens/plantpulse-platform-docker/bin/ ausgeführt. Alle Verben unterstützen --help.

Aufgabe	Befehl	Hinweis
Statusprüfung	`./status.sh`	Zusammenfassung von Service / Health / Volumes. 0=normal / 2=abnormal
Betriebsprüfung	`./ops-check.sh`	Container-Health + Health-API + aktuelle kritische Logs
Start	`./up.sh`	idempotent. 0 = bereit
Stopp	`./down.sh`	Status bleibt erhalten
Neustart	`./restart.sh`	graceful drain → Stopp → Start → Warten auf Bereitschaft
Logs anzeigen	`./logs.sh [서비스]`	zeigt die letzten 200 Zeilen und endet. Zum Verfolgen `-f`. Ohne Argument alle Container. Liste über `--list`
In Container einsteigen	`./shell.sh [서비스]`	ohne Argument Data Lake
Image-Update	`./update.sh`	pull + Neuerstellung. bei Fehlschlag automatisches Rollback auf das vorherige Image
Vollständige Entfernung	`./remove.sh`	entfernt nur Container (Volumes·Konfiguration bleiben erhalten). `RM_IMAGE=1` / `RM_NETWORK=1`
Backup	`./backup.sh [볼륨 …]`	Standard `pp-data` · `pp-security`
Bootvalidierung	`./stack-verify-boot.sh`	Bereitschaftsprüfung des gesamten Stacks
Diagnosepaket	`./doctor.sh`	Tarball für Support-Anfragen. Geheimwerte werden maskiert
Passwort ändern	`./passwd.sh --list`	Liste der änderbaren Schlüssel

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

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

Die alten Namen funktionieren weiterhin

stack-run.sh · stack-stop.sh · stack-bash.sh · stack-update.sh · stack-remove.sh wurden nicht entfernt. Bei direkter Ausführung wird nur der neue Name in einer Zeile angezeigt, das Verhalten ist jedoch identisch. Bestehende Kunden-Runbooks müssen nicht sofort angepasst werden.

Achtung — vollständiges Löschen aller Volumes: ./tools/remove-all-volumes.sh löscht sämtliche Daten dauerhaft. Verwenden Sie es ausschließlich nach abgeschlossener Sicherung.

Installation im Air-Gap-Netzwerk

In Umgebungen ohne Internetzugang erfolgt die Installation in drei Schritten: Bundle beschaffen → auf Datenträger übertragen → auf dem Air-Gap-Server laden.

Schritt 1: Bundle beschaffen

Der empfohlene Weg ist der Download eines von KOPENS veröffentlichten Bundles.

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

Wenn Sie es selbst auf einem Server mit Internetzugang erstellen müssen, verwenden Sie Folgendes.

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)

Das Ergebnis ist eine einzige plantpulse-platform-images-<version>.tar.gz-Datei, die Folgendes enthält.

Offline-Installationspaket der Docker Engine (rpm / deb)
Platform-Images (Ergebnis von docker save)
repo/ — Installations-·Betriebsskripte und das gesamte compose/

Schritt 2: Übertragung auf den Air-Gap-Server

Übertragen Sie die .tar.gz-Datei über ein zugelassenes Medium (USB, interner Dateiserver, scp usw.) auf den Zielserver.

Schritt 3: Laden und Installieren auf dem Air-Gap-Server

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 übernimmt automatisch Folgendes.

Offline-Installation der Docker Engine (rpm -ivh / dpkg -i) — wird übersprungen, falls bereits installiert
Laden der Platform-Images docker load
Aufruf von install.sh (SKIP_LOGIN=1 — kein Registry-Login erforderlich, da die Images bereits lokal vorhanden sind)

Führen Sie Bootvalidierung (./up.sh oder ./stack-verify-boot.sh) und Betriebsprüfung (./ops-check.sh) nach der Installation genauso durch wie bei der manuellen Installation.

Update im Air-Gap-Netzwerk

Erstellen Sie nach demselben Verfahren ein Bundle mit den Images der neuen Version, übertragen und laden Sie es, und erzeugen Sie die bestehenden Container anschließend mit ./update.sh neu.

Fehlerbehebung

Wenn die Preflight-Prüfung fehlschlägt

Meldung	Maßnahme
`docker is installed but daemon is not ready while SKIP_OS=1`	Starten Sie zuerst den Docker-Daemon: `systemctl start docker`. Oder führen Sie ohne `SKIP_OS` aus, dann konfiguriert `install.sh` Docker
Port bereits belegt (WARN)	Ein anderer Dienst verwendet diesen Port. Prüfen Sie den Prozess mit `ss -tlnp \| grep :<port>` und bereinigen Sie ihn vor der Installation der Platform
Übergeordneter Pfad des Docker-data-root fehlt (WARN)	Das Verzeichnis `/data1` existiert nicht. Mounten Sie eine Datenfestplatte unter `/data1` oder erstellen Sie das Verzeichnis

Wenn der Stack nicht startet

Da docker compose up -d auf sämtliche depends_on-Bedingungen wartet, schlägt der gesamte Befehl mit nur einer einzigen verbleibenden Zeile fehl, wenn auch nur ein einziger Container den Health-Check nicht besteht.

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

Diese eine Zeile liefert außer dem Containernamen keinerlei Informationen. Die Betriebsskripte geben in diesem Fall automatisch Container-Liste·Status·Ausgabe der Health-Probe·jeweiliges Log-Ende zusammen aus — lesen Sie diese Ausgabe zuerst. Zur manuellen Prüfung:

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

Häufig festgestellte Ursachen:

Ursache	Prüfung
Speichermangel (OOM)	`docker inspect <컨테이너> --format '{{.State.OOMKilled}}'`. Zu app-spezifischem `mem_limit` siehe Referenz der Umgebungsvariablen
Festplatte voll	freier Speicherplatz von `/data1`
erforderliche Zugangsdaten fehlen	compose fordert das Passwort als `:?` an. Ist es leer, startet der Stack nicht halb, sondern überhaupt nicht — führen Sie zuerst `install.sh` aus, um den Sidecar zu erzeugen
verzögerte DB-Initialisierung	Die erste Installation dauert wegen der Schema-Erzeugung lange. Wenn in den Logs kein Fehler auftritt und der Vorgang fortschreitet, warten Sie bitte etwas länger

Falls die Ursache schwer zu ermitteln ist, erzeugen Sie mit ./doctor.sh ein Diagnosepaket und fügen Sie es der Support-Anfrage bei. Das Diagnosepaket enthält Status und Logs aller Container.

Wenn der TLS-Handshake nur als `TimeoutException` erscheint

Wenn der Name, den eine Anwendung beim Verbindungsaufbau zum Backend verwendet, nicht in der SAN-Liste des Zertifikats enthalten ist, erscheint keine Zertifikatsmeldung, sondern lediglich ein scheinbares Timeout. Vermuten Sie diesen Fall, wenn Sie Containernamen geändert oder den Backend-Host direkt angegeben haben. Wie Sie das Zertifikat neu erzeugen, erfahren Sie unter Sicherheitsverwaltung.

Fehlgeschlagene Registry-Authentifizierung

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

Wenn keine Login-Zugangsdaten vorhanden oder abgelaufen sind, wenden Sie sich zur Ausstellung an das KOPENS-Betriebsteam.
Eine interne Firewall kann den Zugriff auf die Registry blockieren. Bitten Sie den Netzwerkadministrator, HTTPS-Zugriff auf die Domains docker.kopens.io und product.kopens.io freizugeben.
In Umgebungen mit vollständig blockiertem externem Zugriff nutzen Sie bitte die Installation im Air-Gap-Netzwerk.

Technischer Support

Bei Fragen während Installation und Betrieb wenden Sie sich jederzeit an: webmaster@kopens.com

Übersicht​

Installierte Struktur — neun Container​

Vorbereitung​

Manuelles Installationsverfahren​

Schritt 1: Installationspaket herunterladen​

Schritt 2: Vorabprüfung (Preflight)​

Schritt 3: Überprüfung der Umgebungsvariablen (env.sh)​

Schritt 4: Installation ausführen (install.sh)​

Schritt 5: Start und Bootvalidierung​

Schritt 6: Status- und Betriebsprüfung​

Health-Prüfung​

Installationsergebnisse​

Netzwerk und Volumes​

Host-Verzeichnisse​

Zugangsadressen​

Zusammenfassung der Betriebsbefehle​

Installation im Air-Gap-Netzwerk​

Schritt 1: Bundle beschaffen​

Schritt 2: Übertragung auf den Air-Gap-Server​

Schritt 3: Laden und Installieren auf dem Air-Gap-Server​

Update im Air-Gap-Netzwerk​

Fehlerbehebung​

Wenn die Preflight-Prüfung fehlschlägt​

Wenn der Stack nicht startet​

Wenn der TLS-Handshake nur als TimeoutException erscheint​

Fehlgeschlagene Registry-Authentifizierung​

Technischer Support​