Device access control for applications across multiple containers

Abstract

Embodiments of the present disclosure relate to device access control for applications of multiple containers. A device may receive a lock request associated with an embedded device using a containerized environment from a first instance of an application being executed in a first container of a containerized environment. The device may perform a lock operation associated with the embedded device to allow the first instance of the application to use the embedded device and prevent the second instance of the application being executed in a second container of the containerized environment from using the embedded device. The device may monitor use of the embedded device during an access operation of the first instance of the application to detect an unlock event associated with unlocking the embedded device. The device may perform an unlock operation based on detecting the unlock event to allow the second instance of the application to use the embedded device.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to containerization, and more particularly to container simulation applications. Background Art

[0002] Containerization is a form of virtualization in which applications run in isolated user spaces called containers, all of which use the same shared operating system. A container emulates a separate instance of an application from other containers. The container includes the application and all of its related configuration files, libraries, and dependencies required for it to run in a computing environment. Summary of the Invention

[0003] In some implementations, a method includes: receiving, by a device, a lock request associated with an embedded device using a containerized environment, wherein the lock request is associated with a first instance of a first application being executed in a first container of the containerized environment; performing, by the device, a lock operation associated with 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 being executed in a second container of the containerized environment; monitoring, by the device, use of the embedded device during a device access operation by the first instance of the first application to detect an unlock event associated with unlocking the embedded device; and performing, by the device based on detecting the unlock event, an unlock operation to allow the second instance of the second application to use the embedded device.

[0004] In some implementations, a device includes: one or more memories and one or more processors, the one or more processors configured to: receive a lock request from a first container of a containerized environment, the lock request associated with an embedded device using the containerized environment, wherein the lock request is received from a first instance of a software development kit (SDK), the SDK being used by an application in the first container; perform a lock operation associated with the embedded device to: allow the first instance of the SDK to use the embedded device in conjunction with a device access operation, and deny a lock request received from a second instance of the SDK in a second container during the device access operation to prevent the second instance of the SDK from using the embedded device during the device access operation; monitor the device access operation to detect an unlock event associated with unlocking the embedded device; and perform an unlock operation based on detecting the unlock event to allow the second instance of the SDK to use the embedded device.

[0005] In some implementations, a non-transitory computer-readable medium stores an instruction set, the instruction set including one or more instructions that, when executed by one or more processors of a device, causes the device to: receive a lock request associated with a set of embedded devices using a containerized environment, wherein the lock request is associated with a first instance of an SDK, the SDK being associated with a device type of the set of embedded devices and being in a first container of the containerized environment; identify an embedded device in the set of embedded devices for use in conjunction with a device access operation, wherein the embedded device is identified based on the device type identified in the lock request; perform a lock operation associated with the embedded device to: allow the first instance of the SDK to perform the device access operation on the embedded device and prevent a second instance of the SDK from accessing the embedded device during the device access operation, wherein the second instance of the SDK is executing in a second container of the containerized environment; detect an unlock event associated with unlocking the embedded device; and perform an unlock operation based on detecting the unlock event to allow the second instance of the SDK to use the embedded device. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1A-1D is a schematic diagram of one or more example implementations described herein.

[0007] Figure 2 is a schematic diagram of an example environment in which the systems and / or methods described herein may be implemented.

[0008] Figure 3 yes Figure 2 A schematic diagram of example components of one or more devices.

[0009] Figure 4 is a flow diagram of an example process related to device access control for applications of multiple containers. DETAILED DESCRIPTION

[0010] The following detailed description of example implementations refers to the accompanying drawings, in which the same reference numbers in different drawings may identify the same or similar elements.

[0011] A computing device may include a set of standard hardware components, such as a processor, memory, a communication bus, etc. An embedded device may be a computing device that includes one or more non-standard hardware components (e.g., a packet forwarding engine, a switch fabric, a retimer, a sensor, etc.) in addition to the set of standard hardware components. Applications running on the embedded device may access and / or program the non-standard hardware components to perform specialized functions associated with the embedded device. For example, an application running on a router may access and / or program the packet forwarding engine to enable the router to route traffic through a network.

[0012] In some cases, an embedded device may include instances of an application that execute in a set of containers. Each instance of the application can access shared components of the embedded device to perform functions associated with the embedded device. For example, an embedded device may include a physical line card that is sliced ​​so that the physical line card behaves like multiple logical line cards. Each slice of the physical line card can be assigned to a corresponding routing engine slice and together can act as an independent router. Each slice of the physical line card can be associated with a corresponding container that can access various line card hardware components. In some cases, two containers in the container can access the line card hardware components concurrently. Concurrent access to the line card hardware components may cause errors to occur, the termination of the process executed by the container, etc.

[0013] Some implementations described herein relate to a lock manager that controls access to shared resources of an embedded device. The lock manager may receive a lock request associated with use of a shared device. The lock request may be associated with a first instance of an application that is executed in a first container of a containerized environment associated with the lock manager. The lock manager may perform a lock operation associated with the shared device based on receiving the lock request. The lock operation may allow the first instance of the application to use the embedded device and may prevent a second instance of the application executed in a second container from using the embedded device. The lock manager may monitor use of the shared device during a device access operation by the first instance of the application to detect an unlock event associated with unlocking the shared device. The lock manager may perform 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.

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

[0015] For example, concurrent access to a shared device may result in programming errors in the device, resulting in the shared device being unable to perform its intended function. Furthermore, the consequences of such incorrect programming of a shared device can be significant. For example, incorrect programming of a shared device may result in dropped packets, misrouting of packets, link failures, and the like. Recovering from the consequences of incorrect programming of a shared device can be complex. For example, recovery may require reinitializing the shared device, restarting systems associated with the shared device, and the like, resulting in wasted computing resources that could otherwise be used to recover from the consequences of incorrect programming of the shared device.

