Quelle est la différence entre SpringBoot application.yml et bootstrap.yml

SpringBoot prend en charge les fichiers de configuration dans deux formats : propriétés et YAML par défaut. Le premier a un format simple, mais ne prend en charge que les paires clé-valeur. Si vous avez besoin d'exprimer une liste, il est préférable d'utiliser le format YAML. SpringBoot prend en charge le chargement automatique des fichiers de configuration avec des noms convenus, tels que application.yml. S'il s'agit d'un fichier de configuration avec un nom personnalisé, vous devez trouver une autre méthode. Malheureusement, contrairement au premier qui dispose d'une méthode de chargement pratique comme @PropertySource, le chargement du second doit être réalisé à l'aide d'une logique de codage.

1. Ordre d'exécution de bootstrap.yml (bootstrap.properties) et application.yml (application.properties)

bootstrap.yml (bootstrap.properties) est utilisé pour s'exécuter au démarrage du programme et est utilisé pour les informations de configuration antérieures lecture. Par exemple, vous pouvez l'utiliser pour configurer les paramètres utilisés dans application.yml.

application.yml (application.properties) informations de configuration spécifiques à l'application, qui peuvent être utilisées pour configurer les paramètres publics qui doivent être utilisés dans. chaque module suivant.

bootstrap.yml est chargé avant application.yml

2. Les scénarios d'application typiques sont les suivants :

• Lorsque vous utilisez Spring Cloud Config Server, vous devez spécifier spring.application.name et spring dans bootstrap.yml. config.server.git.uri

• et quelques informations cryptées/déchiffrées

Techniquement, bootstrap.yml est chargé par un Spring ApplicationContext parent. Le Spring ApplicationContext du parent est chargé en premier, avant que le ApplicationContext de application.yml ne soit chargé.

Pourquoi devons-nous mettre les informations du serveur de configuration dans bootstrap.yml ?

Lors de l'utilisation de Spring Cloud, les informations de configuration sont généralement chargées à partir du serveur de configuration. Afin d'obtenir des informations de configuration (telles que les mots de passe, etc.), vous avez besoin d'une configuration de démarrage précoce. Par conséquent, placez les informations du serveur de configuration dans bootstrap.yml pour charger les informations de configuration réellement nécessaires pendant cette période.

3. Scénarios d'utilisation avancés

Contexte de démarrage

Spring Cloud créera un contexte Bootstrap en tant que contexte parent du contexte d'application de l'application Spring. Lors de l'initialisation, Bootstrap Context est responsable du chargement des propriétés de configuration à partir de sources externes et de l'analyse des configurations. Les deux contextes partagent un Environnement obtenu de l'extérieur. Les propriétés d'amorçage ont une priorité élevée et, par défaut, elles ne sont pas remplacées par la configuration locale. Le contexte d'amorçage et le contexte d'application ont des conventions différentes, donc un nouveau fichier bootstrap.yml est ajouté à la place de application.yml (ou application.properties). Assurez la séparation des configurations de contexte d’amorçage et de contexte d’application. Voici un exemple :

bootstrap.yml

