component storage

component storage

Why do components need to be stored

Component is the abstract concept of Rianbond, the bottom layer is run through container encapsulation, and the container disk file is short-lived, that is to say, the log, generated or processed files of the program in the container during the running process, once the container is closed or restarted, before The generated or stored files are lost.Therefore, it is necessary to mount a persistent storage space for the component container to save all kinds of data generated by the running of the program.

type of storage

Rainbond supports the following storage types by default:

shared storage
Local storage (host path/grlocaldata)
configuration file
Memory file storage

In addition to the above storage types supported by Rainbond by default, Rainbond also supports custom storage types to expand other storage types as needed.

shared storage

Shared storage is a distributed file system, NFS is used by default, and you can also connect to other distributed file systems (GlusterFS, NAS, etc.). Shared storage has very high reliability and scalability; at the same time, it It also has very high flexibility and can be shared with other components to allocate and isolate storage space based on tenant and component levels.

Shared storage presents different working modes for stateless and：components

stateless components
- There is no instance difference in shared storage, and the data of multiple instances is consistent.
- Can be depended on by other components to achieve data sharing between components.
stateful components
- Each instance has independent storage space
- cannot be shared by other components

local storage

The local storage uses a local disk (usually an SSD disk) of the host where the running instance corresponding to the current component is located, which does not have the attribute of being available across hosts.Local storage only supports stateful component types.Local storage is usually used for components that require very high storage performance, such as database components.They can handle data synchronization between multiple instances from the application level, such as Mysql using master-slave synchronization, TiDB’s equivalent cluster based on raft protocol, etc.These components generally do not require data synchronization at the storage level.

The scheduling of components configured with local storage will follow the host where the storage is located, which is a limited scheduling mechanism.For cluster-like database components, it is a better choice to use local storage to process multi-node synchronization of stored data from the application layer.

configuration file

A configuration file is a special storage type that allows the user to directly define the contents of a file, usually referred to as a configuration file. The Rainbond support configuration file has two major features：

Dynamic rendering

Syntax for dynamic rendering configuration file parsing environment variables:

${环境变量名}
${环境变量名:默认值}

Here is a snippet of the MySQL configuration file:

[mysqld]
port = ${PORT:3306}
socket = /tmp/mysql.sock

If the environment variable PORT exists in the component, then Rainbond will parse the value of PORT into the configuration file; if the environment variable PORT does not exist in the component, then Rainbond will parse 3306 into the configuration file.

If the specified environment variable does not exist, and no default value is set, then Rainbond will not parse

Configure file sharing

The configuration file can be shared through the mechanism of storage sharing. If you have a scene where multiple components use the same configuration file, you can share it directly without editing the settings multiple times.

The configuration file storage supports the editing function, that is, after adding, you can modify the content of the configuration file as needed. After the modification is completed, you need to update the component to take effect.

Memory file storage

The essence of memory file storage is a piece of tmpfs (RAM-backed filesystem), which is temporary , will be created when the component is started, and destroyed when the component is stopped. Although tmpfs is very fast, please note that you write Any file will count towards the component’s memory limit.Therefore, it is generally suitable for disk-based temporary computing scenarios.

How to add storage to components

There are two ways to add storage to：

Add component storage

Click Add Storage on the management panel/storage page, and fill in the relevant information of the storage according to the form prompts to confirm.

The storage addition is completed in the unmounted state, and the component needs to be updated or restarted to take effect.

Shared storage for other components

In Admin Panel/Storage Page Shared Components Storage Management

After clicking the [Mount Shared Storage] button, check the names of other components that need to be mounted, and fill in the directory to mount to this component

Finished mounting other component storage

After adding or mounting the storage of other components, you need to update or restart the components. The storage that mounts other components does not support mounting to stateful components.
When adding or mounting other component storage, the path of this component cannot use the reserved directory of the Linux system, such as：/dev, /usr, /bin, /sys, /proc, etc.

The persistent data of existing local docker running components has been migrated to Rainbond

Example gogs:

step 1 Start the gogs operation locally through docker run, and persist the relevant directories.

docker run -d --net=host -v /var/gogs:/data gogs/gogs

Step 2 The Rainbond platform can also run the above command through docker run. After the application is deployed, the storage path can be obtained through the grctl command.

Step 3 Back up the gogs data (data1) that needs to be migrated, then close the gogs on the platform, then replace the data of the gogs running on the platform with the backed up data1 data, and start the gogs on the platform

Starting from Rainbond 5.2, the /grdata directory is no longer mounted by default on the host due to operating permissions. Therefore, you can perform operations in the rbd-chaos component after querying the actual directory of the component stored in the distributed file system.

common problem

The significance of shared storage between components

Do you have a business scenario where one business component generates data and stores it in a local directory, and another business component reads the data for processing.In the traditional deployment mode, you can only deploy these two components to the same node, let alone multi-instance high-availability deployment.Using shared storage between components, the program does not make any modifications.When the business runs to any node, the read data can be shared normally.

Whether various storage types of Kubernetes are supported by Rainbond

Rainbond supports the existing storage types of Kubernetes by extending storage.For details, refer to Custom Storage Type

📄️ Component Custom Storage SettingsRainbond component custom storage management documentation

Component storage