[0016] Figure 1A-1D is a schematic diagram of one or more example implementations 100 described herein. Figure 1A-1D As shown, the embedded device includes a containerized environment, a device driver module, and a group of shared devices (shared device 1, shared device 2, and shared device 3, as shown in FIG) connected to the device driver module via a communication bus. Figure 1A As shown in ). A containerized environment may include multiple containers (e.g., container A, container B, and container C, as shown in Figure 1A-1D shown) and coordinator.

[0017] In some implementations, one of the multiple containers can include an application configured to access a shared device in the set of shared devices via a device driver module using a software development kit (SDK). In some implementations, the application can access the shared device using an operating system interface, an application programming interface (API), etc.

[0018] In some implementations, the coordinator may include a lock manager configured to control access to the set of shared devices. The lock manager may utilize a locking mechanism to prevent two or more applications from concurrently accessing the shared devices. In some implementations, the lock manager is included in an embedded device. For example, Figure 1A As shown, the lock manager is included in an orchestrator associated with a containerized environment. In some implementations, the lock manager is included in another device. For example, the lock manager can be included in a device included in a cloud computing environment that provides a locking mechanism as a service.

[0019] like Figure 1AAs shown, and indicated by reference numeral 110, the lock manager is configured to control access to the set of devices associated with the containerized environment. In some implementations, the lock manager is configured to control access to the set of devices based on access information associated with the set of devices. The access information may include: information identifying the shared device to which access is to be controlled (e.g., a device identifier), information identifying the number of locks to be utilized by the lock manager (e.g., one lock per shared device, one lock for the set of shared devices of the set of shared devices, etc.), information identifying the type of lock to be utilized by the lock manager (e.g., a semaphore, a mutex, etc.), information identifying the type of shared device to which access is to be controlled (e.g., a packet forwarding engine, a sensor, a structure, etc.), and the like.

[0020] In some implementations, the lock manager can determine access information based on characteristics associated with the embedded device. For example, the lock manager can determine access information based on a determination that a shared device is to be accessed concurrently, based on the type of shared device included in the embedded device (e.g., a packet forwarding engine, a switching fabric, a retimer, etc.), based on the type of embedded device (e.g., a router, a switch, etc.), based on the function performed by the shared device (e.g., a routing function, a switching function, etc.), etc. Alternatively and / or additionally, the lock manager can determine access information based on user input. For example, the user can input access information using a user interface associated with the lock manager.

[0021] The lock manager may allocate one or more locks to the set of shared devices based on the access information. For example, the access information may indicate that a corresponding lock is to be utilized for each shared device in the set of shared devices. The lock manager may allocate a corresponding lock to each shared device based on the access information indicating that a corresponding lock is to be utilized for each shared device.

[0022] The lock manager may provide information identifying the allocated lock to the application based on the allocation of the lock. The lock manager may determine that the application is configured to access a shared device from the set of shared devices. The lock manager may identify the lock allocated to the shared device and may provide information associated with the lock to the application. In some implementations, the lock manager provides information associated with the lock during creation of a container associated with the application.

[0023] The information associated with the lock may include information associated with obtaining the lock from the lock manager (e.g., information identifying a command and / or request to be transmitted to the lock manager to obtain the lock and / or lock a shared device), information associated with returning the lock to the lock manager (e.g., information identifying a command and / or request to be transmitted to the lock manager to return the lock and / or unlock the shared device), etc. The application may receive the information associated with the lock and may provide the information to an SDK associated with the application. In some implementations, the application provides the information to the SDK by assigning the lock to a lock vector associated with the SDK.

