Spring Boot应用在OpenShift中无法读取数据源环境变量求助

以下是针对你的问题的排查和解决步骤：

1. 确认DeploymentConfig的环境变量配置位置正确 #

环境变量必须添加到Pod模板的容器配置下，而非DeploymentConfig的其他层级。正确的YAML配置示例：

spec:
  template:
    spec:
      containers:
        - name: 你的应用容器名称
          env:
            - name: SPRING_DATASOURCE_USERNAME
              value: "数据库用户名"
            - name: SPRING_DATASOURCE_PASSWORD
              value: "数据库密码"

如果用Secret存储敏感信息（推荐做法），配置应为：

env:
  - name: SPRING_DATASOURCE_USERNAME
    valueFrom:
      secretKeyRef:
        name: db-credentials  # 你创建的Secret名称
        key: username
  - name: SPRING_DATASOURCE_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-credentials
        key: password

注意：务必确保容器名称与实际应用容器一致，避免配置到错误容器。

2. 验证环境变量是否已注入Pod #

进入运行中的Pod终端，检查变量是否存在：

# 进入Pod
oc rsh <你的Pod名称>
# 查看环境变量
printenv | grep SPRING_DATASOURCE

如果没有输出，说明DeploymentConfig的配置未生效，执行以下命令触发重新部署：

oc rollout latest dc/<你的DeploymentConfig名称>

3. 检查环境变量命名是否完全匹配 #

Spring Boot要求环境变量严格遵循下划线大写的转换规则：spring.datasource.username对应SPRING_DATASOURCE_USERNAME，需确保OpenShift中的变量名没有拼写错误（比如少下划线、大小写错误）。

4. 查看Spring Boot配置加载日志 #

在DeploymentConfig中添加启动参数--debug，查看配置加载详情：

containers:
  - name: 你的应用容器名称
    args: ["--debug"]

查看Pod日志，找到Property Sources相关内容，确认SPRING_DATASOURCE_*变量是否在配置源列表中。如果不在，说明变量未被注入；如果存在但未生效，检查是否有更高优先级的配置（比如命令行参数）覆盖了环境变量。

5. 排查配置覆盖问题 #

• 检查OpenShift中是否挂载了包含spring.datasource.username/password的ConfigMap或Secret作为配置文件，若有需确保这些配置已移除（环境变量优先级高于挂载的配置文件，但残留配置可能干扰排查）。
• 检查应用代码中是否通过@Value硬编码了数据源信息，或自定义配置类手动设置了参数，导致环境变量被覆盖。

内容的提问来源于stack exchange，提问作者santhiago017