Equipment access control method for multi-container application

Abstract

The invention belongs to the technical field of computer system software, and particularly relates to an equipment access control method for a multi-container application. A device receives a lock request from a first instance of an application executing in a first container of a containerized environment, the lock request associated with an embedded device using the containerized environment. The device performs a lock operation of the embedded device to allow a first instance of the application to use the embedded device and to prevent a second instance of the application executing in a second container of the containerized environment from using the embedded device. The device monitors usage of the embedded device during an access operation of a first instance of the application to detect an unlock event with unlocking the embedded device. The device executes the unlocking operation based on the detected unlocking event so as to allow the second instance of the application program to use the embedded device, and the access control method and device can solve the access control problem of the multiple container applications to the shared device.

Description

Technical Field

[0001] The present invention belongs to the technical field of computer system software, and in particular relates to a device access control method for multi-container applications. Background Art

[0002] Containers are a form of virtualization that isolate applications from each other and run them in user space, sharing the operating system kernel. Containers simulate application instances that are isolated from other containers. Containers include applications and their associated configuration files, libraries, and dependencies required for applications to run in a computing environment. Summary of the invention

[0003] In view of this, the present invention provides a device access control method for multiple container applications, which can solve the access control problem of multiple container applications to a shared device.

[0004] The technical solution of the present invention is:

[0005] A device access control method for multi-container applications:

[0006] A device receives a lock request for an embedded device using a containerized environment, wherein the lock request is associated with a first instance of a first application executed in a first container of the containerized environment; the device performs a lock operation on the embedded device to allow the first instance of the first application to use the embedded device and prevent a second instance of a second application from using the embedded device, wherein the second instance of the second application is executed in a second container of the containerized environment; a lock manager monitors whether the embedded device is used during a device access operation of the first instance, and the first application detects and unlocks an unlock event of the embedded device; the lock manager performs an unlock operation based on detecting the unlock event to allow the second instance of the second application to use the embedded device.

[0007] Further, the lock request is received based on an operating environment in a container; the operating environment is associated with the embedded device and is configured to allow a first instance of the first application to communicate with the embedded device during a device access operation.

[0008] Further, before performing the locking operation, the lock manager verifies that the embedded device is not locked based on another locking request received from a third instance of a third application operating in a container different from the first container and the second container, wherein the locking operation is performed on the premise of verifying that the embedded device is not locked.

[0009] Further, before performing the locking operation, the embedded device is identified based on the locking request, where the locking request is used to identify the following information: the type of the embedded device and the device ID of the embedded device.

[0010] Furthermore, the locking request identifies the type of the embedded device, and the specific process of performing the locking operation includes: based on the device type identified in the locking request, allowing a first instance of a first application to use the embedded device, and preventing a second instance of a second application from using the embedded device.

[0011] Further, monitoring the usage of the embedded device includes:

[0012] Based on receiving the lock request, maintaining a session ID of the first instance of the first application in a device management data structure;

[0013] Deny lock management requests from embedded devices until an unlock event is detected;

[0014] detecting an unlock event based on receiving an unlock request from the first instance of the first application;

[0015] The unlock request includes the session ID of the first instance of the first application and the device ID of the embedded device.

[0016] Further, monitoring the usage of the embedded device includes:

[0017] maintaining a session ID and a timer for a first instance of a first application in a device management data structure;

[0018] rejecting a lock management request received from the embedded device during a time defined by the timer;

[0019] In the case where no lock management request is received, an unlock event is detected based on the expiration time.

[0020] Beneficial effects of the present invention:

[0021] The present invention can solve the problem of access control of multiple container applications to a shared device. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0023] Figure 1 : Example implementations of the invention described;

[0024] Figure 2 : Example implementations of the invention described;

[0025] Figure 3 : Example implementations of the invention described;

[0026] Figure 4 : Example implementations of the invention described;

[0027] Figure 5 : An example diagram for implementing the method described in the present invention;

[0028] Figure 6 : Flowchart of device access control for multiple container applications. DETAILED DESCRIPTION

[0029] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0030] The following describes the embodiments of the present disclosure through specific examples, and those skilled in the art can easily understand other advantages and effects of the present disclosure from the contents disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. The present disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present disclosure.

