Data sharing method and device

Abstract

The embodiments of the present specification provide a data sharing method and apparatus, wherein the data sharing method includes: determining a system container in response to a resource usage request, and allocating virtual device resources to the system container; sequentially mounting the virtual device resources on a host corresponding to the system container and the system container, and updating the resource mounting directory of the host according to the mounting result; utilizing a target process associated with the system container to call the virtual device resources to access target data; and upon monitoring a sharing event, mounting the updated resource mounting directory to an application container associated with the system container for accessing the target data, thereby achieving the purpose of device sharing through a permission reduction strategy, supporting application containers to access target data, and effectively ensuring data security.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of container management technology, and more particularly to a data sharing method and apparatus. Background Art

[0002] With the advancement of computer technology, container technology has provided developers with a more convenient development environment. Containers allow developers to uniformly package their applications and dependencies into a portable container, which can then be published to any server with the Docker engine installed, enabling virtualization. This reduces performance overhead while making it easier to run on machines and data centers. Containers are also independent of any language, framework, or system, making them a valuable aid for developers. In the container space, the primary method for accessing data in containers is through the Container Storage Interface (CSI) API definition, with the underlying userspace file system mounted and operated using the POSIX protocol. However, this method presents certain security issues; data access requires super privileges, which increases the attack surface of the container platform. Therefore, an effective solution is urgently needed to address these issues. Summary of the Invention

[0003] In view of this, embodiments of this specification provide a data sharing method. One or more embodiments of this specification also relate to a data sharing apparatus, a computing device, a computer-readable storage medium, and a computer program to address technical deficiencies in the prior art.

[0004] According to a first aspect of an embodiment of this specification, a data sharing method is provided, which is applied to a resource management module, including:

[0005] determining a system container in response to the resource usage request and allocating virtual device resources to the system container;

[0006] Mounting the virtual device resources on the host corresponding to the system container and the system container in sequence, and updating the resource mounting directory of the host according to the mounting result;

[0007] Using the target process associated with the system container to call the virtual device resource to access target data;

[0008] When a sharing event is monitored, the updated resource mount directory is mounted to the application container associated with the system container for accessing the target data.

[0009] According to a second aspect of an embodiment of this specification, a data sharing device is provided, which is applied to a resource management module and includes:

[0010] an allocation unit configured to determine a system container in response to a resource usage request and allocate virtual device resources to the system container;

[0011] a mounting unit configured to sequentially mount the virtual device resources on the host corresponding to the system container and the system container, and update the resource mounting directory of the host according to the mounting result;

[0012] An access unit is configured to utilize a target process associated with the system container to call the virtual device resource to access target data;

[0013] The sharing unit is configured to mount the updated resource mounting directory to the application container associated with the system container for accessing the target data when a sharing event is monitored.

[0014] According to a third aspect of an embodiment of this specification, a computing device is provided, including:

[0015] memory and processor;

[0016] The memory is used to store computer-executable instructions, and the processor is used to implement any step of the above-mentioned data sharing method when executing the computer-executable instructions.

[0017] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores computer-executable instructions, and when the instructions are executed by a processor, the steps of the above-mentioned data sharing method are implemented.

[0018] According to a fifth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned data sharing method.

[0019] The data sharing method provided in this specification supports the sharing of the mount point of the system container with the application container in order to ensure data security. The system container can be determined in response to a resource usage request, and virtual device resources can be allocated to the system container. After the resource allocation is completed, the virtual device resources can be mounted on the host to which the system container belongs, and the resource mount directory of the host can be updated at the same time; secondly, the virtual device resources can be mounted on the system container. At this time, the target process associated with the system container can be used to call the virtual device resources to access the target data. When a sharing event is received, it indicates that the container has been switched. In order to support the application container associated with the system container to access the data normally without causing security risks, the updated resource mount directory can be mounted to the application container to support the application container to access the target data normally. The purpose of device sharing is achieved through a permission reduction strategy to support application containers to access target data, effectively ensuring data security. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 This is a flow chart of a data sharing method provided by one embodiment of this specification;

[0021] Figure 2 This is a schematic diagram of a data sharing method provided by an embodiment of this specification;

[0022] Figure 3 This is a process flow chart of a data sharing method provided by one embodiment of this specification;

[0023] Figure 4 This is a structural diagram of a data sharing device provided by an embodiment of this specification;

[0024] Figure 5 This is a structural block diagram of a computing device provided by one embodiment of this specification. DETAILED DESCRIPTION

[0025] The following description sets forth many specific details to facilitate a thorough understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0026] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0027] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0028] First, the terms involved in one or more embodiments of this specification are explained.

[0029] Containers are an open-source application container engine that allows developers to uniformly package their applications and their dependencies into portable containers. These containers can then be deployed to any server with the Docker engine installed (including popular Linux and Windows machines), and can also be virtualized. With virtually no performance overhead, they can easily run on machines and in data centers. Most importantly, they are independent of any language, framework, or operating system.

