Container system of host and method for dynamically mounting host data to container

Abstract

A container system of a host computer includes a host computer having a file system, an application process and an application interface server running in a container of the host computer, and a container manager running in the host computer, wherein the container manager establishes an origin directory in the file system and mounts the origin directory to a shared directory of the application process. The application interface server receives a request instruction issued for a target subdirectory in the file system, and the container manager binds and mounts the target subdirectory to a subdirectory of the origin directory according to the request instruction. Furthermore, the container manager informs the application interface server of a location of the target subdirectory in the shared directory, so that the required data is accessed through the shared directory in the container.

Description

Technical Field

[0001] This invention relates to containers, and more particularly to container systems used in a host and a mounting method for dynamically mounting host data to a container. Background Technology

[0002] A container is a technology that virtualizes an operating system. Multiple containers can be created on a single host as needed, each capable of executing any task, from small services and small programs to large applications. Specifically, a container contains the necessary process files, libraries, and configuration files for running an application, but does not need to contain the operating system image, making it quite lightweight and portable.

[0003] The most significant feature of container technology is its ability to isolate the execution environment of an application, ensuring that the execution of an application within a container does not affect the environment outside the container. For example, if multiple applications need to use different versions of libraries, users can run these applications in different containers, thereby overcoming the conflict caused by different library versions required by these applications.

[0004] In common cases, containers have a short execution period after creation and are shut down after their task is completed (e.g., a specified program finishes executing). In this case, container information is not stored, hence they are called stateless containers. Some containers execute more specialized programs (e.g., NFS-ganesha, Samba, etc., software used to connect different communication protocols), therefore their execution period is longer and they are not frequently shut down. In this case, container information needs to be stored, hence they are called stateful containers.

[0005] Applications within stateful containers can be architecturally divided into a control path and a data path. The control path provides the Application Programming Interface (API) to external administrators for configuration (e.g., network connectivity), while the data path shares data based on instructions received from the control path. Because the control path provides the container with a means of external connectivity, it is a prime target for hacker attacks.

[0006] While containers encapsulate an application's execution environment to isolate it from the external environment, the application still needs to access data on the host machine. However, when creating a container, the system cannot predict in advance what data the application will require. If, for convenience, administrators directly mount all storage space on the host machine to the container, or improperly grant containers privileges that allow them to freely query and mount any storage space on the host machine, then when a hacker infiltrates the container through such a control path, they can reverse-engineer all the data in the host's file system (FS). This violates the original purpose of containers—to isolate the execution environment from the external environment—and increases security risks.

[0007] See Figure 1 This is a diagram illustrating the use of containers within a host machine. For example... Figure 1 As shown, host 1 can primarily contain a file system 11 consisting of multiple directories, and can utilize at least one container 12, wherein at least one application runs within container 12. Figure 1 In the architecture, the application is divided into an application interface server (API Server) 13 and an application process (Daemon) 14, wherein the application interface server 13 provides a control path R1 to the outside world, and the application process 14 provides a data path R2.

[0008] As mentioned earlier, since it is impossible to predict what data the application will need from host 1 during execution, some administrators may, for convenience, bind mount the entire file system 11 to the shared directory 15 in container 12. In this case, if a hacker compromises container 12 via control path R1, they can directly obtain all the data in host 1 through the shared directory 15.

[0009] On the other hand, some administrators might grant inappropriate privileges to container 12 during its creation for convenience. In this case, if a hacker compromises container 12 via control path R1, they can query and obtain all data from host 1 using specific commands (such as CLI commands under Docker). Once this happens, the isolation mechanism of container 12 will become ineffective. Summary of the Invention

[0010] The main objective of this invention is to provide a host container system and a method for dynamically mounting host data to a container, which can dynamically mount specific data from the host to the container only when needed, thereby reducing the risk of data inside the host being exposed to the outside.

[0011] To achieve the above objectives, the container system of the present invention includes:

[0012] A host has a file system (FS) consisting of multiple directories;

[0013] An application daemon runs in a container on this host and has at least one shared directory;

[0014] A container management station, running on the host, creates a source directory in the file system, and mounts the source directory to the shared directory; and

[0015] An application interface server (API server) receives a request instruction from an external administrator for a target subdirectory in the file system and forwards the request instruction to the container management station;

[0016] The container management station binds and mounts the target subdirectory to a source subdirectory of the source directory according to the request instruction, and informs the application interface server of the location of the target subdirectory in the shared directory. In this way, the container shares the target subdirectory through the shared directory for internal processing or to share with external users.

[0017] As described above, the source directory is mounted to the shared directory using a slave mount. After the target subdirectory is bound and mounted to the source subdirectory, it automatically appears as a shared subdirectory of the shared directory due to the slave mount feature. The container shares this shared subdirectory for internal computation or for sharing with external users.

[0018] As described above, the application interface server and the application process run in different containers on the host.

[0019] As described above, the application interface server communicates locally with the application process through a first inter-process communication (IPC), and forwards the request instruction to the container management station and receives notification from the container management station through a second inter-process communication.

[0020] As described above, it further includes a binding database that stores a configuration file of the container, the configuration file including at least one of the following: a path name of the shared directory in the container, a mount relationship between the source directory and the shared directory, and a binding mount relationship between the target subdirectory and the source subdirectory.

[0021] As described above, the container management station queries the binding database to obtain the configuration file, creates the container based on the configuration file, and runs the application process in the container.