[0024] like Figure 1B As shown, and indicated by reference numeral 120, the lock manager receives a lock request associated with an operation involving the use of a shared device. The lock request may be associated with a first container (e.g., container A, such as Figure 1B ) is executed in the application (eg, App 1, as shown in Figure 1B The lock manager may receive a lock request based on an operation initiated by an application instance involving use of a shared device. For example, the lock manager may receive a lock request based on an access operation (e.g., a write operation, a read operation, etc.) associated with a shared device initiated by an application instance.

[0025] In some implementations, the lock manager retrieves the lock from an SDK associated with an instance of the application (e.g., SDK X, such as Figure 1B (as shown) receives a lock request. The instance of the application may determine that an access operation is to be performed on a shared device. The instance of the application may cause the SDK associated with the instance of the application to provide a lock request to the lock manager based on the determination that the access operation is to be performed, so as to request a lock from the lock manager. The lock request may include information identifying the shared device associated with the operation (e.g., an identifier associated with the shared device), information identifying the type of the shared device, information identifying the number of shared devices associated with the operation, information identifying the instance of the application, information identifying the SDK associated with the instance of the application, etc.

[0026] The lock manager may receive a lock request and may determine a shared device in the set of shared devices associated with the lock request. For example, the lock request may include information identifying an identifier of the shared device. The lock manager may identify the shared device based on the identifier.

[0027] In some implementations, such as Figure 1CAs shown, the shared devices determined by the lock manager may include a set of shared devices. For example, the lock request may include information identifying the type of shared device associated with the operation (e.g., type X). The lock manager may identify the set of shared devices in the set of shared devices that includes the type of shared device associated with the operation (e.g., shared device 1 and shared device 3, as shown). Figure 1C shown).

[0028] In some implementations, the lock manager can verify that the shared device is not locked based on another lock request received from a different instance of the application and / or a different SDK operating in a different container. The lock manager can verify that the shared device is not locked based on determining that the shared device is associated with an unlocked state. In some implementations, the lock manager can determine that the shared device is associated with an unlocked state based on information included in a data structure associated with the lock manager (e.g., a database, table, list, etc.).

[0029] The lock manager can perform a lock operation associated with the shared device based on verifying that the shared device is unlocked. The lock operation can allow the instance of the application to utilize the shared device to perform operations. The lock operation can prevent another instance of the application executing in another container from utilizing the shared device.

[0030] In some implementations, the locking operation includes providing a lock associated with the shared device to the instance of the application. For example, the lock manager may provide 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, information identifying a time period during which the shared device will be locked, and the like.

[0031] In some implementations, the locking operation includes updating the state of the shared device. For example, the lock manager may store in a data structure: information indicating that the shared device is locked, information identifying an instance of an application, information identifying a container associated with the instance of the application, information identifying a time period during which the shared device will be locked, information identifying a session identifier associated with the instance and / or operation of the application, information identifying the number of times the shared device has been locked and / or unlocked within a period of time, information identifying the number of times an application has been blocked from accessing the shared device based on the shared device being locked, etc.

[0032] The instance of the application can perform operations associated with the shared device based on the lock manager performing the locking operation. For example, the instance of the application can perform operations based on receiving a lock from the lock manager, based on the state of the shared device being updated, etc.

[0033] like Figure 1C As shown, and indicated by reference numeral 130, the lock manager prevents other instances of the application (and instances of other applications) from accessing the shared device (e.g., shared device 1, such as Figure 1BAs shown; shared devices 1 and 3, such as Figure 1C The lock manager can prevent another instance of the application from accessing the shared device during operation by rejecting a lock request received from the other instance of the application. The other instance of the application can be in a different container (e.g., container C, as shown). Figure 1C The lock manager may execute a lock request associated with the shared device and may provide a lock request associated with the shared device to the lock manager. The lock manager may identify the shared device based on information included in the lock request. The lock manager may determine that the shared device is locked based on information included in the data structure indicating that the shared device is locked. In some implementations, the lock manager may deny the lock request based on the shared device being locked to prevent other instances of the application from accessing the shared device.

[0034] In some implementations, the lock manager can cause other instances of an application to wait for access to a shared device. The lock manager can store information identifying the other instances of the application in a data structure. The data structure can store, among other things, a list of applications waiting for access to the shared device, the times at which the applications provided lock requests associated with accessing the shared device, the order in which the lock manager received the lock requests, etc. Upon detecting an unlock event associated with the shared device and unlocking the shared device, as described below, the lock manager can utilize the information stored in the data structure to allow applications (e.g., other instances of the application) waiting for access to the shared device to access the shared device.

[0035] In some implementations, multiple instances of one or more applications may be waiting to access a shared device. The lock manager may allow multiple instances of the one or more applications to access the shared device on a first-come, first-served basis. For example, the lock manager may identify the first instance of the application to request a lock for the shared device relative to other instances of the application that have requested a lock for the shared device based on information stored in a data structure. The lock manager may provide the lock to the instance of the application based on the instance of the application being the first to request a lock for the shared device. The lock manager may subsequently provide the lock to the multiple instances of the one or more applications in a similar manner based on the order in which the multiple instances of the one or more applications requested a lock for the shared device.

[0036] like Figure 1D As shown and indicated by reference numeral 140, the lock manager detects an unlock event associated with the shared device. In some implementations, the lock manager detects the unlock event based on monitoring usage of the shared device by an instance of an application. For example, the lock manager can determine the unlock event based on determining that the instance of the application is unresponsive, based on determining that an error associated with the instance of the application and / or an operation has occurred, based on determining that a time period associated with the operation and / or the lock has expired, etc.

[0037] In some implementations, the lock manager detects an unlock event based on information received from the instance of the application and / or an SDK associated with the instance of the application. For example, the SDK associated with the instance of the application can provide an unlock request to the lock manager based on the instance of the application completing an operation.

[0038] In some implementations, the lock manager detects a lock event based on determining that an application has crashed, failed, ceased execution, etc. For example, an instance of an application may acquire a lock and crash before releasing the lock. The lock manager can detect the application crash and automatically unlock the shared device.

[0039] As shown at 150, the lock manager performs an unlock operation associated with the embedded device. The lock manager can perform the unlock operation and / or allow other instances of the application to access the shared device based on detecting the unlock event. In some implementations, the unlock operation can include updating the state of the shared device to indicate that the shared device is unlocked, providing information indicating that the shared device is unlocked to the instance of the application and / or other instances of the application, etc.

[0040] In this manner, the lock manager can control access to a shared device by multiple instances of an application executing 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 executing in different containers of the containerized environment.

[0041] As described above, Figure 1A-1D are provided as examples. Other examples may be related to Figure 1A-1D The examples described are different. Figure 1A-1D The number and arrangement of devices shown are provided as examples. Figure 1A-1D There may be additional devices, fewer devices, different or differently arranged devices, additional applications within containers, additional containers, fewer containers, applications associated with the SDK, applications not associated with the SDK, etc., compared to those shown. Figure 1A-1D Two or more of the devices shown may be implemented in a single device, or Figure 1A-1D The single device shown may be implemented as multiple distributed devices. Additionally or alternatively, Figure 1A-1D The illustrated set of devices (e.g., one or more devices) may perform the operations described as being performed by Figure 1A-1D One or more functions performed by another set of devices are shown.

[0042] Figure 2 FIG is a diagram of an example environment 200 in which the systems and / or methods described herein may be implemented. Figure 2As shown, environment 200 may include a lock manager 201, which may include one or more elements of a cloud computing system 202 and / or may be executed within the cloud computing system 202. The cloud computing system 202 may include one or more elements 203-213, as described in more detail below. Figure 2 As further shown, environment 200 may include network 220 and / or embedded device 230. The devices and / or elements of environment 200 may be interconnected via wired connections and / or wireless connections.

[0043] Cloud computing system 202 includes computing hardware 203, a resource management component 204, a host operating system (OS) 205, and / or one or more virtual computing systems 206. Resource management component 204 can perform virtualization (e.g., abstraction) of computing hardware 203 to create one or more virtual computing systems 206. Using virtualization, resource management component 204 enables a single computing device (e.g., a computer, server, etc.) to operate as multiple computing devices, such as by creating multiple isolated virtual computing systems 206 from the computing hardware 203 of a single computing device. In this way, computing hardware 203 can operate more efficiently with lower power consumption, higher reliability, higher availability, higher utilization, greater flexibility, and lower cost than using separate computing devices.

[0044] Computing hardware 203 includes hardware and corresponding resources from one or more computing devices. For example, computing hardware 203 can include hardware from a single computing device (e.g., a single server) or from multiple computing devices (e.g., multiple servers) (such as multiple computing devices in one or more data centers). As shown, computing hardware 203 can include one or more processors 207, one or more memories 208, one or more storage components 209, and / or one or more networking components 210. Processors, memories, storage components, and networking components (e.g., communication components) are described elsewhere herein.

[0045] The resource management component 204 includes a virtualization application (e.g., executing on hardware such as the computing hardware 203) that is capable of virtualizing the computing hardware 203 to start, stop, and / or manage one or more virtual computing systems 206. For example, such as when the virtual computing system 206 is a virtual machine 211, the resource management component 204 may include a hypervisor (e.g., a bare metal or type 1 hypervisor, a hosted or type 2 hypervisor, etc.) or a virtual machine monitor. Additionally or alternatively, such as when the virtual computing system 206 is a container 212, the resource management component 204 may include a container manager. In some implementations, the resource management component 204 executes within and / or in conjunction with the host operating system 205.

[0046] The virtual computing system 206 includes a virtual environment that supports performing the operations and / or processes described herein in a cloud-based manner using the computing hardware 203. As shown, the virtual computing system 206 may include virtual machines 211, containers 212, a hybrid environment 213 including virtual machines and containers, and the like. The virtual computing system 206 may execute one or more applications using a file system that includes binary files, software libraries, and / or other resources required to execute the applications on a guest operating system (e.g., within the virtual computing system 206) or a host operating system 205.

[0047] Although the lock manager 201 may include one or more elements 203-213 of the cloud computing system 202, may be executed in the cloud computing system 202, and / or may be hosted within the cloud computing system 202, in some implementations, the lock manager 201 may not be cloud-based (e.g., may be implemented outside of the cloud computing system) or may be partially cloud-based. For example, the lock manager 201 may include one or more devices that are not part of the cloud computing system 202, such as Figure 3 The lock manager 201 may perform one or more operations and / or processes described in greater detail elsewhere herein.

[0048] The network 220 includes one or more wired and / or wireless networks. For example, the network 220 may include a cellular network, a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a private network, the Internet, etc., and / or a combination of these or other types of networks. The network 220 enables communication between devices in the environment 200.

[0049] As described herein, the embedded device 230 may include one or more devices capable of receiving, generating, storing, processing and / or providing information associated with device access control for applications of multiple containers. The embedded device 230 may include a dedicated computing device that includes one or more non-standard hardware components (e.g., packet forwarding engines, switching fabrics, retimers, sensors, etc.) in addition to a set of standard hardware components (e.g., processes, memories, communication buses, etc.) included in a non-dedicated computing device. For example, the embedded device 230 may include a router such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router, a provider core router, etc.), a virtual router, etc. Additionally or alternatively, the embedded device 230 may include a gateway, a switch, a firewall, a hub, a bridge, a reverse proxy, a load balancer, and / or the like.

[0050] Figure 2 The number and arrangement of devices and networks shown are provided as examples. Figure 2 There may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown. Figure 2 Two or more of the devices shown may be implemented in a single device, or Figure 2 The single device shown in FIG200 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (eg, one or more devices) of environment 200 may perform one or more functions described as being performed by another set of devices of environment 200.

[0051] Figure 3 is a diagram of example components of a device 300, which may correspond to the lock manager 201 and / or the embedded device 230. In some implementations, the lock manager 201 and / or the embedded device 230 may include one or more devices 300 and / or one or more components of the device 300. Figure 3 As shown, device 300 may include a bus 310 , a processor 320 , a memory 330 , a storage component 340 , an input component 350 , an output component 360 , and a communication component 370 .

[0052] The bus 310 includes components that enable wired and / or wireless communication between components of the device 300. The processor 320 includes a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field programmable gate array, an application-specific integrated circuit, and / or another type of processing component. The processor 320 is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the processor 320 includes one or more processors that can be programmed to perform functions. The memory 330 includes random access memory, read-only memory, and / or another type of memory (e.g., flash memory, magnetic memory, and / or optical memory).

[0053] Storage component 340 stores information and / or software related to the operation of device 300. For example, storage component 340 may include a hard disk drive, a magnetic disk drive, an optical disk drive, a solid-state disk drive, a compact disc, a digital versatile disc, and / or another type of non-transitory computer-readable medium. Input component 350 enables device 300 to receive input, such as user input and / or sensed input. For example, input component 350 may include a touch screen, a keyboard, a keypad, a mouse, buttons, a microphone, switches, sensors, a global positioning system component, an accelerometer, a gyroscope, an actuator, etc. Output component 360 enables device 300 to provide output, such as via a display, a speaker, and / or one or more light-emitting diodes. Communication component 370 enables device 300 to communicate with other devices, such as via a wired connection and / or a wireless connection. For example, communication component 370 may include a receiver, a transmitter, a transceiver, a modem, a network interface card, an antenna, etc.

[0054] The device 300 can perform one or more processes described herein. For example, a non-transitory computer-readable medium (e.g., memory 330 and / or storage component 340) can store an instruction set (e.g., one or more instructions, codes, software codes, program codes, etc.) for execution by the processor 320. The processor 320 can execute the instruction set to perform one or more processes described herein. In some implementations, the instruction set executed by one or more processors 320 causes the one or more processors 320 and / or the device 300 to perform one or more processes described herein. In some implementations, hard-wired circuitry can be used instead of or in combination with instructions to perform one or more processes described herein. Therefore, the implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0055] Figure 3 The number and arrangement of components shown are provided as examples. Figure 3 The device 300 may include additional components, fewer components, different components, or differently arranged components compared to the components shown. Additionally or alternatively, a set of components (e.g., one or more components) of the device 300 may perform one or more functions described as being performed by another set of components of the device 300.