[0030] Serverless: The full name is Serverless Computing, which is a serverless computing. It is an architectural concept and service model that allows developers to focus on the logic of the application project without worrying about the infrastructure (servers, etc.).

[0031] Kubernetes: An open source system for automating the deployment, scaling, and management of containerized applications.

[0032] Kubelet: An agent component running on every Kubernetes worker node. It is the primary service on a worker node, regularly receiving new or modified Pod specifications from the kube-apiserver component and ensuring that the Pod and its containers run within the expected specifications. It also serves as a monitoring component for the worker node, reporting the host's health to the kube-apiserver.

[0033] In this specification, a data sharing method is provided. This specification also relates to a data sharing device, a computing device, a computer-readable storage medium, and a computer program, which are described in detail one by one in the following embodiments.

[0034] In practical applications, container data access often requires super privileges. In Serverless scenarios, developing super privileges poses certain security risks. To mitigate the impact of data access risks, the data access client is installed in the image of the Serverless virtual machine instance. However, this leads to high version upgrade costs, poor scalability, and an inability to support effective observation and troubleshooting. Therefore, an effective solution is urgently needed to address these issues.

[0035] The data sharing method provided in this specification supports sharing the mount point of the system container with the application container in order to ensure data security while supporting it. The system container can be determined in response to a resource usage request and virtual device resources can be allocated to the system container. After the resource allocation is completed, the virtual device resources can be mounted on the host to which the system container belongs, and the host's resource mount directory can be updated at the same time; then the virtual device resources can be mounted on the system container. At this time, the target process associated with the system container can be used to call the virtual device resources to access the target data. When a sharing event is received, it indicates that the container has switched. To support the application container associated with the system container to access the data normally without causing security risks, the updated resource mount directory can be mounted to the application container to support the application container to access the target data normally. The purpose of device sharing is achieved through a permission reduction strategy to support application containers to access target data, effectively ensuring data security. In other words, this solution can provide a k8s standard and secure device mounting solution in the Serverless scenario, achieve permission convergence, and avoid unauthorized behavior while ensuring security.

[0036] Figure 1 A flow chart of a data sharing method provided according to an embodiment of the present specification is shown. The method is applied to a resource management module and specifically includes the following steps.

[0037] Step S102 : determining a system container in response to a resource usage request, and allocating virtual device resources to the system container.

[0038] In practice, mounting device files in containers is problematic due to security permissions restrictions on direct operations on / dev / fuse (device files). The open-source Linux kernel requires SYS_ADMIN permissions for mounting within containers, but system containers cannot grant permissions, preventing users from mounting device files. Furthermore, propagation of mount points between containers can be flawed.

[0039] In view of this, the data sharing method provided in this specification will replace real device resources with virtual device resources to ensure data access security, and introduce a resource management module to achieve permission convergence for executing mount commands in the container, so as to avoid security issues caused by the use of super permissions. At the same time, the strategy for propagating mount points is changed from sharing files to sharing devices, and the application container and system container are supported to share virtual device resources to realize the propagation of mount directories, thereby avoiding the propagation of new FDs generated inside the container across the mount space. The purpose of device sharing is achieved through a strategy of reducing permissions to support application containers to access target data, effectively ensuring data security.

