Container-based operating system control method

Abstract

The present application provides a container-based operating system control method, the method comprising: a boot loader decompresses a target startup image to a memory block device, and starts the kernel, wherein the native startup image includes the kernel and the root file system of the native operating system, and the target startup image includes the kernel and the root file system of the host system; the kernel starts the root file system of the host system from the memory block device to start the host system; the host system starts the root file system of the container to start the target operating system in the container, wherein the root file system of the container includes the configuration file of the container and the root file system of the target operating system, and the root file system of the target operating system is modified based on the root file system of the native operating system. Through the present application, the startup of the operating system in the container can be realized without the user's awareness, thereby simplifying the user operation and reducing time consumption.

Description

Technical Field

[0001] This application relates to the field of operating system technology, and specifically to a container-based operating system control method. Background Technology

[0002] In today's era of rapid digitalization and cloud computing development, container technology has become an important tool for application deployment and management. Containers provide a lightweight, efficient, and flexible environment for operating systems to run.

[0003] While traditional virtual machine technology can achieve isolated operation of the operating system, it suffers from drawbacks such as high resource consumption and slow startup speed. In contrast, container technology leverages the kernel features of the operating system, enabling multiple containers to coexist efficiently on the same host by sharing the host kernel.

[0004] However, current solutions require users to manually operate container management tools to start the operating system in the container, which is cumbersome and time-consuming for users. Summary of the Invention

[0005] This application provides a container-based operating system control method that enables the operating system to be started in a container without the user's awareness.

[0006] In a first aspect, embodiments of this application provide a container-based operating system control method, the container-based operating system control method comprising:

[0007] The bootloader decompresses the target boot image to a memory block device and starts the kernel. The native boot image contains the kernel and the root file system of the native operating system, while the target boot image contains the kernel and the root file system of the host system.

[0008] The kernel starts the host system's root file system from the memory block device to boot the host system;

[0009] The host system starts the container's root file system to enable the target operating system to boot within the container. The container's root file system contains the container's configuration files and the target operating system's root file system, which is modified from the native operating system's root file system.

[0010] Furthermore, in one embodiment, the native operating system and the target operating system are both Android systems;

[0011] Following the step of starting the root file system of the container on the host system to enable the target operating system to boot within the container, the following is also included:

[0012] After receiving the shutdown request, the target operating system writes the shutdown command to the shared partition;

[0013] After the host system reads the shutdown command from the shared partition, it issues a shutdown command to the kernel.

[0014] Furthermore, in one embodiment, the native operating system and the target operating system are both Android systems;

[0015] Following the step of starting the root file system of the container on the host system to enable the target operating system to boot within the container, the following is also included:

[0016] After receiving the reboot request, the target operating system writes a reboot command to the shared partition;

[0017] After the host system reads the reboot command from the shared partition, it issues a reboot command to the kernel.

[0018] Furthermore, in one embodiment, the host system continuously monitors commands in the shared partition through a daemon process.

[0019] Furthermore, in one embodiment, after the step of the host system starting the root file system of the container to enable the target operating system to start in the container, the method further includes:

[0020] Before the host system issues a shutdown or reboot command to the kernel, it performs a file system synchronization operation.

[0021] Furthermore, in one embodiment, before the step of the host system starting the root file system of the container to enable the target operating system to start in the container, the method further includes:

[0022] The host system sets the partition where the container's root file system is located to a readable and writable state, detects the status of hardware resources in the container's configuration file, and modifies the container's configuration file to allocate hardware resources in a normal state to the container when there are hardware resources in an abnormal state.

[0023] Furthermore, in one embodiment, after the step of the host system starting the root file system of the container to enable the target operating system to start in the container, the method further includes:

[0024] The host system sets the partition containing the container's root file system to read-only.

[0025] Furthermore, in one embodiment, the step of booting the host system by starting the kernel from the memory block device and establishing the root file system of the host system includes:

[0026] The kernel sets the startup path of the initializer to the memory block device via kernel command-line arguments.

[0027] Furthermore, in one embodiment, the root file system of the target operating system, compared to the root file system of the native operating system, removes commands that the container does not have permission to execute and commands that the host system depends on for startup.

[0028] Furthermore, in one embodiment, the commands that the container does not have permission to execute include WIFI configuration commands;

[0029] The commands that the host system depends on for startup include temporary file system mount commands.

[0030] In this application, the bootloader decompresses the target boot image to a memory block device and starts the kernel. The native boot image contains the kernel and the root file system of the native operating system, while the target boot image contains the kernel and the root file system of the host system. The kernel starts the root file system of the host system from the memory block device to boot the host system. The host system then starts the root file system of the container to boot the target operating system within the container. The container's root file system contains the container's configuration files and the root file system of the target operating system, which is modified from the root file system of the native operating system. This application enables the operating system to boot within a container without the user's awareness, thus simplifying user operations and reducing time consumption. Attached Figure Description

