Difference between configmap.yaml, deployment.yaml, configmap.yaml and application.properties

Question

I want to define thread count for my fixed thread pool in my spring application. Where should I do that? I am confused between yaml and application.properties files.

Answer 1

You should define the thread count for your fixed thread pool in the application.properties file. This is the default configuration file for Spring applications, and it is the recommended place to store configuration settings. You can specify the number of threads for your fixed thread pool with the property spring.task.execution.pool.core-size.

For example, if you wanted to define a fixed thread pool with 10 threads, you would add the following to your application.properties file: spring.task.execution.pool.core-size=10

As per Spring boot doc :

YAML files cannot be loaded by using the @PropertySource or @TestPropertySource annotations. So, in the case that you need to load values that way, you need to use a properties file.

Refer to this SO1 and SO2 to know the difference between yaml and application.properties files.

Answer 2

Spring has several ways to set properties. You can use more than one of these mechanisms, if it's appropriate. The most important thing to remember here is that a PROPERTY_NAME environment variable provides a value for a property.name property, and the environment variable overrides the application.yml file.

Some options:

A src/main/resources/application.properties file is compiled into your jar file and your container image. It's useful for providing default values for things, or for providing configuration to Spring layers that use property configuration. Avoid putting environment-specific settings like host names here, though; you do not want to rebuild your application for each new deployment environment.

A Kubernetes deployment.yaml file can provide environment variables, and these can also provide Spring property values

env:
  - name: PROPERTY_NAME  # for @Value("property.name")
    value: property value

If you're using the Helm deployment tool, you can use its templating language here as well. That will let you provide a value actually at deploy time.

# templates/deployment.yaml
env:
  - name: OTHERSERVICE_URL  # @Value("other-service.url")
    value: {{ .Values.otherServiceUrl }}

# values.yaml

# otherServiceUrl provides the location of the other service.
otherServiceUrl: http://other-service

# at the command line
helm install my-service ./ \
  --set otherServiceUrl=http://other-service.other-namespace

You can use Kubernetes ConfigMaps and Secrets to provide individual bits of configuration. The syntax to reference a ConfigMap or Secret value is somewhat verbose

env:
  - name: SPRING_DATASOURCE_PASSWORD
    valueFrom:
      secretKeyRef:
        name: database
        key: password

If you are already using Helm, I wouldn't try to put individual configuration values into ConfigMaps, since it is so verbose and there's no practical benefit above the template-rendering approach. If not, and you find yourself routinely kubectl edit the configuration values, and they are shared across multiple containers, then maybe a ConfigMap could be reasonable. Storing credentials in Secrets rather than ConfigMaps is usually considered a good practice, though Secrets aren't that secret in practice.

Finally, it's possible to provide an entire Spring configuration in a ConfigMap. This is useful in the case where a value key contains an arbitrary map; one example is setting tags for your metrics system. In this case the environment-variable mapping might not work. This approach could be clearer to read; it's a lot of setup but only once per application; in a Helm context you can use templating here too; but it can't reference Secret values.

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: spring-properties  # typically a little more boilerplate in a Helm chart
data:
  applicaton.yml: |
    management:
      metrics:
        tags:
          namespace: {{ .Release.Namespace}}  {{/*- Helm syntax */}}

# templates/deployment.yaml
volumes:
  - name: app-properties
    configMap:
      name: spring-properties
containers:
  - name: application
    volumeMounts:
      - name: app-properties
        mountPath: /app/properties
    env:
      - name: SPRING_CONFIG_ADDITIONALLOCATION
        value: file:///app/properties