spring-cloud-dataflow: Kubernetes Applications do not autoconfigure bindings
Problem description: While developing spring cloud stream applications to use with Kafka to be deployed on the Kubernetes platform it is not documented what docker configurations are required to support skipper configuration bindings.
Solution description: Documentation should explain the need for dockerization of spring applications and the necessary configuration to support Skipper Bindings.
However, this may be a deeper issue. I have been under the impression that spring cloud stream automatically set the spring.cloud.stream.bindings.input/output.destination properties based on the stream and application name. This does not appear to function with custom applications on Kubernetes, but does appear to work with the built-in applications.
Description of alternatives: At current state, dockerized applications were built to define their own application bindings and the graphical and stream DSL were used largely for visual assistance to understand the stream.
Additional context: If the issue is related to a docker image configuration change needed, please direct me to proper instructions and i’ll open a PR to the doc site. If this is a bug i can help reproduce.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 18 (9 by maintainers)
Hi, @derrick-solstice. For custom Stream applications, if the channel bindings revolve around the default contracts in Spring Cloud Stream (e.g.,
Source,Processor, orSink), then the corresponding input/output channel mapping is automatically applied by SCDF when it deploys the custom applications.If you implement a custom channel interface, however, SCDF will not be able to interpret it in this situation. We have a Stream App DSL to support deploying non-linear and comprehensive applications, including Kafka Streams processors.
As for,
It is not clear what do you mean by this. Perhaps you could elaborate on it with an example. Feel free to share a sample of the custom app, so we can relate to what you’re describing.
Thanks for the details. I don’t see anything different from what we normally tend to use in the
Dockerfile. Here’s an example.I do see the reported behavior with your
sourceon GKE, and I’m checking a few things to make sure everything is set up correctly. (for instance, the test-support dependency is in “test” scope, and among others).More soon.