CODEWITHSUNDEEP
javaspringspring-bootdatasourceproduction-environment
Mukhamedali Zhadigerov
Mukhamedali Zhadigerov

Reputation: 861

How to configure Spring Boot datasource part to use in production?

I'm writing my first "real" applicaion in my first job. I could deploy my app using Spring Boot and it works just fine. One thing that i doubt is datasource config part. Now i write all datasource config in application.properties file:

spring.datasource.url = jdbc:postgresql://10.60.6.34:5432/postgres
spring.datasource.username = *username*
spring.datasource.password = *password*
spring.jpa.hibernate.ddl-auto = update
spring.jpa.properties.hibernate.dialect = org.hibernate.dialect.PostgreSQL94Dialect

And that's it! What else should i do to make my app production ready? What about connection pooling and all that stuff? (i'm not quite familiar with all that datasource config stuff) Thanks in advance!

Upvotes: 4

Views: 7723

Answers (4)

Cepr0
Cepr0

Reputation: 30379

You should provide your database parameters as environment variables then set them in your application.properties as placeholders. For example:

spring.datasource.url=${DATASOURCE_URL}

Where DATASOURCE_URL is one of the env. variable.

In your IDE you set them in the project setting (for example)

So at your work you set your local parameters in IDE, and on the production machine you set prod parameters as environment variable.

Upvotes: 0

Shaunak Patel
Shaunak Patel

Reputation: 1671

Additionally, you can use spring config service . Config-service is central location(which can be more secure) for all properties and with very minimal configuration/change your spring-boot application can read properties from config-service.

Upvotes: 0

Patrick
Patrick

Reputation: 3230

So Joe W is not wrong - profiles is an OK way to handle this issue. However, what I'd recommend instead is to handle the issue using environment variables. This will make your application compatible across not only all operating systems (which profiles will too), but will also allow you to run it within Docker (containers) more easily. You will need to do some amount of this anyway, since profiles still requires you to specify which profile you're running, which you'll need to do with an environment variable.

Luckily for you, Spring Boot auto-wires environment variables with no extra work on your side. You can read more about this here: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html

When dealing with environment variables, you use underscores instead of periods, so your configs would look like this:

SPRING_DATASOURCE_URL = jdbc:postgresql://10.60.6.34:5432/postgres
SPRING_DATASOURCE_USERNAME = *username*
SPRING_DATASOURCE_PASSWORD = *password*
SPRING_JPA_HIBERNATE_DDL_AUTO = update
SPRING_JPA_PROPERTIES_HIBERNATE_DIALECT = org.hibernate.dialect.PostgreSQL94Dialect

Then you can set your environment variables to whatever you want, and you don't need to worry about pulling in new profiles for each server. In addition, since environment variables are higher in the hierarchy than file-based configurations, you can leave your current file-based configurations alone (if you'd like) and your environment variables will override them when you deploy.

Around your connection pooling, this is going to heavily depend on your backing servlet container (I.e., tomcat vs other) and your backing database (looks like postgres). I'd recommend you look at tomcat-jdbc usage with Spring boot, which will then allow you to configure the things like max connection pools and such within Spring's environment variables as well.

Upvotes: 4

Joe W
Joe W

Reputation: 2891

You should take advantage of SpringBoot profiles that will allow you to define separate configuration for dev, stage, prod, and any other environment you want based on a property.

https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-profiles.html

A profile gives you a way to control which configuration is loaded based on a property that defines where the application is deployed.

Your question on data connection pooling depends on your backing data storage selection and how that particular storage is setup. In general, when you go to production you should be using connection pooling of some kind but how much and what kind depend on your implementation.

Upvotes: 1

Related Questions