[0031] Figure 1 This is a flowchart illustrating a container-based operating system control method in one embodiment of this application. Detailed Implementation

[0032] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0034] In a first aspect, embodiments of this application provide a container-based operating system control method.

[0035] Figure 1 A flowchart illustrating a container-based operating system control method according to an embodiment of this application is shown.

[0036] Reference Figure 1 In one embodiment, the container-based operating system control method includes the following steps:

[0037] S11. The bootloader decompresses the target boot image to a memory block device and starts the kernel. The native boot image contains the kernel and the root file system of the native operating system, while the target boot image contains the kernel and the root file system of the host system.

[0038] S12. The kernel starts the host system's root file system from the memory block device to boot the host system;

[0039] S13. The host system starts the root file system of the container to enable the target operating system to start in the container. The root file system of the container contains the container's configuration files and the root file system of the target operating system. The root file system of the target operating system is obtained by modifying the root file system of the native operating system.

[0040] Containers need to run on a host system and rely on the resources and basic environment provided by the host system. Containers share the host system's kernel and can use the host system's hardware resources such as CPU, memory, network, and storage, but these resources are managed and allocated by the host system. Containers have their own independent file system view, process space, and network configuration, thus ensuring that applications within the container do not interfere with each other and do not directly affect the host system.

[0041] The host system's root file system needs to be executed on a disk partition. However, since disk partitions take a long time to create during system startup, this cannot meet the host system's requirement for the fastest possible startup. A memory block device is a concept that simulates a block storage device similar to a disk in memory. A memory block device can be used as a regular disk partition, enabling rapid mounting and startup of the host system's root file system.

[0042] Extract the kernel and root file system of the native operating system from the native boot image, build the root file system of the host system, package it with the kernel to form the target boot image, replace the native boot image with the target boot image, set the decompression path of the boot image to the memory block device in the bootloader, and set the startup path of the initializer to the memory block device in the kernel. In this way, after the device is powered on, the bootloader decompresses the target boot image, starts the kernel, and the kernel starts the root file system of the host system, thereby automatically and quickly starting the host system and providing resources and basic environment for container operation.

[0043] To ensure the normal startup of the operating system in the container, the root file system of the native operating system cannot be directly packaged with the container's configuration files to form the container's root file system. Instead, the root file system of the native operating system needs to be modified to obtain the root file system of the target operating system. Then, the root file system of the target operating system is packaged with the container's configuration files to form the container's root file system. After packaging and compression, the container's root file system can be used to obtain a container image. The startup command of the container's root file system is placed in the host system's startup script, so that the container's root file system is automatically started during the host system's startup process, thereby enabling the target operating system to start in the container.

[0044] The original boot process is as follows: the device powers on, the bootloader starts the kernel, the kernel starts the root file system of the native operating system, and the native operating system starts. The improved boot process is as follows: the device powers on, the bootloader starts the kernel, the kernel starts the root file system of the host system, and the host system starts the root file system of the container, thus starting the target operating system within the container. For the user, both processes only require powering on and waiting for the operating system to start, with no significant increase in waiting time. Therefore, this embodiment allows the operating system to start within the container without the user's awareness, simplifying user operations and reducing time consumption.

[0045] Optionally, a streamlined Linux system can be built using the Buildroot framework as the host system. Buildroot is a powerful framework for building embedded Linux systems, allowing users to select the necessary software packages, kernel configurations, file system types, etc., according to specific needs. It integrates and automates the complex embedded Linux system building steps, greatly reducing the difficulty of building and generating suitable systems for various common processor architectures.

[0046] Optionally, the root filesystem of the host system is formatted as ext4. ext4 is a widely used and mature filesystem format, compatible with most Linux distributions and kernel versions, reducing potential compatibility issues. Through long-term use and optimization, ext4 performs excellently in data integrity and error recovery, reducing the risk of data loss and system failure, and ensuring the stable operation of containers. For general read and write operations, ext4 provides good performance, ensuring that applications within the container can quickly access and store data, supporting larger files and file systems, and accommodating the large amounts of data that may be generated within the container.

[0047] Optionally, the native operating system and the target operating system are both Android. Android is an open-source mobile operating system based on the Linux kernel. It has a vast library of applications covering various types and functions, which users can easily download and install according to their needs. It can run on a wide range of devices from different brands and models, and manufacturers and developers can deeply customize it to meet the needs of different user groups and markets.