[0022] To achieve the above objectives, the method of the present invention is applied to a host having a file system, wherein the host runs an application program, an application interface server, and a container management station, the application interface server runs in a first container, the application program runs in a second container, and the method includes:

[0023] a1) The container management station establishes a source directory in the file system;

[0024] a2) The container management station mounts the source directory to a shared directory of the application process;

[0025] a) The container management station receives a request instruction from the application interface server, wherein the request instruction is issued by an external administrator for a target subdirectory in the file system;

[0026] b) The container management station, based on the request instruction, binds and mounts the target subdirectory to a source subdirectory of the source directory; and

[0027] c) After step b), the container management station informs the application interface server of the location of the target subdirectory in the shared directory, so that the second container can share the target subdirectory through the shared directory for internal processing or to share with external users.

[0028] As described above, in step a01), the source directory is mounted to the shared directory by means of dependent mounting, and after step b), the target subdirectory automatically appears as a shared subdirectory of the shared directory by means of dependent mounting, and in step c), the second container shares the shared subdirectory for internal processing or to share with external users.

[0029] As described above, in step a), the application interface server forwards the request instruction to the container management station via a first IPC, and in step c), it receives the notification from the container management station via the IPC and requests the application to share the shared subdirectory via a second IPC.

[0030] As described above, step a) is preceded by the following steps:

[0031] a01) Query a configuration file of the second container in a binding database, wherein the configuration file includes at least one of the following: a path name of the shared directory in the second container, a mount relationship between the source directory and the shared directory, and a binding mount relationship between the target subdirectory and the source subdirectory;

[0032] a02) If the configuration file exists in the binding database, the target subdirectory that has been allowed to be shared will be bound and mounted to the source subdirectory according to the content of the configuration file; and

[0033] a03) After step a02), the second container is established based on the mount relationship between the source directory and the shared directory, and the application process is run in the second container.

[0034] As described above, step a) is preceded by the following steps:

[0035] a04) If the configuration file does not exist in the bound database, determine the namespace of the shared directory to be created in the second container;

[0036] a05) Store the path name of the shared directory in the bound database as the configuration file; and

[0037] a06) Based on the mount relationship between the source directory and the shared directory, the second container is established, and the application process is run in the second container.

[0038] As described above, step a) is preceded by step a07): the container management station creates the first container after step a03) or step a06, and runs the application interface server in the first container.

[0039] As described above, step a) is preceded by the following steps:

[0040] a08) The container management station receives a query request from the application interface server, wherein the query request is issued by the external administrator for a shareable directory on the host; and

[0041] (a09) The container management station responds to the query request with a list of shareable directories to the application interface server, thereby providing the external administrator with the target subdirectories recorded in the list.

[0042] As described above, it further includes the following steps:

[0043] d) The container management station receives a stop sharing request from the application interface server, wherein the stop sharing request is issued by the external administrator for the target subdirectory;

[0044] e) The container management station informs the application interface server of the location of the target subdirectory in the shared directory, thereby requesting the application to stop sharing the target subdirectory;

[0045] f) The container management system unloads the target subdirectory and removes the source subdirectory; and

[0046] g) Record the uninstallation action in a bound database.

[0047] The technical advantage of this invention over related technologies lies in the fact that the container management station can dynamically provide specific data from the host to the container while the container is running, thereby reducing the amount of data that the container can generally access and preventing the host's data from being exposed. Furthermore, the container management station does not need to shut down the container, modify the configuration file, and then rebuild the container, thus simultaneously ensuring both security and convenience.

[0048] The present invention will be described in detail below with reference to the accompanying drawings and specific embodiments, but this is not intended to limit the present invention. Attached Figure Description

[0049] Figure 1 This is a diagram illustrating the use of containers within a host machine;

[0050] Figure 2 This is a first specific embodiment of the container system of the present invention;

[0051] Figure 3 This is a second specific embodiment of the container system of the present invention;

[0052] Figure 4 The third specific embodiment is a schematic diagram of the container system of the present invention;

[0053] Figure 5 This is a first specific embodiment of the flowchart of the dynamic mounting method of the present invention;

[0054] Figure 6 A first specific embodiment of establishing a flowchart for the container of the present invention;

[0055] Figure 7 This is a first specific embodiment of the timing diagram of the dynamic mounting method of the present invention;

[0056] Figure 8 This is a first specific embodiment of the flowchart of the unloading method of the present invention;

[0057] Figure 9 This is a first specific embodiment of the timing diagram of the unloading method of the present invention.

[0058] In the attached figures, the following labels are used:

[0059] 1…host;

[0060] 11…archive system;

[0061] 111… target subdirectory;

[0062] 12… containers;

[0063] 13…Application Interface Server;

[0064] 14…Application schedule;

[0065] 15… Share directory;

[0066] R1…control path;

[0067] R2…data path;

[0068] 2…host;

[0069] 21…archive system;

[0070] 211…Source Directory;

[0071] 2111…Source Subdirectory;

[0072] 212… target subdirectory;

[0073] 22… containers;

[0074] 23…First container;

[0075] 24…Second container;

[0076] 3… Container Management Station;

[0077] 4…bind to the database;

[0078] 5…Application Interface Server;

[0079] 6…Application schedule;

[0080] 7… Share the directory;

[0081] 71… Share subdirectories;

[0082] 8, 81… Communication between trips;

[0083] 9…Managers;

[0084] S10~S22… Mounting steps;

[0085] S30~S42… Steps to establish;

[0086] S51~S66… Mounting steps;

[0087] S70~S78… Uninstallation steps;

[0088] S91~S96… Uninstallation steps. Detailed Implementation

