jHipster应用程序可能会崩溃，因为CloudFoundry激活了云配置文件

我的小型jhipster应用程序“customerapp”的部署失败，可能是因为CloudFoundry在配置文件“dev”之外还设置了配置文件“cloud”。我在CloudFoundry中为开发的不同阶段使用了几个空间：开发、阶段和产品

我使用jhipster生成器，添加了一些实体客户、地址和联系人。应用程序正在本地运行，没有任何问题

我还使用gitlab ci构建、测试和部署我的软件。My.gitlab-ci.yml看起来像这样（我删除了一些不必要的部分）

DOCKERFILE（通过gitlab ci构建并添加到docker存储库中）：

deplpoyToCloudFoundry.sh shell脚本：

cf login -a $CF_API_ENDPOINT -u $CF_USER -p $CF_PASS -o "${CF_ORG^^}" -s  ${CI_COMMIT_REF_NAME^^} 
cf push -n $CI_PROJECT_NAME-$CI_COMMIT_REF_NAME 

我的清单文件：

---
applications:
- name: customerapp
  memory: 1024M
  #buildpack: https://github.com/cloudfoundry/java-buildpack#v3.19.2
  path: target/customerapp-0.0.1-SNAPSHOT.war
  services:
  - postgresql
  env:
    #SPRING_PROFILES_ACTIVE: dev
    #SPRING_PROFILES_DEFAULT: dev
    #JAVA_OPTS: -Dspring.profiles.active=dev

管道运行良好，应用程序被打包到war文件中并上传到cloud foundry，但它崩溃了，我认为这是因为cloud foundry仍然应用了配置文件“cloud”，这覆盖了jhipsters“dev”配置文件中的重要配置

 [...]
2019-01-02T19:03:16.05+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.055  INFO 8 --- [           main] pertySourceApplicationContextInitializer : 'cloud' property source added
2019-01-02T19:03:16.05+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.056  INFO 8 --- [           main] nfigurationApplicationContextInitializer : Reconfiguration enabled
2019-01-02T19:03:16.06+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.064  INFO 8 --- [           main] com.jutoro.cco.CustomerappApp            : The following profiles are active: cloud,dev,swagger     
[...]

这将导致： 2019-01-02T19:03:29.17+0100[APP/PROC/WEB/0]OUT 2019-01-02 18:03:29.172错误8---[main]com.jutoro.cco.CustomerappApp:您的应用程序配置错误！它不应该同时使用“dev”和“cloud”配置文件运行。 [……]

之后，CloudFoundry停止应用程序

2019-01-02T19:04:11.09+0100 [CELL/0] OUT Cell 83899f60-78c9-4323-8d3c-e6255086c8a7 stopping instance 74be1834-b656-4445-506c-bdfa

生成的application-dev.yml和bootstrap.yml只是在某些地方进行了修改：

bootstrap.yml

        uri: https://admin:${jhipster.registry.password}@url.tomy.jhipsterregistryapp/config

        name: customerapp
        profile: dev # profile(s) of the property source
        label: config-dev 

application-dev.yml

client:
    service-url:
        defaultZone: https://admin:${jhipster.registry.password}@url.tomy.jhipsterregistryapp/eureka/

我尝试在cf中设置开发人员配置文件的内容是：

• 除了-Pdev之外，还在gitlab-ci.yml中添加了-Dspring.profiles.active=dev
• 在manifest env:部分添加了SPRING\u PROFILES\u ACTIVE:dev
• 在manifest env:部分添加了SPRING\u PROFILES\u DEFAULT:dev
• 添加了SPRING_应用程序_JSON:{“SPRING.cloud.dataflow.applicationProperties.stream.SPRING.profiles.active”：“dev”}（如中所述）
• 在manifest env:部分中添加了JAVA_选项：-Dspring.profiles.active=dev（cv env customerapp显示它已设置）
• 使用cf set env和cf restage设置JAVA_OPTS-Dspring.profiles.active=dev

感谢您的帮助

问候 罗伯特

也许任何“未来”的人都会遇到同样的行为

我能够将我的jhipster应用程序部署到CloudFoundry。 我不知怎么地“修复”了它，但我没有意识到进一步的后果。然而

原来CloudFoundry在通过标准健康检查类型http（应该是“心跳”）监视我的jhipster应用程序时遇到了问题？ 因此，我决定将监视行为切换到一种不符合心跳的方式。 只需在manifest.yml文件中将健康检查类型切换为process

health-check-type: process

---

应用程序正在运行。

请先忘记答案。事实证明，实际上是数据源问题导致应用程序无法响应心跳。 取消注释

#hibernate.connection.provider_disables_autocommit: true 

---

在应用程序属性中修复了这个问题。

您可以设置

JBP\u CONFIG\u SPRING\u AUTO\u RECONFIGURATION:“[enabled:false]”

来告诉JBP禁用SPRING AUTO RECONFIGURATION，这就是添加云配置文件的地方。请小心，因为这也会禁用服务的自动重新配置。谢谢@DanielMikusa，但我不知道，如果我关闭自动配置，会带来什么后果。但我找到了一种部署的方法。谢谢你的提示。这取决于你的应用程序。例如，您有一个数据源，您可以将其配置为在本地工作。然后，当您推到CF时，JBP的自动重新配置将自动重新配置单个数据源，以指向绑定的数据库。它有点神奇，并且有一些限制，所以在我看来，最好直接使用SpringCloudConnectors并显式地配置您的数据源。如果这样做，那么禁用自动重新配置实际上不会产生任何影响。其缺点是CF无法检测应用程序是否停止工作并重新启动。对于“进程”的健康检查类型，CF只查看进程是否已启动并正在运行。只要JVM不退出，这就是事实。如果您的应用程序挂起并停止处理请求，则进程将继续运行，并且平台不会自动重新启动您的应用程序。如果将健康检查类型设置为“http”，平台将尝试从应用程序访问http端点（默认“/”。如果返回200 OK以外的任何结果，应用程序将自动重新启动。感谢Daniel Mikusa的澄清。这不是理想的行为。因此，我将尝试关闭自动配置。到目前为止谢谢你。你好，丹尼尔，我删除了健康检查类型，添加了JBP\u CONFIG\u SPRING\u AUTO\u重新配置。。。该应用程序现在启动，但仍然应用云配置文件。2019-01-14T09:32:24.93+0100[APP/PROC/WEB/0]输出配置文件：[云、开发、招摇过市]您在哪里/如何添加的？您能否从暂存的输出中确认尚未安装自动重新配置？当它被安装时，您将在登台过程中看到JBP中的一行代码，其中特别指出它已安装。我建议您打开/关闭所做的更改，并确认它实际上禁用了自动重新配置。如果它已禁用，并且您仍在上看到云配置文件，请告诉我。我的错。我将其添加到env变量中。现在自动配置已停用。这意味着我的数据源的${vcap.}占位符不起作用，对吗？

health-check-type: process

#hibernate.connection.provider_disables_autocommit: true