Spring Cloud Config Server ricerca tramite Eureka utilizzando Java invece di bootstrap.yml

Question

Sto tentando di creare codice nel nostro base pom che autoconfigura la ricerca del server Spring Cloud Config tramite Eureka. Lo stiamo facendo per evitare la templazione delle proprietà .yml per gli sviluppatori che creano microservizi. Ad esempio, vogliamo java config tutti i comportamenti innescato da queste proprietà:

spring: 
    application: 
    name: MyMicroservice 
    cloud: 
    config: 
     enabled: true 
    server: 
     prefix: /diagnostics/admin/config 
    failFast: true 
    discovery: 
     enabled: true 
     serviceId: echo 

management: 
    context-path: /diagnostics/admin 

eureka: 
    password: password 
    client: 
    serviceUrl: 
     defaultZone: http://user:${eureka.password}@localhost:8761/eureka/ 
    instance: 
    leaseRenewalIntervalInSeconds: 10 
    statusPageUrlPath: /diagnostics/admin/info 
    healthCheckUrlPath: /diagnostics/admin/health 

Dopo molta sperimentazione, il seguente approccio funziona per lo più fatta eccezione per il server di configurazione Eureka-scoperto (con conseguente immobili di configurazione override):

@Order(-1) 
public class AdditionalBootstrapPropertySourceLocator implements PropertySourceLocator { 

    @Override 
    public PropertySource<?> locate(Environment environment) { 
     Map<String, Object> theBootstrapYmlConfig = new HashMap<>(); 
     theBootstrapYmlConfig.put("spring.cloud.config.enabled", new Boolean(true)); 
     theBootstrapYmlConfig.put("spring.cloud.config.server.prefix", "/diagnostics/admin/config"); 
     theBootstrapYmlConfig.put("spring.cloud.config.failFast", new Boolean(true)); 
     theBootstrapYmlConfig.put("spring.cloud.config.discovery.enabled", new Boolean(true)); 
     theBootstrapYmlConfig.put("spring.cloud.config.discovery.serviceId", "echo"); 

     theBootstrapYmlConfig.put("management.context-path", "/diagnostics/admin"); 

     theBootstrapYmlConfig.put("eureka.client.serviceUrl.defaultZone", "http://user:password@localhost:8761/eureka/"); 
     theBootstrapYmlConfig.put("eureka.instance.leaseRenewalIntervalInSeconds", new Integer(10)); 
     theBootstrapYmlConfig.put("eureka.instance.statusPageUrlPath", "/diagnostics/admin/info"); 
     theBootstrapYmlConfig.put("eureka.instance.healthCheckUrlPath", "/diagnostics/admin/health"); 

     return new MapPropertySource("myExtraBootstrap", theBootstrapYmlConfig);  
    }  
} 

e mi sembra di bisogno di questo fagiolo così:

@ConditionalOnWebApplication 
@Configuration 
@Import(EurekaClientAutoConfiguration.class) 
public class WorkfrontDiscoveryClientConfigServiceBootstrapConfiguration { 

    @Bean 
    @ConditionalOnClass({ DiscoveryClient.class, ConfigServicePropertySourceLocator.class }) 
    @ConditionalOnMissingBean 
    DiscoveryClientConfigServiceBootstrapConfiguration discoveryClientConfigServiceBootstrapConfiguration() { 
     DiscoveryClientConfigServiceBootstrapConfiguration discoveryClientConfigServiceBootstrapConfiguration = 
       new DiscoveryClientConfigServiceBootstrapConfiguration(); 
     return discoveryClientConfigServiceBootstrapConfiguration; 
    } 

} 

Infine, ho messo sia in spring.factories per assicurare che siano costruiti. Il problema è che PropertySourceLocator non viene mai utilizzato per costruire la chiamata all'interno di ConfigServicePropertySourceLocator per recuperare le proprietà. Non importa quello che faccio, non riesco a trovare una corrispondenza con i comportamenti che specificano le proprietà all'interno di bootstrap.yml.

Edit 4 giorni dopo

Il fattore chiave (e la restrizione) qui è la possibilità di cercare il server di configurazione tramite Eureka. Nell'attuale release cloud di primavera (1.0.2), l'origine della proprietà viene recuperata e costruita troppo presto nel ciclo di inizializzazione della primavera per la config-up-e-eureka java source config-source che ho sopra. Inoltre, se il server Eureka è lento o non è disponibile all'avvio del bootstrap, l'origine della proprietà del server Config non viene mai ricostruita al momento dell'arrivo di Eureka. Questo nella mia mente è un insetto.

ho risolto tutto questo, eliminando il concetto di guardare in alto il server di configurazione attraverso Eureka, e che richiedono questa configurazione minima in bootstrap.yml:

spring: 
    application: 
    name: MyMicroservice 
    cloud: 
    config: 
     uri: http://localhost:8888/diagnostics/admin/config 

eureka: 
    client: 
    serviceUrl: 
     defaultZone: http://user:password@localhost:8761/eureka/ 

e quindi impostando il resto in AdditionalBootstrapPropertySourceLocator java

Modifica 30 giorni dopo

Le proprietà di bootstrap di Java-configing continuano a rappresentare una sfida. Lo sto facendo perché sto sviluppando un framework senza template o generazione di codice (la premessa di boot primaverile). Ho aggiunto il ritentato di primavera al mix e il client-to-config è stato riprovato, ma la re-registrazione ad Eureka no. Questo è il motivo per cui Eureka-prima doveva essere abbandonata per me. Metterei il mio voto per integrare il ritentato di primavera nel processo di registrazione di Eureka, così posso tornare su Eureka, prima per il mio framework. Ancora su Spring Cloud 1.0.2.

Modifica 100 giorni dopo

Aggiornamento per dove siamo finiti. Proseguendo lungo il nostro mantra di evitare di template di proprietà, far rispettare le politiche e le pratiche all'interno del codice .. e continuando senza Eureka-primo concetto, abbiamo abbandonato PropertySourceLocator e semplicemente usato uno SpringApplicationRunListener come segue:

public class OurFrameworkProperties implements SpringApplicationRunListener { 
    : 
    public void started() { 
    if (TestCaseUtils.isRunningFromTestCase()) { 
     System.setProperty("spring.cloud.config.failFast", "false"); 
     System.setProperty("spring.cloud.config.enabled", "false"); 
     System.setProperty("eureka.client.enabled", "false"); 
    } else { 
     // set production values same way 
    } 
    } 
} 

Un messaggio di attenzione che questo è cominciato () viene effettivamente chiamato due volte all'interno del codice sorgente (una volta che non passa nessun argomento del programma btw) ogni volta che l'applicazione Spring viene eseguita o ottiene un aggiornamento Actuator().

Answer 1

Se il PropertySourceLocator è elencato in spring.factories (presumo come BootstrapConfiguration) allora deve essere un @Component (o forse anche un @Configuration).