Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the method of Spring Cloud Config server-side configuration". The explanation in this article is simple and clear, easy to learn and understand. Please follow the idea of Xiaobian and go deep into it slowly to study and learn "what is the method of Spring Cloud Config server-side configuration" together!

Let's take a look at a rough working process of Config Server through the following diagram:

In conjunction with this picture, I would like to make the following five points:

1. First of all, we need a remote Git repository. We can use GitHub directly for our own learning. In the actual production environment, we need to build a Git server ourselves. The role of the remote Git repository is mainly to save our configuration files.

2. In addition to the remote Git repository, we also need a local Git repository. Whenever Config Server accesses the remote Git repository, it saves a copy to the local Git repository, so that when the remote repository cannot be connected, it directly uses the locally stored configuration information.

3. As for microservice A and microservice B, they are our specific applications. These applications will load corresponding configuration information from Config Server when they are started.

4. When microservice A/B tries to load configuration information from Config Server, Config Server will clone a configuration file and save it locally through git clone command.

5. Since configuration files are stored in the Git repository, configuration files naturally have version management capabilities. The Hook feature in Git can monitor configuration file modifications in real time.

Placeholders in Git URIs

Flexible use of URI placeholders can effectively reduce our workload. Consider this problem, I have two services, ServerA and ServerB, the storage address of the configuration file corresponding to the two services is located at https://github.com/lenve/scConfig/sa and https://github.com/lenve/scConfig/sb respectively, but my Config Server only has one, so when my ServerA and ServerB are connected to Config Server, how does Config Server know which address to get the configuration file? This time it involves the use of placeholders.

In the previous article, we have learned about the three placeholders in Spring Cloud Config, namely {application},{profile} and {label}. In addition to identifying the rules of the configuration file, these placeholders can also be used to configure the URI of the Git repository in Config Server. When used in URI configuration, the meanings of these three placeholders are as follows:

1. {application} maps to client's spring.application.name

2. {profile} maps to spring.profiles.active on client

3. {label} This is a server-side feature, a set of profiles labeled "version"

At this point, suppose my configuration files for different environments are placed in the following directories:

https://github.com/lenve/scConfig/app/dev

https://github.com/lenve/scConfig/app/prod

https://github.com/lenve/scConfig/app/test

Then my client file is configured like this:

spring.application.name =app# dev Modify spring.cloud.config.profile=devspring.cloud.config.label=masterspring.cloud.config.uri=http://localhost:2007/server.port=2008

Configure Config Server as follows:

spring.cloud.config.server.git.uri=https://github.com/lenve/scConfig.gitspring.cloud.config.server.git.search-paths={application}/{profile}

Of course, this storage plan is not necessarily the best, here is just to demonstrate the use of placeholders for small partners.

By default, Config Server clones are stored in the C:\Users\\AppData\Local\Temp directory. We can modify them by configuring them as follows:

spring.cloud.config.server.git.basedir=E:\\111\\Health Monitoring

By default, Spring Cloud Config will create a health monitor for the configuration center server. By default, this detector accesses the repository file {application} as the app configuration file. If this file does not exist in the repository, the health monitor will display that the repository cannot be connected. In this case, we have two solutions: 1. Add the corresponding configuration file to the repository;2. Re-specify the detection configuration. The re-specification method is as follows:

spring.cloud.config.server.health.repositories.check.name=appspring.cloud.config.server.health.repositories.check.label=masterspring.cloud.config.server.health.repositories.check.profiles=dev

At this point, the system goes back to http://localhost:2007/app/dev/master address, if you can access it, it shows that the repository has been connected, as follows:

safety protection

In the development environment, our configuration center must not be accessed casually, we can add appropriate protection mechanisms, because microservices are built on top of Spring Boot, so integrating Spring Security is the most convenient way.

First add dependencies:

org.springframework.boot spring-boot-starter-security

Then configure the username password in application.properties:

security.user.name=sangsecurity.user.password=123

Finally, configure the username and password on the client in the configuration center, as follows:

Spring.cloud.config.username=sangspring.cloud.config.password=123 Thank you for reading, the above is the "Spring Cloud Config server configuration method is what" content, after learning this article, I believe you have a deeper understanding of Spring Cloud Config server configuration method is what this problem, the specific use of the situation also needs to be verified. Here is, Xiaobian will push more articles related to knowledge points for everyone, welcome to pay attention!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.