[0031] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein can be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on the present disclosure, it should be understood by those skilled in the art that an aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects described herein can be used to implement the device and / or practice the method. In addition, other structures and / or functionalities other than one or more of the aspects described herein can be used to implement this device and / or practice this method.

[0032] It should also be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present disclosure. The illustrations only show components related to the present disclosure rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0033] Additionally, in the following description, specific details are provided to facilitate a thorough understanding of the examples. However, it will be understood by those skilled in the art that the aspects described may be practiced without these specific details.

[0034] The present invention provides a device access control method for a multi-container application, and the described implementation involves a lock manager that controls access to shared resources of an embedded device. The lock manager receives a lock request related to the use of a shared device. The lock request is associated with a first instance of an application executed in a first container of a containerized environment associated with the lock manager. The lock manager performs a lock operation on the shared device based on receiving the lock request. The lock operation allows the first instance of the application to use the embedded device, and prevents the second instance of the application executed in a second container from using the embedded device. The lock manager monitors the use of the shared device during the device access operation of the first instance of the application to detect an unlock event of the shared device. The lock manager performs an unlock operation based on detecting the unlock event to unlock the shared device and allow the second instance of the application to use the shared device.

[0035] In this manner, the lock manager can prevent concurrent access to a shared device by multiple instances of an application, or instances of different applications. By preventing concurrent access to a shared device, the lock manager can prevent an operation associated with a first instance of an application from being overwritten, modified, etc., by an operation associated with a second instance of the application, thereby saving resources (e.g., computing resources, storage resources, communication resources, etc.) that would otherwise be used to re-execute the operation associated with the first instance of the application.

[0036] Concurrent access to a shared device may result in programming errors of the device, and therefore, the shared device will not be able to perform the desired function. Furthermore, the consequences of such programming errors of a shared device are serious. For example, programming errors of a shared device may result in data packets being dropped, data packets being misrouted, link failures, etc. Recovering from the consequences of programming errors of a shared device may be complicated. For example, recovery may require reinitialization of the shared device, rebooting of the system of the shared device, etc., resulting in a waste of computing resources used to recover from the consequences of the error.

[0037] The lock manager can use lock mechanisms to prevent two or more applications from accessing a shared device at the same time.

[0038] like Figure 1 As shown, the lock manager is configured to control access to a device group in a containerized environment. Implementations include:

[0039] 1. The lock manager is configured to control access to the device group based on access information thereof. The access information includes information identifying the shared device to which access is to be controlled (e.g., device ID), information identifying the number of locks to be used by the lock manager (e.g., one lock per shared device), a set of shared devices in the shared device group, information identifying the type of lock used by the lock manager (e.g., semaphore, mutex), information identifying the type of shared device to which access is to be controlled, etc.

[0040] 2. The lock manager determines access information based on the characteristics of the embedded device. For example, the lock manager determines access information based on determining that the shared device will be accessed simultaneously, based on the type of shared device included in the embedded device, based on the type of embedded device (e.g., router, switch, etc.), based on the function performed by the shared device (e.g., routing function, switching function), etc.

[0041] The lock manager allocates locks to a group of shared devices based on the access information. For example, the access information indicates that a corresponding lock will be used for each shared device in the shared device group. The lock manager allocates a corresponding lock to each shared device based on the access information indicating that the corresponding lock will be used for each shared device.

[0042] The lock manager provides information identifying the assigned lock to the application based on the assigned lock. The lock manager determines that the application is configured to access a shared device in the shared device group. The lock manager identifies the lock assigned to the shared device and can provide information associated with the lock to the application.