[0048] In the Android system, upon receiving a shutdown or reboot request, the native logic is to directly issue a shutdown or reboot command to the kernel to perform the device shutdown or reboot operation. However, when running the Android system in a container, the Android system cannot directly issue shutdown or reboot commands to the kernel; the operation will be interrupted.

[0049] Furthermore, in one embodiment, the native operating system and the target operating system are both Android systems;

[0050] Following the step of starting the root file system of the container on the host system to enable the target operating system to boot within the container, the following is also included:

[0051] After receiving the shutdown request, the target operating system writes the shutdown command to the shared partition;

[0052] After the host system reads the shutdown command from the shared partition, it issues a shutdown command to the kernel.

[0053] In this embodiment, the shared partition is a disk partition that is visible to both the host system and the container. It serves as a communication bridge between the two, enabling the shutdown command to be transmitted from the target operating system to the host system, and then from the host system to the kernel, thereby realizing the shutdown operation of the device.

[0054] Furthermore, in one embodiment, the native operating system and the target operating system are both Android systems;

[0055] Following the step of starting the root file system of the container on the host system to enable the target operating system to boot within the container, the following is also included:

[0056] After receiving the reboot request, the target operating system writes a reboot command to the shared partition;

[0057] After the host system reads the reboot command from the shared partition, it issues a reboot command to the kernel.

[0058] In this embodiment, the shared partition is a disk partition that is visible to both the host system and the container. It serves as a communication bridge between the two, enabling the restart command to be transmitted from the target operating system to the host system, and then from the host system to the kernel, thereby enabling the device to restart.

[0059] Furthermore, in one embodiment, the host system continuously monitors commands in the shared partition through a daemon process.

[0060] In this embodiment, the host system can detect new instructions in real time through the daemon process and respond quickly, reducing the delay in instruction acquisition and ensuring the stability of instruction acquisition without being affected by other temporary factors. The daemon process runs in a continuous but low-resource-consumption manner, without incurring a large amount of system resource overhead every time an instruction needs to be acquired, thus avoiding unnecessary resource waste compared to the periodic polling method.

[0061] In Linux systems, daemons can be managed and controlled using the systemctl command or related initialization scripts, including starting, stopping, restarting, and viewing their status.

[0062] Furthermore, in one embodiment, after the step of the host system starting the root file system of the container to enable the target operating system to start in the container, the method further includes:

[0063] Before the host system issues a shutdown or reboot command to the kernel, it performs a file system synchronization operation.

[0064] In this embodiment, the host system uses file system synchronization operations to force the cached data in memory to be written to the disk before shutdown or restart, ensuring data integrity and consistency, thereby avoiding data loss and file system corruption.

[0065] Furthermore, in one embodiment, before the step of the host system starting the root file system of the container to enable the target operating system to start in the container, the method further includes:

[0066] The host system sets the partition where the container's root file system is located to a readable and writable state, detects the status of hardware resources in the container's configuration file, and modifies the container's configuration file to allocate hardware resources in a normal state to the container when there are hardware resources in an abnormal state.

[0067] In related technologies, containers typically use static configuration files. When there are abnormal hardware resources in the container's configuration file, if the host system starts the container's root file system, it will allocate the abnormal hardware resources to the container, causing the container to fail to start.

[0068] In this embodiment, before starting the root file system of the container, the host system first sets the partition where the root file system of the container is located to a readable and writable state, reads the container's configuration file, checks whether the status of the hardware resources is normal, and replaces the hardware resources in an abnormal state with hardware resources in a normal state, thereby realizing dynamic updates of the configuration file and avoiding the problem of container startup failure caused by abnormal hardware resource status.

[0069] Furthermore, in one embodiment, after the step of the host system starting the root file system of the container to enable the target operating system to start in the container, the method further includes:

[0070] The host system sets the partition containing the container's root file system to read-only.

[0071] In this embodiment, after the host system starts the root file system of the container, it sets the partition where the root file system of the container is located to read-only state, thereby ensuring the consistency and stability of the root file system of the container and avoiding system crashes or unpredictable behavior due to erroneous modifications.

[0072] Furthermore, in one embodiment, the step of booting the host system by starting the kernel from the memory block device and establishing the root file system of the host system includes:

[0073] The kernel sets the startup path of the initializer to the memory block device via kernel command-line arguments.

[0074] In this embodiment, the kernel sets the startup path of the initialization program to the memory block device via kernel command-line parameters after each boot. This is more flexible than directly modifying the startup code, i.e., hardcoding the startup path in the code.