[0089] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments to further understand the purpose, solution and effect of the present invention, but it is not intended to limit the scope of protection of the appended claims.

[0090] Please refer to the first one. Figure 2 This is a first specific embodiment of the container system of the present invention. (See diagram below.) Figure 2 As shown, this invention discloses a container system for a host computer, mainly comprising a host computer 2, and a container management station 3, an application program interface server (API server) 5, and application daemons 6 running on the host computer 2. The host computer 2 may be, for example, a personal computer (PC), a laptop computer, an industrial PC (IPC), a server, or other computer equipment, but is not limited thereto. In one embodiment, the container management station 3 is a service within the host computer 2 and runs directly on the host computer 2, while the application program interface server 5 and application daemons 6 run in at least one container 22 within the host computer 2.

[0091] The container 22 is a common technical means in this field, and will not be described in detail here.

[0092] Specifically, application interface server 5 and application process 6 can be different functions of the same application, and are architecturally distinguished as application interface server 5 and application process 6. When host 2 wants to execute this application, it first creates container 22 through container management station 3, and then runs the application in container 22. In this way, the execution environment of this application (i.e., application interface server 5 and application process 6) is isolated from the environment outside container 22, so that they do not affect each other.

[0093] In one embodiment, the application interface server 5 provides a control path externally (e.g., via the Internet), and the application process 6 provides a data path, wherein the data path can be provided externally or internally, without limitation. An administrator can send commands to the application interface server 5 through the control path to control operations within container 22 and query required data. Furthermore, the administrator can obtain relevant data shared by application process 6 through the data path.

[0094] In one embodiment, the application process 6 is software used to connect different communication protocols (e.g., Server Message Block (SMB) protocol and Common Internet File System (CIFS) protocol), such as NFS-ganesha or Samba, but not limited thereto. NFS-ganesha and Samba are well-known technologies in this art and will not be described further here.

[0095] Host 2 contains a file system (FS) 21 consisting of multiple directories. For example... Figure 2 As shown, the file system 2 has a tree structure, and the root directory ( / ) contains directories such as etc, home, and mnt. The mnt directory further contains subdirectories such as a, b, ..., z. The directory names of the above directories and subdirectories are only examples and are not intended to limit the main technical scope of this case.

[0096] like Figure 2 As shown, application process 6 in container 22 can have its own shared directory 7, for example... Figure 2 The shared directory is shown in the image. When an administrator retrieves data from application process 6 via a data path, they can primarily access data under shared directory 7. More specifically, the directory name of the shared directory is a fixed usage when application process 6 typically shares data, indicating that this directory is a shareable directory.

[0097] One of the technical features of this invention is that, when the container system creates container 22, it mounts only a very small amount of content (in...) to the shared directory 7. Figure 2 In this embodiment, no data is mounted under the shared directory 7, and when the application process 6 has a sharing requirement, the container management station 3 dynamically mounts the required data from the file system 21 to the shared directory 7. This avoids the risk of important data in the host 2's file system 21 being leaked via the shared directory 7 due to hacking of the control path.

[0098] Specifically, the container management station 3 of the present invention can establish a source directory 211 in the file system 21 of the host 2 before instantiating the container 22. The source directory 211 is located in... Figure 2 Taking the directory name of C2 as an example, the directory name of the source directory 211 does not have any substantial meaning. The administrator can set the directory name of the source directory 211 himself, or the container management station 3 can randomly generate an arbitrary directory name without any restrictions.

[0099] After container 22 is created, container management station 3 mounts the source directory 211 in the file system 21 of host 2 to the shared directory 7 in container 22 (i.e., mounts the " / C2" directory to the " / share" directory). In one embodiment, container management station 3 primarily mounts the source directory 211 to the shared directory 7 using a slave mount. Due to the nature of slave mount technology, when a subdirectory in file system 21 is bound to a source subdirectory under source directory 211, the bound mount relationship automatically appears in shared directory 7. Therefore, when the subdirectory is bound to a source subdirectory under source directory 211, it automatically appears as a shared subdirectory under shared directory 7 (described in detail later).

[0100] like Figure 2 As shown, the application interface server 5 can receive request instructions from external administrators via a control path. In one embodiment, the request instruction may be issued by an administrator for example, a specific target subdirectory within the file system 21. In this invention, the application interface server 5 does not directly execute this request instruction but forwards it to the container management station 3.

[0101] In one embodiment, the container management station 3 communicates with the application interface server 5 via inter-process communication (IPC) 8. Therefore, the application interface 5 can forward the request instructions to the container management station 3 via inter-process communication 8.

[0102] Specifically, when deploying the inter-process communication 8, the system can configure it to use the local communication protocol, thereby restricting the container management station 3 to only accept and serve requests from the local trust domain via the inter-process communication 8. By using the inter-process communication 8, even if the application interface server 5 is compromised by a hacker, the risk of the hacker obtaining data from the host 2 through the container management station 3 can be avoided.

[0103] As described above, in this invention, the container management station 3 mounts the source directory 211 to the shared directory 7, and the container management station 3 queries the contents of the file system 21 via commands. To achieve this, the host 2 must grant the container management station 3 a certain level of privileges. To reduce the risk of the container management station 3 being compromised by hackers and thus endangering the host 2 through these privileges, the container management station 3 can only communicate with other programs via the inter-process communication 8.

[0104] It is worth mentioning that although inter-process communication 8 can reduce the risk of hackers intruding into container management station 3 through application interface server 5, if application interface server 5 and application process 6 are run in the same container 22, hackers may still be able to intrude into application process 6 through application interface server 5.