[0043] like Figure 2 As shown, the lock manager receives a lock request involving the use of a shared device. The lock request is associated with a first container (e.g., container A, such as Figure 2 ) executed in an application (e.g., Figure 2 The lock manager receives the lock request based on the instance of the application that initiates the use of the shared device. For example, the lock manager receives the lock request based on the instance of the application that initiates the access operation (e.g., write operation, read operation, etc.) of the shared device.

[0044] The lock manager obtains the lock from the runtime environment associated with the instance of the application (e.g., runtime X, such as Figure 2 The instance of the application determines to perform an access operation on the shared device. The instance of the application causes the operating environment to provide a lock request to the lock manager to request a lock from the lock manager based on the determination to perform the access operation. The lock request includes information identifying the shared device (e.g., a shared device ID), information identifying the type of the shared device, information identifying the number of shared devices, information identifying the shared device, the instance of the application, information identifying the operating environment, etc.

[0045] The lock manager receives the lock request and determines the shared device associated with the lock request in the group of shared devices. For example, the lock request includes information identifying the shared device ID, and the lock manager can identify the shared device based on the ID.

[0046] like Figure 3 As shown, the shared devices determined by the lock manager include a group of shared devices. For example, the lock request includes information identifying a type of shared device (e.g., type X). The lock manager identifies a group of shared devices in the group of shared devices (e.g., shared device 1 and shared device 3, such as Figure 3 ), including the type of shared device.

[0047] Implementation methods include:

[0048] 1. The lock manager verifies that the shared device is not locked based on the following information: another lock request received from a different instance of the application and a different runtime environment running in a different container. The lock manager verifies that the shared device is not locked based on determining the shared device and the unlocked state.

[0049] 2. The lock manager determines the shared device and unlock status based on information included in a data structure (eg, a list) associated with the lock manager.

[0050] The lock manager performs a lock operation on the shared device based on verifying that the shared device is unlocked. The lock operation allows the instance of the application to utilize the shared device to perform the operation. The lock operation can prevent another instance of the application executing in another container from using the shared device.

[0051] 3. The locking operation includes providing a lock of a shared device to the instance of the application. For example, the lock manager provides the instance of the application with information indicating that the lock request is approved, information indicating that the instance of the application is allowed to perform the operation, information identifying the shared device, the time when the shared device will be locked, etc.

[0052] 4. The locking operation includes updating the state of the shared device. For example, the lock manager stores information indicating that the state of the shared device is locked, information identifying the application instance, and information identifying the container associated with the application instance in a data structure. The time when the shared device is locked, information identifying the session ID associated with the application and the instance of the operation, information identifying the number of times the shared device is locked and unlocked within a period of time, and information identifying the number of times the application is prevented from accessing the shared device based on the shared device being locked.

[0053] The instance of the application performs an operation of the shared device based on the lock manager performing the locking operation. For example, the instance of the application performs an operation based on receiving a lock from the lock manager and based on the state of the shared device being updated.

[0054] The lock manager prevents other instances of the application from accessing the shared device. The lock manager prevents another instance of the application from accessing the shared device during operation by rejecting a lock request received from another instance of the application. The other instance of the application may be executed in a different container (e.g., container C, such as Figure 1 The lock manager may provide a lock request for the shared device to the lock manager. The lock manager identifies the shared device based on information included in the lock request. The lock manager determines that the shared device is locked based on information included in the data structure indicating that the shared device is locked. The shared device state is locked. The lock manager denies the lock request based on the locked state of the shared device to prevent another instance of the application from accessing the shared device.

[0055] Implementation methods include:

[0056] 1. The lock manager causes another instance of the application to wait for access to the shared device. The lock manager stores information identifying the other instances of the application in a data structure. The data structure may store a list of applications waiting to access the shared device, the time at which the application provided lock requests associated with accessing the shared device, and the order in which the lock manager received the lock requests. When an unlock event of the shared device is detected and the shared device is unlocked, the lock manager uses the information stored in the data structure to allow the instance of the application waiting to access the shared device to access the shared device.

[0057] 2. Multiple instances of an application are waiting to access a shared device. The lock manager allows multiple instances of an application to access the shared device based on a first-come, first-served policy. The lock manager provides a lock to an instance of the application based on the first instance of the application that requests a lock for the shared device. The lock manager subsequently provides locks to multiple instances of the application in a similar manner based on the order in which the multiple instances of the application request a lock for the shared device.

[0058] like Figure 4 As shown, the lock manager detects an unlock event of a shared device.

[0059] Implementation methods include:

[0060] 1. The lock manager detects an unlock event based on monitoring the use of the shared device by the instance of the application. For example, the lock manager detects an unlock event based on determining that the instance of the application is unresponsive, based on determining the occurrence of an error associated with the instance of the application and the operation, based on determining the expiration of a time associated with the operation and the lock, etc.

[0061] 2. The lock manager detects an unlock event based on information received from the instance of the application and the runtime environment. For example, the runtime environment provides an unlock request to the lock manager based on the instance of the application completing the operation.

[0062] 3. The lock manager detects an unlock event based on determining that the application has crashed, failed, stopped executing, etc. For example, an instance of an application acquires a lock and crashes before releasing the lock. The lock manager detects the crash of the application and automatically unlocks the shared device.

[0063] The lock manager performs the unlock operation of the embedded device. The lock manager performs the unlock operation based on detecting the unlock event, allowing other instances of the application to access the shared device. The unlock operation includes updating the state of the shared device to indicate that it is unlocked and providing information that the shared device is unlocked to the instance of the application.

[0064] In this manner, the lock manager controls access to a shared device by instances of an application executed in a set of containers included in a containerized environment. By controlling access to a shared device, the lock manager can prevent concurrent access to the shared device by multiple instances of an application executed in different containers of the containerized environment.

[0065] like Figure 5 As shown, the lock manager includes various components of the cloud computing system.

[0066] The cloud computing system includes a hardware platform, a resource management component, and a virtual computing system. The resource management component performs virtualization (e.g., abstraction of the hardware platform) to create individual virtual computing systems. Using virtualization, the resource management component enables a single computing device to operate multiple computing devices by creating multiple isolated virtual computing systems from the hardware platform of a single computing device. In this way, the hardware platform can be operated more efficiently than using separate computing devices, with lower power consumption, higher reliability, availability and utilization, greater flexibility, and lower cost.

[0067] The hardware platform includes processors, memory, external storage components, and network components.

[0068] The resource management component can virtualize the hardware platform to start, stop and manage virtualized applications of the virtual computing system.

[0069] The virtual computing system includes virtual machines, containers, and containers of virtual machine models, which can execute applications using a file system that includes binary files, software libraries, and other resources required to execute applications on a client operating system.

[0070] Networking enables communication between devices in a containerized environment.

[0071] Embedded devices include devices that are capable of receiving, generating, storing, processing, and providing information associated with device access control for multiple container applications, such as routers and switches.

[0072] like Figure 6 As shown,

[0073] Step 1: Receive a lock request using an embedded device in a containerized environment, wherein the lock request is associated with a first instance of a first application executed in a first container in the containerized environment.

[0074] Implementation methods include:

[0075] 1. A lock request is associated with a first instance of a first application executing in a first container of a containerized environment.

[0076] 2. The lock request is received by an execution environment associated with the embedded device and is configured to allow a first instance of a first application to communicate with the embedded device during a device access operation.

[0077] 3. The execution environment is associated with an instance of a first application in a first container. The device receives a lock request from a first instance of the execution environment based on a first instance of the first application in the first container, so that the first instance of the execution environment provides a lock request to allow the application to perform a device access operation.

[0078] Step 2: Perform the lock operation of the embedded device.

[0079] Implementation methods include:

[0080] 1. The device performs a locking operation to allow the first instance of the first application and the first instance of the runtime environment to use the embedded device in conjunction with a device access operation. The device access operation includes a read operation and a write operation of the embedded device.

[0081] 2. Before performing the lock operation, the device verifies that the embedded device is not locked based on another lock request received from a different instance of a third application operating in a container different from the first container. The device performs the lock operation on the embedded device based on verifying that the embedded device is not locked.

[0082] 3. Before performing the lock operation, the device identifies the embedded device based on a lock request indicating that the operating environment will perform a device access operation by a specific device type. The device performs the lock operation based on identifying that the embedded device belongs to the specific device type and is unlocked. Before performing the lock operation, the device identifies the embedded device based on the lock request including device type or device ID information identifying the embedded device.

[0083] 4. The lock request identifies a device type of the embedded device, and performing the lock operation includes allowing a first instance of the application to use the embedded device based on the device type identified in the lock request, and preventing a second instance from using the embedded device based on the second instance being configured to use an embedded device of the device type.

[0084] 5. The lock request identifies the number of a group of embedded devices, and before performing the lock operation, the device identifies a group of embedded devices. The embedded device may be one of the group of embedded devices, and the lock operation may be performed on the group of embedded devices.

[0085] Step 3: The device receives a lock request from a second instance of a second application.

[0086] Step 4: Preventing a second instance of a second application from accessing the embedded device based on the embedded device being locked, wherein the second instance of the second application waits for the lock to be available to access the embedded device.

[0087] Step 5: Monitor the use of the embedded device during the device access operation of the first instance of the first application to detect and unlock the embedded device. The unlock event includes determining that the device access operation has timed out and receiving an unlock request from the first instance of the execution environment.

[0088] Implementation methods include:

[0089] 1. Monitoring the use of the embedded device includes maintaining a session ID of a first instance of an application in a device management data structure based on receiving a lock request. Monitoring the use of the embedded device includes maintaining a session ID of a first instance of a first application and a timeout timer in the device management data structure; rejecting a received lock management request associated with the embedded device within a time period defined by the timeout timer, and detecting an unlock event based on the expiration of the time period and the received lock management request not including an unlock request associated with the session ID.

[0090] 2. Monitoring the use of the embedded device includes maintaining a session ID of a first instance of the operating environment in a device management data structure based on receiving a lock request; analyzing received lock management requests related to multiple embedded devices of the containerized environment; and determining that an unlock event occurs based on receiving an unlock request from the first instance of the operating environment. The unlock request includes the session ID of the first instance and the device ID of the embedded device.

[0091] 3. Monitoring the use of embedded devices includes maintaining the following session ID: the first instance of the operating environment and a timeout timer in the device management data structure; analyzing lock management requests associated with multiple embedded devices of the containerized environment received within a time period defined by the timeout period.

[0092] Step 6: Perform an unlock operation based on detecting the unlock event to allow the second instance of the second application to use the embedded device.

[0093] Step 7: Based on performing the unlock operation, providing a lock of the embedded device to the second instance of the second application.

[0094] The above is only a specific implementation of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present disclosure should be included in the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be based on the protection scope of the claims.

Claims

1. A device access control method for a multi-container application, characterized in that: A device receives a lock request for an embedded device using a containerized environment, wherein the lock request is associated with a first instance of a first application executed in a first container of the containerized environment; the device performs a lock operation on the embedded device to allow the first instance of the first application to use the embedded device and prevent a second instance of a second application from using the embedded device, wherein the second instance of the second application is executed in a second container of the containerized environment; a lock manager monitors whether the embedded device is used during a device access operation of the first instance, and the first application detects and unlocks an unlock event of the embedded device; the lock manager performs an unlock operation based on detecting the unlock event to allow the second instance of the second application to use the embedded device.

2. The device access control method for multi-container applications according to claim 1, characterized in that: The lock request is received based on an execution environment in a container; the execution environment is associated with the embedded device and is configured to allow a first instance of the first application to communicate with the embedded device during a device access operation.

3. The device access control method for multi-container applications according to claim 1, characterized in that: Before performing the locking operation, the lock manager verifies that the embedded device is not locked based on another locking request received from a third instance of a third application operating in a container different from the first container and the second container, wherein the locking operation is performed on the premise of verifying that the embedded device is not locked.

4. The device access control method for multi-container applications according to claim 3, characterized in that: Before performing the locking operation, the embedded device is identified based on a locking request, the locking request being used to identify the following information: the type of the embedded device and the device ID of the embedded device.

5. The device access control method for multi-container applications according to claim 4, characterized in that: The lock request identifies the type of the embedded device, and the specific process of performing the lock operation includes: based on the device type identified in the lock request, allowing a first instance of a first application to use the embedded device and preventing a second instance of a second application from using the embedded device.

6. The device access control method for multi-container applications according to claim 5, characterized in that: Monitoring the usage of the embedded device includes: Based on receiving the lock request, maintaining a session ID of the first instance of the first application in a device management data structure; Deny lock management requests from embedded devices until an unlock event is detected; detecting an unlock event based on receiving an unlock request from the first instance of the first application; The unlock request includes the session ID of the first instance of the first application and the device ID of the embedded device.

7. The device access control method for multi-container applications according to claim 6, characterized in that: Monitoring the usage of the embedded device includes: maintaining a session ID and a timer for a first instance of a first application in a device management data structure; rejecting a lock management request received from the embedded device during a time defined by the timer; In the case where no lock management request is received, an unlock event is detected based on the expiration time.

Images