[0056] Figure 4 is a flow diagram of an example process 400 associated with device access control for applications of multiple containers. In some implementations, Figure 4 One or more processing blocks of may be performed by a device (e.g., lock manager 201). In some implementations, Figure 4One or more processing blocks of may be performed by another device or a group of devices separate from or including the device, such as an embedded device (e.g., embedded device 230). Additionally or alternatively, Figure 4 One or more processing blocks of may be performed by one or more components of device 300, such as processor 320, memory 330, storage component 340, input component 350, output component 360, communication component 370, and the like.

[0057] like Figure 4 As shown, process 400 may include receiving a lock request associated with an embedded device using a containerized environment, wherein the lock request is associated with a first instance of a first application being executed in a first container of the containerized environment (block 410). For example, as described above, the device may receive a lock request associated with an embedded device using a containerized environment. The embedded device may include at least one of a router, a switch fabric, a retimer, a sensor, and / or another type of device including non-standard computing components.

[0058] In some implementations, the lock request is associated with a first instance of a first application being executed in a first container of a containerized environment. In some implementations, the lock request is received via an SDK that is associated with the embedded device and configured to allow the first instance of the first application to communicate with the embedded device during a device access operation. In some implementations, the SDK is a first instance of the SDK associated with the first instance of the first application in the first container. The device may receive the lock request from the first instance of the SDK based on the first instance of the first application in the first container causing the first instance of the SDK to provide the lock request to allow the application to perform the device access operation.