[0105] Specifically, if the control path and data path are placed in the same container 22, the data shared by the data path will be visible from the control path. Since the control path is generally connected to the Internet, it is often a primary source of hacker attacks. In this case, if any directory / subdirectory in the file system 21 is mounted to the shared directory 7, a hacker may be able to obtain other data within the file system 21 of the host 2 through the shared directory 7. In view of this, the present invention provides another technical solution, which allows the application interface server 5 and the application process 6 to run in different containers 22 to reduce the above-mentioned risks.

[0106] Please see Figure 3 This is a second specific embodiment of the container system of the present invention. Figure 3 This discloses another specific embodiment of the container system of the present invention. Figure 3 Implementation examples and Figure 2 The difference between the embodiments is that the container management station 3 runs a first container 23 and runs the application interface server 5 in the first container 23, and runs a second container 24 and runs the application process 6 in the second container 24.

[0107] like Figure 3 As shown, the application interface server 5 in the first container 23 communicates with the container management station 3 via inter-process communication 8, and also communicates with the application process 6 in the second container 24 via another inter-process communication 81. Through the characteristics of inter-process communications 8 and 81—that only accepting and serving local trusted domains—and by allowing the application interface server 5 to mount only a very small amount of host data (not shown in the figure), Figure 3 The embodiments can further reduce the risk of host 2's data being exposed via application interface server 5.

[0108] It is worth mentioning that the inter-process communication 8 (e.g., the first inter-process communication) used between the application interface server 5 and the container management station 3 and the inter-process communication 81 (e.g., the second inter-process communication) used between the application interface server 5 and the application process 6 are independent of each other and can be implemented using different local IPC mechanisms, but there is no limitation on them.

[0109] Specifically, container management station 3 only needs to implement one type of inter-process communication 8 to support multiple different application servers 5 (e.g., Samba, NFS, etc., each with its own application server). In contrast, the inter-process communication 81 between application server 5 and application process 6 can adopt different implementation methods depending on the nature of the software and actual needs. For example, the inter-process communication 81 used between Samba application server 5 and application process 6 does not necessarily need to be the same as the inter-process communication 81 used between NFS application server 5 and application process 6. More specifically, the inter-process communications 8 and 81 can be implemented using different communication protocols; even if the same communication protocol is used, the supported communication commands can still be different, depending on the content that needs to be communicated between application server 5 and application process 6.

[0110] However, the above are only some specific embodiments of the present invention, and are not limited thereto.

[0111] Please also refer to Figure 4 This is a third specific embodiment of the container system of the present invention. As described above, after the container management station 3 receives the request instruction from the application interface server 5, it can query the location of the target subdirectory 212 specified by the request instruction from the file system 21. Figure 4 (Taking the target subdirectory 212 as an example, the / mnt / a subdirectory). Furthermore, container management station 3 binds and mounts the target subdirectory 212 to the source subdirectory 2111 of the source directory 211. Figure 4 (Taking the source subdirectory 2111, for example, the / C2 / a subdirectory).

[0112] like Figure 4 As shown, when container management station 3 creates the second container 24, it directly mounts the source directory 211 subordinately to the shared directory 7 under application process 6. Based on the characteristics of subordinate mounting technology, when the target subdirectory 212 is bound and mounted to the source subdirectory 2111, the binding mount relationship will automatically appear in the shared directory 7 of the second container 24, and thus the target subdirectory 212 will automatically appear in the shared subdirectory 71 under the shared directory 7 in the second container 24. Figure 4 (Taking the / share / a subdirectory as an example).

[0113] As described above, after the target subdirectory 212 is bound and mounted to the source subdirectory 2111, a corresponding shared subdirectory 71 will automatically appear under the shared directory 7 which has a subordinate mount relationship with the source directory 211. Accordingly, the container management station 3 can inform the application interface server 5 of the location of the target subdirectory 212 in the shared directory 7. More specifically, the container management station 3 can inform the application interface server 5 that the target subdirectory 212 is the same as the shared subdirectory 71 in the second container 24. In this way, the application interface server 5 can request the application process 6 to share the shared subdirectory 71, and the second container 24 can share the contents of the specified target subdirectory 212 (i.e., the contents of the shared subdirectory 71) through the shared directory 7 for internal processing or to share with external users.

[0114] In one embodiment, the application interface server 5 primarily receives notifications from the container management station 3 via inter-process communication 81, and communicates locally with the application process 6 via inter-process communication 81 to request the application process 6 to share the contents of the shared subdirectory 71. This reduces the risk that a hacker, after intruding into the application interface server 5, could further obtain the contents of the shared subdirectory 71 through the application interface server 5, and ultimately gain access to the entire file system 21 of the host 2.

[0115] It is worth mentioning that a cluster can run multiple hosts (i.e., multiple nodes) simultaneously, and each node can run multiple containers. In this invention, if multiple nodes are running on a cluster, each node needs to run a container management station 3 to manage one or more containers on that node.

[0116] Please see below. Figure 5 This is a first specific embodiment of the flowchart of the dynamic mounting method of the present invention. The present invention further discloses a method for dynamically mounting host data to a container (hereinafter referred to as the mounting method in the specification), which is mainly applied to... Figure 2 , Figure 3 and Figure 4 In the container system shown, the risk of data leakage from host 2 is reduced while sharing data through application process 6.

