This is the 18th day of my participation in Gwen Challenge

“Configuration center Spring Cloud Config in detail” series of articles updated, together in the road of technology progress! This series of articles will introduce Spring Cloud Config, which provides a distributed configuration center in Spring Cloud. In addition to the code to realize system functions, application services also need to connect resources and other applications. There are often a lot of data that need to be configured externally to adjust the behavior of applications, such as switching different databases and setting function switches. With the increase of microservices, the system needs to be scalable and extensible, in addition to managing the configuration data of a considerable number of service instances. In the application development stage, each service is autonomous, but in the production environment, it will bring great trouble to the operation and maintenance, especially the micro service scale is relatively large, configuration update is more troublesome. Therefore, the system needs to establish a unified configuration management center.

Application of advanced

The basic application of Spring Cloud Config consists of three main elements:

  • Configuring the Server
  • Configuring the Client
  • Configuration of the warehouse

When the Config client is started, the corresponding configuration information is pulled from the Config Server according to the configuration rules, and then the context of the Config Client is initialized. Dynamic refreshes of configurations and webHook applications for configuration refreshes have also been added.

Other functions include pattern matching and repO, encryption and decryption of configuration warehouse, attribute overwriting, SVN configuration (local) warehouse, and security protection.

In previous articles, we focused on how Spring Cloud Config overwrites remote configuration properties on the client and uses SVN or local file systems as configuration repositories. This article will focus on local file systems and the use of attribute overrides.

Local file system

If you don’t use Git or SVN, Config Server also provides a native file system, corresponding to a “native” profile. Load the configuration file from the local classpath or file. The use of “spring. Cloud. Config. Server. Native. SearchLocations” any you want to configure a static route.

spring:
  profiles:
    active: native
  cloud:
    config:
      server:
        native:
          searchLocations: file:/Users/user/Documents/config-repo
Copy the code

Note that the path to the resource file is prefixed with file:, which is not usually found in the default CLASspath path. The environment placeholder ${user.home} can also be used in Spring Boot applications, and in Windows absolute paths require additional /, such as file:/// /${user.home}/config-repo. SearchLocations Default value and the classpath of the Spring Boot application (for example, [classpath:/, classpath:/config, file:./, file:./config]). This does not expose application.properties from the server to all clients, because any property sources that exist in the server are removed before being sent to the client.

The search path can contain {application}, {profile}, and {label} placeholders so that you can divide the path into directories and choose a straightforward differentiation strategy.

If no placeholders are used in the search path, config Server automatically appends the {label} parameter to the search path HTTP resource when implemented, and the properties file is loaded from each search location and a subdirectory with the same name as the label (marked properties take precedence in the Spring environment). No placeholders, therefore, the default behavior and add a search path to / {label} / ending is the same effect, such as a search path configuration file: / TMP/config file: / TMP/config file: / TMP/config / {label} in fact is the same. Of course, this default behavior can be set by the spring. Cloud. Config. Server. Native. AddLabelLocations = false to stop.

Attribute to cover

Config Server has a property override feature that allows configured properties to be forcibly applied to all application services and cannot be accidentally changed by applications using normal Spring Boot hooks. Statement property coverage, is a kind of map format, in the spring. The cloud. Config. Server overrides the back to increase the key – value, the configuration shown below:

spring:
  cloud:
    config:
      server:
        overrides:
          cloud: Edgware.RELEASE
Copy the code

This will enable all configuration clients to read cloud: edgware.release independently of their configuration. Of course, applications can use the data in Config Server in any way, in which case overrides cannot be performed, but if they are Spring Cloud Config clients, the above configuration is valid.

summary

This article focuses on the Spring Cloud Config local file system and the use of property overrides. In some cases, it is very convenient to use the local file system as the configuration source. In addition, when we need to overwrite some properties, we can also configure them through overrides.