[0059] like Figure 4 As further shown, process 400 may include performing a lock operation associated with the embedded device (block 420). For example, the device may perform a lock operation associated with the embedded device to allow a first instance of a first application to use the embedded device and to prevent a second instance of a second application from using the embedded device, wherein the second instance of the second application is executing in a second container of the containerized environment, as described above. In some implementations, the second instance of the second application is executing in the second container of the containerized environment. The second instance of the second application may be associated with a second instance of the SDK.

[0060] In some implementations, the device may perform a locking operation to allow the first instance of the first application and / or the first instance of the SDK to use the embedded device in conjunction with a device access operation. The device access operation may include at least one of: a read operation associated with the embedded device or a write operation associated with the embedded device.

[0061] In some implementations, before performing the lock operation, the device may verify that the embedded device is not locked based on another lock request received from a different instance of a third application running in a different container than the first container and / or from a different instance of an SDK running in a different container than the first container. The device may perform the lock operation on the embedded device based on verifying that the embedded device is not locked.

[0062] In some implementations, before performing the lock operation, the device may identify the embedded device based on a lock request indicating that the SDK will perform a device access operation via a specific device type. The device may perform the lock operation based on identifying that the embedded device is of the specific device type and is unlocked. Alternatively and / or additionally, before performing the lock operation, the device may identify the embedded device based on a lock request including information identifying at least one of a device type of the embedded device or a device identifier of the embedded device. The device may perform the lock operation on the embedded device based on identifying the embedded device.

[0063] In some implementations, 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 one or more embedded devices of the device type.

[0064] In some implementations, the lock request identifies a number of a set of embedded devices to be used in conjunction with the device access operation, and before performing the lock operation, the device identifies a set of embedded devices in the set of embedded devices that can be used in conjunction with the device access operation. The embedded device can be one of the set of embedded devices, and the lock operation can be performed on the set of embedded devices based on identifying the set of embedded devices.

[0065] like Figure 4 As further shown, process 400 may include receiving a lock request from a second instance of a second application (block 430). For example, as described above, the device may receive a lock request from a second instance of a second application. In some implementations, the first application and the second application may be different applications. In some implementations, the first application and the second application may be the same application.

[0066] like Figure 4As further shown, process 400 may include 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 a lock to become available to access the embedded device (block 440). For example, as described above, the device may prevent the second instance of the second application from accessing the embedded device based on the embedded device being locked. In some implementations, the second instance of the second application waits for a lock to become available to access the embedded device.

[0067] like Figure 4 As further shown, process 400 may include monitoring usage of the embedded device during a device access operation of the first instance of the first application to detect an unlock event associated with unlocking the embedded device (block 450). For example, as described above, the device may monitor usage of the embedded device during a device access operation of the first instance of the first application to detect an unlock event associated with unlocking the embedded device. The unlock event may include at least one of: determining that the device access operation has timed out or receiving an unlock request from the first instance of the SDK.

[0068] In some implementations, monitoring usage of the embedded device includes: maintaining a session identifier for the first instance of the application in a device management data structure based on receiving a lock request. Alternatively and / or additionally, monitoring usage of the embedded device includes: maintaining the session identifier for the first instance of the first application in the device management data structure and a timeout timer; rejecting received lock management requests associated with the embedded device during a time period defined by the timeout timer, and detecting an unlock event based on the lock management requests received upon expiration of the time period not including an unlock request associated with the session identifier.

[0069] In some implementations, monitoring usage of the embedded device includes: maintaining a session identifier of the first instance of the SDK in a device management data structure based on receiving a lock request; analyzing received lock management requests associated with multiple embedded devices of the containerized environment; and determining that an unlock event has occurred in conjunction with receiving an unlock request from the first instance of the SDK. The unlock request may include the session identifier of the first instance and a device identifier of the embedded device.

[0070] In some implementations, monitoring usage of an embedded device includes: maintaining a session identifier of a first instance of an SDK in a device management data structure and a timeout timer; analyzing received lock management requests associated with multiple embedded devices of a containerized environment during a time period defined by the timeout period; and determining that an unlock event has occurred in conjunction with expiration of the time period without receiving an unlock request including the session identifier.

[0071] like Figure 4As further shown, process 400 may include performing an unlock operation based on detecting the unlock event to allow the second instance of the second application to use the embedded device (block 460). For example, as described above, the device may perform an unlock operation based on detecting the unlock event to allow the second instance of the second application to use the embedded device.

