0

I have a dockerised spring-boot based application and i wanted to update some of the values in application.properties. And this seems can be achieved in 3 ways.

  • Update the application.properties file, rebuild the image.

  • Add --spring.config.location= to the ENTRYPOINT, update the prop file, rebuild the image.

  • Use volume mount, mention the prop file location, update the prop, rebuild the image.
  • Using Spring Profiles and pass the profile info before running the container. And even in this approach update the profile specific prop file, rebuild the image.

As we can see all the approaches involve rebuilding images. Is there a way to make changes to application.properties without rebuilding the image? What is the preferred approach in prod scenarios?

Thanks!

Jai
  • 369
  • 3
  • 16

2 Answers2

0

Yes, there is one more way to inject properties using environment variables.

As per spring property resolution order, environmental variables take precedence over property files.

For example, say you want to update the spring.datasource.username, you can set it via environment variable as SPRING_DATASOURCE_USERNAME. Basically, replacing . with _. By nature, environment variables are not case sensitive but by convention, we put them in upper case.

This variable can be passed when you will be creating container from your image as suggested in this answer.

Yogesh Badke
  • 4,249
  • 2
  • 15
  • 23
0

I would recommend using environment variables, as @YogeshBadke suggests in their answer.

Your option of using a volume is also a good option. Host files mentioned using docker run -v replace files in the image when the container is started, and this does not require an image rebuild. For example

docker run -v $PWD/application.properties.prod:/app/application.properties ...

As a general rule you should not need to rebuild your image to run it in a different environment, and you should avoid mentioning environment-specific hostnames or similar settings anywhere in what gets built into your image. I would not recommend having separate "dev" vs. "prod" profiles in a Docker-hosted solution, since you'll have to rebuild the image as soon as you add a "qa" environment or anything else happens; it's better to be able to just change the deploy-time settings.

(If you happen to be deploying this in Kubernetes, my experience has been that setting individual values via environment variables is easiest, injecting an entire properties file via a ConfigMap works, and trying to embed the properties in the image simply doesn't.)

David Maze
  • 130,717
  • 29
  • 175
  • 215