A real-time container engine implementation method based on Ruihua process version operating system

Abstract

The present invention relates to a real-time container engine implementation method based on the Ruihua process version operating system. In view of the resource limitations, system complexity and security problems faced by the deployment and operation of existing container technologies in embedded systems, a real-time container engine architecture and implementation are constructed. The real-time container engine architecture includes a container runtime and a container engine daemon process. The container runtime includes real-time container configuration and container operation process and state transition. The container engine daemon process includes image management, state monitoring, log information, container and image services. It can support the deployment of OCI containers in a low-resource and high-real-time requirement environment and is compatible with traditional container management programs. It can be taken over by upper-level orchestration programs for scheduling and operation. It also optimizes the startup and memory consumption of traditional container engines and runs the container engine in a smaller space. It can meet the real-time requirements of user programs on the basis of ensuring the normal operation of the container.

Description

Technical Field

[0001] The present invention relates to a containerized application technology, and in particular to a method for implementing a real-time container engine based on a Ruihua process version operating system. Background Art

[0002] In today's era, the widespread application of cutting-edge information technologies such as big data processing and artificial intelligence has brought unprecedented challenges to complex systems. These electronic systems face numerous challenges amidst the rapid development of computer hardware and software. Currently, complex software platforms primarily execute tasks by deploying middleware and modular applications within a host operating system. However, these platforms present several significant challenges: low utilization of computer hardware resources; the increasing difficulty of electronic system resource design and configuration as software functionality continues to grow; and the difficulty of achieving software system reconfigurability.

[0003] In the commercial software sector, virtualization technology has become a mainstream solution to these problems. Virtual machine technology is an early adopter. Traditional virtual machine-based cluster management platforms manage infrastructure such as computing, storage, and network resources through the IaaS layer. Within these platforms, virtual machine resources are considered the smallest unit for resource scheduling, and external services are provided through virtual machines. However, this approach of virtualizing by simulating hardware consumes significant hardware resources. Furthermore, since each virtual machine requires loading the operating system kernel to build its own operating system upon startup, application startup and expansion are slow. This approach is limited in complex environments with constrained resources.

[0004] With the continuous development of virtualization technology, container technologies, represented by Docker, have emerged. Containers offer advantages such as lightweightness and flexibility, enabling better management of combat resources and deployment of coordinated combat missions. In complex and ever-changing network environments, the portability and scalability of containers enable dynamic task migration and resource expansion in the event of node failure.

[0005] Lightweight virtualization technology replaces virtual machines, encapsulating heterogeneous underlying platform resources as services to form a virtual resource pool. This is achieved through container cluster management tools and integrated with microservices to provide a unified service call interface. Lightweight container technology offers unmatched lightweight features that virtual machines cannot match, such as boot times in seconds and larger cluster sizes. This allows for full utilization of limited resources in embedded environments, while its near-host-like performance enables faster response and processing of assigned tasks. Compared to virtual machines, it can easily implement dynamic reconfiguration of cluster resources. In the event of node disconnection, resource exhaustion, or failure, not only can the entire platform's resources be dynamically added or removed from the resource pool, but individual resources can also be added or removed – a granularity difficult to manipulate with virtual machines. To complete a task, container technology can provide multiple resource combinations to upper-level decision-making modules or users. A predefined mechanism ranks available underlying resource combinations for selection.

[0006] The container engine based on the Ruihua Real-Time Process (RTP) operating system is designed for real-time embedded operating systems. This real-time container technology mainly includes two aspects:

[0007] 1. A container runtime based on the real-time operating system kernel features. Responsible for creating and running container application processes in an isolated environment.

[0008] 2. An upper-layer container daemon based on the underlying container runtime. Responsible for unified management of container instances and container images, as well as monitoring and scheduling container execution.

[0009] The advantages of real-time container technology include:

[0010] 1. Application isolation: Containers implement resource isolation and restrictions at the operating system level and file system-level isolation and restrictions at the container runtime level. Through two layers of restrictions, the system and container engine ensure that each container is isolated from each other at runtime, preventing out-of-bounds operations of applications and improving security.

[0011] 2. Real-time performance: The container runtime based on the real-time kernel reduces unnecessary expenses during container creation and operation, as well as the kernel-user mode switching process, through streamlined module design and startup process design, ensuring the real-time performance of container applications.

[0012] 3. Configurable: The container setting provides users with a series of interfaces and configuration items, allowing users to create one or more container environments suitable for their own business scenarios according to their needs so that they can be started quickly and executed efficiently after creation.

[0013] 4. Lightweight: Containers contain only the necessary dependencies and the application itself, eliminating the need to run a complete operating system. The size of the container image is also strictly controlled, allowing for fast transfer between different devices.

[0014] 5. Rapid deployment: RTP container images can be quickly generated using default configurations, and container instances can be started within seconds, facilitating rapid and large-scale deployment of applications.

[0015] Real-time container technology ensures application security by isolating resources at the operating system and runtime levels. Designed based on a real-time kernel, it enables efficient startup and operation, guaranteeing real-time performance. It offers a rich set of configuration options to flexibly adapt to business needs. Its lightweight design includes only essential components for rapid transmission and deployment. It supports rapid generation and instantiation, accelerating large-scale application deployment.

[0016] Existing container technologies face multiple challenges in deploying and running embedded systems, primarily in terms of resource limitations, system complexity, and security.

[0017] First, embedded systems typically have very limited resources. Compared to servers in data centers or cloud environments, embedded devices have weaker CPU performance, smaller memory capacity, and limited storage space. While container technology is more lightweight than traditional virtual machines, it still requires a certain amount of computing and storage resources to run the container runtime environment and the applications within it. For example, the Docker daemon itself consumes a portion of system resources, which may be unacceptable for resource-constrained embedded devices. Furthermore, container images used in Linux or other large systems often include complete operating system environments, further increasing resource usage.

[0018] Secondly, security is a crucial consideration in embedded system design. While container technology provides a certain degree of isolation, it cannot completely replace traditional security measures. Existing container technologies are all based on the Linux operating system, relying heavily on the isolation and security mechanisms provided by kernel features. This makes them difficult to port to embedded operating systems outside the Linux family. This makes embedded operating systems with strong real-time requirements incompatible with existing container deployment frameworks. In embedded systems, any potential vulnerability could lead to a complete system crash or data leakage. Therefore, the dual security of system security isolation mechanisms and application isolation management in container technology is required to create secure containers for embedded system platforms.

[0019] Finally, because most existing container products are developed in Go, they are not compatible with most embedded platforms built on C / C++. This requires redesigning the underlying compilation and runtime environments to adapt to existing container solutions. This is challenging for embedded platforms designed for lightweight and high performance, and incurs high development and maintenance costs. The reusability advantages of Go development are not readily apparent on embedded platforms, and the language imposes requirements on the underlying runtime environment and library dependencies. This is why existing general-purpose container solutions are unsuitable for lightweight and low-resource embedded systems. Summary of the Invention

[0020] Aiming at the resource limitation, system complexity and security issues faced by the deployment and operation of existing container technologies in embedded systems, a real-time container engine implementation method based on Ruihua process version operating system was proposed.

[0021] The technical solution of the present invention is:

[0022] A method for implementing a real-time container engine based on the Ruihua process version operating system. The real-time container engine architecture consists of two parts: the container runtime and the container engine daemon. The container runtime includes real-time container configuration and container operation process and state transition. The container engine daemon includes image management, status monitoring, log information, container and image services. The specific implementation is as follows:

[0023] Container runtime: The container runtime creates container processes based on a given configuration and obtains the real-time running status of the container. The container processes started by it can be managed and scheduled by the upper-layer container engine. The container runtime supports operations such as creating, starting, terminating, and deleting containers. Each operation complies with the behavioral definitions in the OCI standard.