spring:
  application:
    name: foo
  cloud:
    config:
      uri: ${SPRING_CONFIG_URI:http://localhost:8888}

Il est recommandé de configurer spring.application.name dans bootstrap.yml ou application.yml. Vous pouvez désactiver le bootstrap en définissant spring.cloud.bootstrap.enabled=false.

Hiérarchie du contexte d'application

Si vous créez un contexte d'application via SpringApplication ou SpringApplicationBuilder, le contexte parent Bootstrap Context sera créé pour le contexte d'application de l'application Spring. Il existe une fonctionnalité dans Spring selon laquelle le contexte enfant héritera des sources de propriétés et des profils de la classe parent, de sorte que le contexte d'application principal ajoutera des sources de propriétés supplémentaires par rapport à la non-utilisation de Spring Cloud Config. Les sources de propriétés supplémentaires sont :

• "bootstrap": Si le PropertySourceLocator est analysé dans le contexte Bootstrap et qu'il existe une propriété, elle sera ajoutée au CompositePropertySource. Spirng Cloud Config ajoute des propriétés de cette manière. Voir le code source ConfigServicePropertySourceLocator` pour plus de détails. Vous trouverez également un exemple de personnalisation ci-dessous.

• "applicationConfig: [classpath:bootstrap.yml]" , (s'il y a spring.profiles.active=production alors par exemple applicationConfig: [classpath:/bootstrap.yml]#production) : Si vous utilisez bootstrap.yml pour configurer le contexte Bootstrap, il a une priorité inférieure à application.yml. Il sera ajouté au contexte enfant dans le cadre de l'application Spring Boot. Introduit ci-dessous.

En raison des règles de priorité, Bootstrap Context ne contient pas de données de bootstrap.yml, mais il peut être utilisé comme paramètres par défaut.

Vous pouvez facilement étendre n'importe quelle hiérarchie de contexte que vous créez en utilisant l'interface qu'elle fournit ou en utilisant les méthodes incluses dans SpringApplicationBuilder (parent(), child(), sibling()). Bootstrap Context sera la classe parent de plus haut niveau. Chaque contexte étendu possède sa propre source de propriété d'amorçage (qui peut être vide). Chaque contexte étendu a un spring.application.name différent. En principe, les contextes parent-enfant au même niveau ont également des noms différents et, par conséquent, il y aura également différentes configurations de Config Server. Les propriétés du contexte enfant remplaceront celles du contexte parent si elles portent le même nom.

Notez que SpringApplicationBuilder permet de partager l'environnement à tous les niveaux, mais pas par défaut. Par conséquent, les contextes frères au même niveau n'ont pas nécessairement les mêmes profils ou sources de propriétés lorsqu'ils ne partagent pas quelque chose avec la classe parent.

Modifier la configuration de l'attribut Bootstrap

Emplacement du code source BootstrapApplicationListener.

   String configName = environment.resolvePlaceholders("${spring.cloud.bootstrap.name:bootstrap}");

    String configLocation = environment.resolvePlaceholders("${spring.cloud.bootstrap.location:}");

    Map<String, Object> bootstrapMap = new HashMap<>();bootstrapMap.put("spring.config.name",configName);
    if(StringUtils.hasText(configLocation)){
        bootstrapMap.put("spring.config.location", configLocation);
    }

bootstrap.yml是由spring.cloud.bootstrap.name（默认:”bootstrap”）或者spring.cloud.bootstrap.location（默认空）。这些属性行为与spring.config.*类似，通过它的Environment来配置引导ApplicationContext。如果有一个激活的profile（来源于spring.profiles.active或者Environment的Api构建），例如bootstrap-development.properties 就是配置了profile为development的配置文件.

覆盖远程属性

property sources被bootstrap context 添加到应用通常通过远程的方式，比如”Config Server”。默认情况下，本地的配置文件不能覆盖远程配置，但是可以通过启动命令行参数来覆盖远程配置。如果需要本地文件覆盖远程文件，需要在远程配置文件里设置授权
spring.cloud.config.allowOverride=true（这个配置不能在本地被设置）。一旦设置了这个权限，你可以配置更加细粒度的配置来配置覆盖的方式，

比如：

• spring.cloud.config.overrideNone=true 覆盖任何本地属性

• spring.cloud.config.overrideSystemProperties=false 仅仅系统属性和环境变量
  源文件见PropertySourceBootstrapProperties

自定义启动配置

bootstrap context是依赖/META-INF/spring.factories文件里面的org.springframework.cloud.bootstrap.BootstrapConfiguration条目下面，通过逗号分隔的Spring @Configuration类来建立的配置。任何main application context需要的自动注入的Bean可以在这里通过这种方式来获取。这也是ApplicationContextInitializer建立@Bean的方式。可以通过@Order来更改初始化序列，默认是”last”。

# spring-cloud-context-1.1.1.RELEASE.jar
# spring.factories
# AutoConfiguration
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.cloud.autoconfigure.ConfigurationPropertiesRebinderAutoConfiguration,\
org.springframework.cloud.autoconfigure.RefreshAutoConfiguration,\
org.springframework.cloud.autoconfigure.RefreshEndpointAutoConfiguration,\
org.springframework.cloud.autoconfigure.LifecycleMvcEndpointAutoConfiguration

# Application Listeners
org.springframework.context.ApplicationListener=\
org.springframework.cloud.bootstrap.BootstrapApplicationListener,\
org.springframework.cloud.context.restart.RestartListener

# Bootstrap components
org.springframework.cloud.bootstrap.BootstrapConfiguration=\
org.springframework.cloud.bootstrap.config.PropertySourceBootstrapConfiguration,\
org.springframework.cloud.bootstrap.encrypt.EncryptionBootstrapConfiguration,\
org.springframework.cloud.autoconfigure.ConfigurationPropertiesRebinderAutoConfiguration,\
org.springframework.boot.autoconfigure.PropertyPlaceholderAutoConfiguration

警告

小心，你添加的自定义BootstrapConfiguration类没有错误的@ComponentScanned到你的主应用上下文，他们可能是不需要的。使用一个另外的包不被@ComponentScan或者@SpringBootApplication注解覆盖到。

bootstrap context通过spring.factories配置的类初始化的所有的Bean都会在SpingApplicatin启动前加入到它的上下文里去。

自定义引导配置来源：Bootstrap Property Sources
默认的property source添加额外的配置是通过配置服务（Config Server），你也可以自定义添加property source通过实现PropertySourceLocator接口来添加。你可以使用它加配置属性从不同的服务、数据库、或者其他。

下面是一个自定义的例子:

@Configuration
public class CustomPropertySourceLocator implements PropertySourceLocator {

    @Override
    public PropertySource<?> locate(Environment environment) {
        return new MapPropertySource("customProperty",
                Collections.<String, Object>singletonMap("property.from.sample.custom.source", "worked as intended"));
    }
}

Environment被ApplicationContext建立，并传入property sources（可能不同个profile有不同的属性），所以，你可以从Environment寻找找一些特别的属性。比如spring.application.name，它是默认的Config Server property source。

如果你建立了一个jar包，里面添加了一个META-INF/spring.factories文件：

org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator

那么，”customProperty“的PropertySource将会被包含到应用。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!