Разница между configmap.yaml, deployment.yaml, configmap.yaml и application.properties

Я хочу определить количество потоков для моего фиксированного пула потоков в моем весеннем приложении. Где я должен это сделать? Я запутался между файлами yaml и application.properties.

stackoverflow.com/a/25401832/11820899 посмотрите этот ответ. Это может помочь
arbitrary_A 21.01.2023 21:12

Это частично отвечает на мой вопрос, какая разница, если я определю количество в файлах yaml?

darkstar 21.01.2023 21:20
0
2
81
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Вы должны определить количество потоков для вашего фиксированного пула потоков в файле application.properties file. Это файл конфигурации по умолчанию для приложений Spring, и это рекомендуемое место для хранения параметров конфигурации. Вы можете указать количество потоков для вашего фиксированного пула потоков с помощью свойства spring.task.execution.pool.core-size.

Например, если вы хотите определить фиксированный пул потоков с 10 потоками, вы должны добавить следующее в файл application.properties: spring.task.execution.pool.core-size=10

Согласно документу Spring boot:

Файлы YAML нельзя загрузить с помощью @PropertySource или Аннотации @TestPropertySource. Итак, в случае, если вам нужно загрузить таким образом, вам нужно использовать файл свойств.

Обратитесь к этим SO1 и SO2, чтобы узнать разницу между файлами yaml и application.properties.

Я вижу, что потоки выполняют одну и ту же задачу в разных модулях. Есть ли способ избежать этого и распространять потоки?

darkstar 22.01.2023 22:15
Ответ принят как подходящий

Spring имеет несколько способов установки свойств. Вы можете использовать более одного из этих механизмов, если это уместно. Здесь важно помнить, что переменная среды PROPERTY_NAME предоставляет значение для свойства property.name, а переменная среды переопределяет файл application.yml.

Некоторые варианты:

Файл src/main/resources/application.properties компилируется в ваш файл jar и образ контейнера. Это полезно для предоставления значений по умолчанию для вещей или для предоставления конфигурации слоям Spring, которые используют конфигурацию свойств. Тем не менее, избегайте размещения здесь настроек, специфичных для среды, таких как имена хостов; вы не хотите перестраивать приложение для каждой новой среды развертывания.

Файл Kubernetes deployment.yaml может содержать переменные среды, а также значения свойств Spring.

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

Если вы используете инструмент развертывания Helm, вы также можете использовать его язык шаблонов здесь. Это позволит вам предоставить значение фактически во время развертывания.

# 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

Вы можете использовать Kubernetes ConfigMaps и Secrets для предоставления отдельных битов конфигурации. Синтаксис для ссылки на значение ConfigMap или Secret несколько подробен.

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

Если вы уже используете Helm, я бы не стал пытаться помещать отдельные значения конфигурации в ConfigMaps, так как это слишком многословно и нет никакой практической пользы по сравнению с подходом с рендерингом шаблонов. Если нет, и вы регулярно обнаруживаете kubectl edit значения конфигурации, и они совместно используются несколькими контейнерами, то, возможно, ConfigMap может быть разумным. Хранение учетных данных в секретах, а не в ConfigMaps, обычно считается хорошей практикой, хотя на практике секреты не являются такими уж секретными.

Наконец, можно предоставить всю конфигурацию Spring в ConfigMap. Это полезно в том случае, когда ключ значения содержит произвольную карту; например, установка тегов для вашей системы метрик. В этом случае сопоставление переменных среды может не работать. Этот подход может быть более понятным для чтения; это много настроек, но только один раз для каждого приложения; в контексте Helm вы также можете использовать шаблоны; но он не может ссылаться на секретные значения.

# 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

Любая идея, как распределить поток по разным модулям? Я вижу, что одна и та же задача выполняется потоком во всех модулях.

darkstar 22.01.2023 22:09

Поток по своей сути является локальным для данного процесса. Вы можете посмотреть на поддержку Spring для систем обмена сообщениями, таких как RabbitMQ, чтобы вставить рабочую очередь в вашу обработку.

David Maze 23.01.2023 02:33

Другие вопросы по теме