1. I have pushed the scdf server jar and skipper server in PCF, now I want to change the existing DB i.e. H2 to MySQL, For this I have created the MySQL service from marketplace , but when I tried to bind the MySQL service to skipper server app I am getting below exception

2. I tried to apply JBP_CONFIG_SPRING_AUTO_RECONFIGURATION '{enabled: false}' to skipper server environment variable but I still gets the same exception.

3. As per the exception I need to remove `Spring cloud connector libraryv from classpath, but I have used to push skkiper server jar to pcf, so how can I remove this dependency(do I need to take skipper server code and manually remove the dependency ? If yes then what is the dependency I need to exclude in maven ?)

skipper version used : 2.1.0

我正在将 SCDF2.2.1.RELEASE与 Skipper Kubernetes 部署程序一起使用，2.1.2.RELEASE并且我正面临一种奇怪的行为，我想了解它是否真的是有意的、一个问题或只是一个无功能。

当我部署流时，我最初可以按照以下模式指定每个元素的副本数：

这很有效，因为我指出的实例都部署到了 Kubernetes 中。然后，如果我回到流的定义，我会看到添加了一个新属性，可能源自deployer.<app>.count我提供的属性：

但是，现在还不清楚如何更新这样的计数，因为如果我尝试将deployer.<appName>.count属性更改为不同的东西，例如1（不更改其他派生属性），那么 SCDF 会回复错误并且什么也不做：

然后，如果我也更改了派生属性app.<appName>.spring.cloud.stream.instanceCount=1，则会发生意外行为：SCDF 为特定应用程序生成一个新版本，但仍然使用原始2实例启动它，完全忽略了新值。如果我检查流的新定义，它会显示未同步的值：

因此，我不确定这是预期行为还是只是尚未实现的问题或事件，因此 SCDF 只是app.<appName>.spring.cloud.stream.instanceCount将deployer.<appName>.count. 这很令人困惑。

可能来自 SCDF 团队的任何人都可以阐明这件事，以确定这是否真的是一个问题？

谢谢！

当我尝试使用带有以下命令的 skipper shell 安装手动创建、上传的包时，出现“没有可用于 'null' 的发布管理器”错误

包安装 --package-name 演示 --package-version 1.0.0 --release-name 演示

我正在使用本地仓库，我已经创建了包演示并上传了它。

我一直在学习使用 spring-cloud-dataflow 创建流的教程。它创建以下流 -

http --port=7171 | transform --expression=payload.toUpperCase() | file --directory=c:/dataflow-output

所有三个应用程序都可以正常启动。我正在使用rabbitMQ，如果我登录到rabbit UI，我可以看到为流创建了两个队列。该教程说我应该能够使用邮递员向http://localhost:7171 发布消息。当我这样做时，什么也没有发生。我没有得到响应，我在队列中看不到任何东西，也没有创建文件。在我的数据流日志中，我可以看到它被列出。

local: [{"targets":["skipper-server:20060","skipper-server:20052","skipper-server:7171"],"labels":{"job":"scdf"}}]

本教程使用的是旧版本的数据流，我不相信它使用了船长。由于我使用的是船长，这会改变网址吗？我尝试了 http://skipper-server:7171和http://localhost:7171但这些似乎都没有到达端点。我确实在邮递员设置中关闭了 SSL 证书验证。

很抱歉这周问了这么多数据流问题。提前致谢。

我正在开发春季云数据流流应用程序。我可以使用以下配置在 Cloud Foundry 中运行的船长在本地运行 Spring 云数据流服务器。现在我正在尝试与在 kubernetes 集群中运行的船长运行相同的操作。我怎样才能指定相同的？

清单.yml

当我在 Spring Cloud Dataflow 中部署新流时，我想影响服务名称，以便我可以访问例如始终使用相同名称的源。我已经找到了这个答案，但没有提到如何关闭它。查看已部署的实例，我可以看到属性。

我已经检查了 Spring Cloud Dataflow、Kubernetes 部署程序和 Skipper 中所有可能的属性，但我找不到更改服务名称的方法。当我还在运行 SCDF 1.7 时，我没有遇到这个问题。升级到 Skipper 2.1.2 和 SCDF 2.2.1 后，我无法摆脱它。

通过数据流 UI 部署 Spring Cloud Stream 应用程序时，我正在尝试将包含属性文件的文件夹添加到我的类路径中。我相信我想使用 java-cmd 行，但是当我这样做时，我得到了船长错误。我的语法是不是有点不对劲？

也试过引号

问题

我以前能够注册应用程序并部署它们，现在我不能。

它是如何发生的

我能够很好地取消部署和部署上述流。但是，有一天我取消部署它并尝试再次部署它太快了，它抱怨入口 http 端口不可用，因为 pod 还没有停止。我基本上在 2 秒内取消部署和重新部署，没有给它太多时间。现在，由于在船长中似乎是卡住/孤立的部署元数据，我无法部署。我现在每次尝试部署我的流时都会收到此错误：

解决方法

如果我取消注册应用程序并重新注册它不会解决任何问题。但是，如果我取消注册应用程序并使用新名称注册它们，那么它就可以工作。但是因为它是在自动化环境中使用的，所以不得不继续这样做是很烦人的。执行 hacky 命令和重命名并不理想。

我的自定义流卡在“正在部署”中。但是流实际上正在工作。消息由接收器接收。但 SCDF 中的状态是“正在部署”。每个查询 - Spring Cloud Dataflow 自定义应用程序卡在部署状态@Sabby Anandan 说，SCDF 检查/health和/info. 但是根据这篇文章Spring boot actuator "/health" 不起作用URL 应该是actuator/health. 这也与我的代码一致。http://localhost:1234/health不起作用，但http://localhost:1234/actuator/health给了我{"status":"UP"}

这是SCDF中的错误吗？它应该检查actuator/health. 你能帮忙吗？如果这是一个错误，我有什么解决方法吗？以下是版本详细信息：

-SCDF-spring-cloud-dataflow-server-2.5.1.BUILD-20200518.143034-16

-船长-spring-cloud-skipper-server-2.4.1.BUILD-20200518.094106-12

-启动 - 2.3.0

我正在玩 SCDF 几天检查不同的场景，因为我们可能想在我们的一个项目中使用它。

我用

• 掌舵图https://hub.helm.sh/charts/stable/spring-cloud-data-flow/2.7.1
• k8s 版本 - 1.16 (AWS EKS eks.1)
• 使用外部 rabbit 和 postgres - 配置的其余部分是 vanilla SCDF 入门文章的默认配置。

我检查的场景之一是 SCDF 如何处理应用程序故障。

其中一个应用程序版本故意未能通过健康检查，不断返回 503 和状态 DOWN。应用程序是春季启动应用程序。当更新流并使用应用程序的损坏版本时，以前的版本在更新后立即被杀死。在 UI 中，它还将新版本显示为"deploying"。如果经过一段时间并且探测次数失败 - pod 会重新启动。如果您等待几次重新启动，您会看到应用程序的最终状态更改为“失败”。但是，每次重新启动时，它都会重置为"deployed"然后移动到"failed"。

观察到的行为与文档中关于船长的“红\黑”部署策略的内容不一致。

https://docs.spring.io/spring-cloud-dataflow/docs/2.5.1.RELEASE/reference/htmlsingle/#_skipper_s_upgrade_strategy

船长有一个简单的“红/黑”升级策略。它部署新版本的应用程序，使用与当前运行版本一样多的实例，并检查应用程序的 /health 端点。如果新应用程序的运行状况良好，则取消部署之前的应用程序。如果新应用程序的健康状况不佳，则取消部署所有新应用程序，并认为升级不成功。

怎么了

我的期望是，Skipper 应该保留应用程序的现有版本，直到确定新版本是健康的。现在看起来它会杀死健康版本并部署损坏的版本，使其在崩溃循环中旋转。

重现问题的步骤

• 部署了名为my-pipeline的流 (v48)
• 一个名为my-app 的应用程序使用 v48 部署
• 更新流并将my-app的版本更改为损坏的 v49
• my-app-v48被杀死
• my-app-v49已启动，但在崩溃循环中运行，不断未能通过健康检查并尝试重新启动

我检查了船长的日志，可以看到以下几行：

看起来HandleHealthCheckStep#handleHealthCheck是在健康设置为 true 的情况下调用的。我猜这是因为“deploying”或“deployed”（重新启动时应用程序的第一个状态）被视为health。

如果我需要提供更多详细信息，请告诉我。

更新：状态的外观

1. 活跃度在 /actuator/health 失败，准备在 /actuator/info 没问题。

k8s状态

pod 的状态是：“0/1 运行”，经过就绪探测延迟后，它会变为“1/1 运行”。在活动探测失败后，Pod 会重新启动并随着重新启动次数的增加返回到“0/1 Running”。

scdf 状态

在 3 第一次重新启动之前。应用程序的状态是“部署”相同的流。在延迟准备就绪后，它会进入“已部署”状态，对于流也是如此。

3 次第一次重新启动后。应用程序的状态是“失败”的流，它是“部分”。在延迟准备就绪后，它会进入“已部署”状态，对于流也是如此。

2. 也只是尝试将 liveness 和 rediness 都设置为失败的执行器/健康。

k8s状态

pod 的状态为：“0/1 Running”，重启次数增加

scdf 状态

在 3 第一次重新启动之前。应用程序的状态是“部署”相同的流。

3 次第一次重新启动后。应用程序的状态是“失败”的流，它是“部分”。

然而，在这两种情况下，现有版本的应用程序都会在流升级后立即被终止。