До использования Spring Cloud Config моя команда использовала Puppet для настройки приложений в различных средах (dev, test, preprod, prod). Наши сценарии являются типичными: общие свойства для приложений плюс определенные свойства, объединенные во всех средах.
Чтобы справиться со всеми возможными различными значениями одного и того же свойства конфигурации в зависимости от среды, а также с теми свойствами конфигурации, которые совместно используются несколькими приложениями в одной среде, мы разработали подход определения «общей» конфигурации файл в среде со всеми возможными значениями «замены» (которые мы придумали как «токены»).
Так, например, давайте представим, что у нас есть 5 приложений в среде "dev", которые совместно используют 2 URL базы данных. Мы бы создали следующий «общий» файл конфигурации со следующими «токенами»:
databaseX.url = jdbc:url:.......
databaseY.url = jdbc:url:.......
Затем для каждого приложения мы определяем собственный файл свойств конфигурации, в котором мы определяем заполнители, которые будут заменены соответствующими токенами в «общем» файле конфигурации. Так, например, это будет файл свойств конфигурации для App1:
app.name = App1
property1 = value1
property2 = value2
...
database.url = ${databaseX.url}
А это для App2:
app.name = App2
property3 = value3
property4 = value4
...
database.url = ${databaseY.url}
Видишь смысл? При таком подходе мы могли бы поддерживать глобальный «общий» файл свойств конфигурации для каждой среды, где каждое отдельное приложение могло бы решить, какое свойство выбрать, и Puppet просто заменит его на определенный «токен». Обратите внимание, что Puppet заменит только запрошенные "токены", а не полный "общий" файл свойств конфигурации.
Однако при переходе к Spring Cloud Config я еще не выяснил, как реализовать этот подход, поскольку наличие «общего» файла свойств конфигурации (верхний уровень application.yaml в терминах иерархии Spring Cloud Config) всегда приводит к в все свойства , определенные в таком application.yaml, копируются во все приложения, следовательно, каждое отдельное приложение заканчивается множеством свойств, которые ему не требуются (а также создает проблему безопасности / конфиденциальности). конечно).
Следовательно, существует ли в Spring Cloud Config механизм, с помощью которого я могу просто заменить свойства родителя, если и только если его аналог-заполнитель определен в конфигурации приложения, и, следовательно, отбрасывать остальные свойства не явно запрашивается в качестве заполнителей?
Подход будет аналогичен тому, что делает плагин «Фильтр ресурсов» для Maven:
https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
Мне бы очень хотелось услышать от людей, которые решили эту проблему с помощью Spring Cloud Config.
Спасибо!