Communication Variable Injection

This article applies to application developers and operation and maintenance personnel

Communication variables refer to the necessary configuration variables when using other components to provide services, such as the user name password and communication address of the database, the authentication method and communication address of the API service, and so on. In a standardized design scenario, the type of service that the formed business code depends on cannot be changed, but the actual service that it depends on can be changed. This design needs to rely on injecting configuration information through environment variables. The use case in the Communication Between Components article is to rely on standard variable injection to achieve dynamic service dependencies.

In the component development process, we recommend that developers use environment variables to define the configuration related to communication with other components. For example, spring boot uses the following method to configure the jdbc address:

spring.datasource.url=jdbc:mysql://${MYSQL_HOST:127.0.0.1}:${MYSQL_PORT:3306}/${MYSQL_DATABASE:test}
spring.datasource.username=${MYSQL_USER}
spring.datasource.password=${MYSQL_PASSWORD}

After the above definition, we actually set a specification. This business component needs a Mysql component, and the related configuration is defined through the above variables. What component we use to provide this service in the future is actually decoupled. We can define a Mysql component to provide it, or a Tidb component to provide it. The most important thing is that these components can provide the variable information required above. Therefore, communication variable injection is a very useful mechanism in component-dependent communication scenarios.

Prerequisites

  1. Create two components A and B, where A depends on B and needs to obtain related configuration information
  2. Understand the mechanism of communication between Kato components, refer to Communication Documents between Components

Operating Procedures

  1. Define the connection address variable: Under the port management page of the management panel of component B (assuming it is a Mysql service), we can define an alias for each port, click on the port settings _ use alias_ Part, you can set the alias of the port in the pop-up window, for example, set it to MYSQL. After setting, it will automatically generate two variables MYSQL_HOST and MYSQL_PORT for the connection address.

  2. Define other connection variables: Under the dependency management page of the management panel of component B, there is the definition and management of connection information variables, and the definition and management methods are consistent with environmental variables. After entering the panel after step 1, we will find that there are two variables, MYSQL_HOST and MYSQL_PORT. We can continue to define other variables such as MYSQL_USER, MYSQL_PASSWORD, etc.

  3. The defined variables are part of the environment variables and take effect in the current component: Some connection variables are also useful for the component itself. For example, Mysql defines MYSQL_USER, MYSQL_PASSWORD and other variables as the initialization data when Mysql is initialized. Define variables. Therefore, the connection information defined by the component in Kato will also take effect in the current component as an environment variable, and the component connection information and environment variables can be transferred to each other.

  4. Inject the defined variables into the component environment that depends on the current component: At this time, we drag and drop in the topology diagram to make A depend on B, and then update the A component. After completion, we can use Check below and find that there are MYSQL-related environment variables.

Common Problems

The difference between connection information and environment variables

The connection information and environment variables of the component have the same effect on the component itself, and will take effect as environment variables in its own operating environment and plug-in environment. The difference is that the connection information will be injected into other components that depend on the current component. It is equivalent to being Public.

Must the connection information be defined?

We recommend to define the connection information based on the actual common reason.