MatthiasWinzeler
commented
7 years ago +1 from my side. Since the service broker is internally deployed as a BOSH release, deploying as an app was not in our scope and has some drawbacks we'd like to address in the future.
Unrelated question:
Some concourse-related frameworks make it easy to declare bosh dependencies and automate their fetching and upload to be bosh director.
This sounds interesting - what frameworks are you talking about?
(Sharing with the community offline discussions we had with @mcelep )
It would be useful to share a deployment mechanism that can leverage public binaries (e.g. the ones currently built by the travis-ci automation and stored as github releases) while injecting some private secrets, bosh template manifest and possibly plugins.
The framework currently fetches bosh manifest templates from the path specified by the
boshManifestFolderin the BoshBasedServiceConfig and falls back to loading the template from the classpath (to support automated tests during the build phase). See https://github.com/swisscom/open-service-broker/blob/38ddf115e07e5f0bd8155ed3d38df2a2fa73bd6b/broker/src/main/groovy/com/swisscom/cloud/sb/broker/services/bosh/BoshFacade.groovy#L121-L121When looking at deploying the broker as a CF app:
A bosh release might be a nice alternative way to embed official binaries, and common options rendered in application.yml (such as various useful log levels), and allow for injection of non public files by other collocated private bosh releases. This might deploy to CF using a bosh errand.
The bosh release might also be useful in concourse pipelines to express prerequisites on the bosh director (such as bosh releases, cloud-config and possibly run-time config). Some concourse-related frameworks make it easy to declare bosh dependencies and automate their fetching and upload to be bosh director.