How to make programmers be cloud native – configuration

Time:2020-2-8

Preface

This is the second article in the “how programmers make themselves be cloud native” series. From the feedback in the first article, some students give feedback that the twelve elements are too formalistic to follow blindly. The author believes that any theory and technology need to have their own views, which are based on the discrimination ability gradually exercised by the individual knowledge system.Be Cloud NativeThis series of articles will share some experience based on the theory of twelve elements and the changes observed in the evolution of architecture since the birth of cloud computing.

Chapter one: warehouse and dependence. “Portal”

Example

The core idea of configuration is code and data isolation. When our software is very small at the beginning, we may directly write all kinds of configuration and even code in the production environment in the code, configuration or even a part of the code? For example, the following code break is as follows:


public boolean serviceConnectable() {
  return ping("edas.console.aliyun.com", 3);
  }

This method realizes the function of whether a local can connect to the remote server. If you write according to the above code, you can only achieve the desired effect in the public cloud environment. If the program is deployed in a proprietary cloud or IDC environment, the code needs to be changed.

If you change to the following way, the effect will be quite different. At that time, if the program is deployed in a new environment, it only needs to changeedas.server.addressThis configuration.

@Value("edas.server.address")
private String remoteAddress;

public boolean serviceConnectable() {
return ping(remoteAddress, 3);

}

Definitions and examples

This example should be closer to your daily life. We will upgrade the above example to a higher level and make a preliminary definition as follows: application behavior = code + input. The code is fixed and needs to be recompiled and distributed, which cannot be changed according to the environment; the input is alive. The above example is aCodePart of the content in theDataThe process. After this change, the application is more adaptable to change. Of course, theseDataSome are entered by the user, some are determined when the system is started, and the latter is defined by usTo configure, which is also the subject of our discussion today. From this perspective, configuration can include many kinds. For example, the Java language can be divided into at least the following:

  • File configuration in Code: *. Properties file.
  • File configuration *. Properties file on the machine.
  • Start parameters specified with the – D parameter.
  • Environment variable.
  • Configuration management system, simple db; more popular domain products such as Nacos, zookeeper, ectd, etc.

With more choices, it seems that the world is not so wonderful, because we always fall into “what to use” and “why”. The author’s point of view is that before using what, first make clear two aspects of the demand level:

  • Isolation granularity: is each version different? Is each machine different? Is each process different?
  • Security: visible to operation and maintenance personnel? Visible to developers? Or should it not be visible?

Before discussing these two points carefully, let’s give a few examples about configuration:

  • Program version number: from codeReleaseFrom the beginning of (build), it is basically determined; there is basically no possibility for this kind of configuration to change, that is, the isolation granularity of this kind of configuration is equal toCode 。
  • Version number of a front-end component: the front-end version number has a feature of frequent changes, especially in the online process, it is very common to release three or four versions; and in the online process, the gray level verification is generally performed first, and then the online release. So this kind of configuration needs to have a feature that it can be flexibly changed and released according to the granularity of the environment (different machines, different traffic).
  • Server port number: the port number of the server needs to be bound to the process, especially in some microservice scenarios; if the same service is deployed on the same machine, it must accurately inform other services of the exact address and port of the service.
  • Database meta information configuration: in this configuration, the same service in the same set of environment will be the same, and the deeper its real value is hidden, the better. In addition, there are some AK / SK, user name and password. Each set of environment will be different, and the security requirements of different products for this kind of configuration may be different.

Induce

Through the simple discussion of the above examples, we can roughly classify the relevant configurations as follows:

Configuration item location Isolation Safety
Code file Control the behavior of different versions of software, which is the same as the code and basically unchanged Visible to all people with code permission
Documents on the machine Isolation at machine environment level The visibility can be set flexibly according to the system permission of the file
startup parameter Process level isolation It can be seen if it can enter the system
environment variable It can be flexibly matched according to the container, system, user and process Can be set to system user level
Configuration management system Programmers are free to program, generally service level isolation Depending on the implementation of different products, some schemes can achieve the best security

What the author would like to emphasize here is the point of security, especially in some financial scenarios. The native configuration mode can’t achieve high security without making code changes. However, in some distributed products, especially in some cloud products, it can be very secure. For details, please refer to the following figure:

Take the implementation of ACM on the cloud of Nacos as an example to give a simple explanation of the above figure. The general program reading configuration mode is shown in the left figure. After executing the startup script, the application program obtains the configuration from the environment variable, file or startup parameter set in the script. These methods can meet most scenarios, but if your application is a distributed large cluster, it is impossible to configure it on the machine if you want to change a configuration at this time, and then modify the area of one set. At this time, we need a distributed configuration service that supports large clusters. There are many open source configuration centers, such as zookeeper, etcd, Nacos, etc.

But there is a scenario where the configuration center in general can not meet the requirements, that is, the configuration with high security requirements such as database password. There will be some good implementations of this kind in the cloud. The example on the right of the above figure explains how to do it in the cloud:

  • When the user writes a configuration to the configuration service, the encryption service will be used for encryption first, as shown in Figure a.
  • If necessary, push the corresponding encrypted data to the corresponding client, B in the figure.
  • When the client receives the data, it will request the cloud encryption service to decrypt it according to the cloud role on the machine. C in the figure.

From the above description, we can feel the whole process. With the ability of cloud ecology, we can do it elegantly and safely without any additional code intrusion.

summary

To write here, I need to point out that to achieve “be cloud native”, configuration is an essential link. One of the ways to make our world a little better is to turn every hard coded character into an operational and safe configuration.

At the same time, on the cloud, we will see different, more elegant, more secure and lower cost solutions. The security of configuration is simple and easy, which may cause sensitive information of production level or even DB leakage.

Another meaning of be cloud native is to build a more secure, elegant, scalable and highly available application architecture by making the most of the native technology capabilities provided by cloud vendors.


Author: middleware brother

Read the original text

This is the original content of yunqi community, which can not be reproduced without permission.