[0024] Real-time container configuration: Container creation depends on container configuration; users set container properties through a configuration file that complies with the OCI specification;

[0025] Container operation process and state transition: The state transition of the container conforms to the state definition in the OCI specification: Each container determines its creation and operation parameters through the configuration file and the container's bundle directory. When the container runtime is used to create a container, a corresponding process is created in user mode to execute the user program code. The various properties set in the configuration are parsed by the container runtime, and after it prepares the container operation environment, the corresponding properties are passed to the process as creation parameters. After the user issues an execution or start command, the container runtime sends a signal to the container process and places it in the task queue, waiting for the operating system to schedule it.

[0026] Container engine daemon: The daemon runs continuously in the embedded operating system as a resident background process. It is primarily responsible for managing container instances and OCI container images. It also uses the status information in the container runtime to generate richer container monitoring data and can generate container and system-level operation logs.

[0027] Image management: The daemon can import standard OCI container images and generate persistent storage information locally. Each time the container engine is started, it reads the local image data and container data. When creating a container instance, the daemon uses the read-only layer in the image to build the container's file system. When executing the container, it mounts the root file system and then calls the underlying container runtime to launch the user application.

[0028] Status monitoring: During the startup process, the daemon process can choose to start a monitoring task in the background to monitor the status and resources of the container environment managed by the current engine. The monitor will regularly collect status information of each container and perform survival checks on the container using a signal mechanism.

[0029] Log information: Users can use the log collector to persistently store the output results of the container; the log module can be manually enabled or disabled. Disabling the log module will improve the overall performance of the system.

[0030] Container and image services: The daemon process provides HTTP network services. The server receives container or image operation requests from various clients and returns the corresponding responses in formatted data types.

[0031] Furthermore, the container runtime at the lower layer is the cornerstone of the entire container engine. It interacts directly with the underlying operating system mainly by using system calls or kernel-level functions, and is the executor of creating, running, and managing container processes.

[0032] Furthermore, in the process version of Ruihua operating system, container instances are started with real-time processes as the smallest unit; the configurable items provided by the system include the container's OCI version, startup process, root file system, working directory, environment variables, mount point, memory limit, status hook function, configuration items to be expanded, host name, and host domain name.

[0033] Furthermore, during the container operation process and state transition, the stop and kill commands can be used to terminate the running state of the running container in advance; the terminated container will reclaim the relevant process resources and release the mount points used in the process, completely restoring the container to the state before it started running.

[0034] Furthermore, the daemon process at the upper layer is the unified manager of the entire system's container instances and container images, and is also the provider of the entire system's monitoring and external services.

[0035] Furthermore, the management of images includes generation, pulling, reading, and exporting.

[0036] Furthermore, in status monitoring, the monitor can collect container information including startup / running time, memory usage, CPU usage, I / O read and write rates, and network bandwidth.

[0037] Furthermore, in the log information, when the log function is turned on, when the container exits normally or crashes abnormally, you can view the output information of the corresponding container through the log collector for debugging.

[0038] Furthermore, in container and image services, the container engine for accessing network services can be combined with higher-level orchestration management or cluster management tools to form a container cluster with multiple other embedded devices, providing scalability for container deployment; a set of feasible container services can provide data for multiple types of business applications.

[0039] The beneficial effects of the present invention are:

[0040] Most traditional embedded operating systems are in resource-constrained environments, making it difficult to support the deployment of the Linux macro kernel and many kernel modules. Desktop machines such as Mac and Windows also use Linux VMs to run containers, and existing container solutions cannot be separated from the Linux kernel. The container engine designed based on the Ruihua process version of the operating system can support the deployment of OCI containers in low-resource, high-real-time requirements environments and is compatible with traditional container management programs. It can be taken over by upper-level orchestration programs for scheduling and operation. The solution also optimizes the startup and memory consumption of traditional container engines, running the container engine in a smaller space; and the container runtime based on the real-time process can meet the real-time requirements of user programs while ensuring the normal operation of the container. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 This is a schematic diagram of the overall design of the entire system architecture of the present invention;

