Advice - what is the best way to handle database connection settings

[kurr...@gmail.com]

Hello

We have a springboot application, and database settings are stored in an application.yml file.

This means database connection settings go into version control. 

Goals

• Personally I would prefer if we use environment variables.
  
• If we use env vars, that the setup of these can be part of the project
• We are also looking for a way for each developer to have their own db settings - and that they are not committed to git

If we use environment variables, how can these env vars be setup when the container spins up?

Pom File

It is possible to set env vars in pom file, eg,

<env>
          <HTTP_PORT>8080</HTTP_PORT>
           <JAVA_APP_JAR>${project.artifactId}-${project.version}.war</JAVA_APP_JAR>
</env>

However, this has a few problems - values are still committed to git, and fmp does not allow null values.

And if the values are null, then the application will not start.

Deployment.yml

I see F8 has a deployment yml file which apparently allows env vars to be set, but I could not get it to work, probably due to incorrect indentation.

Any recommendations or advice on how best to solve this is appreciated.

Br

Anton

[kurr...@gmail.com]

So it seems the recommended practice is to use ConfigMaps and Secrets.

https://access.redhat.com/documentation/en-us/red_hat_jboss_middleware_for_openshift/3/html/red_hat_jboss_fuse_integration_services_2.0_for_openshift/kube-spring-boot

Is it really needed to add a new dependency to use config maps in Springboot?

Im looking for a way to read env vars (or a similar store) in spring boot, but have these shared between other services, but also solution that is not tightly coupled to Openshift / kube, so lightweight development can be done, without the need for minishift.

[Ioannis Canellos]

Your options are to either use the feature of spring-cloud-kubernetes to use configmaps and secrets as a property source, or mount them locally and read them as application.yml etc.

--
You received this message because you are subscribed to the Google Groups "fabric8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabric8+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Ioannis Canellos

Blog: http://iocanel.blogspot.com

Twitter: iocanel

[James Strachan]

On 8 March 2017 at 14:21, <kurr...@gmail.com> wrote:

So it seems the recommended practice is to use ConfigMaps and Secrets.

https://access.redhat.com/documentation/en-us/red_hat_jboss_middleware_for_openshift/3/html/red_hat_jboss_fuse_integration_services_2.0_for_openshift/kube-spring-boot

Is it really needed to add a new dependency to use config maps in Springboot?

no library or runtime dependency is required. Its just a change in the kubermetes manifest. e.g. like this example

https://github.com/fabric8-quickstarts/spring-boot-webmvc

e.g. 

https://github.com/fabric8-quickstarts/spring-boot-webmvc/blob/master/src/main/fabric8/deployment.yml#L8-L18

or as Ioannis said the other option is to use a java library to query the ConfigMap under the cover for you

 

Im looking for a way to read env vars (or a similar store) in spring boot, but have these shared between other services, but also solution that is not tightly coupled to Openshift / kube, so lightweight development can be done, without the need for minishift.

Yeah, a shared ConfigMap sounds good then you can refer to entries and expose them as env vars via the deployment.yml

--

James
-------
Red Hat

Twitter: @jstrachan
Email: james.s...@gmail.com

Blog: https://medium.com/@jstrachan/

fabric8: https://fabric8.io/

open source development platform

funktion: https://funktion.fabric8.io/

open source event based lambda programming

[Anton]

But if springboot can already read environment variables, and - maybe I am mistaken - configmaps can write env vars to a pod - why is an additional dependency needed?

[James Strachan]

as I said - if you read environment variables or files from disk mounted into your pod via a ConfigMap there is no need to add any new dependencies; just like in the above example I posted

[Anton]

Thanks James - my apologies, I didnt see your reply, only saw reply from Ioannis.