Centralize common config for quarkus

user_5082270 0
Viewed 441

We have a multi-module Quarkus project with a common lib and multiple apps. In the common lib, we have various caches that are used across all the apps.

We would prefer not to have to configure retention and capacity across all configuration files in each application.

Is there a way to centralize the config without writing our own ConfigSource. Or is writing our own ConfigSource the preferred way?

quarkus jakarta-ee configuration
2 Answers

There are three top-level approaches that I can think of.

  1. Use a shared service like Consul, Vault, ConfigMap, or Spring Config Server with the appropriate extension for your environment.
  2. Store the common configuration in config/application.properties. See Overriding Properties at Runtime step 4. Just copy config/application.properties along with your other deployment artifact(s) to your deployment location.
  3. Use a shared config file in your multi-module project. As far as I know, Quarkus only supports one instance each of application.properties, microprofile-config.properties, and application.yaml. You could store application properties in any one of them and the shared properties in one of the remaining two property files that is copied in during a build. Yuck, I know, and I've never tried it :-) I don't think you can point to a config file outside of the project directory, except for #2 exception above. The order of precedence is microprofile-config.properties, application.properties, and then application.yaml (from the least to most significant).
user_648520

I just tested with the current Quarkus Version 2.9.2 and quarkus-config-yaml dependency.

If you put one application.yaml (the one with the basic config for example) in a JAR (Path src/main/resources/), the other one in the application itself and define the JAR as a dependency, it seems to work as expected. The config from the JAR is overwritten by the values in the application, if set, otherwise the config values from the JAR are used.

According to https://github.com/quarkusio/quarkus/blob/main/extensions/config-yaml/runtime/src/main/java/io/quarkus/config/yaml/runtime/ApplicationYamlConfigSourceLoader.java the application.yaml from the classpath has a lower priority (255) than the one from the file system (265).

I think you should not put the same config keys in two jars, but with different config keys, this should work.

user_4271050
Related