[0040] Based on this, the resource management module specifically refers to the component that manages the life cycle of virtual device resources. This component follows the working mechanism of the Device Plugin in the k8s system (Device Plugin is a grpc service used to register resources and devices with kubelet. When the device changes, it updates kubelet, accepts kubelet's application for third-party resources, and returns them to kubelet in the form of parameters). However, unlike Device Plugin, it is used to manage the reporting and mounting of virtual device resources, and to isolate users from directly accessing real device resources when using device resources, in order to improve security.

[0041] Accordingly, a resource usage request specifically refers to a request for the system container to use device resources to complete program development. In other words, through a resource usage request, it can be made clear that the developer needs to use the development environment provided by the system container. Accordingly, the system container specifically refers to the file system that provides the developer with the required development environment. Accordingly, virtual device resources specifically refer to device files mapped according to real device files; wherein, real device files specifically refer to files corresponding to external hardware devices, such as files corresponding to input and output devices, files corresponding to keyboards, files corresponding to mice, etc., for the container to call to access data in the set storage space; it completes the generation of real device files by adding kernel components; accordingly, virtual device resources and real device resources have a one-to-one mapping relationship, which is used to support that when virtual device resources are called, real device resources can be used for the call request.

[0042] Based on this, when it is determined that the developer needs to use a system container for development in the current scenario, the system container that the developer needs to use will be determined based on the resource usage request submitted by the developer, and then virtual device resources will be allocated to the system container to subsequently support the system container to complete access to external data through virtual device resources.

[0043] Furthermore, considering that the addition of kernel components will change dynamically with the needs of the scenario, when a kernel component is added, it is also necessary to create a virtual device file for the device file generated by the kernel component to support subsequent mounting under the premise of security. In this embodiment, the specific implementation method is as follows:

[0044] When a new device resource is identified, resource information corresponding to the new device resource is determined; an initial virtual device resource is created for the new device resource according to the resource information, and the initial virtual device resource is added to a virtual device resource sequence; thereafter, the virtual device resource can be selected from the virtual device resource sequence in response to the resource usage request and allocated to the system container.

[0045] Specifically, the newly added device resources specifically refer to the newly added real device files identified by the resource management module. Accordingly, the resource information specifically refers to the collection of quantity information, device type information and / or device name information corresponding to the newly added device resources; accordingly, the initial virtual device resources specifically refer to the virtual device files created for the newly added device resources and have not yet been used; accordingly, the virtual device resource sequence specifically refers to the list used to manage all idle virtual device resources.

[0046] Based on this, when the resource management module identifies new device resources, it means that a kernel component has been added to the current scenario, and the kernel component has generated multiple device files. In order to support the use of the new device resources, the resource information corresponding to the new device resources can be determined first, and then the initial virtual device resources are created for the new device resources according to the resource information to establish a virtual mapping of the new device resources. The initial virtual device resources are then added to the virtual device resource list to support being called in the application stage.

[0047] On this basis, after the system container is determined in response to the resource usage request, the virtual device resources that meet the current usage requirements can be selected from the virtual device resource sequence according to the resource usage request and allocated to the system container to support the system container to use the allocated virtual device resources to complete subsequent data access processing.

[0048] This example uses the Safe FUSE Device Plugin as a resource management module to illustrate the data sharing method. Based on this, when a new kernel component generates 128 device files, the number and device information corresponding to these 128 newly added device files are determined. A virtual fuse device file, / dev / safefuse_x, is then created for the / dev / fuse device file. x ranges from 0 to 127, representing a group of devices responsible for security verification and system protection. During this process, upon discovering this group of devices, the Safe FUSE Device Plugin component reports its fluid.io / fuse as an extended resource to the Kubelet and exposes it to the Kubernetes cluster. A total of 128 devices are exposed to support Fuse Container use during the development phase.

[0049] In summary, by using the resource management module to report and manage virtual device resources, virtual mapping processing can be completed at the stage of adding resources, effectively ensuring the security of the management level.

[0050] Furthermore, after determining the system container corresponding to the resource usage request, virtual device resources will be allocated to the system container. In this process, considering that virtual device resources are virtual mapping objects established for real device resources, in order to support the system container to use resources to complete data access after allocating virtual device resources, allocation can be completed through virtual device identification. In this embodiment, the specific implementation method is as follows: Steps S1022 to S1024:

[0051] Step S1022: Determine resource allocation information corresponding to the system container in response to the resource usage request.

[0052] Specifically, resource allocation information refers to the allocation of virtual device resources for a system container. Different allocation information corresponds to different quantities and types of virtual device resources. Based on this, when a resource usage request is received, the system container that the developer needs to use is first determined. The number and type of resources required for the current scenario are also determined. This information then determines the resource allocation information for the system container, facilitating subsequent resource allocation processing.

[0053] Step S1024: Determine a virtual device identifier according to the resource allocation information, and allocate the virtual device resource corresponding to the virtual device identifier to the system container.

[0054] Specifically, after determining the resource allocation information, to ensure the rationality of resource allocation, a virtual device identifier can be first determined based on the resource allocation information. The virtual device resource corresponding to the virtual device identifier is then allocated to the system container. This allows the virtual device resource that meets the current usage scenario to be selected from the virtual device resource cluster for allocation. Specifically, the virtual device identifier refers to a unique identifier corresponding to each virtual device resource.

[0055] Furthermore, a virtual device identifier is determined according to the resource allocation information, and the virtual device resource corresponding to the virtual device identifier is allocated to the system container. The specific implementation is as follows:

[0056] The resource allocation function corresponding to the resource management module is called according to the resource allocation information, and virtual device resources are applied for through the resource allocation function; the virtual device identifier is determined according to the application result and fed back to the container management system; the virtual device identifier is added to the interface configuration request of the system container through the container management system; and the virtual device resources allocated to the system container are determined according to the interface configuration request with the virtual device identifier added.

[0057] Specifically, the resource allocation function refers to the function in the resource management module used to apply for appropriate resources for the system container; accordingly, the container management system is the kubelet system; accordingly, the interface configuration request refers to the CRI request created by the system container, which defines the service interface of the container and image. Because the container runtime and the image lifecycle are isolated from each other, two services need to be defined to configure the interface through this request.

[0058] Based on this, to properly allocate resources for the system container, the resource management module's corresponding resource allocation function can be called based on the resource allocation information. This function then requests virtual device resources that meet the current scenario's requirements. Based on the request result, the virtual device identifier corresponding to the requested virtual device resource can be determined and fed back to the container management system. The container management system can then add the virtual device identifier to the system container's interface configuration request. Finally, based on the interface configuration request with the virtual device identifier added, virtual device resources can be allocated to the system container.

[0059] Continuing with the above example, when the Safe FUSE Device Plugin component allocates a virtual fuse device to a Fuse Container, the Kubelet receives the Pod and node binding event, and then creates a real Pod entity on the node. Before starting the Fuse Container, the Kubelet first calls the Allocate method of the Safe FUSE Device Plugin. The Allocate method is used to inject the virtual device file required in the current scenario into the Fuse Container. The parameter of the Allocate method is the fluid.io / fuse requested by the Pod, which then determines the device's uuid as x. The Safe FUSE Device Plugin component then allocates the virtual fuse device file to be mounted, namely / dev / safefuse_x, to the Fuse Container based on the device's uuid (x). During the allocation process, the virtual fuse device file / dev / safefuse_x needs to be returned to the Kubelet. The Kubelet then adds the device information of the feedback virtual fuse device file to the CRI request for container creation to complete the allocation of the Fuse Container. At the same time, to achieve the purpose of achieving user-unawareness, the virtual fuse device file / dev / safefuse_x is still seen in the Fuse Container, mapping the fuse device file / dev / fuse.

[0060] In summary, when allocating virtual device resources to system containers, in order to support the system containers to use virtual device resources to complete data access, the virtual device resources can be determined in combination with the applied virtual device identifier, and resource allocation can be completed accordingly, which can ensure more reasonable resource allocation and higher utilization.

[0061] Step S104 : Mount the virtual device resources on the host corresponding to the system container and the system container in sequence, and update the resource mounting directory of the host according to the mounting result.

[0062] Specifically, after determining the system container and allocating virtual device resources to the system container, in order to enable the system container to complete data access based on the allocated virtual device resources, the host to which the system container belongs is first determined, and then the virtual device resources are mounted on the host. The virtual device resources are then mounted on the system container. At the same time, the host's resource mount directory is updated to facilitate subsequent mounting to the application container during the sharing phase, supporting data access by the application container. The host refers to the host machine to which the system container belongs; correspondingly, the resource mount directory refers to the folder where the host mounts the virtual device resources, used to store virtual device files.

[0063] Furthermore, in order to enable subsequent application containers to access target data in the same way as system containers, it is necessary to first mount virtual device resources on the host. In this embodiment, the specific implementation is as follows: Steps S1042 to S1044:

[0064] Step S1042 : determining a virtual device identification list corresponding to the virtual device resource, and determining a device path corresponding to the virtual device resource and a mount path corresponding to the host according to the virtual device identification list.

[0065] Specifically, the virtual device identification list specifically refers to a list of unique identifiers corresponding to the virtual device resources allocated to the system container; correspondingly, the device path specifically refers to the real path corresponding to the virtual device file; correspondingly, the mount path specifically refers to the path where the host mounts the virtual device file.

[0066] Based on this, in order to support the resource management module to mount virtual device resources on the host to support subsequent use; the virtual device identification list corresponding to the virtual device resources can be determined first, and then the device path corresponding to the virtual device resources and the mount path corresponding to the host can be reversed according to the virtual device identification list, so as to facilitate the subsequent combination of the device path and the mount path to complete the mounting of the virtual resources on the host.

[0067] Step S1044: Mount the virtual device resource on the host according to the device path and the mount path.

[0068] Specifically, after determining the device path and mount path according to the virtual device list as mentioned above, the folder path for storing the virtual device resources allocated to the system container and the folder path for the host to mount these virtual device resources are actually determined according to the virtual device resource list. On this basis, the virtual device resources allocated to the system container are mounted on the host according to the mount path, so that when the application container is called, the virtual device resources can be called by mounting the host's resource mount directory to complete data access.

[0069] Furthermore, the virtual device resource is mounted on the host, and the specific implementation method is as follows:

[0070] Determine the system container information corresponding to the system container, and query the resource mounting directory of the host according to the system container information; add the virtual device identifier included in the virtual device identifier list to the resource mounting directory as the virtual device resource mounted on the host.

[0071] Specifically, the system container information specifically refers to information corresponding to the system container, which is used to record the directory location where the system container can mount virtual device resources.

[0072] Based on this, when mounting virtual device resources on the host, in order to ensure that they can be used by application containers later, the system container information corresponding to the system container will be determined first, and then the host's resource mounting directory will be queried based on the system container information. After determining the resource mounting directory based on the query results, it means that as long as the virtual device file is written to the directory, the virtual device resource can be mounted on the host; therefore, the virtual device identifier contained in the virtual device identifier list can be added to the resource mounting directory as a virtual device resource mounted on the host to support subsequent use.

[0073] After the host completes mounting the virtual device resources, further, in order to support the system container to respond to development requests for developers to apply, virtual device resources from the same source will also be mounted to facilitate subsequent use by the application container. In this embodiment, the specific implementation method is: adding the virtual device resources to the system container, and using the addition result as the virtual device resource mounted in the system container.

[0074] Based on this, adding virtual device resources to the system container refers to injecting the virtual device resources into the system container, so that the system container can call the virtual device resources to complete access to external data.

[0075] In summary, by mounting virtual device resources on the host, the application container can be supported to mount the resource mounting directory corresponding to the host, so that during the application stage, the application container can call the virtual device resources just like the system container to complete the access to external data.

[0076] Step S106: Utilize the target process associated with the system container to call the virtual device resource to access target data.

[0077] Specifically, after the virtual device resources are mounted on the host first and then on the system container, developers can use the system container for development by invoking the virtual device resources to access target data through the target process associated with the system container to meet the current development scenario. The target data specifically refers to external data that needs to be accessed during the development phase to meet the current development scenario. Access to the target data can be selected based on the actual application scenario and is not limited in this embodiment.

[0078] Furthermore, when the system container accesses the target data, it actually does so when a data access event is triggered. That is, when access to external data is needed to meet development requirements during the development phase, resources can be called to complete data access. In this embodiment, the specific implementation is as follows:

[0079] Receive a data access event submitted for the system container, wherein the data access event is used to access data in the object storage space; associate the target process with the system container according to the data access event; and in response to the data access event, call the virtual device resource through the target process to access the target data in the object storage space.

[0080] Specifically, a data access event refers to an event in which a developer needs to access published data during the development phase using a system container. Accordingly, an object storage space refers to the space used to store data required for the current development scenario. Object storage space varies in different scenarios and is not limited in this embodiment. Accordingly, a target process refers to a process capable of handling data access events.

[0081] Based on this, after receiving a data access event submitted to the system container, it indicates that the current scenario requires access to external data to complete development. At this time, the target process can be associated with the system container according to the data access event. At the same time, in response to the data access event, the virtual device resources are called through the target process to access the target data in the object storage space for use in the application in the current development scenario.

[0082] In summary, by allowing the system container and the host to mount virtual device resources with the same source, mount point sharing can be achieved, meeting data sharing in security scenarios and facilitating users to call resources for applications more flexibly.

[0083] Continuing with the previous example, when the Safe FUSE Device Plugin executes mount.fuse on the host to mount the virtual fuse device file, it relies on the virtual device's real path, / dev / safefuse_x, and the host's mount path. Therefore, it determines the real and mount paths based on the device ID list corresponding to the virtual fuse device file assigned to the Fuse Container. The virtual fuse device file is then mounted on the host according to the real and mount paths.

[0084] Furthermore, before the Fuse Container is actually started, Kubelet first calls the lifecycle function of the Safe FUSE DevicePlugin component (PreStartContainer, which is used to inject the virtual fuse device file into the container). The parameter passed to the PreStartContainer method is the list of device IDs assigned to the Fuse Container during the device allocation phase, DevicesIDs. This list is used to complete the host mounting. During this process, PreStartContainer completes the mounting through the following operations:

[0085] The corresponding virtual fuse device file is found according to the device ID list. If the ID is x, the corresponding file is / dev / safefuse_x. Secondly, the ID cooperates with PodResourcesListerClient and PodClient to query the corresponding Fuse Container information, and the host's mount directory can be obtained through environment variables. At this time, you can consider injecting the Dataset name into the Fuse Pod as an environment variable. According to the determination result, the host mount directory mount_path is clearly defined as / runtime-mnt / alluxio / default / hbase (where namespace is default and dataset name is hbase). Finally, if the Safe FUSE Device Plugin component executes the pseudocode {fd=open( / dev / safefuse_x)mount.fuse--fd=fd / runtime-mnt / alluxio / default / hbase}, it indicates that the host has mounted the virtual fuse device file.

[0086] Furthermore, after the host is mounted, the Fuse Container will execute mount.fuse again to mount the same virtual fuse device file. During this process, since the Safe FUSE Device Plugin component passes the virtual fuse device file / dev / safefuse_x on the host to the Fuse Container in the form of / dev / fuse, the / dev / fuse seen in the Fuse Container is actually the virtual fuse device file / dev / safefuse_x. Therefore, this process does not require any modification for the user. The internal logic of the Fuse Container is to execute the following pseudo code {fd=open( / dev / fuse)mount.fuse--fd=fd--userid=xxx--groupid=xxx; 3.start_fuse_server(fd)}; At the same time, considering that a process is required to handle the event later, the handler that actually handles the event (jindo-fuse, alluxio-fuse and other programs) will also be associated; that is, the mount.fuse of the Fuse Container needs to start the real fuse handler, and the Safe FUSE Device There is no need to call start_fuse_server in the PrestartContainer in the Plugin component.

[0087] Step S108 : When a sharing event is monitored, the updated resource mount directory is mounted to the application container associated with the system container for accessing the target data.

[0088] Specifically, when a sharing event is received, it means that the developer has completed the development in the system container, and the developed project actually needs to be used in the application environment. Therefore, in order to simulate the performance in the application environment, it is necessary to first determine the application container associated with the system container, and then mount the updated resource mount directory of the host to the application container, so that the application container can access the target data during the simulation phase.

[0089] Furthermore, the updated resource mount directory is mounted to the application container associated with the system container for accessing the target data, and the specific implementation is as follows:

[0090] Determine the application container associated with the system container, and mount the updated resource mount directory to the application container according to a preset mount policy; and in response to the sharing event, call the virtual device resource through the application container to access the target data.

[0091] Based on this, an application container capable of simulating the application environment and associated with the system container is first identified. The updated resource mount directory on the host is then mounted onto the application container according to a preset mount policy. This allows the application container to respond to sharing events and access the target data by invoking the virtual device resources through the application container. The mount policy, which uses a bind mount method, is used to mount files and directories on the host onto the application container. The data on the application container is readable and writable by the host and all containers mounted to it.

[0092] Continuing with the previous example, to achieve data sharing, the App Container can mount a host directory to access the data. In other words, the App Container only needs to bind mount the host directory mount_path / runtime-mnt / alluxio / default / hbase to the App Container to complete data sharing.

[0093] See also Figure 2 As shown in the diagram, the Safe FUSE Device Plugin (resource management module) component first identifies and reports the number of virtual fuse devices to Kubelet (container management system). Next, it allocates virtual fuse devices to the Fuse Container (system container). After allocation, mount.fuse is executed on the host to mount the virtual fuse device. Mount.fuse is then executed again through the Fuse Container to mount the virtual fuse device on the host. Finally, in the application phase, the directory generated on the host is mounted on the App Container (application container) to achieve data sharing.

[0094] The data sharing method provided in this specification supports the sharing of the mount point of the system container with the application container in order to ensure data security. The system container can be determined in response to a resource usage request, and virtual device resources can be allocated to the system container. After the resource allocation is completed, the virtual device resources can be mounted on the host to which the system container belongs, and the resource mount directory of the host can be updated at the same time; secondly, the virtual device resources can be mounted on the system container. At this time, the target process associated with the system container can be used to call the virtual device resources to access the target data. When a sharing event is received, it indicates that the container has been switched. In order to support the application container associated with the system container to access the data normally without causing security risks, the updated resource mount directory can be mounted to the application container to support the application container to access the target data normally. The purpose of device sharing is achieved through a permission reduction strategy to support application containers to access target data, effectively ensuring data security.

[0095] The following combined Figure 3 , taking the application of the data sharing method provided in this specification in a development scenario as an example, the data sharing method is further explained. Figure 3 A flow chart of the processing process of a data sharing method provided in one embodiment of this specification is shown, which specifically includes the following steps.

[0096] Step S302: When a new device resource is identified, resource information corresponding to the new device resource is determined.

[0097] Step S304: creating an initial virtual device resource for the newly added device resource according to the resource information, and adding the initial virtual device resource to the virtual device resource sequence.

[0098] Step S306 : determining a system container in response to the resource usage request, selecting a virtual device resource from a virtual device resource sequence, and allocating the resource to the system container.

[0099] Step S308 : determining a virtual device identification list corresponding to the virtual device resource, and determining a device path corresponding to the virtual device resource and a mount path corresponding to the host according to the virtual device identification list.

[0100] Step S310: Mount the virtual device resource on the host according to the device path and the mount path.

[0101] Specifically, the system container information corresponding to the system container is determined, and the resource mounting directory of the host is queried according to the system container information; the virtual device identifier included in the virtual device identifier list is added to the resource mounting directory as a virtual device resource mounted on the host.

[0102] Step S312: Add the virtual device resource to the system container, and use the addition result as the virtual device resource mounted in the system container.

[0103] Step S314: receiving a data access event submitted to the system container, where the data access event is used to access data in the object storage space.

[0104] Step S316: Associating the target process with the system container according to the data access event.

[0105] Step S318 , in response to the data access event, access the target data in the object storage space by calling the virtual device resource through the target process.

[0106] Step S320: Determine the application container associated with the system container, and mount the updated resource mount directory to the application container according to a preset mount policy.

[0107] Step S322 : In response to the sharing event, the application container calls the virtual device resource to access the target data.

[0108] In summary, in order to ensure data security while supporting the sharing of the mount point of the system container with the application container, the system container can be determined in response to a resource usage request, and virtual device resources can be allocated to the system container. After the resource allocation is completed, the virtual device resources can be mounted on the host to which the system container belongs, and the resource mount directory of the host is updated at the same time; secondly, the virtual device resources can be mounted on the system container. At this time, the target process associated with the system container can be used to call the virtual device resources to access the target data. When a sharing event is received, it indicates that the container has switched. In order to support the application container associated with the system container to access the data normally without causing security risks, the updated resource mount directory can be mounted to the application container to support the application container to access the target data normally. The purpose of device sharing is achieved through a permission reduction strategy to support application containers to access target data, effectively ensuring data security.

[0109] Corresponding to the above method embodiment, this specification also provides a data sharing device embodiment, Figure 4 FIG1 shows a schematic diagram of a data sharing device provided by an embodiment of this specification. Figure 4 As shown, the device includes:

[0110] an allocating unit 402 configured to determine a system container in response to a resource usage request and allocate virtual device resources to the system container;

[0111] The mounting unit 404 is configured to sequentially mount the virtual device resources on the host corresponding to the system container and the system container, and update the resource mounting directory of the host according to the mounting result;

[0112] An access unit 406 is configured to use a target process associated with the system container to call the virtual device resource to access target data;

[0113] The sharing unit 408 is configured to, when a sharing event is monitored, mount the updated resource mounting directory to the application container associated with the system container for accessing the target data.

[0114] In an optional embodiment, the data sharing device further includes:

[0115] an identification unit configured to, upon identifying a newly added device resource, determine resource information corresponding to the newly added device resource; create an initial virtual device resource for the newly added device resource according to the resource information, and add the initial virtual device resource to a virtual device resource sequence;

[0116] Accordingly, the allocating unit 402 is further configured to:

[0117] In response to the resource usage request, the virtual device resource is selected from the virtual device resource sequence and allocated to the system container.

[0118] In an optional embodiment, the allocating unit 402 is further configured to:

[0119] In response to the resource usage request, resource allocation information corresponding to the system container is determined; a virtual device identifier is determined according to the resource allocation information, and the virtual device resource corresponding to the virtual device identifier is allocated to the system container.

[0120] In an optional embodiment, the allocating unit 402 is further configured to:

[0121] The resource allocation function corresponding to the resource management module is called according to the resource allocation information, and virtual device resources are applied for through the resource allocation function; the virtual device identifier is determined according to the application result and fed back to the container management system; the virtual device identifier is added to the interface configuration request of the system container through the container management system; and the virtual device resources allocated to the system container are determined according to the interface configuration request with the virtual device identifier added.

[0122] In an optional embodiment, the mounting unit 404 is further configured to:

[0123] Determine a virtual device identification list corresponding to the virtual device resource, and determine a device path corresponding to the virtual device resource and a mount path corresponding to the host according to the virtual device identification list; and mount the virtual device resource on the host according to the device path and the mount path.

[0124] In an optional embodiment, the mounting unit 404 is further configured to:

[0125] Determine the system container information corresponding to the system container, and query the resource mounting directory of the host according to the system container information; add the virtual device identifier included in the virtual device identifier list to the resource mounting directory as the virtual device resource mounted on the host.

[0126] In an optional embodiment, the mounting unit 404 is further configured to:

[0127] The virtual device resource is added to the system container, and the addition result is used as the virtual device resource mounted in the system container.

[0128] In an optional embodiment, the access unit 406 is further configured to:

[0129] Receive a data access event submitted for the system container, wherein the data access event is used to access data in the object storage space; associate the target process with the system container according to the data access event; and in response to the data access event, call the virtual device resource through the target process to access the target data in the object storage space.

[0130] In an optional embodiment, the sharing unit 408 is further configured to:

[0131] Determine the application container associated with the system container, and mount the updated resource mount directory to the application container according to a preset mount policy; and in response to the sharing event, call the virtual device resource through the application container to access the target data.

[0132] The data sharing device provided in this specification can support the sharing of the mount point of the system container with the application container in order to ensure data security. It can determine the system container in response to a resource usage request and allocate virtual device resources to the system container. After the resource allocation is completed, the virtual device resources can be mounted on the host to which the system container belongs, and the resource mount directory of the host can be updated at the same time; secondly, the virtual device resources can be mounted on the system container. At this time, the target process associated with the system container can be used to call the virtual device resources to access the target data. When a sharing event is received, it indicates that the container has switched. In order to support the application container associated with the system container to access the data normally without causing security risks, the updated resource mount directory can be mounted to the application container to support the application container to access the target data normally. The purpose of device sharing is achieved through a permission reduction strategy to support application containers to access target data, effectively ensuring data security.

[0133] The above is a schematic scheme of a data sharing device of this embodiment. It should be noted that the technical scheme of the data sharing device and the technical scheme of the above-mentioned data sharing method are of the same concept. For details not described in detail in the technical scheme of the data sharing device, please refer to the description of the technical scheme of the above-mentioned data sharing method.

[0134] Figure 5 The block diagram of a computing device 500 according to one embodiment of the present disclosure is shown. Components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and a database 550 is used to store data.

[0135] The computing device 500 also includes an access device 540 that enables the computing device 500 to communicate via one or more networks 560. Examples of such networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 540 may include one or more of any type of network interface (e.g., a network interface card (NIC)), whether wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, a near field communication (NFC) interface, and the like.

[0136] In one embodiment of the present specification, the above components of the computing device 500 and Figure 5 Other components not shown in the figure may also be connected to each other, for example, via a bus. Figure 5 The computing device structure block diagram shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art may add or replace other components as needed.

[0137] Computing device 500 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook computer, etc.), a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smartwatch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or PC. Computing device 500 can also be a mobile or stationary server.

