You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 28, 2024. It is now read-only.
(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 boshManifestFolder in the BoshBasedServiceConfig and falls back to loading the template from the classpath (to support automated tests during the build phase). See
using the standard JavaMainspringboot or tomcat java buildpack containers make it hard to externalize the bosh template manifests
using the DistZip mechanism could be an option allowing to package the public service-broker-X.war along with bosh manifests and possibly custom externalized application.yml
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.
The text was updated successfully, but these errors were encountered:
+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?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
(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
boshManifestFolder
in the BoshBasedServiceConfig and falls back to loading the template from the classpath (to support automated tests during the build phase). Seeopen-service-broker/broker/src/main/groovy/com/swisscom/cloud/sb/broker/services/bosh/BoshFacade.groovy
Line 121 in 38ddf11
When 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.
The text was updated successfully, but these errors were encountered: