Vehicle lightweight container deployment method, device and equipment and storage medium

Abstract

The invention provides a vehicle lightweight container deployment method, device and equipment and a storage medium, a container mirror image is constructed, and a root file system of the container mirror image is a read-only compressed file system with non-essential components removed; the method comprises the following steps: configuring a system service unit on the basis of a container mirror image of a read-only compressed file system during OCI (open container proposal) operation of a daemon-free process, so that the system service unit directly calls a command during OCI operation to manage a container; when the OCI is triggered to run through the system service unit, first creation of the container is executed, and the running state of the container is persistently stored; and when the system is subsequently started and the OCI is directly called to run through the system service unit, starting the container based on the running state stored persistently. By adopting the method, not only is the lightweight of the volume of the container and the improvement of the management efficiency realized, but also the starting time of the container is obviously shortened, and the consumption of storage and operation resources is reduced.

Description

A method, apparatus, device, and storage medium for deploying lightweight containers for vehicles. Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method, apparatus, device, and storage medium for deploying lightweight containers for vehicles. Background Technology

[0002] As automotive electronic and electrical architectures evolve from traditional distributed to centralized computing-regional control architectures, the increasing richness and intelligence of vehicle functions place higher demands on software's computing power, real-time response speed, and scalability. Simultaneously, the diversification of software forms makes the deployment and updating of in-vehicle software a critical factor affecting vehicle development efficiency and user experience. Against this backdrop, achieving efficient updates and stable operation of in-vehicle applications to meet the stringent requirements of in-vehicle scenarios has become a pressing technical challenge for the industry.

[0003] In existing technologies, the deployment and updates of automotive applications mainly adopt the traditional over-the-air (OTA) mode. In this mode, the automotive application is tightly coupled with the operating system (OS) and board support package (BSP). The application's function iteration or vulnerability fixes all require re-integration and compilation with the operating system and packaging into a complete firmware image. After receiving the complete image, the vehicle completes the application update by flashing the entire system, which makes it impossible to deploy and upgrade the application independently.

[0004] The aforementioned existing technologies have significant drawbacks: due to the large size of the complete firmware image, the OTA update process consumes a large amount of network bandwidth and has a long update cycle, which seriously affects the user experience; at the same time, the whole package flashing update method has a complex process. Once an abnormal situation such as network interruption or image verification failure occurs during the update process, it is not only difficult to quickly restore to the original system state, but it may also cause abnormalities in the core vehicle functions, posing a very high risk of rollback, and cannot meet the requirements of vehicle scenarios for software update security and efficiency. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a lightweight container deployment method, apparatus, device and storage medium for vehicles, which not only achieves lightweight container size and improved management efficiency, but also significantly shortens container startup time and reduces storage and operating resource consumption.

[0006] In a first aspect, embodiments of this application provide a lightweight container deployment method for vehicles. The method includes: constructing a container image, wherein the root file system of the container image is a read-only compressed file system with non-essential components removed; configuring a system service unit based on the Open Container Initiative (OCI) runtime without daemon processes and the container image of the read-only compressed file system, such that the system service unit directly calls commands of the OCI runtime to manage the container; triggering the OCI runtime through the system service unit to perform the initial creation of the container and persistently storing the running state of the container; and starting the container based on the persistently stored running state by directly calling the OCI runtime through the system service unit during subsequent system startup.

[0007] Optionally, when building the container image, removing non-essential components includes: removing the shell interpreter, package manager, and language runtime environment unrelated to the target application from the base image, retaining only the binary files of the target application and its necessary dynamic link libraries.

[0008] Optionally, the read-only compressed file system is in SquashFS or EROFS format; wherein, when using SquashFS format, a high compression ratio algorithm is used for packaging; when using EROFS format, a fixed block size and compression mode are used for packaging.

[0009] Optionally, when running the container, the read-only compressed file system is mounted as a read-only layer over the OverlayFS file system, and a writable layer is superimposed on the read-only layer; wherein, the writable layer is used to store temporary files, log files and configuration changes generated during the operation of the container.

[0010] Optionally, the system service unit is a systemd service unit file, whose configuration includes: the ExecStart instruction pointing to the command line that calls the OCI runtime, the Restart policy configured to automatically restart when the container exits abnormally, and the restriction of container resources through Cgroups.

[0011] Optionally, the daemonless OCI runtime includes crun or runc; wherein, when using crun, its C language implementation achieves low memory usage and fast startup characteristics; when using runc, its Go language implementation achieves cross-platform compatibility.

[0012] Optionally, the persistent storage of the container's running state includes: storing the namespace configuration, control group configuration, file system mount point information, and environment variables generated during the container creation process in the non-volatile memory of the vehicle computing platform; and, starting the container based on the persistent storage of the running state specifically includes: the system service unit reactivating the persistent container process and restoring its file system mount point and namespace by calling the start command of the OCI runtime.

[0013] Secondly, embodiments of this application provide a lightweight container deployment device for vehicles. The device includes: an image building module for building a container image, wherein the root file system of the container image is a read-only compressed file system with non-essential components removed; a service unit configuration module for configuring a system service unit based on the Open Container Initiative (OCI) runtime without daemon processes and the container image of the read-only compressed file system, so that the system service unit directly calls the commands of the OCI runtime to manage the container; a persistent storage module for triggering the OCI runtime through the system service unit to perform the initial creation of the container and persistently store the running state of the container; and a container startup module for starting the container based on the persistently stored running state by directly calling the OCI runtime through the system service unit during subsequent system startup.

[0014] Optionally, when building the container image, removing non-essential components includes: removing the shell interpreter, package manager, and language runtime environment unrelated to the target application from the base image, retaining only the binary files of the target application and its necessary dynamic link libraries.

[0015] Optionally, the read-only compressed file system is in SquashFS or EROFS format; wherein, when using SquashFS format, a high compression ratio algorithm is used for packaging; when using EROFS format, a fixed block size and compression mode are used for packaging.

[0016] Optionally, when running the container, the read-only compressed file system is mounted as a read-only layer over the OverlayFS file system, and a writable layer is superimposed on the read-only layer; wherein, the writable layer is used to store temporary files, log files and configuration changes generated during the operation of the container.

[0017] Optionally, the system service unit is a systemd service unit file, whose configuration includes: the ExecStart instruction pointing to the command line that calls the OCI runtime, the Restart policy configured to automatically restart when the container exits abnormally, and the restriction of container resources through Cgroups.

[0018] Optionally, the daemonless OCI runtime includes crun or runc; wherein, when using crun, its C language implementation achieves low memory usage and fast startup characteristics; when using runc, its Go language implementation achieves cross-platform compatibility.

[0019] Optionally, the persistent storage of the container's running state includes: storing the namespace configuration, control group configuration, file system mount point information, and environment variables generated during the container creation process in the non-volatile memory of the vehicle computing platform; and, starting the container based on the running state of the persistent storage specifically includes: the system service unit reactivating the persistent container by calling the start command of the OCI runtime.

[0020] Thirdly, embodiments of this application provide a computer device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the computer device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the vehicle lightweight container deployment method described in any of the optional embodiments of the first aspect are performed.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the vehicle lightweight container deployment method described in any of the optional embodiments of the first aspect.

[0022] The technical solution provided in this application includes, but is not limited to, the following beneficial effects: constructing a container image with a read-only compressed file system that eliminates non-essential components can significantly reduce the size of the container image and reduce the occupation of in-vehicle storage resources. At the same time, the read-only attribute can ensure the consistency and stability of the application's operating environment, prevent the environment from being accidentally tampered with during operation, and lay the foundation for the stable operation of in-vehicle applications.

[0023] Based on the Open Container Initiative (OCI) runtime without daemon processes and the container image configuration system service unit, the system service unit directly calls the OCI runtime commands to manage containers. This eliminates the resource consumption of daemon processes in traditional container architectures, reduces system load, and the direct call mode reduces intermediate forwarding links in command execution, improves the response efficiency of container management, and ensures rapid control of in-vehicle applications.

[0024] By triggering the OCI runtime through the system service unit to perform the initial creation of the container and persist its running state, the time-consuming configuration operations during container creation can be concentrated in the first execution, avoiding the repetition of redundant steps during subsequent startups. This provides the prerequisite for rapid container startup and reduces unnecessary resource consumption and time costs.

[0025] When the system starts up later, the container can be started directly based on the running state of persistent storage, which can significantly shorten the container startup time. There is no need to repeatedly initialize the configuration and environment, and the container process can be quickly activated, meeting the stringent requirements of the vehicle scenario for the real-time startup of applications and improving the overall response speed of the vehicle system.

[0026] In summary, the four steps of the invention are progressive and synergistic. By simplifying the image, optimizing the container management architecture, persisting the running state, and implementing a fast startup strategy, it not only achieves lightweight container size and improved management efficiency, but also significantly shortens container startup time, reduces storage and runtime resource consumption, and fully adapts to the core requirements of automotive scenarios for application deployment efficiency, stability, and real-time performance.

[0027] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0028] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 shows a flowchart of a vehicle lightweight container deployment method provided in Embodiment 1 of this application; Figure 2 shows an architecture diagram of a vehicle lightweight container deployment provided in Embodiment 1 of this application; Figure 3 shows a structural schematic diagram of a vehicle lightweight container deployment device provided in Embodiment 2 of this application; Figure 4 shows a structural schematic diagram of a computer device provided in Embodiment 3 of this application. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0031] To facilitate understanding of this application, the following detailed description of Embodiment 1 of this application is provided in conjunction with the flowchart of a vehicle-mounted lightweight container deployment method shown in Figure 1.

[0032] Referring to Figure 1, Figure 1 shows a flowchart of a lightweight container deployment method for vehicles provided in Embodiment 1 of this application, wherein the method includes steps S101~S104: S101: Build a container image, wherein the root file system of the container image is a read-only compressed file system that removes non-essential components.

[0033] Specifically, when building container images, the traditional approach of using full operating system distributions (such as Ubuntu and CentOS) is abandoned. Instead, a blank file system (scratch) is started, and only the core components necessary for application operation are retained, minimizing the image size.

[0034] Read-only compressed file systems have high compression characteristics and immutability, which can reduce image storage space and OTA transmission bandwidth consumption, solidify the application runtime environment, and prevent malicious tampering during runtime, thus meeting the safety and resource constraints of the vehicle scenario.

[0035] S102: Based on the Open Container Initiative (OCI) runtime without daemon processes and the container image of the read-only compressed file system, configure a system service unit so that the system service unit can directly call the commands of the OCI runtime to manage the container.

[0036] Specifically, the OCI runtime without daemons eliminates the complex and resource-intensive resident daemons (such as docker-daemon) found in traditional containers, retaining only the core execution functions that conform to the OCI specification, thus eliminating the startup latency and additional memory overhead caused by daemons from the root.

[0037] The system service unit replaces the container's built-in daemon process to assume management responsibilities. By directly calling OCI runtime commands, it avoids the performance loss of the intermediate forwarding layer and achieves efficient management of the container's lifecycle.

[0038] This architecture design is specifically designed to meet the evolving needs of automotive electronic and electrical architectures, solving the problem of insufficient adaptability of traditional container solutions to automotive scenarios and laying the foundation for decoupling applications from underlying systems.

[0039] S103: Trigger the OCI runtime through the system service unit to perform the initial creation of the container and persist the running state of the container.

[0040] Specifically, the initial container creation process involves time-consuming operations such as namespace creation, cgroups configuration, and file system mounting. These operations are performed only once during application installation or system startup to avoid repeated resource consumption.

[0041] The core purpose of persistent storage is to retain the key configurations and states of a container after its creation, providing a foundation for rapid startup and avoiding the redundant process of repeated initialization every time a container is started.

[0042] This step separates container creation from subsequent startup, which is a key prerequisite for achieving millisecond-level cold starts and meets the stringent requirements for response speed in in-vehicle scenarios such as smart cockpits and assisted driving.

[0043] S104: When the system starts up later, the OCI runtime is directly called through the system service unit to start the container based on the running state of the persistent storage.

[0044] Specifically, when the system is powered on again, the system service unit will detect the persistent container configuration, skip the time-consuming creation steps, and directly execute the startup command to activate the container process, greatly reducing the startup time.

[0045] The startup process only needs to restore the container's running context (such as file system mount points and namespaces), without having to re-execute resource initialization operations, reducing cold start time from seconds to milliseconds compared to traditional containers.

[0046] This strategy ensures that in-vehicle applications can respond quickly every time the vehicle is powered on, meeting automotive-grade real-time requirements, while reducing the resource consumption of the system.

[0047] In an optional implementation, when building the container image, removing non-essential components includes: removing the shell interpreter, package manager, and language runtime environment independent of the target application from the base image, retaining only the binary files of the target application and its necessary dynamic link libraries.

[0048] Specifically, shell interpreters include interactive terminal tools such as bash, and package managers include software installation tools such as apt and yum. These components are not necessary for the operation of in-vehicle applications and will increase the image size and system attack surface, so they have been completely removed.

[0049] Language runtime environments unrelated to the target application include non-dependent execution environments such as Python and Node.js. Removing these can further streamline the image and avoid unnecessary resource consumption.

[0050] Only the binary files of the target application and its necessary dynamic link libraries (.so files) are retained, ensuring that the image contains only the core runtime elements, achieving extreme lightweight design and adapting to the computing power and storage limitations of the vehicle controller.

[0051] In an optional implementation, the read-only compressed file system is in SquashFS or EROFS format.

[0052] Specifically, SquashFS is a highly compressed read-only file system that has been proven to have good compatibility and compression performance in automotive scenarios, making it one of the preferred solutions for image packaging.

[0053] EROFS is a high-performance read-only file system that has been integrated into the Linux mainline. Its design philosophy is highly compatible with the performance requirements of automotive scenarios and can be used as an equivalent alternative to SquashFS.

[0054] Specifically, when using the SquashFS format, a high compression ratio algorithm is used for packaging; when using the EROFS format, a fixed block size and compression mode are used for packaging.

[0055] Specifically, SquashFS's high compression ratio algorithm can perform deep compression on binary files and library files for automotive applications. Compared with conventional compression methods, the image size can be further reduced by more than 30%, significantly reducing OTA transmission costs.

[0056] EROFS uses a fixed block size and compression mode for packaging, which can optimize file reading performance while ensuring compression efficiency, reduce decompression delay during application startup, and improve running smoothness.

[0057] In an alternative implementation, when the container is running, the read-only compressed file system is mounted as a read-only layer over the OverlayFS file system, and a writable layer is overlaid on the read-only layer.

[0058] Specifically, OverlayFS's layered mounting mechanism achieves physical separation between application code and runtime data. The read-only layer stores the fixed application image content, while the writable layer is dedicated to handling dynamically generated data, ensuring that the application's core files are not tampered with.

[0059] This mounting method is compatible with the file system architecture of the in-vehicle Linux operating system, requiring no major modifications to the underlying system. It has good adaptability and reliability, and meets the stability requirements of automotive-grade systems.

[0060] The writable layer is used to store temporary files, log files, and configuration changes generated during container operation.

[0061] Specifically, temporary files include short-term valid data such as application runtime cache data and session data; log files include runtime status records, error alarm information, and other content used for troubleshooting; and configuration changes include personalized data such as user-defined settings and dynamic parameter adjustments.

[0062] The independent storage design of the writable layer allows applications to be updated by simply replacing the image file of the read-only layer, while the data in the writable layer is preserved, avoiding data loss during the update process. It also simplifies the update process and enables independent OTA updates for applications.

[0063] In an optional implementation, the system service unit is a systemd service unit file, whose configuration includes: the ExecStart instruction pointing to the command line that calls the OCI runtime, the Restart policy configured to automatically restart when the container exits abnormally, and the restriction of container resources through Cgroups.

[0064] Specifically, the command line format of the ExecStart command, such as " / usr / bin / crun run my-container", directly points to the core execution command of the OCI runtime, without needing to be forwarded through a daemon process, thus reducing command execution latency and improving response speed.

[0065] When the Restart policy is configured as "on-failure", it can automatically restart the container when it exits due to failure, abnormal crash, or other reasons, ensuring the high availability of in-vehicle services (such as smart cockpit navigation and instrument display) and meeting automotive-grade reliability requirements.

[0066] Resources restricted by Cgroups include CPU utilization, memory usage, and I / O bandwidth. This can prevent a single container from excessively consuming resources and affecting the normal operation of other vehicle functions, thus achieving reasonable scheduling and isolation of vehicle resources.

[0067] As the mainstream service manager for automotive Linux operating systems, systemd is deeply integrated with the kernel (especially cgroups v2). Its mature management mechanism offers better stability and compatibility compared to the daemons that come with containers.

[0068] In an optional implementation, the daemonless OCI runtime includes crun or runc.

[0069] Specifically, both crun and runc fully comply with the OCI specification, possess core functions such as container creation, running, and stopping, and have no persistent daemons, meeting the lightweight requirements of automotive scenarios.

[0070] Both can directly interface with systemd service units, enabling container lifecycle management without the need for an additional adaptation layer, and adapting to the architecture design of in-vehicle systems.

[0071] When using crun, its C language implementation achieves low memory usage and fast startup characteristics.

[0072] Specifically, the C language implementation makes the cron code smaller, reduces runtime memory usage by 20%-40%, and improves startup speed by more than 50% compared to runtime implementations in other languages, perfectly matching the resource constraints and rapid response requirements of in-vehicle scenarios.

[0073] This feature makes crun the preferred runtime for scenarios such as smart cockpits and instrument clusters that are sensitive to startup speed and memory usage, and it can better meet automotive-grade real-time requirements.

[0074] When using runc, cross-platform compatibility is achieved through its Go language implementation.

[0075] Specifically, Go's cross-platform capabilities enable runc to support automotive SoC chips from different manufacturers and different versions of automotive Linux operating systems, reducing the adaptation costs of porting across vehicle models and hardware platforms.

[0076] Its excellent compatibility enables application containers to achieve "build once, run anywhere". When the underlying chip or OS version changes, there is no need to recompile and adapt the application, which significantly improves the efficiency of R&D iteration.

[0077] In an optional implementation, the persistent storage of the container's runtime state includes storing the namespace configuration, control group configuration, file system mount point information, and environment variables generated during the container creation process in the non-volatile memory of the in-vehicle computing platform.

[0078] Specifically, namespace configuration includes isolation configuration information such as network namespace, PID namespace, and mount namespace to ensure resource isolation during container runtime; control group configuration includes resource limit parameters and scheduling policies to ensure reasonable resource allocation.

[0079] File system mount point information includes mount paths and permission settings for each layer of OverlayFS, while environment variables include configuration parameters and path information required for application operation. Together, these information constitute the complete context for container operation.

[0080] Non-volatile memory, including onboard hard drives, eMMC, and other storage media, ensures that persistent configuration information is not lost after a power outage and can be reused directly upon the next power-on, guaranteeing the stability of rapid startup.

[0081] Furthermore, starting the container based on the running state of the persistent storage specifically includes: the system service unit reactivating the persistent container process by calling the start command of the OCI runtime, and restoring its file system mount point and namespace.

[0082] Specifically, the start command of OCI runtime only performs process activation and context recovery operations, without repeating time-consuming steps such as namespace creation and control group configuration. The entire process can be completed in milliseconds.

[0083] The restoration of file system mount points and namespaces strictly follows the persistent storage configuration information to ensure that the runtime environment after container startup is completely consistent with that at the time of initial creation, thus guaranteeing the stability and consistency of application operation.

[0084] This startup method completely solves the pain point of traditional container cold start in seconds, meets the stringent requirements for rapid response in key vehicle scenarios such as smart cockpits and assisted driving, and reduces the resource consumption of system operation.

[0085] Referring to Figure 2, which shows an architecture diagram of a lightweight container deployment for vehicles provided in Embodiment 1 of this application, the overall structure presents a top-down hierarchical structure. The top layer is a service carrying layer composed of container 1, container 2, and container 3, which serves as the running carrier for various in-vehicle applications.

[0086] Below that is the service management layer, which is based on Systemd and uses a service configuration module to achieve comprehensive management of the container lifecycle.

[0087] Next is the runtime layer, which is based on the cron container runtime and uses resource configuration files to complete the allocation of resources such as CPU and memory, as well as shell-related configurations.

[0088] The lowest layer is the Linux Kernel support layer, which uses Cgroups and Namespaces to achieve resource isolation and restriction, and DAC and MAC mechanisms to provide permission control. It provides stable underlying technical support for the upper layers, and the overall architecture reflects the design concept of lightweight, efficient, isolated and secure vehicle container deployment.

[0089] Referring to Figure 3, which illustrates a schematic diagram of a lightweight container deployment device for vehicles provided in Embodiment 2 of this application, the device includes: an image building module 301 for building a container image, wherein the root file system of the container image is a read-only compressed file system with non-essential components removed; a service unit configuration module 302 for configuring a system service unit based on the Open Container Initiative (OCI) runtime without daemon processes and the container image of the read-only compressed file system, so that the system service unit can directly call the commands of the OCI runtime to manage the container; a persistent storage module 303 for triggering the OCI runtime through the system service unit to perform the initial creation of the container and persistently store the running state of the container; and a container startup module 304 for starting the container based on the persistently stored running state by directly calling the OCI runtime through the system service unit during subsequent system startup.

[0090] In an optional implementation, when building the container image, removing non-essential components includes: removing the shell interpreter, package manager, and language runtime environment independent of the target application from the base image, retaining only the binary files of the target application and its necessary dynamic link libraries.

[0091] In an optional implementation, the read-only compressed file system is in SquashFS or EROFS format; wherein, when using SquashFS format, a high compression ratio algorithm is used for packaging; and when using EROFS format, a fixed block size and compression mode are used for packaging.

[0092] In an optional implementation, when the container is running, the read-only compressed file system is mounted as a read-only layer over the OverlayFS file system, and a writable layer is superimposed on the read-only layer; wherein the writable layer is used to store temporary files, log files and configuration changes generated during container operation.

[0093] In an optional implementation, the system service unit is a systemd service unit file, whose configuration includes: the ExecStart instruction pointing to the command line that calls the OCI runtime, the Restart policy configured to automatically restart when the container exits abnormally, and the restriction of container resources through Cgroups.

[0094] In an optional implementation, the daemonless OCI runtime includes crun or runc; wherein, when using crun, its C language implementation achieves low memory footprint and fast startup characteristics; and when using runc, its Go language implementation achieves cross-platform compatibility.

[0095] In an optional implementation, the persistent storage of the container's runtime state includes: storing the namespace configuration, control group configuration, file system mount point information, and environment variables generated during container creation in the non-volatile memory of the in-vehicle computing platform; and starting the container based on the persistent storage of the runtime state specifically includes: the system service unit reactivating the persistent container by calling the start command of the OCI runtime.

[0096] Based on the same application concept, as shown in Figure 4, the third embodiment of this application provides a schematic diagram of the structure of a computer device. As shown in Figure 4, the computer device 400 provided in the third embodiment of this application includes a processor 401, a memory 402, and a bus 403. The memory 402 stores machine-readable instructions executable by the processor 401. When the computer device 400 is running, the processor 401 and the memory 402 communicate through the bus 403. The machine-readable instructions are executed by the processor 401 to perform the steps of the vehicle lightweight container deployment method shown in the first embodiment above.

[0097] Based on the same application concept, Embodiment 4 of this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the vehicle lightweight container deployment method described in any of the above embodiments.

[0098] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0099] The computer program product for deploying lightweight containers for vehicles provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0100] The lightweight container deployment device for vehicles provided in this application embodiment can be specific hardware on the device or software or firmware installed on the device. The implementation principle and technical effects of the device provided in this application embodiment are the same as those in the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0101] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0102] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0103] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0104] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0105] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0106] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for deploying a lightweight container for vehicles, characterized in that, The method includes: constructing a container image, wherein the root file system of the container image is a read-only compressed file system with non-essential components removed; configuring a system service unit based on the Open Container Initiative (OCI) runtime without daemons and the container image of the read-only compressed file system, so that the system service unit directly calls the commands of the OCI runtime to manage the container; triggering the OCI runtime through the system service unit to perform the initial creation of the container and persistently storing the running state of the container; and starting the container based on the persistently stored running state by directly calling the OCI runtime through the system service unit during subsequent system startup.

2. The method according to claim 1, characterized in that, When building the container image, removing non-essential components includes: removing the shell interpreter, package manager, and language runtime environment unrelated to the target application from the base image, retaining only the binary files of the target application and its necessary dynamic link libraries.

3. The method according to claim 1, characterized in that, The read-only compressed file system is in SquashFS or EROFS format; when using SquashFS format, a high compression ratio algorithm is used for packaging; when using EROFS format, a fixed block size and compression mode are used for packaging.

4. The method according to claim 1, characterized in that, When the container is running, the read-only compressed file system is mounted as a read-only layer over the OverlayFS file system, and a writable layer is superimposed on the read-only layer; wherein, the writable layer is used to store temporary files, log files and configuration changes generated during the operation of the container.

5. The method according to claim 1, characterized in that, The system service unit is a systemd service unit file, whose configuration includes: the ExecStart instruction pointing to the command line that calls the OCI runtime, the Restart policy configured to automatically restart when the container exits abnormally, and the restriction of container resources through Cgroups.

6. The method according to claim 1, characterized in that, The daemonless OCI runtime includes crun or runc; when using crun, it achieves low memory usage and fast startup through its C language implementation; when using runc, it achieves cross-platform compatibility through its Go language implementation.

7. The method according to claim 1, characterized in that, The persistent storage of the container's running state includes storing the namespace configuration, control group configuration, file system mount point information, and environment variables generated during container creation in the non-volatile memory of the vehicle computing platform; and starting the container based on the persistent storage of the running state specifically includes: the system service unit reactivating the persistent container process and restoring its file system mount point and namespace by calling the start command of the OCI runtime.

8. A lightweight container deployment device for vehicles, characterized in that, The apparatus includes: an image building module for building a container image, wherein the root file system of the container image is a read-only compressed file system with non-essential components removed; a service unit configuration module for configuring a system service unit based on the Open Container Initiative (OCI) runtime without daemon processes and the container image of the read-only compressed file system, so that the system service unit directly calls the commands of the OCI runtime to manage the container; a persistent storage module for triggering the OCI runtime through the system service unit to perform the initial creation of the container and persistently store the running state of the container; and a container startup module for starting the container based on the persistently stored running state by directly calling the OCI runtime through the system service unit during subsequent system startup.

9. A computer device, characterized in that, include: The system includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the computer device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the automotive lightweight container deployment method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the vehicle lightweight container deployment method as described in any one of claims 1 to 7.

Images