Real-time container engine implementation method based on aneuhua process version operating system

Abstract

The invention relates to a real-time container engine implementation method based on an aneuhua process version operating system, and aims to construct a real-time container engine architecture and implementation aiming at the problems of resource limitation, system complexity and safety faced by deployment and operation of an existing container technology in an embedded system. The real-time container engine architecture comprises container runtime and a container engine daemon process, the container runtime comprises real-time container configuration and container running process and state conversion, and the container engine daemon process comprises mirror image management, state monitoring, log information, a container and mirror image service; the OCI container can be deployed in a low-resource and high-real-time-requirement environment and is compatible with a traditional container management program, the OCI container can be taken over, scheduled and run by an upper-layer programming program, starting and memory consumption of a traditional container engine are optimized, and the container engine is run in a small space; on the basis of ensuring normal operation of the container, the real-time requirement of a user program can be met.

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 are facing many challenges in the context of the rapid development of computer hardware and software. At present, complex software platforms mainly perform tasks in the form of middleware and modular applications deployed by host operating systems, but there are several significant problems: low utilization of computer hardware resources; with the continuous increase in software functions, the difficulty of resource design and configuration of electronic systems has increased dramatically; and the difficulty in achieving the reconfigurability of software systems.

[0003] In the field of commercial software, virtualization technology has become the mainstream solution to solve these problems. Among them, virtual machine technology is an earlier method. The traditional cluster management platform based on virtual machines manages infrastructure such as computing resources, storage resources, and network resources through the IaaS layer. In this platform, virtual machine resources are regarded as the smallest unit of resource scheduling, and services are provided to the outside world through virtual machines. However, this method of simulating hardware to achieve virtualization consumes a lot of hardware resources. At the same time, since each virtual machine needs to load the operating system kernel to build its own operating system when it starts, the startup and expansion of applications are slow. In complex environments with limited resources, the application of this method is limited.

[0004] With the continuous development of virtualization technology, container technology represented by Docker has emerged. Containers have the advantages of being lightweight and flexible, and can better manage combat resources and deploy collaborative combat tasks. For complex and ever-changing network environments, the portability and scalability of containers can realize the dynamic migration of tasks and dynamic expansion of resources when nodes are destroyed.

[0005] Lightweight virtualization technology is used to replace virtual machines, and the underlying platform heterogeneous resources are service-encapsulated to form a virtual resource pool. Through the container cluster management tool and combined with the upper-level tasks of microservices, a unified service call interface is provided. Lightweight container technology has a lightweightness that virtual machines cannot match, such as a startup time of seconds and a larger cluster. It can make full use of the limited resources of the embedded environment. Its performance close to that of the host machine can also respond and process the assigned tasks faster. Compared with virtual machines, it can easily realize the dynamic reorganization of cluster resources. In the case of node disconnection, resource exhaustion or failure, not only can the resources of the entire platform be dynamically added or deleted from the resource pool, but also a single resource can be added or deleted, which is a resource granularity that is difficult for virtual machines to operate. In order to complete a task, container technology can provide multiple resource combinations for the upper-level decision-making module or user, and sort the available underlying resource combinations through a set mechanism for the upper layer to choose.

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

[0007] 1. A container runtime based on the kernel characteristics of a real-time operating system. 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 brought by real-time container technology include:

[0010] 1. Application isolation: Containers implement resource isolation and restriction at the operating system level, and file system-level isolation and restriction 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, avoiding cross-border 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, thus 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: The container only contains the necessary dependencies and the application itself, and does not need to run a complete operating system separately. At the same time, the size of the container image is strictly controlled and can be quickly transferred on different devices.

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

[0015] Real-time container technology ensures application security through resource isolation at the operating system and runtime levels. It is based on real-time kernel design to achieve efficient startup and operation and ensure real-time performance. It provides rich configuration items to flexibly adapt to business needs. It is lightweight and only contains necessary components to facilitate rapid transmission and deployment. It supports rapid generation and instantiation to accelerate large-scale application deployment.

[0016] The deployment and operation of existing container technologies in embedded systems face multiple challenges, mainly in terms of resource limitations, system complexity, and security.

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

[0018] Secondly, security is an important consideration in embedded system design. Although 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, and have a strong reliance on the isolation and security mechanisms provided by kernel features, and cannot be ported to embedded operating systems other than the Linux series. This makes embedded operating systems with strong real-time performance incompatible with existing container deployment frameworks. In embedded systems, any potential vulnerabilities may cause the entire system to crash or data leak, so the dual protection of the system's security isolation mechanism and the application isolation management of container technology is required to form a secure container under the embedded system platform.

[0019] Finally, since most existing container products use Go as the development language, they cannot be used on most embedded platforms that use C / C++ as the core. It is necessary to redesign the underlying compilation and runtime environment to adapt to the existing container solutions. This is difficult for embedded platforms that aim to be lightweight and high-performance, and has high development and maintenance costs. The reusability advantage of the original Go language development cannot be reflected on embedded platforms, and it also puts forward requirements for the underlying operating environment and library dependencies. This is why embedded systems with lightweight and low resource characteristics cannot be applied to existing general container solutions. Summary of the invention

[0020] Aiming at the resource limitation, system complexity and security problems 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 includes two parts: container runtime and 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, state monitoring, log information, container and image services. The specific implementation is as follows:

[0023] Container runtime: 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-layer container engine. The operations supported by the container runtime include container creation, startup, termination, and deletion. Each operation complies with the behavior definition in the OCI standard.

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

[0025] Container operation process and state transition: The state transition of the container complies with the state definition in the OCI specification: each container determines its creation and operation parameters through the configuration file and the bundle directory of the container; when the container runtime is used to create a container, a corresponding process will be created in the user state to execute the user program code; the various properties set in the configuration will be parsed by the container runtime, and the corresponding properties will be passed to the process as creation parameters after it prepares the container operation environment; after the user issues an execution or start command, the container runtime sends a signal to the container process and puts it into the task queue, waiting for the operating system to schedule and run;

[0026] Container engine daemon: The daemon runs continuously in the embedded operating system as a resident background. 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.

[0027] Image management: 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 are 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.

[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 collect the status information of each container at regular intervals and check the survival of the container through a signal mechanism;

[0029] Log information: Users can use the log collector to store the output results of the container persistently; the log module can be manually turned on or off. Turning off the log module will improve the overall performance of the system operation;

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

[0031] Furthermore, 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 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 points, memory limits, status hook functions, configuration items to be expanded, host name, and host domain name.

[0033] Furthermore, in 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 recycle the related process resources and release the mount points used in the process, completely restoring to the state before the container started running.

[0034] Furthermore, the daemon process at the upper layer is the unified manager of the entire system container instances and container images, and is also the provider of the entire system 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, the output information of the corresponding container can be viewed 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 operating system can support the deployment of OCI containers in low-resource and high-real-time requirements environments and is compatible with traditional container management programs, and 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 to run 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 when the container is running in 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 in conjunction with 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 by using system calls or kernel-level functions. It 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 container creation, startup, termination, and deletion. Each operation complies with the behavior definition 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 to generate corresponding output Stop The ID of the container that was successfully stopped Wait for a running container process to be suspended 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 operating system, the container instance is 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] The state transition of the container conforms to the state definition in the OCI specification: each container determines its creation and running parameters through the configuration file and the bundle directory of the container. When creating a container using the container runtime, a corresponding process will be created in the user state to execute the user program code. The various properties set in the configuration will be parsed by the container runtime, and the corresponding properties will be passed to the process as creation parameters after it prepares the container running environment. After the user issues an execution or start command, the container runtime sends a signal to the container process and puts it in the task queue, waiting for the operating system to schedule it.

[0060] For a running container, you can use the stop and kill commands to terminate its running state in advance. The terminated container will recycle 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 container instance and container image, and is also the provider of the entire system 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, 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, 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 images from local image files to local storage pull The ID of the image to be pulled 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 collect the status information of each container at regular intervals and use the signal mechanism to check the survival of the container. The container information that the monitor can collect includes startup / running time, memory usage, CPU usage, I / O read and write rate, network bandwidth, etc. The status monitoring process is as follows: Figure 4 .

[0071] Log information

[0072] Users can use the log collector to store the output of the container persistently. The log module can be turned on or off manually. Turning off the log module will improve the overall performance of the system. When the log function is turned on, when the container exits normally or crashes abnormally, the output information of the corresponding container can be viewed through the log collector for debugging.

[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 other multiple 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-mentioned embodiment only expresses one implementation mode of the present invention, and its description is relatively specific and detailed, but it cannot be understood as limiting the scope of the invention patent. It should be pointed out that for ordinary technicians in this field, several modifications and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be based on the attached 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: container runtime and 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, state monitoring, log information, container and image services. The specific implementation is as follows: Container runtime: 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-layer container engine. The operations supported by the container runtime include container creation, startup, termination, and deletion. Each operation complies with the behavior definition in the OCI standard. Real-time container configuration: The creation of a container first depends on the container configuration; users set the properties of the container through a configuration file that complies with the OCI specification; Container operation process and state transition: The state transition of the container complies with the state definition in the OCI specification: each container determines its creation and operation parameters through the configuration file and the bundle directory of the container; when the container runtime is used to create a container, a corresponding process will be created in the user state to execute the user program code; the various properties set in the configuration will be parsed by the container runtime, and the corresponding properties will be passed to the process as creation parameters after it prepares the container operation environment; after the user issues an execution or start command, the container runtime sends a signal to the container process and puts it into the task queue, waiting for the operating system to schedule and run; Container engine daemon: The daemon runs continuously in the embedded operating system as a resident background. 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. Image management: 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 are 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. 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 collect the status information of each container at regular intervals and check the survival of the container through a signal mechanism; Log information: Users can use the log collector to store the output results of the container persistently; the log module can be manually turned on or off. Turning off the log module will improve the overall performance of the system operation; Container and image services: The daemon provides HTTP network services. The server receives container operation or image operation requests from various clients and returns the responses to the corresponding requests in formatted data types.

2. According to claim 1, the method for implementing a real-time container engine based on the Ruihua process version operating system is characterized in that: 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 by using system calls or kernel-level functions. It is the executor of creating, running, and managing container processes.

3. According to claim 1, the method for implementing a real-time container engine based on the Ruihua process version operating system 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. According to claim 1, the method for implementing a real-time container engine based on the Ruihua process version operating system is characterized in that: In 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 recycle the related process resources and release the mount points used in the process, completely restoring the container to the state before it started running.

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

6. According to claim 1, the method for implementing a real-time container engine based on the Ruihua process version operating system is characterized in that: The management of images 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 log function is turned on, 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