[0072] like Figure 4 As further shown, process 400 may include providing a lock associated with the embedded device to a second instance of the second application based on performing the unlock operation (block 470). For example, as described above, the device may provide a lock associated with the embedded device to the second instance of the second application based on performing the unlock operation.

[0073] although Figure 4 Example blocks of process 400 are shown, but in some implementations, Figure 4 Process 400 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than the blocks shown. Additionally or alternatively, two or more blocks of process 400 may be performed in parallel.

[0074] According to some embodiments, the following examples are provided.

[0075] Example 1. A method comprising: receiving, by a device, a lock request associated with an embedded device using a containerized environment, wherein the lock request is associated with a first instance of a first application being executed in a first container of the containerized environment; performing, by the device, a lock operation associated with 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 being executed in a second container of the containerized environment; monitoring, by the device, use of the embedded device during a device access operation of the first instance of the first application to detect an unlock event associated with unlocking the embedded device; and performing, by the device based on detecting the unlock event, an unlock operation to allow the second instance of the second application to use the embedded device.

[0076] Example 2. The method of example 1, wherein the lock request is received via a software development kit associated with the embedded device and configured to allow the first instance of the first application to communicate with the embedded device during a device access operation.

[0077] Example 3. The method according to Example 1 further includes: before performing the locking operation, verifying that the embedded device is not locked based on another locking request received from a different instance of a third application running in a container different from the first container, wherein the locking operation is performed based on verifying that the embedded device is not locked.

[0078] Example 4. The method according to Example 1 further includes: before performing the locking operation, identifying the embedded device based on a locking request, the locking request including information identifying at least one of the following: a device type of the embedded device, or a device identifier of the embedded device, wherein based on identifying the embedded device, the locking operation is performed on the embedded device.

[0079] Example 5. A method according to Example 1, wherein the lock request identifies a device type of the embedded device, and performing the lock operation includes: allowing a first instance of a first application to use the embedded device based on the device type being identified in the lock request; and preventing a second instance of a second application from using the embedded device based on the second instance of a second application being configured to use one or more embedded devices of the device type.

[0080] Example 6. A method according to Example 1, wherein monitoring the use of the embedded device includes: maintaining a session identifier of a first instance of a first application in a device management data structure based on receiving a lock request; rejecting lock management requests associated with the embedded device until an unlock event is detected; and detecting an unlock event based on receiving an unlock request from the first instance of the first application, wherein the unlock request includes the session identifier of the first instance of the first application and a device identifier of the embedded device.

[0081] Example 7. A method according to Example 1, wherein monitoring the use of the embedded device includes: maintaining a session identifier of a first instance of a first application in a device management data structure and a timeout timer; rejecting a received lock management request associated with the embedded device during a time period defined by the timeout timer; and detecting an unlock event based on the lock management request received upon expiration of the time period not including an unlock request associated with the session identifier.

[0082] Example 8. A device comprising: one or more memories; and one or more processors for: receiving a lock request from a first container of a containerized environment, the lock request associated with an embedded device using the containerized environment, wherein the lock request is received from a first instance of a software development kit (SDK), the SDK being used by an application in the first container; performing a lock operation associated with the embedded device to: allow the first instance of the SDK to use the embedded device in conjunction with a device access operation, and deny a lock request received from a second instance of the SDK in a second container during the device access operation to prevent the second instance of the SDK from using the embedded device during the device access operation; monitoring the device access operation to detect an unlock event associated with unlocking the embedded device; and performing an unlock operation based on detecting the unlock event to allow the second instance of the SDK to use the embedded device.

[0083] Example 9. The device of Example 8, wherein the first instance of the SDK is associated with a first instance of the application in a first container, and wherein the second instance of the SDK is associated with a second instance of the application in a second container.

[0084] Example 10. A device according to Example 8, wherein the one or more processors are further used to: identify the embedded device based on a lock request before performing a lock operation, the lock request indicating that the SDK will perform a device access operation via a specific device type, wherein the lock operation is performed based on identifying that the embedded device belongs to the specific device type and is unlocked.

[0085] Example 11. The device of example 8, wherein the unlock event comprises at least one of: determining that a device access operation has timed out, or receiving an unlock request from the first instance of the SDK.

[0086] Example 12. A device according to Example 8, wherein when monitoring use of an embedded device, one or more processors are configured to: maintain a session identifier of a first instance of the SDK in a device management data structure based on receiving a lock request; analyze received lock management requests associated with multiple embedded devices of a containerized environment; and determine that an unlock event has occurred in combination with receiving an unlock request from the first instance of the SDK, wherein the unlock request includes the session identifier of the first instance and a device identifier of the embedded device.

[0087] Example 13. A device according to Example 8, wherein when monitoring use of an embedded device, one or more processors are configured to: maintain a session identifier of a first instance of the SDK in a device management data structure and a timeout timer; analyze received lock management requests associated with multiple embedded devices of a containerized environment during a time period defined by the timeout timer; and determine that an unlock event has occurred in conjunction with expiration of the time period without receiving an unlock request including the session identifier.

[0088] Example 14. The device of Example 8, wherein the embedded device comprises at least one of: a router, a switch fabric, a retimer, or a sensor.

[0089] Example 15. A non-transitory computer-readable medium storing an instruction set, the instruction set comprising: one or more instructions that, when executed by one or more processors of a device, cause the device to: receive a lock request, the lock request being associated with a set of embedded devices using a containerized environment, wherein the lock request is associated with a first instance of a software development kit (SDK), the SDK being associated with a device type of the set of embedded devices and being in a first container of the containerized environment; identify an embedded device in the set of embedded devices for use in conjunction with a device access operation, wherein the embedded device is identified based on the device type identified in the lock request; perform a lock operation associated with the embedded device to: allow the first instance of the SDK to perform a device access operation on the embedded device, and prevent a second instance of the SDK from accessing the embedded device during the device access operation, wherein the second instance of the SDK is executing in a second container of the containerized environment; detect an unlock event associated with unlocking the embedded device; and perform an unlock operation based on detecting the unlock event to allow the second instance of the SDK to use the embedded device.

[0090] Example 16. The non-transitory computer-readable medium of example 15, wherein the lock request is received from the first instance of the SDK based on the instance of the application in the first container causing the first instance of the SDK to provide the lock request to allow the application to perform the device access operation.

[0091] Example 17. A non-transitory computer-readable medium according to Example 15, wherein the one or more instructions further cause the device to: before performing the lock operation, verify that the embedded device is not locked based on another lock request received from a different instance of the SDK running in a container different from the first container, wherein the lock operation is performed based on verifying that the embedded device is not locked.

[0092] Example 18. Non-transitory computer-readable medium according to Example 15, wherein the lock request identifies a number of a set of embedded devices to be used in conjunction with the device access operation, wherein the one or more instructions further cause the device to: before performing the lock operation, identify a set of embedded devices in the set of embedded devices that can be used in conjunction with the device access operation; wherein based on identifying the set of embedded devices, the lock operation is performed on the set of embedded devices, wherein the embedded device is one of the set of embedded devices.

[0093] Example 19. The non-transitory computer-readable medium of example 15, wherein the one or more instructions that cause the one or more processors to detect an unlock event cause the one or more processors to: receive an unlock request from the first instance of the SDK, wherein receiving the unlock request corresponds to the unlock event.

[0094] Example 20. The non-transitory computer-readable medium of example 15, wherein the device access operation comprises at least one of: a read operation associated with the embedded device, or a write operation associated with the embedded device.

[0095] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0096] As used herein, the term "component" is intended to be broadly interpreted as hardware, firmware, or a combination of hardware and software.

[0097] As used herein, a service or content may include a collection of packets. A packet may refer to a communication structure for transmitting information, such as a protocol data unit (PDU), a service data unit (SDU), a network packet, a datagram, a segment, a message, a block, a frame (e.g., an Ethernet frame), a portion of any of the above, and / or other types of formatted or unformatted data units capable of transmission over a network.

[0098] Certain user interfaces have been described herein and / or shown in the accompanying drawings. User interfaces may include graphical user interfaces, non-graphical user interfaces, text-based user interfaces, and the like. A user interface may provide information for display. In some implementations, a user may interact with the information, such as by providing input via an input component of a device that provides the user interface for display. In some implementations, the user interface may be configurable by the device and / or the user (e.g., the user may change the size of the user interface, the information provided via the user interface, the location of the information provided via the user interface, and the like). Additionally or alternatively, the user interface may be preconfigured as a standard configuration, a specific configuration based on the type of device on which the user interface is displayed, and / or a set of configurations based on the capabilities and / or specifications associated with the device that displays the user interface.

[0099] Obviously, the systems and / or methods described herein can be implemented in various forms of hardware, firmware, and / or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not constitute a limitation on the implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code - it should be understood that based on the description herein, the systems and / or methods can be implemented using software and hardware.

[0100] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of the various implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of the various implementations includes each dependent claim in combination with every other claim in the claim set.