[0138] The processor 520 is configured to execute the following computer-executable instructions, which implement the steps of the above-mentioned data sharing method when executed by the processor.

[0139] The above is a schematic scheme of a computing device of this embodiment. It should be noted that the technical solution of the computing device and the technical solution of the above-mentioned data sharing method are of the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-mentioned data sharing method.

[0140] An embodiment of the present specification further provides a computer-readable storage medium storing computer-executable instructions, which implement the steps of the above-mentioned data sharing method when executed by a processor.

[0141] The above is a schematic scheme of a computer-readable storage medium of this embodiment. It should be noted that the technical scheme of this storage medium and the technical scheme of the above-mentioned data sharing method are based on the same concept. For details not described in detail in the technical scheme of the storage medium, please refer to the description of the technical scheme of the above-mentioned data sharing method.

[0142] An embodiment of the present specification further provides a computer program, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned data sharing method.

[0143] The above is an illustrative solution of a computer program of this embodiment. It should be noted that the technical solution of the computer program and the technical solution of the above-mentioned data sharing method are of the same concept. For details not described in detail in the technical solution of the computer program, please refer to the description of the technical solution of the above-mentioned data sharing method.

[0144] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0145] The computer instructions include computer program code, which may be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0146] It should be noted that for the aforementioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0147] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0148] The preferred embodiments disclosed above are intended only to help illustrate this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and variations can be made based on the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that those skilled in the art can better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A data sharing method, applied to a resource management module, comprising: determining a system container in response to the resource usage request and allocating virtual device resources to the system container; Mounting the virtual device resources on the host corresponding to the system container and the system container in sequence, and updating the resource mounting directory of the host according to the mounting result, wherein the resource mounting directory is used to store virtual device files; Using the target process associated with the system container to call the virtual device resource to access target data; In the case of monitoring a sharing event, the updated resource mounting directory is mounted to the application container associated with the system container, and the application container accesses the target data based on the virtual device file during the simulation phase.

