Previously on:

  • Spring Cloud Alibaba Basics: Service Registration and Discovery using Nacos
  • Spring Cloud Alibaba Basic Tutorial: Several service Consumption Modes supported
  • Spring Cloud Alibaba Basics: Using Nacos as the Configuration Center
  • Spring Cloud Alibaba Basic Tutorial: Details of Nacos Configuration loading rules

From the two previous articles on configuration management in Nacos, you learned how to add configuration to Nacos and how Spring Cloud applications can be configured to load their content. Next, we discuss a common concern when using the configuration center: how to implement and manage the configuration of multiple environments.

Multi-environment management

Nacos itself has several concepts of different management levels, including Data ID, Group, and Namespace. As long as you make good use of these hierarchical concepts, you can manage multiple environments according to your needs.

Here, I would like to introduce several implementations that can be used:

useData IDwithprofilesimplementation

In Nacos, Data ID can be understood as the configuration file name of a Spring Cloud application. By default, the name of the Data ID is ${spring.application.name}.properties. Properties file named after the Spring Cloud application.

In fact, the Data ID rules also include environment logic, similar to the design of Spring Cloud Config. When we start the application, we can specify the specific environment name via spring.profiles. Active, and the client will organize the Data ID to fetch the configuration as: The ${spring. Application. The name} – ${spring. Profiles. The active}. The properties.

In fact, the more primitive and most general matching rule looks like this: The ${spring. Cloud. Nacos. Config. The prefix} – ${spring. Profile. The active}. ${spring. Cloud. Nacos. Config. File – the extension}. And the results of the above because ${spring. Cloud. Nacos. Config. The prefix} and ${spring. Cloud. Nacos. Config. File – the extension} is used by default.

Give it a try

We can use the examples in Spring Cloud Alibaba Basics: Using Nacos as the Configuration Center (available in the end repository) to get a taste of this environment-specific configuration approach.

Step 1: In Nacos, create the configuration content for two different environments according to this rule. Such as:

As shown in the figure above, we define two separate environment configurations for DEV and TEST for the Alibaba-nacos-config-client application. We can define different content values inside to verify later that the correct configuration is actually loaded.

Step 2: Add the environment configuration: spring.profiles. Active =DEV in the configuration file of the alibaba-nacos-config-client application

Step 3: Start the application. We can see the loaded configuration file printed in the log:

The 2019-01-30 15:25:18. 96958-216 the INFO [main] O.S.C.A.N.C.N acosPropertySourceBuilder: Loading nacos data, dataId: 'alibaba-nacos-config-client-DEV.properties', group: 'DEFAULT_GROUP'Copy the code

useGroupimplementation

Group is an important concept used in Nacos for collection management of Data ids. Therefore, if we treat the configuration of one environment as a collection, then configuration management of different environments can also be implemented. There is no fixed regulation on the usage of Group, so we need to manage multiple environments in architecture operation and maintenance or manage parameters of different modules in business according to our specific requirements in actual use. In order to avoid conflicts, we need to do some planning at the beginning of the architecture design. Here, we first talk about how to use Group to achieve the specific implementation of multi-environment configuration management.

Give it a try

Step 1: In Nacos, create configurations for two different environments by differentiating groups. Such as:

As shown in the figure above, we define two separate configurations for the DEV environment and the TEST environment for the alibaba-nacos-config-client application. These two matches are different from the previous method. Their Data ID is exactly the same, but the GROUP is different.

Step 2: in alibaba – nacos – config – the client application configuration file, increase Group specified configuration: spring. Cloud. Nacos. Config. The Group = DEV_GROUP

Step 3: Start the application. We can see the loaded configuration file printed in the log:

The 2019-01-30 15:55:23. 3216-718 the INFO [main] O.S.C.A.N.C.N acosPropertySourceBuilder: Loading nacos data, dataId: 'alibaba-nacos-config-client.properties', group: 'DEV_GROUP'Copy the code

useNamespaceimplementation

Namespace is a first in this series of tutorials. Let’s start with the official concept statement: configuration isolation for tenant granularity. Different namespaces can have the same Group or Data ID configuration. One of the common scenarios of a Namespace is the isolation of configurations in different environments, for example, the isolation of resources (such as configurations and services) between the development test environment and the production environment.

In the official introduction, it can be used as the isolation of the environment, let’s try it out!

Give it a try

Step 1: Create multiple namespaces based on the environment name in Nacos. Such as:

Step 2: At the top of the configuration list, you can see that in addition to Public, there are several more Namepsace that you just created. Create a configuration for alibaba-nacos-config-client under DEV and TEST 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. The namespace = 83 eed625 – d166-4619 – df2088883a b923-93.

Note that the namespace ID is used instead of the namespace name.

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

Deep thinking

Above, we utilize several different dimensions of Nacos configuration management functionality to achieve multi-environment configuration management. In terms of the results, either way can meet the requirements, but which one is best?

The first one is implemented through Data ID and profile.

  • advantages: This approach is very similar to the implementation of Spring Cloud Config. Users who have used Spring Cloud Config can transition to Spring Cloud Config without violating the rules. Since the naming rules are similar, it is also very easy to migrate from Spring Cloud Config.
  • disadvantagesThis approach can be very confusing when there are multiple projects and environments. In the configuration list, you can see that the configurations of different applications and environments are intertwined, which is very difficult to manage.
  • advice: the project is not used for a long time, or can be combinedGroupBreak down the project according to the business or organizational structure.

The second way: through the Group.

  • advantagesThrough:GroupAccording to the environment, the application configuration is isolated. Can be very convenient to useData IDandGroupTo view configurations by application latitude and environment latitude respectively.
  • disadvantages: Because it will occupyGroupLatitude, so you need to pairGroupAfter all, some configuration groups on the business conflict with the use of good planning.
  • advice: Although this method is structurally better than the previous one, there may still be some confusion, mainly in theGroupTo do a good job in the management of planning and control.

The third way is through Namespace.

  • advantages: The official recommended way throughNamespaceTo distinguish between different environments, releasedGroupDegrees of freedom, so that you can makeGroupFocus on group management at the business level. At the same time, Nacos control page forNamespaceThere are also group displays, no need to search, can separate different environment configuration, very easy to use.
  • disadvantages: No shortcomings, may be the introduction of a concept, users need to understand it.
  • advice: It will be easier in the long run to use this method directly. Although there may not be a lot of projects for a small team, the first and second approach is enough, but what if it gets bigger later?

Note: either way. For the specified environment configuration (spring. Profiles. The active = DEV, spring. Cloud. Nacos. Config. The group = DEV_GROUP, spring. Cloud. Nacos. Config. The namespace = 83 eed 625-D166-4619-b923-93DF2088883A), do not configure it in the application bootstrap.properties. It is more flexible to specify it dynamically in the startup command of the publishing script with -dspring.profiles. Active =DEV! .

The resources

  • Nacos official documentation

Code sample

Readers of the sample article can check out the Alibaba-Nacos-config-client project in the following repository:

If you are interested in these, welcome to star, follow, favorites, forward to give support!

The following tutorials may be of interest to you