Docker arguments: how to parameterize containers

The initial problem was a Java + Spring application that was already dockerized and had two environments: local and docker. Switching between them required manually commenting and uncommenting values inside application.properties, which created an obvious risk of deploying the wrong configuration.

The problem

Changing the properties file every time the app moved between localhost and the database container made the workflow fragile and error-prone.

The basic solution

Spring is still just a Java application that runs through java -jar, and that command can receive arguments. Those arguments take priority over values from application.properties, so the app can be launched like this:

java -jar api-0.0.1.jar --spring.datasource.url=jdbc:postgresql://database:5432/license

Once moved into a Dockerfile, we can set a sensible default for the dockerized environment:

FROM openjdk:12

EXPOSE 8080

CMD java -jar api-0.0.1.jar --spring.datasource.url=jdbc:postgresql://database:5432/license

Refining the solution

We can go a step further by allowing the container to receive external parameters. That can be done with ARG and ENV in the Dockerfile:

ARG datasource_url=jdbc:postgresql://database:5432/license
ENV DATASOURCE_URL ${datasource_url}

CMD java -jar api-0.0.1.jar --spring.datasource.url="${DATASOURCE_URL}"

This means the container will point to the dockerized database by default unless someone explicitly overrides the value.

If docker-compose is involved

If the environment is started with docker-compose.yml, the value can be passed through args in the relevant service:

api:
  build:
    context: .
    dockerfile: Dockerfile-api
    args:
      datasource_url: jdbc:postgresql://database:5432/license

Conclusion

The final idea is to propagate one variable through deeper layers while leaving a sensible default at each level:

docker-compose.yml: the value chosen by whoever deploys the service.
Dockerfile: the default for the dockerized environment.
application.properties: the local fallback.

That reduces manual edits, minimizes environment mistakes, and keeps the application flexible without making it harder to operate.