2. The method according to claim 1, before executing the step of determining the system container in response to the resource usage request, further comprising: When a new device resource is identified, determining resource information corresponding to the new device resource; Creating an initial virtual device resource for the newly added device resource according to the resource information, and adding the initial virtual device resource to a virtual device resource sequence; Accordingly, allocating virtual device resources to the system container includes: In response to the resource usage request, the virtual device resource is selected from the virtual device resource sequence and allocated to the system container.

3. The method according to claim 1, wherein allocating virtual device resources to the system container comprises: determining resource allocation information corresponding to the system container in response to the resource usage request; A virtual device identifier is determined according to the resource allocation information, and the virtual device resource corresponding to the virtual device identifier is allocated to the system container.

4. The method according to claim 3, wherein determining the virtual device identifier according to the resource allocation information and allocating the virtual device resource corresponding to the virtual device identifier to the system container comprises: Calling a resource allocation function corresponding to the resource management module according to the resource allocation information, and applying for virtual device resources through the resource allocation function; Determine the virtual device identifier based on the application result and feed it back to the container management system; adding the virtual device identifier to the interface configuration request of the system container via the container management system; The virtual device resources allocated to the system container are determined according to the interface configuration request to which the virtual device identifier is added.

5. The method according to claim 1, wherein mounting the virtual device resource on the host corresponding to the system container comprises: Determine a virtual device identification list corresponding to the virtual device resource, and determine a device path corresponding to the virtual device resource and a mount path corresponding to the host according to the virtual device identification list; The virtual device resource is mounted on the host according to the device path and the mount path.