[0042] Figure 2 A state transition diagram for managing the container lifecycle during the container runtime of the present invention;

[0043] Figure 3 The image hierarchy diagram stored locally in the present invention;

[0044] Figure 4 is a flow chart of the status monitoring of the present invention;

[0045] Figure 5 This is an example diagram of a set of feasible container services of the present invention that can provide data for multiple types of business applications. DETAILED DESCRIPTION

[0046] The present invention is described in detail below with reference to the accompanying drawings and specific embodiments. This embodiment is implemented based on the technical solution of the present invention, and provides a detailed implementation method and specific operation process, but the protection scope of the present invention is not limited to the following embodiments.

[0047] A real-time container engine implementation method based on Ruihua process version operating system. The entire system architecture includes two parts: container runtime and container engine daemon process. The overall design of the solution is as follows Figure 1 As shown:

[0048] 1. Container runtime

[0049] The container runtime (Runtime) at the lower layer is the cornerstone of the entire container engine. It interacts directly with the underlying operating system mainly through system calls or kernel-level functions, and is the executor of creating, running, and managing container processes.

[0050] The container runtime creates a container process based on a given configuration and obtains the real-time running status of the container. The container process started by it can be managed and scheduled by the upper-level container engine.

[0051] The operations supported by the container runtime include creating, starting, terminating, and deleting containers. Each operation complies with the behavioral definitions in the OCI standard, and the specific execution effects are:

[0052] enter Output Effect list All container information on the current host Read all container information from the container list create The ID of the container that was successfully created Create a container process and wait for start to execute start The ID of the container that successfully ran Execute the container process and generate corresponding output run The ID of the container that was successfully executed Create and run the container process and generate corresponding output Stop The ID of the container that was successfully stopped Wait for a running container process to pause kill The ID of the container that was successfully terminated Forcefully terminate a running container process delete The ID of the container that was successfully deleted Delete all information and data of a container

[0053] Real-time container configuration

[0054] The creation of a container first depends on the container configuration. In the process version of Ruihua OS, container instances are started with a real-time process as the smallest unit. Users set the properties of the container through a configuration file that complies with the OCI specification (Open Container Initiative). The configurable items provided by the system include the container's OCI version, startup process, root file system, working directory, environment variables, mount point, memory (resource) limit, status hook function, configuration items to be expanded, host name, host domain name, etc.

[0055] The specific attribute list is as follows:

[0056]

[0057]

[0058] Container operation process and state transition

[0059] Container state transitions conform to the state definitions in the OCI specification: Each container's creation and runtime parameters are determined by the configuration file and the container's bundle directory. When a container is created using the container runtime, a corresponding process is created in user mode to execute the user program code. The container runtime interprets the various properties set in the configuration and, after preparing the container's runtime environment, passes the corresponding properties to the process as creation parameters. After the user issues an execute or start command, the container runtime sends a signal to the container process and places it in the task queue, awaiting scheduling by the operating system.

[0060] For a running container, you can use the stop and kill commands to terminate its running state in advance. The terminated container will reclaim the related process resources and release the mount points used in the process, completely restoring the state before the container started running. The state transition of the container life cycle managed by the container runtime is as follows Figure 2 shown.

[0061] 2. Container Engine Daemon

[0062] The daemon at the upper layer is the unified manager of the entire system's container instances and container images, and is also the provider of the entire system's monitoring and external services.

[0063] The daemon process runs continuously in the embedded operating system as a resident background process. It is mainly responsible for managing container instances and OCI container images. It uses the status information in the container runtime to generate richer container monitoring data and can generate container and system-level operation logs.

[0064] Image Management