[0075] Furthermore, in one embodiment, the root file system of the target operating system, compared to the root file system of the native operating system, removes commands that the container does not have permission to execute and commands that the host system depends on for startup.

[0076] Specifically, in a container environment, due to its isolation and security design principles, some commands that containers do not have permission to execute exist. If these commands are retained in the target operating system's root file system, it will cause the target operating system to fail to boot within the container. The host system's boot process depends on a series of critical commands that are pre-executed during the host system's boot process. Retaining these commands in the target operating system's root file system will create resource conflicts, causing the target operating system to fail to boot within the container. Therefore, compared to the native operating system's root file system, the target operating system's root file system needs to remove commands that containers do not have permission to execute and commands that the host system depends on to ensure the target operating system boots normally within the container.

[0077] Optionally, the command to delete the root file system of the target operating system compared to the root file system of the native operating system can be implemented through the container's configuration file, the root file system of the host system, the host system's startup script, etc.

[0078] Furthermore, in one embodiment, the commands that the container does not have permission to execute include WIFI configuration commands;

[0079] The commands that the host system depends on for startup include the Temporary File System (TMPFS) mount command.

[0080] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0081] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit the "first", "second" and "third" to different types.

[0082] In the description of the embodiments of this application, the words "exemplary," "for example," or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary," "for example," or "for example" in the embodiments of this application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary," "for example," or "for example" is intended to present the relevant concepts in a concrete manner.

[0083] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.

[0084] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0085] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0086] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A container-based operating system control method, characterized in that: The container-based operating system control method includes: The boot loader decompresses the target boot image to a memory block device and starts the kernel, wherein the target boot image is used to replace the native boot image, the native boot image includes the kernel and the root file system of the native operating system, the target boot image includes the kernel and the root file system of the host system, the kernel in the target boot image is modified based on the kernel in the native boot image, and the kernel in the target boot image modifies the boot path of the initialization program to the memory block device compared to the kernel in the native boot image; The kernel starts the root file system of the host system from the memory block device to start the host system, wherein the host system is used to provide resources and a basic environment for the container to run, and the self-start script of the host system contains the startup command of the root file system of the container; The host system starts the root file system of the container to realize the startup of the target operating system in the container, wherein the root file system of the container includes the configuration file of the container and the root file system of the target operating system, the root file system of the target operating system is modified based on the root file system of the native operating system, and the root file system of the target operating system deletes the commands that the container has no permission to execute and the commands that the host system depends on to start compared with the root file system of the native operating system, and realizes the commands deleted by the root file system of the target operating system compared with the root file system of the native operating system through at least one of the configuration file of the container, the root file system of the host system and the self-starting script of the host system.

2. The container-based operating system control method according to claim 1, characterized in that: The native and target operating systems are Android; After the host system starts the root file system of the container to start the target operating system in the container, the method further includes: After receiving the shutdown request, the target operating system writes a shutdown instruction to the shared partition; After the host system reads the shutdown command from the shared partition, it sends the shutdown command to the kernel.

3. The container-based operating system control method according to claim 1, characterized in that: The native and target operating systems are Android; After the host system starts the root file system of the container to start the target operating system in the container, the method further includes: After receiving the restart request, the target operating system writes a restart instruction to the shared partition; After the host system reads the restart instruction from the shared partition, it sends the restart instruction to the kernel.

4. The container-based operating system control method according to claim 2 or 3, characterized in that: The host system continuously listens to the instructions in the shared partition through a daemon process.

5. The container-based operating system control method according to claim 2 or 3, characterized in that: After the host system starts the root file system of the container to start the target operating system in the container, the method further includes: Before the host system issues a shutdown command or a restart command to the kernel, it performs a file system synchronization operation.

6. The container-based operating system control method according to claim 1, characterized in that: Before the host system starts the root file system of the container to start the target operating system in the container, the method further includes: The host system sets the partition where the root file system of the container is located to a readable and writable state, detects the state of the hardware resources in the configuration file of the container, and when there are hardware resources in an abnormal state, modifies the configuration file of the container to allocate the hardware resources in a normal state to the container.

7. The container-based operating system control method according to claim 6, characterized in that: After the host system starts the root file system of the container to start the target operating system in the container, the method further includes: The host system sets the partition where the container's root file system is located to read-only status.

8. The container-based operating system control method according to claim 1, characterized in that: Before the step of the kernel starting the root file system of the host system from the memory block device to start the host system, the step further includes: The kernel sets the startup path of the initialization program to the memory block device through the kernel command line parameters.

9. The container-based operating system control method according to claim 1, characterized in that: The commands that the container has no permission to execute include WIFI configuration commands; The commands that the host system depends on for startup include temporary file system mounting commands.

Images