6. The method according to claim 5, wherein mounting the virtual device resource on the host comprises: Determine system container information corresponding to the system container, and query the resource mount directory of the host according to the system container information; The virtual device identifier included in the virtual device identifier list is added to the resource mounting directory to mount the virtual device resource on the host.

7. The method according to claim 1, wherein mounting the virtual device resource on the system container comprises: The virtual device resource is added to the system container, and the addition result is used as the virtual device resource mounted in the system container.

8. The method according to claim 1, wherein the step of utilizing the target process associated with the system container to call the virtual device resource to access target data comprises: receiving a data access event submitted for the system container, wherein the data access event is used to access data in the object storage space; Associating the target process with the system container according to the data access event; In response to the data access event, the target process calls the virtual device resource to access the target data in the object storage space.

9. The method according to claim 1, wherein mounting the updated resource mount directory to the application container associated with the system container, and the application container accessing the target data based on the virtual device file during the simulation phase, comprises: Determine the application container associated with the system container, and mount the updated resource mount directory to the application container according to a preset mount policy; In response to the sharing event, the application container calls the virtual device resource based on the virtual device file at the simulation node to access the target data.

10. A data sharing device, applied to a resource management module, comprising: an allocation unit configured to determine a system container in response to a resource usage request and allocate virtual device resources to the system container; a mounting unit configured to sequentially mount the virtual device resource on the host corresponding to the system container and the system container, and update a resource mounting directory of the host according to the mounting result, wherein the resource mounting directory is used to store virtual device files; An access unit is configured to utilize a target process associated with the system container to call the virtual device resource to access target data; The sharing unit is configured to mount the updated resource mounting directory to the application container associated with the system container when a sharing event is monitored, and the application container accesses the target data based on the virtual device file during the simulation phase.

11. A computing device comprising: memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the method according to any one of claims 1 to 9 are implemented.

12. A computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the steps of the method according to any one of claims 1 to 9.

Images