Configuration isolation of multiple environments is one of the most basic features of a configuration center. The values are different in different environments, such as database information and service configuration.
Spring Boot Multi-environment configuration
First let’s review how to isolate the environment using configuration files in Spring Boot.
By default, we create an application.properties configuration file, which is context-neutral and generic.
To differentiate the environment we can create a configuration file for each environment, for example;
- Development environment application-dev.properties
- Test environment application-test.properties
Active =dev can be used to activate the configuration of the development environment at project deployment time, and spring.profiles. Active =test can be used to activate the configuration of the test environment.
Apollo multi-environment configuration
Since speaking of the configuration center, then I will have a more mature Apollo to carry out a comparison, some of the same or different points are analyzed, so that we can have a reference when selecting the type.
The multi-environment configuration of Apollo needs to be determined at the time of building. Each environment can be divided into different clusters, which can be created dynamically.
Select a different environment and perform configuration operations. The configuration in this environment is changed.
When the client is connected, the env is specified to obtain the configuration of the corresponding environment. Another point is that the configuration of each environment in Apollo is isolated by DB, and each environment has its own ConfigDB.
Nacos Multi-environment configuration
The Namespace is used to configure tenant granularity isolation. Different namespaces can have the same Group or Data ID configuration. One of the common scenarios of Namespace is the isolation of configurations in different environments, such as the isolation of resources (such as configurations and services) between the development test environment and the production environment.
If you have used Apollo, you should know that a Namespace in Apollo is a configuration file, which is very different from the concept of Nacos.
The configuration file in Nacos is defined as the Data ID, and the first thing you need to understand about any framework is its concepts.
In Nacos, multi-environment isolation is implemented, which means that we need to create multiple namespaces.
The final menu in Nacos is named namespaces. Click on it to see the following list of Spaces you can create:
Public is the default, we create a dev environment, this time will generate a data, we need to care about the namespace ID, to prevent namespace name conflicts, after saving an ID is automatically generated, the project needs to specify the current environment when the space ID, not the space name.
After the space is created, you can switch between different Spaces on the configuration list page. Then create the configuration in the corresponding space.
In our project, we will use Spring Boot to explain the current project’s space value.
nacos.config.namespace=334139e6-d700-4a7b-ae0d-5ae30abd94a8
Copy the codeThe best way is to pass in parameters during deployment. If you write directly in the project, do you have to change the namespace ID to the namespace ID on the line when you go online?
The way Apollo is designed in this area is that the environment can be configured in a configuration file on disk, just like a machine can be configured with an environment, so that the applications on that machine are the environment, and the environment follows the machine, not the project.
