Summary of methods for configuring multi-environment management in Nacos (detailed steps)

This article brings you a summary (detailed steps) of how to configure multi-environment management in Nacos. It has certain reference value. Friends in need can refer to it. I hope it will be useful to you. Helps.

Multiple environment management

In Nacos, there are multiple concepts of different management levels, including: Data ID, Group, Namespace. As long as you make good use of the relationship between these hierarchical concepts, you can achieve multi-environment management according to your own needs.

Next, I will introduce several implementation methods that can be used:

Using Data ID and profiles to implement

Data ID in Nacos, we can understand it as It is the configuration file name of a Spring Cloud application. From the previous article "Spring Cloud Alibaba Basic Tutorial: Detailed Explanation of Nacos Configuration Loading Rules", we know that by default the name format of Data ID is like this: ${spring.application.name}.properties, that is: Spring Cloud application Named properties file.

In fact, the Data ID rules also include environmental logic, which is similar to the design of Spring Cloud Config. When the application starts, we can specify the specific environment name through spring.profiles.active. At this time, the client will organize the Data ID to obtain the configuration as: ${spring.application.name}-${spring.profiles .active}.properties.

Actually, the more original and most common matching rule is this: ${spring.cloud.nacos.config.prefix}-${spring.profile.active}.${spring.cloud. nacos.config.file-extension}. The above result is because both ${spring.cloud.nacos.config.prefix} and ${spring.cloud.nacos.config.file-extension} use default values.

Give it a try

We can use the examples in the article "Spring Cloud Alibaba Basic Tutorial: Using Nacos as the Configuration Center" (available in the warehouse at the end of the article) As a basis, let’s experience this configuration method that distinguishes environments.

Step 1: First, in Nacos, create the configuration content of two different environments based on this rule. For example:

As shown above, we have defined two independent environment configurations for DEV and TEST for the alibaba-nacos-config-client application. We can define different content values ​​in it so that we can later verify whether the correct configuration is actually loaded.

Step 2: In the configuration file of the alibaba-nacos-config-client application, add the environment configuration: spring.profiles.active=DEV

Step 3: Start the application, we can I saw the loaded configuration file printed in the log:

2019-01-30 15:25:18.216  INFO 96958 --- [           main] o.s.c.a.n.c.NacosPropertySourceBuilder   : Loading nacos data, dataId: 'alibaba-nacos-config-client-DEV.properties', group: 'DEFAULT_GROUP'

Using Group to implement

Group is an important concept used for collection management of Data ID in Nacos. Therefore, if we regard the configuration of an environment as a set, then we can achieve configuration management of different environments. There are no fixed regulations for the usage of Group, so when we actually use it, we need to according to our specific needs, which can be the management of multiple environments in terms of architecture operation and maintenance, or the parameter management of different modules in business. In order to avoid conflicts, we need to make certain plans at the beginning of the architecture design. Here, let’s first talk about the specific implementation of how to use Group to implement multi-environment configuration management.

Try it yourself

Step one: First, in Nacos, create the configuration content of two different environments by distinguishing the Group. For example:

As shown above, we have defined two independent configurations of the DEV environment and the TEST environment for the alibaba-nacos-config-client application. These two matchings are different from the previous method. Their Data IDs are exactly the same, only the GROUP is different.

Step 2: In the configuration file of the alibaba-nacos-config-client application, add the specified configuration of the Group: spring.cloud.nacos.config.group=DEV_GROUP

Step 3 : Start the application, we can see the loaded configuration file printed in the log:

2019-01-30 15:55:23.718  INFO 3216 --- [main] o.s.c.a.n.c.NacosPropertySourceBuilder   : Loading nacos data, dataId: 'alibaba-nacos-config-client.properties', group: 'DEV_GROUP'

Using Namespace to implement

Namespace should appear for the first time in this series of tutorials. Let’s take a look at the official concept description first: used for tenant-granular configuration isolation. Configurations of the same Group or Data ID can exist in different namespaces. One of the common scenarios of Namespace is the differentiation and isolation of configurations in different environments, such as the isolation of resources (such as configurations and services) between development and test environments and production environments.

In the official introduction, it was introduced that it can be used as an environment isolation. Let’s try it out!

Try it first

Step one: First, create multiple Namespaces based on the environment name in Nacos. For example:

Step 2: At the top of the configuration list, you can see that in addition to Public, there are several more Namepsace just created. Create configuration content for the alibaba-nacos-config-client application in the DEV and TEST spaces respectively:

Step 3: In the configuration file of the alibaba-nacos-config-client application, add the specified configuration of Namespace, for example: spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a.

It should be noted here that the namespace configuration does not use the name, but uses the ID of the Namespace.

Step 4: Start the application and verify whether the returned content is correct by accessing the localhost:8001/test interface. In this way, the current version of the log does not output information related to the Namespace, so it cannot be used as a basis for determining the content to be loaded.

In-depth thinking

Above we have used several different dimensions in the Nacos configuration management function to achieve multi-environment configuration management. In terms of results, no matter which method is used, it can meet the needs, but which one is the best?

The first type: realized through Data ID and profile.

Advantages: This method is very similar to the implementation of Spring Cloud Config. Users who have used Spring Cloud Config can transition to it without any sense of disobedience. Since the naming rules are similar, they must start from Spring Cloud Config. Migration is also very simple.

Disadvantages: This method will make the configuration content very confusing when there are many projects and environments. You will see a variety of different applications in the configuration list, and the configurations of different environments are intertwined, which is very unfavorable for management.

Suggestion: Use it when there are not many projects, or you can combine it with Group to make some split planning for the project according to the business or organizational structure.

The second type: implemented through Group.

Advantages: The configuration of each application is isolated by environment through Group. It is very convenient to use the search function of Data ID and Group to view the configuration from the application latitude and environment latitude respectively.

Disadvantages: Since it will occupy the Group latitude, you need to plan the use of the Group. After all, it may conflict with some configuration groups in the business.

Suggestion: Although this method is structurally better than the previous one, it may still cause some confusion. The main thing is to plan and control the management of the Group.

The third type: implemented through Namespace.

Advantages: The officially recommended method uses Namespace to distinguish different environments, releasing the freedom of Group, which allows the use of Group to focus on group management at the business level. At the same time, Namespaces are also displayed in groups on the Nacos control page. Different environment configurations can be isolated without searching, which is very easy to use.

Disadvantages: There are no shortcomings. It may be that it introduces one more concept and requires users to understand it.

Suggestion: Using this method directly will be more worry-free in the long run. Although for a small team, there may not be many projects, the first and second methods are enough, but what if it becomes bigger later?

Note: No matter which method is used to achieve it. For the configuration of the specified environment (spring.profiles.active=DEV, spring.cloud.nacos.config.group=DEV_GROUP, spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a), do not configure it In the application's bootstrap.properties. Instead, use -Dspring.profiles.active=DEV to dynamically specify it in the startup command of the release script, which will be more flexible!

The above is the detailed content of Summary of methods for configuring multi-environment management in Nacos (detailed steps). For more information, please follow other related articles on the PHP Chinese website!