Wo befinden sich die Konfigurationsdateien

Die Konfiguration des Datensees wird nach dem Prinzip «zwei Quellen, eine Richtung» aufgebaut. Die Dateien, die der Betreiber ändern darf, sind festgelegt, und die Konfigurationsdateien im Container werden durch Multiplikation dieser Dateien generiert.

호스트 /etc/kopens/conf/*.template          ← 설정의 «형태» (빈칸이 뚫린 원본)
  × /etc/kopens/plantpulse-platform.env      ← 시크릿 (비밀번호 · API 키)
  × /etc/kopens/platform.node.env            ← 이 노드의 값 (IP · 모드)
  + 이미지 안 config/defaults.env            ← 비밀 아닌 기본값 (위에서 안 준 것만)
  ─────────────────────────────────────────
  → pd config render → /opt/kopens/plantpulse-platform/<module>/conf/…   (생성물)

pd start wird ohne Ausnahme jedes Mal zuerst gerendert. Deshalb verschwinden manuelle Änderungen an generierten Dateien im Container beim nächsten Start. Am 2026-09-01 gab es einen Zwischenfall, bei dem die Authentifizierung in cassandra.yaml im Container manuell aktiviert wurde, aber durch die Regeneration zurückgesetzt und vollständig beschädigt wurde.

Vier maßgebliche Dateien

#	Datei	Inhalt	Format	Wer schreibt
1	`/etc/kopens/plantpulse-platform.env`	Geheimnisse — Dienstkonten-Passwörter · API-Schlüssel · TLS-Passwörter. Auch öffentliche Gemeinschaftswerte können hier eingetragen werden	`VAR=값` eine Zeile pro Eintrag, `export` ohne Leerzeichen. Die ersten zwei Zeilen (`# generated:` · `# last rotation:`) werden von Werkzeugen verwaltet	`install.sh` erstellt, `passwd.sh` aktualisiert. Nicht geheime Zeilen können der Betreiber direkt bearbeiten
2	`/etc/kopens/platform.node.env`	Werte, die nur für diese Box gültig sind — `PP_MASTER_IP` · `PP_KAFKA_ADVERTISED_HOST` · `DOCKER_PP_EXTERNAL_IP` · `PP_NODE_ID`	gleiches Format	Installationswerkzeug erstellt aus Vorlage, der Betreiber bearbeitet direkt
3	`/etc/kopens/conf/*.template`	Konfigurationsvorlagen — 33 ursprüngliche Konfigurationsdateien für jede Engine	Syntax jeder Engine + `${PP_변수}` Platzhalter	beim ersten Start aus dem Image initialisiert, danach bearbeitet der Betreiber direkt
4	(im Image) `plantpulse-datalake-cli/config/defaults.env`	Öffentliche Standardwerte — Ports · Kontonamen · Verzeichnisse · TLS-Einstellungen	`KEY=value`	Produkt. Der Betreiber ändert diese nicht und überschreibt sie mit 1·2

Passwörter werden nicht durch Dateibearbeitung geändert

Das bloße Bearbeiten einer Passwortzeile in der Sidecar-Datei führt nicht zur Anwendung der Änderung. Werte, bei denen der Server das Original ist, wie PostgreSQL · Cassandra, müssen auch auf der Serverseite geändert werden, und wenn die Reihenfolge falsch ist, startet die Plattform nicht. bin/passwd.sh führt diese Schritte in der richtigen Reihenfolge durch → Passwörter · API-Schlüssel ändern

Reihenfolge der Wertbestimmung

Die Reihenfolge, in der der bin/env.sh des Hosts von oben nach unten gelesen wird, ist die Prioritätsreihenfolge. Das später Gelesene gewinnt.

Priorität	Quelle	Warum es gewinnt
1 (höchste)	`/etc/kopens/platform.node.env`	bedingungslose Zuweisung nach der Sidecar
2	`/etc/kopens/plantpulse-platform.env`	bedingungslose Zuweisung von `VAR=값` — überschreibt auch Shell `export`
3	`export` der aufgerufenen Shell	nur wenn 1 · 2 diesen Namen nicht angeben
4 (niedrigste)	`bin/env.sh` von `${VAR:-기본값}`	nur wenn niemand einen Wert gesetzt hat

Dieser Wert geht durch compose als Umgebungsvariable in den Container, und im Container gewinnt der übertragene Wert gegen defaults.env.

Bei bereits installierten Knoten wird export stillschweigend ignoriert

Die Methode, Werte von der Shell aus zu übergeben, wie PP_PG_PASSWORD=새값 bin/up.sh, funktioniert nur auf Knoten, bei denen die Sidecar noch nicht vorhanden ist. Wenn die Sidecar bereits diesen Namen kennt, gewinnt die Sidecar. Es gab tatsächlich einen Zwischenfall, bei dem man dachte, dies auf diese Weise geändert zu haben, aber weitermachte.

Um die aktuell geltenden Werte dieser Box und deren Quelle zu sehen, simulieren Sie das Ganze nicht im Kopf — führen Sie diesen Befehl aus. Geheimnisse werden mit **** verborgen.

cd /opt/kopens/plantpulse-platform-docker
bin/env.sh --print

Im Container gibt es keine Sidecar

Die /etc/kopens/plantpulse-platform.env Datei ist nicht im Container gemountet. Werte gelangen nur über den Pfad, dass der bin/env.sh des Hosts die Sidecar liest und compose diese als Umgebungsvariablen in den Container einfügt.

Das hat zwei Folgen:

Nach der Bearbeitung der Sidecar muss der Container neu erstellt werden, damit die neuen Werte eingefügt werden. Der bin/restart-datalake.sh des Hosts erledigt diese Aufgabe.
Namen, die compose nicht angibt, erreichen den Container nicht, egal wie sehr Sie sie in die Sidecar schreiben. Welche Namen erreichbar sind, werden von der compose/docker-compose.yml des x-pp-secrets Ankers und dem plantpulse-datalake Block environment: des Services bestimmt. In Variablenreferenz haben wir nur die «erreichbaren Namen» zusammengefasst.

Wenn Sie pd doctor im Container ausführen, erscheint die Sidecar-Zeile nicht als «Datei nicht gefunden», sondern überhaupt nicht, und stattdessen ist die all required secrets set Zeile die tatsächliche Messung — das ist normal.

Vorlagenliste — was wird wohin gerendert

Die 33 Vorlagen aus dem Host /etc/kopens/conf/ (23 auf der obersten Ebene + 10 in cluster/) gehen an die Positionen unten. Die verbindliche Referenz ist plantpulse-datalake-cli/config/render.map im Container, und pd config list gibt die Zeile aus, die dem Modus dieses Knotens entspricht.

Vorlage	Renderposition (bezogen auf `PP_HOME`)	MASTER	WORKER
`valkey.conf`	`plantpulse-storage/cache/valkey/conf/valkey.conf`	○	○ (`cluster/`)
`postgresql.conf` · `pg_hba.conf`	`plantpulse-storage/db/postgres/conf/`	○	○ (`cluster/`)
`cassandra.yaml` · `jvm-server.options`	`plantpulse-storage/db/cassandra/conf/`	○	○ (`cluster/`)
`spark-env.sh` · `spark-defaults.conf` · `metrics.properties`	`plantpulse-analytics/spark/conf/`	○	○
`hive-site.xml` · `hive-auth.properties`	`plantpulse-analytics/spark/conf/`	○	○ (`cluster/`)
`hive-site.xml`	`plantpulse-analytics/hive/conf/hive-site.xml`	○	—
`kyuubi-defaults.conf`	`plantpulse-analytics/kyuubi/conf/`	○	○
`gravitino-iceberg-rest-server.conf`	`plantpulse-analytics/gravitino/conf/`	○	—
`kafka.properties` · `kafka-jaas.conf`	`plantpulse-messaging/kafka/config/kafka.properties` · `jaas.conf`	○	—
`hivemq.xml` · `plantpulse-mq-auth.properties`	`plantpulse-messaging/mqtt/conf/config.xml` · `auth.properties`	○	—
`plantpulse-timeseries-engine.conf`	`plantpulse-timeseries/engine/conf/` (unter zwei Namen)	○	—
`plantpulse-datalake-admin-api.properties`	`plantpulse-datalake-admin-api/config/`	○	○ (`cluster/`)
`workflow.yaml` · `application.yaml`	`plantpulse-workflow/temporal/config/` · `kestra/config/`	○	—
`plantpulse-cep.properties`	`plantpulse-cep/config/`	○	—
`plantpulse-jdbc.properties` · `plantpulse-data-gateway.properties`	`plantpulse-data-gateway/config/`	○	—

Die Markierung cluster/ bedeutet, dass ein WORKER-Knoten eine andere Vorlage unter /etc/kopens/conf/cluster/ verwendet. Zum Beispiel hat die valkey.conf.template des MASTER kein replicaof, aber cluster/valkey.conf.template hat replicaof ${PP_MASTER_IP} ${PP_REDIS_PORT}.

Vorlagensyntax

Es gibt nur drei.

Syntax	Bedeutung
`${PP_VAR}`	Wenn der Wert fehlt, schlägt das gesamte Rendering fehl (exit 4). Es wird nicht mit einem leeren Wert gefüllt und fortgefahren
`${PP_VAR:기본값}` · `${PP_VAR:-기본값}`	Wenn der Wert fehlt, wird der Standardwert verwendet

Geheimnisse können keine Inline-Standardwerte haben. Der alte Renderer hat leere Werte gefüllt und fortgefahren, was zu Cassandra mit leerem Passwort führte. Jetzt listet der Renderer alle fehlenden Namen auf und stoppt.

Nicht gerenderte Konfiguration — Verwaltungskonsolenkonten

Die Anmeldekonten der Verwaltungskonsole werden in keine Vorlage eingegeben. Der admin-api Prozess liest sie direkt aus den Umgebungsvariablen. Dies vermeidet, eine zusätzliche Kopie des Passworts auf der Festplatte zu erstellen.

Variable	Quelle	Standardwert
`PP_DATALAKE_ADMIN_USER`	`defaults.env`	`admin`
`PP_DATALAKE_ADMIN_PASSWORD`	Sidecar	Ab Installation 2026-09-05 mit Entwicklungs-Standardwert, der gleich dem Web-Konsolen-Administrator ist → Anfangspasswort ändern. Frühere Installationen sind leer, daher ist die Konsole deaktiviert
`PP_DATALAKE_ADMIN_API_KEY`	Sidecar	nicht vorhanden — wenn leer, wird nur die Schlüssel-Authentifizierung deaktiviert, Browser-Anmeldung bleibt

Unterschiede zu älteren Anleitungen

Alte Dokumentation	Heute
`configure.sh` generiert die Konfiguration	`pd config render` (und `pd start` jedes Mal)
`/etc/kopens/conf` wird als `plantpulse-startup/template` gemountet	wird als `plantpulse-datalake-cli/config/templates` gemountet (2026-09-03). Die alte Position ist eine Kopie, die nichts liest, sodass Betreiber-Änderungen das Rendering nicht beeinflussen
Im Container `env.sh` · `env-reset.sh`	sind verschwunden. Werte werden vom Host bestimmt und compose übergibt sie
Komponenten mit `PP_OPTIONS` ausschalten	der Variablenname ist zu `PD_OPTIONS` geändert worden, der aktuelle compose Stack übergibt diesen Wert nicht an den Container → FAQ
`PP_TIER` (FULL / DATALAKE / APP)	wurde am 2026-09-02 gelöscht. Alle Boxen sind vollständige Installationen

Vier maßgebliche Dateien​

Reihenfolge der Wertbestimmung​

Im Container gibt es keine Sidecar​

Vorlagenliste — was wird wohin gerendert​

Vorlagensyntax​

Nicht gerenderte Konfiguration — Verwaltungskonsolenkonten​

Unterschiede zu älteren Anleitungen​

Verwandte Dokumentation​