Solución:
Cambie el nombre de sus archivos de propiedades en git o sistema de archivos donde su servidor de configuración está mirando.
a.properties -> <your_application_name>.properties
a.properties -> <your_application_name>-<profile-name>.properties
Por ejemplo, si el nombre de su aplicación es test y está ejecutando su aplicación en dev profile, debajo de dos propiedades se usarán juntas.
test.properties
test-dev.properties
También puede especificar perfiles adicionales en bootstrap.properties de su cliente de configuración para recuperar más archivos de propiedades como a continuación. Por ejemplo,
spring:
profiles: dev
cloud:
config:
uri: http://yourconfigserver.com:8888
profile: dev,dev-db,dev-mq
Si especifica como arriba, debajo todos los archivos se usarán juntos.
test.properties
test-dev.properties
test-dev-db.prpoerties
test-dev-mq.properties
Tenga en cuenta que la respuesta proporcionada asume sus archivos de propiedad abordar diferentes perfiles de ejecución. Si no es así, es decir, sus propiedades se dividen en diferentes archivos por alguna otra razón, por ejemplo, para fines de mantenimiento, divididos por dominio comercial / funcional, o cualquier otra razón que se adapte a sus necesidades, entonces, al definir un perfil para cada archivo, simplemente está “abusando” de la función del perfil para lograr su objetivo (varios archivos de propiedad por aplicación).
A continuación, podría preguntar “Está bien, entonces, ¿cuál es el problema con eso?”. El problema es que te abstienes de varias posibilidades que de otro modo tendrías. Si realmente desea personalizar la configuración de su aplicación por perfil, tendrá que crear pseudo, sub, perfiles para eso, ya que el nombre del archivo ya es un perfil. Ejemplo:
La configuración de su aplicación podría ser personalizada por diferentes perfiles, que usa dentro de su aplicación springboot (por ejemplo, en la anotación @Profile ()), déjelos ser dev, uat, pinchar. Puede iniciar su aplicación configurando diferentes perfiles como activos, por ejemplo, ‘dev’ frente a ‘uat’, y obtener el grupo de propiedades que desee. Para su archivo a.properties b.properties y c.properties, si se admitieran diferentes nombres de archivo, tendrías un-dev.propiedades b-dev.properties y c-devarchivos .properties vs a-uat.propiedades b-uat.properties y c-uatArchivos .properties para el perfil ‘dev’ y ‘uat’.
sin embargo, con la solución proporcionada, ya ha definido 3 perfiles para cada archivo: appname-a.properties appname-b.properties y appname-c.properties: a, B, y C. Ahora imagina que tienes que crear un perfil diferente para cada … perfil (¡ya muestra que algo va mal aquí)! terminarías con muchas permutaciones de perfil (que empeoraría a medida que aumentan los archivos): los archivos serían appname-a-dev.properties, appname-b-dev.propiedades, aplicaciónc-dev.properties vs nombre de la aplicación-a-uat.properties, appname-b-uat.propiedades, aplicaciónc-uat.properties, pero los perfiles se habrían aumentado de [‘dev’, ‘ uat’] para [‘a-dev’, ‘b-dev’, ‘c-dev’, ‘a-uat’, ‘b-uat’, ‘c-uat’] !!!
Peor aún, ¿cómo va a hacer frente a todos estos perfiles dentro de su código y más específicamente sus anotaciones @Profile ()? ¿Abordará el espacio de código con perfiles “artificiales” sólo porque desea agregar uno o dos archivos de propiedades diferentes? Debería haber sido suficiente para definir tu dev o uat perfiles, cuando corresponda, y defina en otro lugar los nombres de archivo de propiedades aplicables (que luego podrían ser compatibles con el perfil, sin ninguna otra acción de configuración), tal como sucede en la configuración de propiedades externalizadas para aplicaciones individuales de springboot
Para completar el argumento, solo agregaré aquí que si desea cambiar a .yml archivos de propiedad un día, con la solución de nomenclatura basada en perfiles proporcionada, también pierde la capacidad de definir diferentes “secciones de documento yaml por perfil” dentro del mismo archivo .yml (Sí, en .yml puede tener un archivo de propiedad y definir múltiples documentos yml lógicos en el interior, que generalmente se hace para personalizar las propiedades para diferentes perfiles, mientras tiene todas las propiedades relacionadas en un solo lugar). Pierde la capacidad porque ya ha utilizado el perfil en el nombre del archivo (appname-profile.yml)
He emitido una solicitud de extracción con una corrección menor para spring-cloud-config-server 1.4.x, que permite definir nombres de archivos admitidos adicionalmente (además de “application[-profile]”y” {appname}[-profile]”, que se admiten actualmente) proporcionando un spring.cloud.congif.server.searchNames propiedad ambiental – análoga a spring.config.name para aplicaciones springboot. Espero que sea revisado y aceptado.
Últimamente me encontré con el mismo requisito con un poco más de restricción de que no se me permite jugar con los perfiles del entorno. Así que no se me permitió hacer la respuesta aceptada. Estoy compartiendo cómo lo hice como alternativa a aquellos que podrían tener el mismo caso que yo.
En mi aplicación, tengo propiedades como:
appxyz-data-soures.properties
appxyz-data-soures-staging.properties
appxyz-data-soures-production.properties
appxyz-interfaces.properties
appxyz-interfaces-staging.properties
appxyz-interfaces-production.properties
appxyz-feature.properties
appxyz-feature-staging.properties
appxyz-feature-production.properties
application.properties // for my use, contains local properties only
bootstrap.properties // for my use, contains management properties only
En mi solicitud, Tengo estas propiedades particulares establecidas que me permiten lograr lo que necesitaba. Pero tenga en cuenta que también tengo el resto de la configuración necesaria (habilitar la configuración de la nube, la actualización del actuador, el descubrimiento del servicio eureka, etc.), solo resaltando estos para enfatizar:
spring.application.name=appxyz
spring.cloud.config.name=appxyz-data-soures,appxyz-interfaces,appxyz-feature
Puede observar que no quería jugar con el nombre de mi aplicación, sino que lo usé como prefijo para mis archivos de propiedades de configuración.
En mi servidor de configuración Configuré en application.yml para capturar pattern: 'appxyz-*':
spring:
cloud:
config:
server:
git:
uri: <git repo default>
repos:
appxyz:
pattern: 'appxyz-*'
uri: <another git repo if you have 1 repo per app>
private-key: ${git.appxyz.pk}
strict-host-key-checking: false
ignore-local-ssh-settings: true
private-key: ${git.default.pk}
En mi repositorio de Git tengo lo siguiente. Sin application.properties y bootstrap porque no quería que se publicaran y se reemplazaran / actualizaran externamente, pero puede hacerlo si lo desea.
appxyz-data-soures.properties
appxyz-data-soures-staging.properties
appxyz-data-soures-production.properties
appxyz-interfaces.properties
appxyz-interfaces-staging.properties
appxyz-interfaces-production.properties
appxyz-feature.properties
appxyz-feature-staging.properties
appxyz-feature-production.properties
Será la coincidencia de patrones pattern: 'appxyz-*' que capturará y devolverá los archivos coincidentes de mi repositorio de git. El perfil también se aplicará y obtendrá el archivo de propiedades correcto en consecuencia. También se preserva la priorización de valor.
Además, si desea agregar más archivos en su aplicación (digamos appxyz-circuit-breaker.properties), solo tenemos que hacer:
- Agregue el patrón de nombre en el
spring.cloud.config.name=...,appxyz-circuit-breaker - A continuación, agregue las copias del archivo localmente y también externamente (en el repositorio de git.
No es necesario agregar / modificar más o reiniciar su servidor de configuración más adelante. Para una nueva aplicación, es como registrarse una sola vez para agregar una entrada debajo del repos de application.yml.
¡Espero que te ayude de una forma u otra!