配置文件位置在哪

数据湖的配置遵循 «两个出源，一个方向» 的原则。运营者修改的文件是固定的，容器内的配置文件是由它生成的。

호스트 /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 每次无例外地 优先渲染。因此即使手动修改容器内的生成文件，下次启动时也会消失。2026-09-01 发生过一起事故：有人在容器内修改了 cassandra.yaml 来启用认证，但重新生成时文件被还原，导致认证功能完全失效。

四份源文件

#	文件	内容	格式	谁来写
1	`/etc/kopens/plantpulse-platform.env`	密钥 — 服务账户密码 · API 密钥 · TLS 密钥。非密钥的共通值也可以写在这里	`VAR=값` 每行一条，`export` 无注释。头两行(`# generated:` · `# last rotation:`)由工具管理	`install.sh` 创建，`passwd.sh` 更新。非密钥行由运营者直接编辑
2	`/etc/kopens/platform.node.env`	本节点专有的值 — `PP_MASTER_IP` · `PP_KAFKA_ADVERTISED_HOST` · `DOCKER_PP_EXTERNAL_IP` · `PP_NODE_ID`	相同格式	安装工具从模板生成，运营者直接编辑
3	`/etc/kopens/conf/*.template`	配置形态 — 每个引擎的原始配置文件 33 份	各引擎语法 + `${PP_변수}` 占位符	首次启动时从镜像种子导入，之后由运营者直接编辑
4	(镜像内) `plantpulse-datalake-cli/config/defaults.env`	非密钥默认值 — 端口 · 账户名 · 目录 · TLS 设置	`KEY=value`	产品预置。运营者不修改，用 1·2 覆盖

密码不能通过文件编辑更改

仅修改边车的密码行还不够生效。对于 PostgreSQL · Cassandra 这样 服务器账户是源头 的值，必须同时修改服务器端，顺序错误会导致平台无法启动。bin/passwd.sh 代替您完成这个顺序 → 更改密码 · API 密钥

值的确定顺序

主机的 bin/env.sh 从上到下读取的顺序就是优先级。后读的覆盖先读的。

优先级	出源	为什么会覆盖
1 (最高)	`/etc/kopens/platform.node.env`	在边车之后读取的无条件赋值
2	`/etc/kopens/plantpulse-platform.env`	`VAR=값` 无条件赋值 — 也会覆盖 shell `export`
3	调用 shell 的 `export`	仅当 1·2 没有设置该名称时
4 (最低)	`bin/env.sh` 的 `${VAR:-기본값}`	仅当没人设置时

该值经过 compose 进入容器作为环境变量，容器内 传入的值覆盖 defaults.env。

已安装的节点上 export 会被默默忽略

从 shell 传值的方法（如 PP_PG_PASSWORD=새값 bin/up.sh）仅在边车 还不存在 的节点上有效。如果边车已经持有该名称，边车就会覆盖它。曾经有人因为这个原因发生过误操作事故。

要查看此时此刻这个节点的有效值及其出源，不要在脑子里模拟，请运行这个命令。密钥会被 **** 隐藏。

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

容器内没有边车

容器 不挂载 /etc/kopens/plantpulse-platform.env 文件。值只通过这条路径进入：主机的 bin/env.sh 读边车，compose 把它作为 环境变量 传入容器。

因此有两个后果。

修改边车后必须重建容器，新值才会生效。主机的 bin/restart-datalake.sh 负责这项工作。
compose 中没有列出的名称，即使在边车中写了也 不会到达容器。哪些名称会到达，由 compose/docker-compose.yml 的 x-pp-secrets 锚点和 plantpulse-datalake 服务的 environment: 块决定。变量参考中单独列出了«到达的名称»。

在容器内运行 pd doctor 时，边车行不会显示为«文件不存在»，而是根本不出现，取而代之的是 all required secrets set 行显示实际测量值 — 这是正常的。

模板清单 — 什么渲染到哪里

主机 /etc/kopens/conf/ 中的 33 个模板（顶层 23 个 + cluster/ 10 个）渲染到下列位置。对应表的源头是容器内 plantpulse-datalake-cli/config/render.map，pd config list 为该节点的模式打印对应行。

模板	渲染位置 (相对 `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/` (两个名称)	○	—
`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/`	○	—

cluster/ 标记表示 WORKER 节点在 /etc/kopens/conf/cluster/ 下使用 不同的 模板。例如 MASTER 的 valkey.conf.template 不包含 replicaof，而 cluster/valkey.conf.template 包含 replicaof ${PP_MASTER_IP} ${PP_REDIS_PORT}。

模板语法

只有三种。

语法	含义
`${PP_VAR}`	值缺失会导致整个渲染失败(exit 4)。不会以空值填充并继续
`${PP_VAR:기본값}` · `${PP_VAR:-기본값}`	值缺失时使用默认值

密钥中不能有内联默认值。旧的渲染器会以空值填充并继续，曾经导致 Cassandra 的密码是空字符串 的情况，现在改为列出所有缺失名称然后停止。

不被渲染的配置 — 管理控制台账户

管理控制台登录账户不会写入任何模板。admin-api 进程 直接从环境变量 读取它。目的是不在磁盘上多留一份密码副本。

变量	从哪来	默认值
`PP_DATALAKE_ADMIN_USER`	`defaults.env`	`admin`
`PP_DATALAKE_ADMIN_PASSWORD`	边车	2026-09-05 之后安装的版本使用 Web 控制台管理员相同的开发用默认值 → 更改初始密码。之前的安装版本为空，控制台被禁用
`PP_DATALAKE_ADMIN_API_KEY`	边车	无 — 为空时仅关闭密钥认证，浏览器登录保留

旧文档的变更

旧文档	现在
`configure.sh` 生成配置	`pd config render` (以及 `pd start` 每次都)
`/etc/kopens/conf` 挂载到 `plantpulse-startup/template`	挂载到 `plantpulse-datalake-cli/config/templates` (2026-09-03 起)。旧位置只是不被读取的副本，运营者编辑无法影响渲染
容器内 `env.sh` · `env-reset.sh`	已移除。值由主机决定，compose 传递
用 `PP_OPTIONS` 关闭组件	变量名改为 `PD_OPTIONS`，但当前 compose 堆栈不会把此值传入容器 → FAQ
`PP_TIER` (FULL / DATALAKE / APP)	2026-09-02 删除。所有节点都是完整安装

四份源文件​

值的确定顺序​

容器内没有边车​

模板清单 — 什么渲染到哪里​

模板语法​

不被渲染的配置 — 管理控制台账户​

旧文档的变更​

相关文档​