[0065] The daemon can import standard OCI container images and generate persistent storage information locally. Each time the container engine is started, the local image data and container data will be read. When creating a container instance, the daemon uses the read-only layer in the image to build the container's file system, and completes the mounting of the root file system when executing the container, and then calls the lower-level container runtime to pull up the user application. The image hierarchy stored locally is as follows: Figure 3 shown.

[0066] The management of images includes: generation, pulling, reading, and exporting; the details are shown in the following table:

[0067] enter Output Effect load Generated image ID Import an image from a local image file to local storage pull Pulled image ID Pull the specified image from the image repository to local storage list All mirror information of this machine Read all image information from the local image list save Exported image compressed file Generate OCI container images from local image storage

[0068] Condition Monitoring

[0069] During the startup process, the daemon process can choose to start a monitoring task in the background to monitor the status and resources of the container environment managed by the current engine.

[0070] The monitor will periodically collect the status information of each container and perform survival checks on the container using a signal mechanism. The container information that the monitor can collect includes startup / running time, memory usage, CPU usage, I / O read and write rates, network bandwidth, etc. The status monitoring process is as follows: Figure 4 .

[0071] Log information

[0072] Users can use the log collector to persistently store container output. The logging module can be manually enabled or disabled. Disabling the logging module will improve overall system performance. Enabling logging allows debugging by viewing the container's output when the container exits normally or crashes unexpectedly.

[0073] Container and image services

[0074] The daemon provides HTTP network services. The server receives container operation or image operation requests from various clients and returns the corresponding response in a formatted data type. The container engine that accesses the network service can be combined with higher-level orchestration management or cluster management tools to form a container cluster with multiple other embedded devices, providing scalability for container deployment. A set of feasible container services can provide data for multiple types of business applications, such as Figure 5 .

[0075] References are as follows:

[0076] [1]David Bernstein.Containers and Cloud:From LXC to Docker toKubernetes[J].Cloud Computing,IEEE,2014,Vol.1(3):81-84

[0077] [2]MERKEL,DIRK.Docker:lightweight Linux containers for consistent development and deployment[J].Linux Journal,2014,Vol.2014(239):76-91

[0078] [3] Wang Jiezhang. Design and implementation of container runtime system based on Android[D]. Huazhong University of Science and Technology, 2020. DOI: 10.27157 / d.cnki.ghzku.2020.000658.

[0079] [4] Queiroz, RuiaCAa; Cruz, TiagoaCAb; Mendes, Sousa, Pedroc CAd; PauloaCAe.Container-based Virtual izat ion for Real-timeIndustrial Systems-A Systematic Review[J].ACM Computing Surveys,2023,Vol.56(3):59

[0080] [5] Yu Baozhong, Hao Jifeng, Zhou Ting, et al. Research on embedded container technology in cloud computing applications [J]. Microcontrollers and Embedded Systems Applications, 2021, 21(05): 9-11+21.

[0081] [6]Lammi,TJ(2018).Feasibility of Application Containers in EmbeddedReal-Time Linux.2018

[0082] The above-described embodiment merely represents one embodiment of the present invention. While the description is relatively specific and detailed, it should not be construed as limiting the scope of the patent. It should be noted that a person skilled in the art would be able to make various modifications and improvements without departing from the spirit of the present invention, and these modifications and improvements fall within the scope of protection of the present invention. Therefore, the scope of protection of the patent for this invention shall be determined by the appended claims.

Claims

