Migrating Spring-based Application Configuration to Alibaba Cloud ACM

This blog explores how you can migrate your Java Spring application configuration to Alibaba Cloud Application Configuration Management (ACM) using a simple example.

Recently, some of my developer friends want to migrate their Java Spring application configuration to Alibaba Cloud Application Configuration Management (ACM). During the migration process, they asked some interesting questions. This article uses a simple example to explain their concerns during the migration process and gives the corresponding solutions. I hope you will find them helpful.

What Configuration Items Are Required to Be Migrated to ACM?

This is the first question for all users who want to migrate their configuration to ACM. Let's analyze this question in two dimensions—timeliness and security.

Timeliness: Comparison between Static and Dynamic Configuration Items

Static configuration items refer to those that basically do not need to be modified after the application is released. For example:

Software version number: The version number does not usually need to be changed after it is determined.
Log style: The layout of the log, for example, the timestamp, file name, and log level, typically does not need major changes.
Third-party software LicenseKey: Basically, it does not change. It is possible that a third-party software license is updated during use. However, such a configuration change can usually be handled by republishing the software.
PaaS platform connection string: For example, a database connection string contains the database name, username and password. This configuration item does not change unless the password is modified for the sake of compliance, or the database is changed.

Dynamic configuration refers to some configuration items which may change when the program is running. Such changes usually affect the running behavior of the program, for example:

Throttling parameters: Throttling parameters are generally not fixed. Throttling parameters, such as the response time (RT) threshold and peak transaction per second (TPS), are adjusted dynamically according to the actual workload pattern when the system is running.
Thresholds for monitoring and alerts: For example, the system generates an error alert when the transaction volume decreases by 20% in comparison with the previous period, and generates a critical alert when it decreases by 50%. For a monitoring system, the online service characteristics change frequently, so the thresholds are generally not fixed.
Log print level: For example, after something strange happens, we want to change the log print level from error to debug. We'd prefer dynamically adjusting this configuration item without restarting the application.
Multi-active disaster recovery: After a site suffers from a disaster, we definitely hope the service can be failed over as soon as possible. Therefore, this configuration item must take effect in seconds to minimize the asset loss.

In terms of timeliness, we recommend that users save their own copies of static configuration items, which should be as simple as possible. Dynamic configuration items need to be saved to the ACM to increase the flexibility and the timeliness of dynamic changes.

Security: Comparison between Non-Sensitive and Sensitive Configuration Items

Non-sensitive configuration items generally refer to technology-oriented configuration items. Exposing them does not cause security risks. For example:

Software version number: It iterates with the product and contains no business attributes. Therefore, it is not sensitive.
Log style: This configuration item is associated with the future diagnostics of a program, and it is not sensitive.
Log print level: This configuration item determines the content of a log to be printed, and it is not sensitive.
Throttling parameters: Throttling parameters are mainly used to maintain internal application stability, and they are not sensitive.
Thresholds for monitoring and alerts: They mainly specify the alert precision for the business, and they are not sensitive.
Multi-active disaster recovery: This configuration item is generally associated with the primary-backup configuration and service sharding. It is not sensitive.

Sensitive configuration items are often associated with business data and can cause security risks if they are disclosed to unauthorized persons, for example:

Third-party software LicenseKey: The disclosure of the license key may cause unauthorized use of it. It is sensitive.
PaaS platform connection string: For example, both internal and external users can easily log on to the business database and access sensitive business information with a database connection string. It is sensitive.

In terms security, we recommend that users save their own copies of the non-sensitive configuration items, which should be as simple as possible. Sensitive configuration items need to be saved to the ACM. For sensitive configuration items, encryption and authentication are required, and these items must be secured from unauthorized persons.

The summary for the timeliness and security analysis

How Can I Migrate Spring-based Java Application Configuration?

Java developers who use the Spring framework usually use the @value function to automatically insert configuration.

The Original Pure Static File Scenario

For example, this configuration contains two configuration items, the software version number and the database connection string:

We can automatically insert the configuration items by using the @PropertySource and @value annotations.