[0117] It is worth mentioning that the container management station 3 is primarily an application running on the host 2, providing specific services to the host 2. For example, the host 2 may be a Network Attached Storage (NAS) server, and the container management station 3 may be an application used to provide network access services, implementing the application interface server 5 and application process 6 on the host 2 through container technology. However, the above is only one embodiment of the present invention, and is not limited to it.

[0118] The application may contain computer-executable program code, which, when an electronic device, such as... Figures 2 to 4 After the host 2 shown executes the computer executable code, the container management station 3 can run on it, and the container management station 3 can be used to achieve... Figure 5 The specific steps of the mounting method are shown.

[0119] like Figure 5 As shown, to execute the mounting method of the present invention, the host 2 first executes the application to run the container management station 3 on the host 2. Next, the container management station 3 creates a source directory 211 in the file system 21 of the host 2 (step S10). Specifically, the purpose of creating the source directory 211 is to mount specific subdirectories to the container without affecting other directories in the file system 21. Therefore, in step S10, the container management station 3 can randomly generate the directory name of the source directory 211 and randomly determine the location of the source directory 211 in the file system 21, thereby increasing execution flexibility.

[0120] After step S10, container management station 3 can mount source directory 211 to application process 6 (i.e., as shown in step S10). Figure 4 The shared directory 7 of the second container 24 shown (step S12). In one embodiment, in step S12, the container management station 3 mounts the source directory 211 to the shared directory 7 of the application process 6 via a dependent mount, and the application process 6 may be, for example, Samba. However, the above is only one embodiment of the present invention and is not limited thereto.