[0101] Unless otherwise expressly stated, any element, behavior or instruction used in this article shall not be interpreted as key or necessary. Moreover, as used herein, the articles "one" and "an" are intended to include one or more items and can be used interchangeably with "one or more". Further, as used herein, the article "the" is intended to include one or more items quoted in conjunction with the article "the", and can be used interchangeably with "one or more". Furthermore, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.), and can be used interchangeably with "one or more". When intended to refer to only one item, phrase "only one" or similar language is used. Moreover, as used herein, the term "having (has, have, having)" etc. is intended to be open terms. Further, unless otherwise expressly stated, the phrase "based on" is intended to represent "at least partially based on". Moreover, as used herein, the term "or" is intended to be inclusive when used in series, and can be used interchangeably with "and / or", unless otherwise expressly stated (e.g., if used in conjunction with "either" or "only one of them".

Claims

1. A method comprising: providing, by the device during creation of a first container of a containerized environment, information identifying a lock of the embedded device to be used for the containerized environment, wherein said information identifying said lock is provided to said first container, and wherein the lock is configured to prevent concurrent access to the embedded device by multiple instances of the first application; receiving, by the device, a lock request associated with use of the embedded device based on the information, wherein the lock request is associated with a first instance of the first application being executed in the first container; performing, by the device, a lock operation associated with the embedded device to: allowing the first instance of the first application to use the embedded device, and preventing a second instance of the first application from using the embedded device during a time period when the first instance of the first application is using the embedded device, wherein the second instance of the first application is executing in a second container of the containerized environment; monitoring, by the device, usage of the embedded device during a device access operation of the first instance of the first application; detecting, by the device, an unlock event associated with unlocking the embedded device based on monitoring the use of the embedded device during the device-access operation of the first instance of the first application; as well as An unlock operation is performed by the device based on detecting the unlock event to unlock the embedded device, wherein unlocking the embedded device enables the second instance of the first application to use the embedded device.

2. The method of claim 1 , wherein the lock request is received via a software development kit associated with the embedded device and configured to allow the first instance of the first application to communicate with the embedded device during the device access operation.

3. The method according to claim 1, further comprising: Before performing the locking operation, verifying that the embedded device is not locked based on another locking request received from a different instance of the first application running in a different container than the first container, The locking operation is performed based on verifying that the embedded device is not locked.

4. The method according to claim 1, further comprising: Before performing the locking operation, the embedded device is identified based on the locking request, the locking request including information identifying at least one of: the device type of the embedded device, or a device identifier of the embedded device, Based on identifying the embedded device, the locking operation is performed on the embedded device.

5. The method of claim 1 , wherein the lock request identifies a device type of the embedded device, and performing the lock operation comprises: Based on the device type identified in the lock request, the first instance of the first application is allowed to use the embedded device.

6. The method of claim 1 , wherein monitoring the usage of the embedded device comprises: Based on receiving the lock request, maintaining a session identifier of the first instance of the first application in a device management data structure; denying lock management requests associated with the embedded device until the unlock event is detected; as well as detecting the unlock event based on receiving an unlock request from the first instance of the first application, The unlock request includes the session identifier of the first instance of the first application and a device identifier of the embedded device.

7. The method of claim 1 , wherein monitoring the usage of the embedded device comprises: maintaining a session identifier for the first instance of the first application in a device management data structure and a timeout timer; denying a received lock management request associated with the embedded device during a period of time defined by the timeout timer; as well as The unlock event is detected based on the time period expiring without the received lock management request including an unlock request associated with the session identifier.

8. A device comprising: one or more memories; as well as One or more processors to: providing, during creation of a first container of a containerized environment, information identifying a lock of an embedded device to be used for the containerized environment, wherein the information identifying the lock is provided to the first container, and wherein the lock is configured to prevent concurrent access to the embedded device; receiving a lock request associated with use of the embedded device from the first container based on the information, wherein the lock request is received from a first instance of a software development kit (SDK), the SDK being used by an application in the first container; Performing a lock operation associated with the embedded device to: allowing the first instance of the SDK to use the embedded device in conjunction with device access operations, and denying a lock request received from a second instance of the SDK in a second container during the device access operation to prevent the second instance of the SDK from using the embedded device during the device access operation; monitoring usage of the embedded device by the first instance of the SDK during the device access operation; detecting an unlock event associated with unlocking the embedded device based on monitoring the use of the embedded device by the first instance of the SDK during the device access operation; as well as An unlock operation is performed to unlock the embedded device based on detecting the unlock event, wherein unlocking the embedded device allows the second instance of the SDK to use the embedded device.

9. The apparatus of claim 8, wherein the first instance of the SDK is associated with a first instance of the application in the first container, and The second instance of the SDK is associated with the second instance of the application in the second container.

10. The apparatus of claim 8, wherein the one or more processors are further configured to: Before performing the lock operation, identifying the embedded device based on the lock request, the lock request indicating that the SDK is to perform the device access operation via a specific device type, The locking operation is performed based on identifying that the embedded device belongs to the specific device type and is unlocked.

11. The device of claim 8, wherein the unlocking event comprises at least one of the following: Determining that the device access operation has timed out, or An unlock request is received from the first instance of the SDK.

12. The device of claim 8, wherein when monitoring the usage of the embedded device, the one or more processors are configured to: Based on receiving the lock request, maintaining a session identifier of the first instance of the SDK in a device management data structure; analyzing received lock management requests associated with a plurality of embedded devices of the containerized environment; as well as In conjunction with receiving an unlock request from the first instance of the SDK, determining that the unlock event has occurred, The unlock request includes the session identifier of the first instance and a device identifier of the embedded device.

13. The device of claim 8, wherein when monitoring the usage of the embedded device, the one or more processors are configured to: Maintaining a session identifier of the first instance of the SDK in a device management data structure and a timeout timer; analyzing, during a time period defined by the timeout timer, received lock management requests associated with a plurality of embedded devices of the containerized environment; as well as In conjunction with expiration of the time period without receiving an unlock request including the session identifier, it is determined that the unlock event has occurred.

14. The device of claim 8, wherein the embedded device comprises at least one of the following: router, Switching fabric, a retimer, or sensor.

15. A non-transitory computer-readable medium storing an instruction set, the instruction set comprising: One or more instructions that, when executed by one or more processors of a device, cause the device to: providing, during creation of a first container of a containerized environment, information identifying a lock of a set of embedded devices to be used for the containerized environment, wherein said information identifying said lock is provided to said first container, and wherein the lock is configured to prevent concurrent access to the set of embedded devices receiving a lock request based on the information, the lock request associated with using the set of embedded devices, wherein the lock request is associated with a first instance of a software development kit (SDK), the SDK being associated with a device type of the set of embedded devices and being in the first container; identifying an embedded device in the set of embedded devices for use in conjunction with a device access operation, wherein the embedded device is identified based on the device type identified in the lock request; Performing a lock operation associated with the embedded device to: allowing the first instance of the SDK to perform the device access operation on the embedded device, and preventing a second instance of the SDK from concurrently accessing the embedded device during the device access operation, wherein the second instance of the SDK is executing in a second container of the containerized environment; monitoring usage of the embedded device by the first instance of the SDK during the device access operation; detecting an unlock event associated with unlocking the embedded device based on monitoring the use of the embedded device by the first instance of the SDK during the device access operation; as well as An unlock operation is performed to unlock the embedded device based on detecting the unlock event, wherein unlocking the embedded device allows the second instance of the SDK to use the embedded device.

16. The non-transitory computer-readable medium of claim 15, wherein the lock request is received from the first instance of the SDK based on the instance of the application in the first container causing the first instance of the SDK to provide the lock request to allow the application to perform the device access operation.

17. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions further cause the device to: Before performing the locking operation, verifying that the embedded device is not locked based on another locking request received from a different instance of the SDK running in a different container than the first container, The locking operation is performed based on verifying that the embedded device is not locked.

18. The non-transitory computer-readable medium of claim 15, wherein the lock request identifies a number of the set of embedded devices to be used in conjunction with the device access operation, wherein the one or more instructions further cause the device to: Before performing the locking operation, identifying a set of embedded devices in the set of embedded devices that can be used in conjunction with the device access operation, wherein based on identifying the set of embedded devices, the locking operation is performed on the set of embedded devices, The embedded device is one of the group of embedded devices.

19. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions that cause the one or more processors to detect the unlock event cause the one or more processors to: receiving an unlock request from the first instance of the SDK, Receiving the unlock request corresponds to the unlock event.

20. The non-transitory computer-readable medium of claim 15, wherein the device access operation comprises at least one of: a read operation associated with the embedded device, or A write operation associated with the embedded device.

Images