1. A method for implementing a real-time container engine based on the Ruihua process version operating system, characterized in that: The real-time container engine architecture consists of two parts: the container runtime and the container engine daemon. The container runtime includes real-time container configuration and container operation processes and state transitions. The container engine daemon includes image management, status monitoring, log information, container and image services. The specific implementation is as follows: Container runtime: The container runtime creates container processes based on a given configuration and obtains the real-time running status of the container. The container processes started by it can be managed and scheduled by the upper-layer container engine. The container runtime supports operations such as creating, starting, terminating, and deleting containers. Each operation complies with the behavioral definitions in the OCI standard. Real-time container configuration: Container creation depends on container configuration; users set container properties through a configuration file that complies with the OCI specification; Container operation process and state transition: The state transition of the container conforms to the state definition in the OCI specification: Each container determines its creation and operation parameters through the configuration file and the container's bundle directory. When the container runtime is used to create a container, a corresponding process is created in user mode to execute the user program code. The various properties set in the configuration are parsed by the container runtime, and after it prepares the container operation environment, the corresponding properties are passed to the process as creation parameters. After the user issues an execution or start command, the container runtime sends a signal to the container process and places it in the task queue, waiting for the operating system to schedule it. Container engine daemon: The daemon runs continuously in the embedded operating system as a resident background process. It is primarily responsible for managing container instances and OCI container images. It also uses the status information in the container runtime to generate richer container monitoring data and can generate container and system-level operation logs. Image management: The daemon can import standard OCI container images and generate persistent storage information locally. Each time the container engine is started, it reads the local image data and container data. When creating a container instance, the daemon uses the read-only layer in the image to build the container's file system. When executing the container, it mounts the root file system and then calls the underlying container runtime to launch the user application. Status monitoring: During the startup process, the daemon process can choose to start a monitoring task in the background to monitor the status and resources of the container environment managed by the current engine. The monitor will regularly collect status information of each container and perform survival checks on the container using a signal mechanism. Log information: Users can use the log collector to persistently store the output results of the container; the log module can be manually enabled or disabled. Disabling the log module will improve the overall performance of the system. Container and image services: The daemon process provides HTTP network services. The server receives container or image operation requests from various clients and returns the corresponding responses in formatted data types.

2. The method for implementing a real-time container engine based on the Ruihua process version operating system according to claim 1 is characterized in that: The container runtime at the lower layer is the cornerstone of the entire container engine. It interacts directly with the underlying operating system mainly by using system calls or kernel-level functions. It is the executor of creating, running, and managing container processes.

3. The method for implementing a real-time container engine based on the Ruihua process version operating system according to claim 1 is characterized in that: In the process version of Ruihua operating system, container instances are started with real-time processes as the smallest unit; the configurable items provided by the system include the container's OCI version, startup process, root file system, working directory, environment variables, mount point, memory limit, status hook function, configuration items to be expanded, host name, and host domain name.

4. The method for implementing a real-time container engine based on the Ruihua process version operating system according to claim 1 is characterized in that: During the container operation process and state transition, you can use the stop and kill commands to terminate the running state of a running container in advance; the terminated container will reclaim related process resources and release the mount points used in the process, completely restoring the container to the state before it started running.

5. The method for implementing a real-time container engine based on the Ruihua process version operating system according to claim 1 is characterized in that: The daemon process at the upper layer is the unified manager of the entire system's container instances and container images, and is also the provider of the entire system's monitoring and external services.

6. The method for implementing a real-time container engine based on the Ruihua process version operating system according to claim 1 is characterized in that: Image management includes generation, pulling, reading, and exporting.

7. The method for implementing a real-time container engine based on the Ruihua process version operating system according to claim 1 is characterized in that: In status monitoring, the monitor can collect container information including startup / running time, memory usage, CPU usage, I / O read and write rates, and network bandwidth.

8. The method for implementing a real-time container engine based on the Ruihua process version operating system according to claim 1 is characterized in that: In the log information, when the logging function is enabled, when the container exits normally or crashes abnormally, you can use the log collector to view the output information of the corresponding container for debugging.

9. The method for implementing a real-time container engine based on the Ruihua process version operating system according to claim 1 is characterized in that: In container and image services, the container engine for accessing network services can be combined with higher-level orchestration management or cluster management tools to form a container cluster with multiple other embedded devices, providing scalability for container deployment; a set of feasible container services can provide data for multiple types of business applications.

Images