[0121] like Figure 4 As shown, the container system of the present invention can also configure a binding database 4, implemented in hardware or software, in the host 2. After step S10 above, the container management station 3 can mainly write the relevant information of the source directory 211 into the container to be created (e.g., Figure 4The configuration files (Config) of the first container 23 and the second container 24 shown are recorded in the binding database 4. Furthermore, the container management station 3 writes the mount relationship between the source directory 211 and the shared directory 7 of the soon-to-be-established second container 24 into the configuration files.

[0122] In step S12, the container management station 3 reads the configuration file from the binding database 4 and creates the corresponding second container 24 based on the contents of the configuration file. Therefore, after the container management station 3 creates the second container 24, the application process 6 can be run directly within the second container 24, and the application process 6 will have a shared directory 7 that has been mounted to the source directory 211. In other words, the container management station 3 can first create the second container 24 and then establish the mount relationship between the source directory 211 and the shared directory 7; or, the container management station 3 can first establish the mount relationship between the source directory 211 and the shared directory 7 and save it as a configuration file, and then create the second container 24 based on the configuration file.

[0123] When creating the second container 24, although container management station 3 mounts the source directory 211 to the shared directory 7, container management station 3 does not necessarily mount additional subdirectories to the second container 24 (e.g., Figure 3 As shown, neither the source directory 211 nor the sharing directory 7 contains any data. At this time, if the application interface server 23 in the first container 23 receives a request instruction from an external administrator, it will forward this request instruction to the container management station 3 via the IPC8. That is, the container management station 3 will receive the request instruction sent from the outside via the application interface server 23 (step S14).

[0124] Upon receiving the request instruction, the container management station 3 can parse the content of the request instruction. For example, when an external administrator wants to query, retrieve, or use a target subdirectory 212 in the file system 21 (e.g., Figure 4 When the target subdirectory 212 is found (e.g., / mnt / a subdirectory), a corresponding request command can be sent to the application interface server 23. After receiving and parsing the request command, the container management station 3 can search for the target subdirectory 212 in the file system 21 by executing internal commands (e.g., CLI commands) (step S16).

[0125] After locating the target subdirectory 212, container management station 3 further binds and mounts the target subdirectory 212 to the source subdirectory 2111 under the source directory 211 (e.g., Figure 4 (See the / C2 / a subdirectory shown) (step S18). The binding and mounting technology is a common technique in this technical field and will not be described in detail here.

[0126] As mentioned earlier, container management station 3 primarily uses dependent mounting technology to mount the source directory 211 to the shared directory 7 of the second container 24. Based on the characteristics of dependent mounting technology, once the target subdirectory 212 is bound and mounted to the source subdirectory 2111, the binding mount relationship will automatically appear in the shared directory 7. Therefore, the target subdirectory 212 will automatically appear in the shared subdirectory 71 under the shared directory 7 (e.g., ...). Figure 4 (as shown in the / share / a subdirectory). Therefore, after step S18, the container management station 3 can inform the application interface server 5 of the location of the target subdirectory 212 in the shared directory 7 (step S20).

[0127] Specifically, in step S14 above, the container management station 3 mainly receives a request from the application interface server 5 to mount the target subdirectory 212 to the second container 24. In step S20, the container management station 3 mainly informs the application interface server 5 that the target subdirectory 212 is the shared subdirectory 71 in the second container 24.

[0128] After step S20, the application interface server 5 sends a sharing request to the application process 6 through the IPC81, ​​so that the second container 24 can share the target subdirectory 212 (i.e., share subdirectory 71) through the sharing directory 7 for internal processing of the host 2, or share it with external users (step S22).

[0129] As mentioned earlier, container management station 3 can first read the configuration file of the container to be created from binding database 4, and then create the corresponding container based on the contents of the configuration file. If the configuration file of the container exists in binding database 4, it means that this container has been created before and was later closed (or host 2 was rebooted); if the configuration file of the container does not exist in binding database 4, it means that this container is being created for the first time. Therefore, whether the required container has been created before will affect the creation operation of container management station 3.

[0130] Please also refer to Figure 6 This is a first specific embodiment of the container creation flowchart of the present invention. As mentioned above, the mounting method of the present invention mainly mounts the source directory 211 in the file system 21 of the host 2 to the shared directory 7 of the second container 24. Therefore, before executing the mounting method, the container management station 3 needs to first create the source directory 211 and the second container 24.

[0131] In this embodiment, container management station 3 first randomly generates a directory name (e.g., Figure 4The source directory 211 is created at any location in the file system 21 based on the directory name "C2" shown in the figure (step S30). Next, the container management station 3 queries the binding database 4 for the configuration file of the second container 24 to be created (step S32), and determines whether the configuration file of the second container 24 to be created exists in the binding database 4 (step S34).

[0132] In one embodiment, the configuration file is data recorded in the binding database 4 when the container management station 4 previously created the second container 24, and may include, for example, at least one of the following: the path name of the shared directory 7 in the second container 24, the mount relationship between the source directory 211 and the shared directory 7, and the binding mount relationship between the target subdirectory 212 and the source subdirectory 2111.

[0133] As mentioned above, the configuration file may exist in the binding database 4 (i.e., the second container 24 was created and then closed), or it may not exist (i.e., the second container 24 was never created). If the container management station 3 determines in step S34 that the configuration file exists in the binding database 4, then the container management station 3 binds and mounts the shared target subdirectory 212 to the source subdirectory 2111 according to the content of the configuration file (step S36). After step S34, the container management station 3 then creates the second container 7 and runs the application process 6 according to the content of the configuration file (step S38).

[0134] Specifically, in step S38, the container management station 3 can create a second container 7 based on the mount relationship between the source directory 211 and the shared directory 7 recorded in the configuration file. After the second container 7 is created, it will have the shared directory 7, and the shared directory 7 and the source directory 211 will have a subordinate mount relationship. Therefore, the source subdirectory 2111 will automatically appear as the shared subdirectory 71 under the shared directory 7 due to the subordinate mount characteristic, without requiring the container management station 3 to perform any additional configuration actions.

[0135] If container management station 3 determines in step 34 that the configuration file does not exist in the binding database 4, it means that the second container 24 has never been created. At this time, container management station 3 first determines the namespace of the shared directory 7 to be created to the second container 24 (step S40), and stores the path name of the shared directory 7 in the binding database 4 as the configuration file of the second container 24 (step S42). After step S42, container management station 3 creates the second container 24 according to the mount relationship between the source directory 211 and the shared directory 7, and runs the application process 6 (step S38).

[0136] Please also refer to Figure 7This is a first specific embodiment of the timing diagram of the dynamic mounting method of the present invention. Figure 7 The actions of container management station 3, binding database 4, application interface server 5 (i.e., first container 23), application process 6 (i.e. second container 24) and manager 9 are further explained in terms of action sequence.

[0137] like Figure 7 As shown, first, host 2 runs container management station 3. After container management station 3 runs, it queries the binding database 4 for the previously recorded target subdirectory 212 that has been allowed to be shared, as well as the relevant data of the shared directory 7 in the previously configured second container 24 (step S51). Next, container management station 3 randomly creates a source directory 211 (e.g., ...) in the file system 21 of host 2. Figure 4 The / C2 directory shown is used to bind and mount the subdirectory 212 (if it exists) found in step S51 to the source subdirectory 2111 of the source directory 211 (e.g., the source subdirectory 2111 of the source directory 211). Figure 4 (See the / C2 / a subdirectory shown) (step S52).

[0138] After step S52, container management station 3 can run the second container 24, and run application process 6 (e.g., Samba) in the second container 24, and mount the source directory 211 subordinately to the shared directory 7 of the second container 24 (e.g., Figure 4 (See the / share directory shown) (step S53). Furthermore, the container management station 3 uses the shared directory 7 as the root directory of the second container 24 and stores it in the binding database 4 as the configuration file for the second container 24 (step S54).

[0139] After the second container 24 is run, it can share the contents of the subdirectories in the shared directory 7 according to its own configuration settings (step S55), thereby realizing the main function of the application process 6 (e.g., Samba).

[0140] After the second container 24 is established (i.e., after the application process 6 is run), the container management station 3 may further establish the first container 23 and run the application interface server 5 in the first container 23 (step S56).

[0141] After the first container 23 is established (i.e., after the application interface server 5 is running), the administrator 9 can connect to the application interface server 5 from the outside and issue a query request (step S57). The query request is issued by the administrator 9 for the shareable directories of the host 2.

[0142] After receiving the query request, the application interface server 5 forwards it to the container management station 3 via IPC8, requesting the container management station 3 to provide a list of shareable directories. Upon receiving the query request, the container management station 3 queries the file system 21 of host 2 and creates a list of shareable directories for host 2, then replies to the application interface server 5 via IPC8 (step S58). After receiving the list, the application interface server 5 replies to the administrator 9 (step S59).

[0143] After receiving the list, administrator 9 can determine which directories in host 2's file system 21 are currently allowed to be shared. Therefore, administrator 9 can, based on actual needs, target the desired subdirectories 212 (e.g., Figure 4 The system sends a request command to the application interface server 5 (step S60) to request the sharing of the target subdirectory 212. In other words, the target subdirectory 212 that the administrator 9 requests to share must exist in the list of shareable directories provided by the container management station 3.

[0144] It is worth mentioning that, in order to reduce cybersecurity risks, the contents of the shareable directory list can be determined by the container management station 3, so as to prevent the administrator 9 from directly viewing all the data in the file system 21 of the host 2. However, the above is only one embodiment of the present invention, and is not limited thereto.

[0145] After receiving the request instruction, the application interface server 5 forwards it to the container management station 3 via IPC8, requesting the container management station 3 to mount the target subdirectory 212 to the second container 24 (step S61). Upon receiving the request instruction, the container management station 3 creates a source subdirectory 2111 under the source directory 211 (e.g., ...). Figure 4 As shown in / C2 / a), the target subdirectory 212 in the file system 21 is bound and mounted to the source subdirectory 2111 (step S62). Furthermore, the container management station 3 records this binding and mounting relationship in the binding database 4 (step S63).

[0146] After step S62, the target subdirectory 212 will automatically appear as the shared subdirectory 71 under the shared directory 7 of the second container 24 based on the characteristic of dependent mounting. Therefore, the container management station 3 can inform the application interface server 5 via IPC8 that the target subdirectory 212 it requested is the shared subdirectory 71 in the second container 24 (step S64).

[0147] Upon receiving notification from container management station 3, application interface server 5 requests application process 6 to share the shared subdirectory 71 via IPC81 (step S65). At this time, application process 6 shares the shared subdirectory 71 based on the request from application interface server 5, for internal processing by host 2, or to share with external administrator 9 or other users. Furthermore, application process 6 records this sharing action and content in its own configuration settings (step S66).

[0148] As described above, all mounting actions performed via the mounting method of this invention are stored in the binding database 4 by the container management station 3. When a container (especially the second container 24 running application process 6) needs to be rebuilt or the host 2 needs to be rebooted, the container management station 3 can query the configuration file recorded in the binding database 4 to automatically complete the previously allowed mountings when rebuilding the container or rebooting the host 2. In this way, this invention is applicable not only to application scenarios using containers with long execution periods, but also to application scenarios using containers with short execution periods or those that need to be frequently rebuilt.

[0149] The mounting method of this invention binds the target subdirectory 212 to the source subdirectory 2111, and automatically generates a shared subdirectory 71 in the second container 24 through the characteristic of subordinate mounting. Furthermore, this invention allows the application interface server 5 to communicate with the application process 6 and the container management station 3 only through IPC 81, thereby reducing security risks. To further reduce the risk of data leakage from the host 2, the mounting method of this invention can also unmount the target subdirectory 212 (as well as the source subdirectory 2111 and the shared subdirectory 71) after the sharing process of the application process 6 ends.

[0150] Please see Figure 8 This is a first specific embodiment of the flowchart of the uninstallation method of the present invention. As described above, application process 6 can share the shared subdirectory 71 according to the request of application interface server 5. When application interface server 5 receives a stop sharing request, it indicates that the administrator 9 or other users no longer need the relevant data. At this time, application interface server 5 forwards the stop sharing request to container management station 3 via IPC8.

[0151] The container management station 3 receives the stop sharing request from the application interface server 5 via IPC8 (step S70). In this embodiment, the stop sharing request is issued by the administrator 9 to the target subdirectory 212 in the file system 21 of the host 2.

[0152] After step S70, container management station 3 informs application interface server 5 of the location of target subdirectory 212 in shared directory 7 of second container 24 via IPC8 (step S72). Thereby, application interface server 5 can communicate with application process 6 via IPC81 to request application process 6 to stop sharing target subdirectory 212 (i.e., sharing subdirectory 71) (step S74).

[0153] After step S74, application process 6 stops sharing, so the target subdirectory 212 no longer needs to be bound and mounted to the source subdirectory 2111. At this time, container management station 3 unmounts the target subdirectory 212 and removes the source subdirectory 2111 (step S76). In this way, the risk of data leakage from file system 21 via the mounting action can be effectively reduced.

[0154] Furthermore, the container management station 3 records the unloading action performed in step S76 in the binding database 4 (step S78). In one embodiment, the binding database 4 is stored in the system's persistent storage. Even if the host 2 is powered off or loses power, the configuration files recorded in the binding database 4 will be continuously saved. In this way, when the second container 24 is rebuilt or the host 2 is restarted, the container management station 3 can automatically and quickly restore the entire system to the state before the rebuild or restart based on the contents of the binding database 4.

[0155] Please also refer to Figure 9 This is a first specific embodiment of the timing diagram of the unloading method of the present invention. Figure 9 The above-mentioned unloading action of container management station 3 is further explained in terms of action timing.

[0156] like Figure 9 As shown, when administrator 9 no longer needs the shared data, it can send a stop sharing request to application interface server 5 (step S91). After receiving the stop sharing request, application interface server 5 forwards it to container management station 3 via IPC8 (step S92). After receiving the stop sharing request, container management station 3 learns from the content of the stop sharing request that administrator 9 requests to stop sharing the target subdirectory 212. Therefore, container management station 3 informs application interface server 5 of the target subdirectory 212 (e.g., ...) via IPC8. Figure 4 The / mnt / a shown is the shared subdirectory 71 in the second container 24 (e.g., Figure 4 (See / share / a)(step S93).

[0157] Upon receiving notification from container management station 3, application interface server 5 communicates with application process 6 via IPC81 and requests application process 6 to stop sharing the shared subdirectory 71 (step S94). Upon receiving the request from application interface server 5, application process 6 can stop sharing.

[0158] After step S93, container management station 3 can learn from the stop sharing request that administrator 9 no longer needs to access target subdirectory 212, and therefore can unload target subdirectory 212 and remove source subdirectory 2111 under source directory 211 (e.g. Figure 4 (See step S95). Finally, the container management station 3 records the above unloading action to the binding database 4 (step S96). In this way, when the second container 24 is rebuilt, the shared subdirectory 71 will not be automatically mounted under the shared directory 7, thereby reducing security risks.

[0159] This invention architecturally splits an application into an application interface server and an application process, each running in a separate container. Furthermore, this invention minimizes the amount of data loaded into each container, and dynamically loads specific data from the host machine into the container where the application process resides via a container management system when needed. This effectively reduces the risk of host data leakage due to improper user configuration of the containers.

[0160] Of course, the present invention may have other various embodiments. Without departing from the spirit and essence of the present invention, those skilled in the art can make various corresponding changes and modifications according to the present invention, but these corresponding changes and modifications should all fall within the protection scope of the appended claims.

Claims

1. A host-based container system, characterized in that, include: A host computer has an archive system consisting of multiple directories; An application process, running in a container on this host, and having at least one shared directory; A container management station, running on the host, creates a source directory in the file system and mounts the source directory to the shared directory; An application interface server receives a request instruction from an external administrator for a target subdirectory in the file system and forwards the request instruction to the container management station; and A binding database stores a configuration file of the container, the configuration file including at least one of the following: a path name of the shared directory in the container, a mount relationship between the source directory and the shared directory, and a binding mount relationship between the target subdirectory and a source subdirectory of the source directory; The container management station binds and mounts the target subdirectory to the source subdirectory according to the request instruction, and informs the application interface server of the location of the target subdirectory in the shared directory. In this way, the container shares the target subdirectory through the shared directory for internal processing or to share with external users.

2. The container system according to claim 1, characterized in that, The source directory is mounted to the shared directory in a subordinate manner. After the target subdirectory is bound and mounted to the source subdirectory, it automatically appears as a shared subdirectory of the shared directory due to the subordinate mounting feature. The container shares the shared subdirectory for internal computation or to share with external users.

3. The container system according to claim 2, characterized in that, The application interface server and the application process run in different containers on the host.

4. The container system according to claim 3, characterized in that, The application interface server communicates locally with the application process through a first inter-process communication, and forwards the request instruction to the container management station and receives notification from the container management station through a second inter-process communication.

5. The container system according to claim 4, characterized in that, The container management station queries the binding database to obtain the configuration file, creates the container based on the configuration file, and runs the application process in the container.

6. A method for dynamically mounting host data to a container, applied to a host having a file system, characterized in that, The host runs an application program, an application interface server, and a container management station. The application interface server runs in a first container, the application program runs in a second container, and the method includes: a1) The container management station establishes a source directory in the file system; a2) The container management station mounts the source directory to a shared directory of the application process; a) The container management station receives a request instruction from the application interface server, wherein the request instruction is issued by an external administrator for a target subdirectory in the file system; b) The container management station, based on the request instruction, binds and mounts the target subdirectory to a source subdirectory of the source directory; and c) After step b), the container management station informs the application interface server of the location of the target subdirectory in the shared directory, so that the second container can share the target subdirectory through the shared directory for internal processing or to share with external users. The following steps are included before step a): a01) Query a configuration file of the second container in a binding database, wherein the configuration file includes at least one of the following: a path name of the shared directory in the second container, a mount relationship between the source directory and the shared directory, and a binding mount relationship between the target subdirectory and the source subdirectory; a02) If the configuration file exists in the binding database, the target subdirectory that has been allowed to be shared will be bound and mounted to the source subdirectory according to the content of the configuration file; and (a03) After step (a02), the second container is established based on the mount relationship between the source directory and the shared directory, and the application process is run in the second container.