@Configuration
@ComponentScan("com.alibaba")
@PropertySource("classpath:myApp.properties")
  public class AppConfig {

  @Value(value="${url}")
  private String URL;
  @Value(value="${dbuser}")
  private String USER;
  @Value(value="${driver}")
  private String DRIVER;
  @Value(value="${dbpassword}")
  private String PASSWORD;

  @Value(value="${appVersion}")
  private String version;
}

Operations such as the connection and initialization of the related database are omitted in the above code.

The Mixed Configuration Scenario after the Start of the Configuration Migration

For the sake of security compliance or configuration timeliness, we need to migrate our configuration to the ACM. After the analysis, we found that we'd better migrate some database configurations to ACM. These configuration items are marked in red. The red part will be migrated to the ACM.

Next, we need to make the following three modifications.

Add a record for the relevant configuration on the ACM console.
Add ACM SDK dependencies to the Java engineering package.
Slightly modify the code—add annotations to enable ACM to retrieve configurations.

First, directly create a configuration item on ACM with the name of myapp.dbconfig.properties, and edit the configuration content in the corresponding edit box. For detailed instructions, see the ACM Quick Start document. The operation screenshots are as follows:

Second, add dependencies into maven's pom.xml file:

  <dependency> 
    <groupId>com.alibaba.nacos</groupId> 
    <artifactId>nacos-spring-context</artifactId> 
    <version>0.2.1- RC1</version> 
  </dependency>

Third, add API annotations to the corresponding AppConfig.java code, to enable ACM to retrieve dynamic configurations. Add the red part to the code.

  @Configuration @ComponentScan("com.journaldev") 
  @PropertySource("classpath:myApp.properties") 
  @EnableNacosConfig(globalProperties = 
  @NacosProperties(endpoint = "acm.aliyun.com", namespace = "xxx", accessKey = "xxx", secretKey = "xxx")) 
  @NacosPropertySource(dataId = "myApp.dbconfig.properties", autoRefreshed = true) public class AppConfig { 
  @Value(value="${url}") private String URL; 
  @Value(value="${dbuser}") private String USER; 
  @Value(value="${driver}") private String DRIVER; 
  @Value(value="${dbpassword}") private String PASSWORD; 

  @Value(value="${appVersion}") 
  private String version; public String getVersion() { 
      return version; 
  }
}

Now, the modification is finished. Because the ACM SDK supports Spring's @value annotation function, we barely need to modify the code.

Notes:

In the above code example, note that:

The ACM SDK used in the code is the Nacos SDK. Nacos (http://nacos.io) is the open-source form of ACM, and ACM is fully compatible with all Nacos APIs.
In the code example, I used plaintext annotations to fix ACM parameters, such as endpoints, namespace, AK, and SK. However, in actual practice, they do not need to be fixed.
The parameters, such as endpoint and namespace can be passed-in by using ACM's related file configuration or system variables. For details, see: https://www.alibabacloud.com/help/doc-detail/60138.htm
For sensitive information, such as AK and SK, we can use the ECS Ram Role function to enable the system to retrieve the information automatically, and we do not have to fix it in the code. For details, see: https://www.alibabacloud.com/help/doc-detail/72013.htm
The callback function for dynamic configuration listening is not included in the code. For how to use Spring-based dynamic configuration, see: https://github.com/nacos-group/nacos-spring-project

More Information

If you are interested in Nacos, the open source version of Alibaba Cloud ACM, visit our official website at https://developer.alibabacloud.com/opensource/project/nacos

Community

Migrating Spring-based Application Configuration to Alibaba Cloud ACM

What Configuration Items Are Required to Be Migrated to ACM?

Timeliness: Comparison between Static and Dynamic Configuration Items

Security: Comparison between Non-Sensitive and Sensitive Configuration Items

How Can I Migrate Spring-based Java Application Configuration?

The Original Pure Static File Scenario

The Mixed Configuration Scenario after the Start of the Configuration Migration

More Information

Read previous post:

Read next post:

Alibaba Clouder

You may also like

Comments

Alibaba Clouder

Related Products

API Gateway

Application Real-Time Monitoring Service