7. The method according to claim 6, characterized in that, In step a2), the source directory is mounted to the shared directory via a dependent mount. After step b), the target subdirectory automatically appears as a shared subdirectory of the shared directory due to the dependent mount feature. In step c), the second container shares the shared subdirectory for internal computation or for sharing with external users.

8. The method according to claim 7, characterized in that, In step a), the application interface server forwards the request instruction to the container management station via a first IPC, and in step c), it receives the notification from the container management station via the IPC and requests the application to share the shared subdirectory via a second IPC.

9. The method according to claim 8, characterized in that, This step a) is preceded by the following steps: a04) If the configuration file does not exist in the bound database, determine the shared directory to be created to a namespace of the second container; a05) Store a path name of the shared directory in the bound database as the configuration file; and a06) Based on the mount relationship between the source directory and the shared directory, the second container is established, and the application process is run in the second container.

10. The method according to claim 9, characterized in that, This step a) is preceded by a step a07): the container management station creates the first container after step a03) or step a06) and runs the application interface server in the first container.

11. The method according to claim 8, characterized in that, This step a) is preceded by the following steps: a08) The container management station receives a query request from the application interface server, wherein the query request is issued by the external administrator for a shareable directory on the host; and (a09) The container management station responds to the query request with a list of shareable directories to the application interface server, thereby providing the external administrator with the target subdirectories recorded in the list.

12. The method according to claim 8, characterized in that, It also includes the following steps: d) The container management station receives a stop sharing request from the application interface server, wherein the stop sharing request is issued by the external administrator for the target subdirectory; e) The container management station informs the application interface server of the location of the target subdirectory in the shared directory, thereby requesting the application to stop sharing the target subdirectory; f) The container management system unloads the target subdirectory and removes the source subdirectory; and g) Record the uninstallation action in the bound database.

Images