WO2018045926A1 - 用于访问容器的方法和装置 - Google Patents

用于访问容器的方法和装置 Download PDF

Info

Publication number
WO2018045926A1
WO2018045926A1 PCT/CN2017/100351 CN2017100351W WO2018045926A1 WO 2018045926 A1 WO2018045926 A1 WO 2018045926A1 CN 2017100351 W CN2017100351 W CN 2017100351W WO 2018045926 A1 WO2018045926 A1 WO 2018045926A1
Authority
WO
WIPO (PCT)
Prior art keywords
container
driving
instances
target
driver
Prior art date
Application number
PCT/CN2017/100351
Other languages
English (en)
French (fr)
Inventor
黄强
张伟
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP17848099.2A priority Critical patent/EP3499365A4/en
Priority to KR1020197009003A priority patent/KR102176298B1/ko
Publication of WO2018045926A1 publication Critical patent/WO2018045926A1/zh
Priority to US16/294,591 priority patent/US11321109B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances

Definitions

  • the embodiments of the present application relate to the field of computers, and in particular, to a method and apparatus for accessing a container.
  • the container engine can be used to manage containers. Users can run multiple types of containers through a container engine, such as Linux containers and container virtual machines. However, when managing multiple different types of containers through a container engine, it is necessary to manage the driver instances used to drive different types of containers through different programs. At this time, the management in the container engine is increased to drive different types of containers. The running overhead of the program that drives the instance. The following is an example of the container engine Docker.
  • Docker is an open source container engine designed to provide an automated deployment solution for an application. Based on the technology of Linux container technology, it combines various technologies and innovations to make the application of the container very convenient and efficient. Its concept of image and mirror warehouse makes it easy to establish and run the application. , mobile, and derived from the surrounding ecosystem, greatly reducing the workload and complexity of the application in deployment and distribution. Docker has greatly promoted the development of Linux container technology and has become the benchmark and de facto industry standard for Linux container technology applications in recent years.
  • Figure 1 shows a schematic block diagram of the Docker architecture.
  • the type of the execution driver of the container that is, the local/container (Native/run container).
  • Native/runc driver instance ie Docker default driver instance
  • Linux container Linux Container
  • LXC Linux Container
  • the present application provides a method and apparatus for accessing a container to reduce the running overhead of a program in a container engine that manages driver instances for driving different types of containers, for example, in Docker, the Docker Daemon can be reduced.
  • the running overhead is a method and apparatus for accessing a container to reduce the running overhead of a program in a container engine that manages driver instances for driving different types of containers, for example, in Docker, the Docker Daemon can be reduced.
  • the running overhead is a method and apparatus for accessing a container to reduce the running overhead of a program in a container engine that manages driver instances for driving different types of containers, for example, in Docker, the Docker Daemon can be reduced.
  • a method for accessing a container comprising: receiving a container access request, for example, the container access request may be sent by a Docker client (Client), and the container access request is used to request access to a target container; Selecting a driver instance corresponding to the target container from multiple driver instances currently running, different driver instances of the multiple driver instances are used to drive different types of containers, and the multiple driver instances are managed by the same program.
  • the plurality of driver instances are all managed by the Docker daemon Daemon; the container access request is sent to the driver instance corresponding to the target container.
  • each of the plurality of driver instances corresponds to one driver, and different drivers are used to drive different types of containers.
  • the method may be performed by a router, which may be set in an execution driver for scheduling a container access request sent by a user.
  • the above multiple driver instances are managed by the same program, and may refer to that the above multiple driver instances are managed by the same daemon, which may be a background service process in the operating system. For example, in Docker it can be Docker Daemon.
  • a driver instance for driving different types of containers is managed by a program, so that a user can access a plurality of different types of containers through one program, avoiding different drivers managed by different programs in the prior art. Instances that access different types of containers reduce the operational overhead of programs in the container engine that manage multiple driver instances.
  • a driver instance for driving different types of containers can be managed by a Docker Daemon, so that a user can access multiple different types of containers through a Docker Daemon, thereby avoiding
  • different types of containers are accessed through different driver instances managed by different Docker Daemons, reducing the running overhead of the Docker Daemon in the Docker system.
  • a set of Docker Application Programming Interfaces can be used to access multiple types of containers, improving the flexibility of accessing containers through the Docker Daemon.
  • the receiving the container access request further includes: receiving, by the Docker Daemon, the container access request sent by the Docker client (Client).
  • the router can receive the container access request through the Docker Daemon.
  • the method further includes: receiving a container running request, for example, the container access request may be sent by a Docker Client, and the container running request carries the a type of the driving instance corresponding to the target container; determining, according to the type of the driving instance corresponding to the target container, a driving instance corresponding to the target container from the plurality of driving instances; and sending the driving instance corresponding to the target container The container runs the request.
  • a container running request for example, the container access request may be sent by a Docker Client, and the container running request carries the a type of the driving instance corresponding to the target container; determining, according to the type of the driving instance corresponding to the target container, a driving instance corresponding to the target container from the plurality of driving instances; and sending the driving instance corresponding to the target container The container runs the request.
  • a driver instance for driving different types of containers is managed by a program, so that a user can run a plurality of different types of containers through one program, thereby avoiding the management of different driver instances by different programs in the prior art. Run different types of containers to reduce the running overhead of programs in the container engine that manage multiple driver instances.
  • a set of Docker Application Programming Interfaces can run multiple types of containers, increasing the flexibility of managing containers through the Docker Daemon.
  • the receiving the container access request includes: receiving the container access request, the container access request carrying a container IP of the target container; and selecting the target container from a plurality of currently running driving instances
  • the corresponding driving instance includes: selecting, according to the container IP of the target container, a driving instance corresponding to the target container from the plurality of driving instances.
  • the target container is accessed according to the container IP of the target container by carrying the container IP of the target container in the container access request.
  • the receiving a container access request includes: receiving the container access request, and the container access request carrying Determining, by the container ID of the target container, the driving instance corresponding to the target container from the plurality of currently running driving instances, including: selecting, according to the container ID of the target container, the plurality of driving instances The driver instance corresponding to the target container.
  • the driver instance may determine, according to the container ID of the target container carried in the container access request, the target container accessed by the container access request, and the driver instance sends the container access request to the target container.
  • the target container accessed by the container access request is determined according to the container ID, so that the user accesses the target container.
  • the container access request may carry the container ID of the target container and the container type of the target container, and the driving instance corresponding to the target container may be selected from the multiple driving instances according to the container type of the target container.
  • the driver instance may determine, according to the container ID, a target container that the container access request needs to access, and the driver instance sends the container access request to the target container.
  • the storage space (for example, Docker) stores the storage relationship between the container ID and the container type (or the mapping relationship between the container ID and the container type).
  • the selecting the target from the multiple driving instances according to the container ID of the target container includes: determining, according to the container ID of the target container, a mapping relationship between the container ID and the container type, determining a container type of the target container; according to the container type of the target container, and the container type and driving a mapping relationship of the type of the instance, and selecting a driving instance corresponding to the target container from the plurality of driving instances.
  • mapping relationship between the container ID and the container type, and the mapping relationship between the container type and the type of the driving instance are determined, and the driving instance corresponding to the target container is determined, so that the user accesses the target container through the driving instance corresponding to the target container.
  • the selecting the target from the multiple driving instances according to the container ID of the target container Container corresponding drive includes: selecting, according to the container ID of the target container, a mapping relationship between the container ID and the type of the driving instance, selecting a driving instance corresponding to the target container from the multiple driving instances.
  • the mapping instance corresponding to the target container is determined by the mapping relationship between the container ID and the type of the driving instance, so that the user accesses the target container through the driving instance corresponding to the target container.
  • an apparatus for accessing a container comprising means for performing the method of the first aspect.
  • the present application provides an apparatus for accessing a container, the apparatus comprising: a memory, a processor, an input/output interface, a communication interface, and a bus system.
  • the memory, the processor, the input/output interface, and the communication interface are connected by a bus system for storing instructions for executing instructions stored by the memory, and when the instructions are executed, the processor passes The communication interface performs the method of the first aspect, and controls the input/output interface to receive input data and information, and output data such as an operation result.
  • the present application provides a computer readable storage medium for storing program code for transmitting a search request, the program code for executing the method instructions in the first aspect.
  • the above driver instance may be a driver sub-module in an execution driver.
  • the plurality of driver instances are managed by the same program, and the plurality of driver instances may be included to be managed by the same process.
  • Figure 1 shows a schematic block diagram of the Docker architecture.
  • FIG. 2 shows a schematic block diagram of a Docker system architecture for a method of accessing a container in accordance with an embodiment of the present application.
  • FIG. 3 shows a schematic block diagram of another Docker system architecture for a method of accessing a container in accordance with an embodiment of the present application.
  • FIG. 4 shows a schematic flow diagram of a method for accessing a container in accordance with an implementation of the present application.
  • FIG. 5 shows a schematic block diagram of an apparatus for accessing a container in accordance with an embodiment of the present application.
  • FIG. 6 shows a schematic block diagram of an apparatus for accessing a container in accordance with another embodiment of the present application.
  • the LXC technology in the Docker architecture is a lightweight virtualization technology.
  • the principle is that the operating system-based kernel provides different system views for different running processes. This isolation can be used to authorize access to hardware resources while maintaining security and efficiency.
  • LXC is isolated by using the kernel's namespace. In other words, multiple LXCs still share a single core. Compared with traditional virtualization technology, LXC technology has lower loss and higher performance. At the same time, there are disadvantages of insufficient isolation and security. When serving some applications that require high security, LXC cannot meet the security requirements of the application.
  • a container virtual machine which is essentially using traditional virtualization technologies, such as virtual operating system simulator (QEMU), combined with mirrors, warehouses, etc. in the Docker ecosystem.
  • QEMU virtual operating system simulator
  • the container or container virtual machine can be selected for the application according to the security requirements of different applications.
  • the embodiment of the present application proposes a different type of driver by Docker Daemon. The idea of managing instances to implement a solution for running different types of containers through a Docker Daemon.
  • FIG. 2 a schematic block diagram of a Docker system architecture for a method for accessing a container according to an embodiment of the present application will be briefly described with reference to FIG.
  • the client shown in Figure 2 can be a Docker Client
  • the daemon can be a Docker Daemon
  • the execution driver can be an execution driver, where the execution driver includes different types of driver instances.
  • the Docker Daemon, the execution driver, the driver instance, and the container can be on a single physical host.
  • the Docker Daemon, the execution driver, the driver instance, and the container can also be on a virtual machine.
  • the Docker Client and the Docker Daemon can be on one physical host or virtual machine, or on different physical hosts or virtual machines. This application does not specifically limit this.
  • the Docker Daemon can use the prior art process of initializing the driver instance in the execution driver layer, and sequentially initialize different types of driver instances in the execution driver layer, or use other methods to simultaneously execute the execution. Different types of driver instances in the driver layer are initialized, which is not specifically limited in this application.
  • the user can use the Docker Client to establish communication with the Docker Daemon and send a request to the Docker Daemon, which can include container access requests, container run requests, and so on.
  • Docker Daemon can first provide the functionality of Docker Server, receive requests from Docker Client, and then send requests to the engine in Docker Daemon.
  • Engine can perform a series of tasks inside Docker. Every job can exist in the form of a job, that is, the Job can be considered as the most basic work execution unit inside the Engine.
  • the Job can download the image from the Docker Registry and store the downloaded image in the form of a Graph through the Graph driver; when it needs to be created for Docker In the network environment, the Job can create and configure the container's network environment through the network driver; when it is necessary to restrict the container to run resources or perform user instructions, the Job can be completed by executing the Execution driver.
  • Docker can directly call libcontainer, a separate container management package that ultimately manipulates the container's namespace, control group, cgroup, network devices, and firewall rules.
  • an actual container is in a running state, and the container can have an independent File system, as well as an independent and relatively safe operating environment.
  • FIG. 3 shows a schematic block diagram of another Docker system architecture for a method of accessing a container in accordance with an embodiment of the present application. It should be understood that the functions of the various modules in the Docker architecture shown in FIG. 3 are the same as those of the modules shown in FIG. 2, and only the parts related to the present application in the Docker architecture are shown, and other functional modules not shown. Can be the same as other modules in the current Docker architecture. For the sake of brevity, reference may be made to the above description, and details are not described herein again.
  • the execution driver layer can be independent of the daemon, specific driver instances (for example, Native/runc shown in Figure 3, a built-in container driver).
  • Example; LXC, driver instance of LXC container; runv a driver instance of a container virtual machine) can also be independent of the execution driver layer. It should be noted that the above independent existence may refer to two independent processes.
  • the architecture shown in FIG. 2 and FIG. 3 above may also be modified.
  • the daemon and the execution driver may be two independent processes, but a specific driver instance may be used as a segment in the execution driver process.
  • the logic, that is, the specific driver instance is no longer independent of the execution driver layer.
  • the present application does not specifically limit the Docker architecture shown in FIG. 2 and FIG. 3 above.
  • FIG. 4 shows a schematic flow diagram of a method for accessing a container in accordance with an implementation of the present application.
  • the method shown in FIG. 4 can be performed by the router in FIG. 2 or 3.
  • FIG. 4 illustrates detailed steps or operations of a method for accessing a container, but these steps or operations are merely examples, and other embodiments of the present application may be performed, or variations of the operations of FIG.
  • the various steps in FIG. 4 may be performed in a different order than that presented in FIG. 4, and it is possible that not all operations in FIG. 4 are to be performed.
  • the method steps shown in Figure 4 are described in detail below.
  • the client sends a container access request to the router, where the container access request is used to request access to the target container.
  • the above router is used to schedule a request sent by a user, and the request may include a container access request and/or a container running request.
  • the above container access request may carry the container ID of the target container or the container IP of the target container for the router to determine the target container for which the container access request is accessed.
  • the foregoing client may be a Docker Client, and the Docker Client and the Docker Daemon may be on a physical host or a virtual machine, or may be on different physical hosts or virtual machines, which is not specifically limited in this application.
  • the above router can be a piece of logic in the execution driver
  • the execution driver can be a piece of logic in the Docker Daemon process
  • the execution driver and the Docker Daemon can be two different processes.
  • the router selects a driving instance corresponding to the target container from multiple driving instances that are currently running, and different driving instances of the multiple driving instances are used to drive different types of containers, and the multiple driving instances pass the same
  • the Docker daemon is managed by Daemon.
  • each of the plurality of driver instances corresponds to one driver, and different drivers are used to drive different types of containers.
  • the above multiple driver instances are managed by the same Docker Daemon, which can initialize each of the above multiple driver instances at startup.
  • the router sends the container access request to a driver instance corresponding to the target container.
  • the router can access the target container through a driver instance corresponding to the target container.
  • a driver instance for driving different types of containers can be managed by a Docker Daemon, allowing users to access multiple different types of containers through a Docker Daemon, that is, specific to the Docker Daemon and the execution driver.
  • the "strong binding" mode of a driver instance is changed to the Docker Daemon's mode of managing multiple specific driver instances in the execution driver, avoiding the different driver instances managed by different Docker Daemons in the prior art. Access to different types of containers reduces the operational overhead of the Docker Daemon in the Docker system.
  • a set of Docker Application Programming Interfaces can be used to access multiple types of containers, improving the flexibility of accessing containers through the Docker Daemon.
  • step 410 the container access request is received, where the container access request carries a container ID of the target container; in step 420, according to the container ID of the target container, Selecting a driving instance corresponding to the target container from the plurality of driving instances.
  • the receiving container access request may refer to that the router receives the container access request sent by the Docker Client, where the container access request may carry the container ID of the target container, and the router may obtain related information of the target container according to the container ID, for example, the target container. Container type, etc.
  • the router may select a driver instance corresponding to the target container from multiple different types of driver instances in the Execution Driver layer according to the container type of the obtained target container.
  • selecting a driving instance corresponding to the target container from the plurality of driving instances is implemented by various specific implementation manners, for example, the router may pass the pre-established container ID according to the container ID of the target container.
  • the mapping relationship of the driving instance directly determines the driving instance corresponding to the target container; the router can also determine the driving instance corresponding to the target container by using the mapping relationship between the pre-established container ID and the driving instance type according to the container ID of the target container.
  • the manner in which the above-mentioned driving example corresponding to the target container is selected is not specifically limited.
  • the selecting, according to the container ID of the target container, the driving instance corresponding to the target container from the multiple driving instances including: according to the container ID of the target container, and a mapping relationship between the container ID and the container type, determining a container type of the target container; selecting, according to a container type of the target container, and a mapping relationship between the container type and the type of the driving instance, selecting the plurality of driving instances The driver instance corresponding to the target container.
  • a field may be added, which may record the mapping relationship between the container ID and the container type, and/or the mapping relationship between the container type and the type of the driving instance.
  • mapping relationship between the container ID and the container type, and/or the mapping relationship between the container type and the type of the driver instance may be pre-established at the time of the Docker Daemon initialization, which is not specifically limited in this application.
  • the selecting, according to the container ID of the target container, the driving instance corresponding to the target container from the multiple driving instances including: according to the container ID of the target container, and a mapping relationship between the container ID and the type of the driving instance, and selecting a driving instance corresponding to the target container from the plurality of driving instances.
  • a field can be added, which can record the mapping relationship between the container ID and the type of the driver instance.
  • mapping relationship between the above-mentioned container ID and the type of the driver instance may be pre-established at the time of initialization of the Docker Daemon, which is not specifically limited in this application.
  • the method further includes: Step 440 to Step 450.
  • the receiving container running request may refer to the router receiving the container running request sent by the Docker Client.
  • the above container running request carries the type of the driving instance corresponding to the target container, that is, the container running request may indicate that a container is running.
  • the router determines, according to the type of the driving instance corresponding to the target container, the driving instance corresponding to the target container from the multiple driving instances.
  • the Docker Client sends the above container run request to the router, that is, the container runs the request to enter the router in the execution driver layer, and the router can analyze the container run request to determine the "exec-driver" in the container run request.
  • the parameter that determines the type of driver instance specified by the container run request is the container run request to determine the "exec-driver" in the container run request.
  • the initialization time of the above multiple running driver instances may be performed during the initialization of the Docker Daemon, or after the Docker Daemon is run, when the container running access request sent by the Docker Client is received, it is determined that the operation needs to be run.
  • the type of the driver instance to be initialized is determined according to the type of the target container, and the driver instance corresponding to the type of the driver instance is initialized.
  • the added step of analyzing the container running request does not change the usage of the interface and other parameters in the original Docker architecture.
  • the router sends a container running request to the driver instance corresponding to the target container.
  • the router can run a target container through the driver instance corresponding to the target container.
  • a driver instance for driving different types of containers is managed by a program, so that a user can run multiple different types of containers through one program, that is, a specific driver instance in the Docker Daemon and the execution driver.
  • the "strong binding" mode is changed to the mode in which Docker Daemon manages multiple specific driver instances in the execution driver, avoiding different types of driver instances managed by different programs in the prior art.
  • a set of Docker Application Programming Interfaces can run multiple types of containers, increasing the flexibility of managing containers through the Docker Daemon.
  • FIG. 5 shows a schematic block diagram of an apparatus for accessing a container in accordance with an embodiment of the present application.
  • the apparatus 500 shown in FIG. 5 includes: a first receiving module 510, a first selecting module 520, and a first sending module 530.
  • a first receiving module 510 configured to receive a container access request, where the container access request is used to request access to a target container;
  • a first selection module 520 configured to select a driving instance corresponding to the target container from a plurality of currently running driving instances, where different driving instances of the multiple driving instances are used to drive different types of containers, the multiple The driver instance is managed by the same program;
  • the first sending module 530 is configured to send the container access request to a driving instance corresponding to the target container selected by the first selecting module.
  • a driver instance for driving different types of containers is managed by a program, so that a user can access a plurality of different types of containers through one program, avoiding different drivers managed by different programs in the prior art. Instances that access different types of containers reduce the operational overhead of programs in the container engine that manage multiple driver instances.
  • multiple driver instances through the same program management may refer to managing multiple driver instances through the same Docker Daemon, in which a Docker Daemon is used to manage different types of containers.
  • the driver instance allows the user to access multiple different types of containers through a Docker Daemon, avoiding the different types of containers accessed by different Docker Daemons in the prior art, reducing the Docker Daemon in the Docker system. Running overhead.
  • a set of Docker Application Programming Interfaces can be used to access multiple types of containers, improving the flexibility of accessing containers through the Docker Daemon.
  • the apparatus 500 further includes: a second receiving module, configured to receive a container running request, where the container running request carries a type of a driving instance corresponding to the target container; and a second selecting module, And the driving instance corresponding to the target container is selected from the plurality of driving instances according to the type of the driving instance corresponding to the target container; and the second sending module is configured to send the driving instance corresponding to the target container The container runs the request.
  • a second receiving module configured to receive a container running request, where the container running request carries a type of a driving instance corresponding to the target container
  • a second selecting module And the driving instance corresponding to the target container is selected from the plurality of driving instances according to the type of the driving instance corresponding to the target container
  • the second sending module is configured to send the driving instance corresponding to the target container The container runs the request.
  • the first receiving module is specifically configured to: receive the container access request, where the container access request carries a container ID of the target container; the first selecting module is specifically configured to: And selecting, according to the container ID of the target container, a driving instance corresponding to the target container from the plurality of driving instances.
  • the first selection module is further configured to: determine, according to a container ID of the target container, a mapping relationship between the container ID and the container type, determine a container type of the target container; a container type of the target container, and a mapping relationship between the container type and the type of the driving instance, and selecting a driving instance corresponding to the target container from the plurality of driving instances.
  • the first selecting module is further configured to: select, according to a container ID of the target container, a mapping relationship between the container ID and a type of the driving instance, from the multiple driving instances.
  • FIG. 6 shows a schematic block diagram of an apparatus for accessing a container in accordance with another embodiment of the present application.
  • the apparatus 600 shown in FIG. 6 includes a memory 610, a processor 620, an input/output interface 630, a communication interface 640, and a bus system 650.
  • the memory 610, the processor 620, the input/output interface 630, and the communication interface 640 are connected by a bus system 660 for storing instructions for executing instructions stored in the memory 610 to control input/
  • the output interface 630 receives the input data and information, outputs data such as an operation result, and controls the communication interface 640 to transmit a signal.
  • the processor 620 is configured to select a driving instance corresponding to the target container from multiple currently running multiple driving instances, where different driving instances of the multiple driving instances are used to drive different types of containers, the multiple driving instances Managed by the same procedure;
  • the input/output interface 630 is configured to send the container access request to a driver instance corresponding to the target container.
  • the processor 620 may be a general-purpose central processing unit (CPU), a microprocessor, an application specific integrated circuit (ASIC), or one or more.
  • CPU central processing unit
  • ASIC application specific integrated circuit
  • communication interface 640 implements a mobile terminal using transceivers such as, but not limited to, transceivers. Communication between 600 and other devices or communication networks.
  • the memory 610 can include read only memory and random access memory and provides instructions and data to the processor 620.
  • a portion of the processor 620 can also include a non-volatile random access memory.
  • the processor 620 can also store information of the device type.
  • the bus system 650 may include a power bus, a control bus, a status signal bus, and the like in addition to the data bus. However, for clarity of description, various buses are labeled as bus system 650 in the figure.
  • each step of the above method may be completed by an integrated logic circuit of hardware in the processor 620 or an instruction in a form of software.
  • the method for accessing a container disclosed in connection with the embodiments of the present application may be directly implemented as a hardware processor execution, or may be performed by a combination of hardware and software modules in the processor.
  • the software module can be located in a conventional storage medium such as random access memory, flash memory, read only memory, programmable read only memory or electrically erasable programmable memory, registers, and the like.
  • the storage medium is located in the memory 610, and the processor 620 reads the information in the memory 610 and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.
  • a driver instance for driving different types of containers is managed by a program, so that a user can access a plurality of different types of containers through one program, avoiding different drivers managed by different programs in the prior art. Instances that access different types of containers reduce the operational overhead of programs in the container engine that manage multiple driver instances.
  • multiple driver instances through the same program management may refer to managing multiple driver instances through the same Docker Daemon, in which a Docker Daemon is used to manage different types of containers.
  • the driver instance allows the user to access multiple different types of containers through a Docker Daemon, avoiding the different types of containers accessed by different Docker Daemons in the prior art, reducing the Docker Daemon in the Docker system. Running overhead.
  • a set of Docker Application Programming Interfaces can be used to access multiple types of containers, improving the flexibility of accessing containers through the Docker Daemon.
  • B corresponding to A means that B is associated with A, and B can be determined according to A.
  • determining B from A does not mean that B is only determined based on A, and that B can also be determined based on A and/or other information.
  • the size of the sequence numbers of the foregoing processes does not mean the order of execution sequence, and the order of execution of each process should be determined by its function and internal logic, and should not be applied to the embodiment of the present application.
  • the implementation process constitutes any limitation.
  • the disclosed systems, devices, and methods may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • there may be another division manner for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in an electrical, mechanical or other form.
  • the units described as separate components may or may not be physically separate, displayed as a unit
  • the components may or may not be physical units, ie may be located in one place or may be distributed over multiple network elements. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the computer program product includes one or more computer instructions.
  • the computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable device.
  • the computer instructions can be stored in a computer readable storage medium or transferred from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be from a website site, computer, server or data center Transmission to another website site, computer, server, or data center by wire (eg, coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (eg, infrared, wireless, microwave, etc.).
  • the computer readable storage medium can be any available media that can be read by a computer or a data storage device such as a server, data center, or the like that includes one or more available media.
  • the usable medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a Digital Video Disc (DVD)), or a semiconductor medium (eg, a Solid State Disk (SSD)). )Wait.
  • a magnetic medium eg, a floppy disk, a hard disk, a magnetic tape
  • an optical medium eg, a Digital Video Disc (DVD)
  • DVD Digital Video Disc
  • SSD Solid State Disk

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

本申请公开了一种用于访问容器的方法和装置，该方法包括：接收容器访问请求，所述容器访问请求用于请求访问目标容器；从当前运行的多个驱动实例中选取所述目标容器对应的驱动实例，所述多个驱动实例中的不同驱动实例用于驱动不同类型的容器，所述多个驱动实例通过相同的程序进行管理；向所述目标容器对应的驱动实例发送所述容器访问请求。在该方案中，通过一个程序管理用于驱动不同类型的容器的驱动实例，使得用户通过一个程序可以访问多个不同类型的容器，避免了现有技术中，通过不同的程序管理的不同的驱动实例，访问不同类型的容器，减少容器引擎中管理多个驱动实例的程序的运行开销。

Description

用于访问容器的方法和装置
本申请要求于2016年9月07日提交中国专利局、申请号为201610806797.3、发明名称为“用于访问容器的方法和装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及计算机领域，尤其涉及一种用于访问容器的方法和装置。
背景技术
容器引擎可以用于对容器进行管理，用户可以通过一个容器引擎运行多种类型的容器，例如，Linux容器和容器虚拟机等。然而，在通过一个容器引擎管理多种不同类型的容器时，需要通过不同的程序管理用于驱动不同类型的容器的驱动实例，此时，会增加容器引擎中的管理用于驱动不同类型的容器的驱动实例的程序的运行开销。下面以容器引擎Docker为例具体介绍。
Docker是一个开源的容器引擎，旨在提供一种应用的自动化部署解决方案。它在Linux容器技术的基础上，结合多种技术和创新，使得容器的应用变得非常方便和高效，它提出的镜像(image)和镜像仓库等概念，使得可以方便地对应用进行建立、运行、移动，并衍生出了周边生态系统，极大的减少了应用在部署和分发上的工作量和复杂度。Docker极大的推动了Linux容器技术的发展，成为近些年Linux容器技术应用的标杆和事实上的业界标准。
图1示出了Docker架构的示意性框图。从图1所示的Docker架构中可以看出，在启动Docker守护程序(Daemon)时，需要指定容器的执行驱动(execution driver)的类型，也就是说，需要从本地/容器(Native/run container，Native/runc)驱动实例(即Docker默认的驱动实例)和Linux容器(Linux Container，LXC)驱动实例中选择一个执行驱动，图1仅以选择Native/runc的驱动实例为例进行说明。选择Native/runc的驱动实例之后，对Native/runc的驱动实例进行初始化，在之后运行的所有容器都是由Native/runc的驱动实例进行驱动，并且Native/runc的驱动实例只能驱动与Native/runc的驱动实例对应的一种类型的容器。也就是说，由于Docker Daemon和execution driver属于“强绑定”关系，使得在一台主机的一个Docker Daemon上只能运行一种类型的容器，当需要运行其他类型的容器时，则需要再运行一个Docker Deamon。此时，会增加Docker中Docker Daemon的运行开销。
发明内容
本申请提供一种用于访问容器的方法和装置，以减少容器引擎中管理用于驱动不同类型的容器的驱动实例的程序的运行开销，例如，在Docker中，可以减少Docker Daemon 的运行开销。
第一方面，提供一种用于访问容器的方法，包括：接收容器访问请求，例如，该容器访问请求可以是Docker客户端(Client)发送的，所述容器访问请求用于请求访问目标容器；从当前运行的多个驱动实例中选取所述目标容器对应的驱动实例，所述多个驱动实例中的不同驱动实例用于驱动不同类型的容器，所述多个驱动实例通过相同的程序管理，例如，该多个驱动实例均通过Docker守护程序Daemon管理；向所述目标容器对应的驱动实例发送所述容器访问请求。
具体地，上述多个驱动实例中的每个驱动实例对应一种驱动程序，不同的驱动程序用于驱动不同类型的容器。
需要说明的是，该方法可以由路由器(router)执行，该路由器可以设置在execution driver中，用于对用户发送的容器访问请求进行调度。
应理解，上述多个驱动实例通过相同的程序管理，可以指上述多个驱动实例通过相同的守护程序管理，该守护程序可以是操作系统中的后台服务进程。例如，在Docker中可以是Docker Daemon。
在该方案中，通过一个程序管理用于驱动不同类型的容器的驱动实例，使得用户通过一个程序可以访问多个不同类型的容器，避免了现有技术中，通过不同的程序管理的不同的驱动实例，访问不同类型的容器，减少容器引擎中管理多个驱动实例的程序的运行开销。
进一步地，当上述容器引擎为Docker时，在该方案中，可以通过一个Docker Daemon管理用于驱动不同类型的容器的驱动实例，使得用户通过一个Docker Daemon可以访问多个不同类型的容器，避免了现有技术中，通过不同的Docker Daemon管理的不同的驱动实例，访问不同类型的容器，减少Docker系统中Docker Daemon的运行开销。
并且，通过一个Docker Daemon，使用一套Docker应用程序编程接口(Application Programming Interface，API)可以对多种类型的容器进行访问，可以提高通过Docker Daemon访问容器的灵活性。
可选地，上述接收容器访问请求，还包括：通过Docker Daemon接收Docker客户端(Client)发送的所述容器访问请求。
具体地，当router所在的execution driver与Docker Daemon为两个相互独立的进程时，router可以通过Docker Daemon接收容器访问请求。
在该方案中，通过将router所在的execution driver与Docker Daemon解耦为两个相互独立的进程，便于后续使用过程中对execution driver与Docker Daemon的维护。
结合第一方面，在第一方面的一种可能的实现方式中，所述方法还包括：接收容器运行请求，例如，该容器访问请求可以是Docker Client发送的，所述容器运行请求携带所述目标容器对应的驱动实例的类型；根据所述目标容器对应的驱动实例的类型，从所述多个驱动实例中确定所述目标容器对应的驱动实例；向所述目标容器对应的驱动实例发送所述容器运行请求。
在该方案中，通过一个程序管理用于驱动不同类型的容器的驱动实例，使得用户通过一个程序可以运行多个不同类型的容器，避免了现有技术中，通过不同的程序管理不同的驱动实例，运行不同类型的容器，减少容器引擎中管理多个驱动实例的程序的运行开销。
进一步地，当上述容器引擎为Docker时，在该方案中，通过一个Docker Daemon管 理用于驱动不同容器类型的驱动实例，使得用户通过一个Docker Daemon可以运行多个不同类型的容器，避免了现有技术中，通过不同的Docker Daemon管理的不同的驱动实例，运行不同类型的容器，减少Docker系统中Docker Daemon的运行开销。
并且，通过一个Docker Daemon，使用一套Docker应用程序编程接口(Application Programming Interface，API)可以运行多种类型的容器，提高通过Docker Daemon管理容器的灵活性。
可选地，所述接收容器访问请求，包括：接收所述容器访问请求，所述容器访问请求携带所述目标容器的容器IP；所述从当前运行的多个驱动实例中选取所述目标容器对应的驱动实例，包括：根据所述目标容器的容器IP，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
在该方案中，通过在容器访问请求中携带目标容器的容器IP，根据该目标容器的容器IP，以对目标容器进行访问。
结合第一方面或上述任一种可能的实现方式，在第一方面的一种可能的实现方式中，所述接收容器访问请求，包括：接收所述容器访问请求，所述容器访问请求携带所述目标容器的容器ID；所述从当前运行的多个驱动实例中选取所述目标容器对应的驱动实例，包括：根据所述目标容器的容器ID，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
具体地，驱动实例可以根据容器访问请求中携带的目标容器的容器ID，确定该容器访问请求访问的目标容器，该驱动实例将该容器访问请求发送至目标容器。
在该方案中，通过在容器访问请求中携带目标容器的容器ID，根据容器ID确定该容器访问请求访问的目标容器，以便用户访问目标容器。
可选地，上述容器访问请求可以携带目标容器的容器ID和目标容器的容器类型，可以根据目标容器的容器类型，从上述多个驱动实例中选取目标容器对应的驱动实例。
具体地，驱动实例可以根据容器ID确定该容器访问请求需要访问的目标容器，该驱动实例将该容器访问请求发送至该目标容器。
在该方案中，通过在容器访问请求中携带目标容器的容器类型和容器ID，对目标容器进行访问，与在容器访问请求中仅携带目标容器的容器ID的实施例相比，节省了在容器引擎(例如，Docker)中存储容器ID与容器类型的映射关系(或容器ID和容器类型的映射关系)的存储空间。
结合第一方面或上述任一种可能的实现方式，在第一方面的一种可能的实现方式中，所述根据所述目标容器的容器ID，从所述多个驱动实例中选取所述目标容器对应的驱动实例，包括：根据所述目标容器的容器ID，以及容器ID与容器类型的映射关系，确定所述目标容器的容器类型；根据所述目标容器的容器类型，以及容器类型与驱动实例的类型的映射关系，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
在该方案中，通过容器ID与容器类型的映射关系，和容器类型与驱动实例的类型的映射关系，确定目标容器对应的驱动实例，以便用户通过该目标容器对应的驱动实例访问目标容器。
结合第一方面或上述任一种可能的实现方式，在第一方面的一种可能的实现方式中，所述根据所述目标容器的容器ID，从所述多个驱动实例中选取所述目标容器对应的驱动 实例，包括：根据所述目标容器的容器ID，以及容器ID与驱动实例的类型的映射关系，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
在该方案中，通过容器ID与驱动实例的类型的映射关系，确定目标容器对应的驱动实例，以便用户通过该目标容器对应的驱动实例访问目标容器。
第二方面中，提供一种用于访问容器的装置，所述装置包括用于执行第一方面中的方法的模块。
第三方面，本申请提供一种用于访问容器的装置，所述装置包括：存储器、处理器、输入/输出接口、通信接口和总线系统。其中，存储器、处理器、输入/输出接口和通信接口通过总线系统相连，该存储器用于存储指令，该处理器用于执行该存储器存储的指令，当所述指令被执行时，所述处理器通过所述通信接口执行第一方面的方法，并控制输入/输出接口接收输入的数据和信息，输出操作结果等数据。
第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质用于存储发送搜索请求的方法的程序代码，所述程序代码用于执行第一方面中的方法指令。
在某些实现方式中，上述驱动实例可以是execution driver中的驱动子模块。
在某些实现方式中，上述多个驱动实例通过相同的程序管理，可以包括该多个驱动实例通过相同的进程管理。
附图说明
图1示出了Docker架构的示意性框图。
图2示出了根据本申请实施例的用于访问容器的方法的Docker系统架构的示意性框图。
图3示出了根据本申请实施例的另一用于访问容器的方法的Docker系统架构的示意性框图。
图4示出了根据本申请实施的用于访问容器的方法的示意性流程图。
图5示出了根据本申请实施例的用于访问容器的装置的示意性框图。
图6示出了根据本申请另一实施例的用于访问容器的装置的示意性框图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
Docker架构中的LXC技术是一种轻量级虚拟化技术，它的原理是基于操作系统的内核对不同的运行进程提供了不同的系统视图。这种隔离可以用于在保证安全性和效率的情况下授权访问硬件资源。目前，LXC通过使用内核的命名空间(namespace)进行隔离，也就是说，实际上多个LXC仍然共享一份内核，跟传统虚拟化技术相比，LXC技术虽然损耗更小，性能更高，但同时存在隔离性和安全性不足的缺点。在为一些对安全性要求较高的应用提供服务时，LXC无法满足应用对于安全性的需求。
所以在为对安全性较高的应用提供服务时，可以选择容器虚拟机，其本质是使用传统的虚拟化技术，如虚拟操作系统模拟器(QEMU)，结合Docker生态中的镜像、仓库等应用，使得可以像使用LXC一样使用虚拟机。由于虚拟机可以为用户提供包括内核在内的一个完整的系统镜像，相对于LXC可以满足一些应用较高的安全性需求。
因此，可以根据不同应用的安全性需求，为应用选择容器或者容器虚拟机。为了解决现有技术中Docker Daemon一次只能运行一种驱动实例，而导致无法在通过一个Docker Daemon运行、访问不同种类的容器的问题，本申请实施例提出一种由Docker Daemon对不同类型的驱动实例进行管理的思想，以实现在通过一个Docker Daemon运行、访问不同种类的容器的方案。
为了便于理解，先结合图2，简单介绍根据本申请实施例的用于访问容器的方法的Docker系统架构的示意性框图。在图2所示的客户端可以是Docker Client，守护程序可以是Docker Daemon，执行驱动程序可以是execution driver，其中，execution driver中包括不同类型的驱动实例。
应理解，图2中仅以Native/runc、LXC、runv作为具体的驱动实例进行说明，驱动实例可以包括其他类型的驱动实例。图2所示的Docker架构中也可以运行访问其他类型的容器。
还应理解，图2中只示出了Docker系统架构中与本申请有关的各个模块，图2所示的系统架构中还可以包括Docker系统架构中的其他模块，本申请对此不做具体限定。
还应理解，在图2所示的Docker架构中，Docker Daemon、execution driver、驱动实例和容器可以在一台物理主机上。Docker Daemon、execution driver、驱动实例和容器还可以在一台虚拟机上。Docker Client和Docker Daemon可以在一台物理主机或虚拟机上，也可以在不同的物理主机或虚拟机上，本申请对此不做具体限定。
从图2所示的Docker架构中可以看出Docker Daemon不再和execution driver层的某一个驱动实例建立“强绑定”的关系，而是作为一个“管理者”对execution driver层中的驱动实例进行管理。
需要说明的是，Docker Daemon可以采用现有技术中对execution driver层中的驱动实例进行初始化的流程，依次对execution driver层中的不同类型的驱动实例进行初始化，也可以采用其他的方式同时对execution driver层中的不同类型的驱动实例进行初始化，本申请对此不做具体限定。
用户使用可以通过Docker Client与Docker Daemon建立通信，并向Docker Daemon发送请求，该请求可以包括容器访问请求、容器运行请求等。Docker Daemon作为Docker系统架构中的主体部分，首先可以提供Docker Server的功能，接收Docker Client发送的请求；然后将请求发送至Docker Daemon中的运行引擎(Engine)，Engine可以执行Docker内部的一系列工作，每一项工作都可以以一个Job的形式的存在，也就是说，Job可以认为是Engine内部最基本的工作执行单元。
Engine在运行Job的过程中，当需要容器镜像时，则Job可以从Docker Registry中下载镜像，并通过镜像管理驱动(Graph driver)将下载镜像以镜像(Graph)的形式存储；当需要为Docker创建网络环境时，Job可以通过网络管理驱动(network driver)创建并配置容器的网络环境；当需要限制容器运行资源或执行用户指令等操作时，Job可以通过执行驱动程序(Execution driver)来完成。
Docker可以直接调用libcontainer，即一项独立的容器管理包，最终操纵容器的命名空间(namespace)、控制族群(control group，cgroup)、网络设备以及防火墙规则等。
当执行完容器运行请求后，一个实际的容器就处于运行状态，该容器可以拥有独立的 文件系统，以及独立并且相对安全的运行环境等。
图3示出了根据本申请实施例的另一用于访问容器的方法的Docker系统架构的示意性框图。应理解，图3所示的Docker架构中各个模块的功能和图2所示的各个模块的功能相同，并且也只示出了Docker架构中与本申请相关的部分，其他未示出的功能模块可以与目前Docker架构中的其他模块相同。为了简洁，可以参考上文中的描述，在此不再赘述。
从图3所示的Docker架构可以看出，执行驱动程序(execution driver)层可以独立于守护程序，具体的驱动实例(例如，图3中所示的Native/runc，一种内置的容器的驱动实例；LXC，LXC容器的驱动实例；runv一种容器虚拟机的驱动实例)也可以独立于execution driver层。需要说明的是，上述的独立存在可以指两个相互独立的进程。
应理解，还可以对上述图2和图3所示的架构做变形，例如，守护程序和执行驱动程序可以是两个相互独立的进程，但是具体的驱动实例可以作为执行驱动程序进程中的一段逻辑，也就是说，具体的驱动实例不再独立于execution driver层。本申请对上述图2和图3所示的Docker架构不作具体限定。
图4示出了根据本申请实施的用于访问容器的方法的示意性流程图。图4所示的方法可以由图2或图3中的路由器(router)执行。应理解，图4示出了用于访问容器的方法的详细的步骤或操作，但这些步骤或操作仅是示例，本申请实施例还可以执行其他操作，或者图4中各操作的变形。此外，图4中的各个步骤可以按照与图4呈现的不同顺序来执行，并且有可能并非要执行图4中的全部操作。下面具体描述图4所示的方法步骤。
410，客户端向router发送容器访问请求，该容器访问请求用于请求访问目标容器。
具体地，上述router用于对用户发送的请求进行调度，该请求可以包括容器访问请求和/或容器运行请求。
应理解，上述容器访问请求可以携带目标容器的容器ID或者目标容器的容器IP，用于router确定该容器访问请求访问的目标容器。
还应理解，上述客户端可以是Docker Client，该Docker Client和Docker Daemon可以在一台物理主机或虚拟机上，也可以在不同的物理主机或虚拟机上，本申请对此不做具体限定。
需要说明的是，上述router可以是execution driver中的一段逻辑，execution driver可以是Docker Daemon进程中的一段逻辑，execution driver和Docker Daemon还可以是两个不同的进程。
420，router从当前运行的多个驱动实例中选取所述目标容器对应的驱动实例，所述多个驱动实例中的不同驱动实例用于驱动不同类型的容器，所述多个驱动实例通过相同的Docker守护程序Daemon进行管理。
具体地，上述多个驱动实例中的每个驱动实例对应一种驱动程序，不同的驱动程序用于驱动不同类型的容器。
上述多个驱动实例通过相同的Docker Daemon进行管理，该Docker Daemon可以在启动时，对上述多个驱动实例中的每个驱动实例进行初始化。
430，router向所述目标容器对应的驱动实例发送所述容器访问请求。
具体地，router可以通过目标容器对应的驱动实例访问该目标容器。
在该方案中，可以通过一个Docker Daemon管理用于驱动不同类型的容器的驱动实例，使得用户通过一个Docker Daemon可以访问多个不同类型的容器，也就是说，将Docker Daemon和execution driver中具体的一个驱动实例的“强绑定”模式，改变为Docker Daemon对execution driver中的多个具体的驱动实例进行管理的模式，避免了现有技术中，通过不同的Docker Daemon管理的不同的驱动实例，访问不同类型的容器，减少Docker系统中Docker Daemon的运行开销。
并且，通过一个Docker Daemon，使用一套Docker应用程序编程接口(Application Programming Interface，API)可以对多种类型的容器进行访问，可以提高通过Docker Daemon访问容器的灵活性。
可选地，作为一个实施例，在步骤410中，接收所述容器访问请求，所述容器访问请求携带所述目标容器的容器ID；在步骤420中，根据所述目标容器的容器ID，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
具体地，上述接收容器访问请求可以指router接收Docker Client发送的容器访问请求，该容器访问请求中可以携带目标容器的容器ID，router可以根据容器ID，获取目标容器的相关信息，例如目标容器的容器类型等。Router可以根据获取的目标容器的容器类型从Execution Driver层的多个不同类型的驱动实例中，选择与目标容器对应的驱动实例。
应理解，上述根据目标容器的容器ID，从多个驱动实例中选取目标容器对应的驱动实例由多种具体的实现方式，例如，router可以根据目标容器的容器ID，通过预先建立的容器ID和驱动实例的映射关系直接确定目标容器对应的驱动实例；router还可以根据目标容器的容器ID通过预先建立的容器ID和驱动实例类型的映射关系，确定目标容器对应的驱动实例。本申请对上述选取目标容器对应的驱动实例的方式不做具体限定。
可选地，作为一个实施例，所述根据所述目标容器的容器ID，从所述多个驱动实例中选取所述目标容器对应的驱动实例，包括：根据所述目标容器的容器ID，以及容器ID与容器类型的映射关系，确定所述目标容器的容器类型；根据所述目标容器的容器类型，以及容器类型与驱动实例的类型的映射关系，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
需要说明的是，可以在Docker Daemon维护的各个容器信息中，增加字段，该字段可以记录容器ID与容器类型的映射关系，和/或容器类型与驱动实例的类型的映射关系。
应理解，上述容器ID与容器类型的映射关系，和/或，容器类型与驱动实例的类型的映射关系，可以是在Docker Daemon初始化时预先建立的，本申请对此不做具体限定。
可选地，作为一个实施例，所述根据所述目标容器的容器ID，从所述多个驱动实例中选取所述目标容器对应的驱动实例，包括：根据所述目标容器的容器ID，以及容器ID与驱动实例的类型的映射关系，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
需要说明的是，可以在Docker Daemon维护的各个容器信息中，增加字段，该字段可以记录容器ID与驱动实例的类型的映射关系。
应理解，上述容器ID与驱动实例的类型的映射关系，可以是在Docker Daemon初始化时预先建立的，本申请对此不做具体限定。
可选地，作为一个实施例，所述方法还包括：步骤440至步骤450。
440，接收容器运行请求，容器运行请求携带目标容器对应的驱动实例的类型。
具体地，上述接收容器运行请求可以指router接收Docker Client发送的容器运行请求。
上述容器运行请求携带目标容器对应的驱动实例的类型，也就是说该容器运行请求可以表示运行一个容器。
例如，可以在上述容器运行请求中携带参数“-exec-driver＝runv”，则该容器运行请求可以用于指示通过驱动实例runv运行一个runv容器。
450，router根据目标容器对应的驱动实例的类型，从多个驱动实例中确定目标容器对应的驱动实例。
例如，Docker Client向router发送上述容器运行请求，也就是说，该容器运行请求进入execution driver层中的router，router可以对该容器运行请求进行分析，确定该容器运行请求中的“exec-driver”的参数，即确定该容器运行请求指定的驱动实例的类型。
需要说明的是，上述当前运行的多个驱动实例的初始化时间可以在Docker Daemon初始化的过程中进行，也可以在Docker Daemon运行之后，接收到Docker Client发送的容器运行访问请求时，确定需要运行的目标容器的类型之后，根据目标容器的类型确定需要初始化的驱动实例的类型，并对该驱动实例的类型对应的驱动实例进行初始化。
在本申请实施例中，增加的对容器运行请求进行分析的步骤，并不会改变原有的Docker架构中的接口以及其他参数的使用情况。
460，router向目标容器对应的驱动实例发送容器运行请求。
具体地，router可以通过目标容器对应的驱动实例，运行一个目标容器。
在该方案中，通过一个程序管理用于驱动不同类型的容器的驱动实例，使得用户通过一个程序可以运行多个不同类型的容器，也就是说，将Docker Daemon和execution driver中具体的一个驱动实例的“强绑定”模式，改变为Docker Daemon对execution driver中的多个具体的驱动实例进行管理的模式，避免了现有技术中，通过不同的程序管理的不同的驱动实例，运行不同类型的容器，减少容器引擎中管理多个驱动实例的程序的运行开销。
并且，通过一个Docker Daemon，使用一套Docker应用程序编程接口(Application Programming Interface，API)可以运行多种类型的容器，提高通过Docker Daemon管理容器的灵活性。
图5示出了根据本申请实施例的用于访问容器的装置的示意性框图。图5所示的装置500包括：第一接收模块510，第一选取模块520和第一发送模块530。
第一接收模块510，用于接收容器访问请求，所述容器访问请求用于请求访问目标容器；
第一选取模块520，用于从当前运行的多个驱动实例中选取所述目标容器对应的驱动实例，所述多个驱动实例中的不同驱动实例用于驱动不同类型的容器，所述多个驱动实例通过相同的程序管理；
第一发送模块530，用于向所述第一选取模块选取的所述目标容器对应的驱动实例发送所述容器访问请求。
在该方案中，通过一个程序管理用于驱动不同类型的容器的驱动实例，使得用户通过一个程序可以访问多个不同类型的容器，避免了现有技术中，通过不同的程序管理的不同的驱动实例，访问不同类型的容器，减少容器引擎中管理多个驱动实例的程序的运行开销。
进一步地，当上述容器引擎为Docker时，多个驱动实例通过相同的程序管理可以指通过同一Docker Daemon管理多个驱动实例，在该方案中，通过一个Docker Daemon管理用于驱动不同类型的容器的驱动实例，使得用户通过一个Docker Daemon可以访问多个不同类型的容器，避免了现有技术中，通过不同的Docker Daemon管理的不同的驱动实例，访问不同类型的容器，减少Docker系统中Docker Daemon的运行开销。
并且，通过一个Docker Daemon，使用一套Docker应用程序编程接口(Application Programming Interface，API)可以对多种类型的容器进行访问，可以提高通过Docker Daemon访问容器的灵活性。
可选地，作为一个实施例，所述装置500还包括：第二接收模块，用于接收容器运行请求，所述容器运行请求携带所述目标容器对应的驱动实例的类型；第二选取模块，用于根据所述目标容器对应的驱动实例的类型，从所述多个驱动实例中选取所述目标容器对应的驱动实例；第二发送模块，用于向所述目标容器对应的驱动实例发送所述容器运行请求。
可选地，作为一个实施例，所述第一接收模块具体用于：接收所述容器访问请求，所述容器访问请求携带所述目标容器的容器ID；所述第一选取模块具体用于：根据所述目标容器的容器ID，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
可选地，作为一个实施例，所述第一选取模块具体还用于：根据所述目标容器的容器ID，以及容器ID与容器类型的映射关系，确定所述目标容器的容器类型；根据所述目标容器的容器类型，以及容器类型与驱动实例的类型的映射关系，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
可选地，作为一个实施例，所述第一选取模块具体还用于：根据所述目标容器的容器ID，以及容器ID与驱动实例的类型的映射关系，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
图6示出了根据本申请另一实施例的用于访问容器的装置的示意性框图。图6所示的装置600包括：存储器610、处理器620、输入/输出接口630、通信接口640和总线系统650。其中，存储器610、处理器620、输入/输出接口630和通信接口640通过总线系统660相连，该存储器610用于存储指令，该处理器620用于执行该存储器610存储的指令，以控制输入/输出接口630接收输入的数据和信息，输出操作结果等数据，并控制通信接口640发送信号。
输入/输出接口630，用于容器访问请求，所述容器访问请求用于请求访问目标容器；
处理器620，用于从当前运行的多个驱动实例中选取所述目标容器对应的驱动实例，所述多个驱动实例中的不同驱动实例用于驱动不同类型的容器，所述多个驱动实例通过相同程序进行管理；
所述输入/输出接口630，用于向所述目标容器对应的驱动实例发送所述容器访问请求。
应理解，在本申请实施例中，该处理器620可以采用通用的中央处理器(Central Processing Unit，CPU)，微处理器，应用专用集成电路(Application Specific Integrated Circuit，ASIC)，或者一个或多个集成电路，用于执行相关程序，以实现本申请实施例所提供的技术方案。
还应理解，通信接口640使用例如但不限于收发器一类的收发装置，来实现移动终端 600与其他设备或通信网络之间的通信。
该存储器610可以包括只读存储器和随机存取存储器，并向处理器620提供指令和数据。处理器620的一部分还可以包括非易失性随机存取存储器。例如，处理器620还可以存储设备类型的信息。
该总线系统650除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线系统650。
在实现过程中，上述方法的各步骤可以通过处理器620中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的用于访问容器的方法可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器610，处理器620读取存储器610中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
在该方案中，通过一个程序管理用于驱动不同类型的容器的驱动实例，使得用户通过一个程序可以访问多个不同类型的容器，避免了现有技术中，通过不同的程序管理的不同的驱动实例，访问不同类型的容器，减少容器引擎中管理多个驱动实例的程序的运行开销。
进一步地，当上述容器引擎为Docker时，多个驱动实例通过相同的程序管理可以指通过同一Docker Daemon管理多个驱动实例，在该方案中，通过一个Docker Daemon管理用于驱动不同类型的容器的驱动实例，使得用户通过一个Docker Daemon可以访问多个不同类型的容器，避免了现有技术中，通过不同的Docker Daemon管理的不同的驱动实例，访问不同类型的容器，减少Docker系统中Docker Daemon的运行开销。
并且，通过一个Docker Daemon，使用一套Docker应用程序编程接口(Application Programming Interface，API)可以对多种类型的容器进行访问，可以提高通过Docker Daemon访问容器的灵活性。
应理解，在本申请实施例中，“与A相应的B”表示B与A相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。
应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的 部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital Subscriber Line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够读取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，数字通用光盘(Digital Video Disc，DVD))或者半导体介质(例如，固态硬盘(Solid State Disk，SSD))等。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

  1. 一种用于访问容器的方法，其特征在于，包括：
    接收容器访问请求，所述容器访问请求用于请求访问目标容器；
    从当前运行的多个驱动实例中选取所述目标容器对应的驱动实例，所述多个驱动实例中的不同驱动实例用于驱动不同类型的容器，所述多个驱动实例通过相同的程序管理；
    向所述目标容器对应的驱动实例发送所述容器访问请求。
  2. 如权利要求1所述的方法，其特征在于，所述方法还包括：
    接收容器运行请求，所述容器运行请求携带所述目标容器对应的驱动实例的类型；
    根据所述目标容器对应的驱动实例的类型，从所述多个驱动实例中选取所述目标容器对应的驱动实例；
    向所述目标容器对应的驱动实例发送所述容器运行请求。
  3. 如权利要求1或2所述的方法，其特征在于，所述接收容器访问请求，包括：
    接收所述容器访问请求，所述容器访问请求携带所述目标容器的容器ID；
    所述从当前运行的多个驱动实例中选取所述目标容器对应的驱动实例，包括：
    根据所述目标容器的容器ID，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
  4. 如权利要求3所述的方法，其特征在于，所述根据所述目标容器的容器ID，从所述多个驱动实例中选取所述目标容器对应的驱动实例，包括：
    根据所述目标容器的容器ID，以及容器ID与容器类型的映射关系，确定所述目标容器的容器类型；
    根据所述目标容器的容器类型，以及容器类型与驱动实例的类型的映射关系，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
  5. 如权利要求3所述的方法，其特征在于，所述根据所述目标容器的容器ID，从所述多个驱动实例中选取所述目标容器对应的驱动实例，包括：
    根据所述目标容器的容器ID，以及容器ID与驱动实例的类型的映射关系，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
  6. 一种用于访问容器的装置，其特征在于，包括：
    第一接收模块，用于接收容器访问请求，所述容器访问请求用于请求访问目标容器；
    第一选取模块，用于从当前运行的多个驱动实例中选取所述目标容器对应的驱动实例，所述多个驱动实例中的不同驱动实例用于驱动不同类型的容器，所述多个驱动实例通过相同的程序管理；
    第一发送模块，用于向所述第一选取模块选取的所述目标容器对应的驱动实例发送所述容器访问请求。
  7. 如权利要求6所述的装置，其特征在于，所述装置还包括：
    第二接收模块，用于接收容器运行请求，所述容器运行请求携带所述目标容器对应的驱动实例的类型；
    第二选取模块，用于根据所述目标容器对应的驱动实例的类型，从所述多个驱动实例 中选取所述目标容器对应的驱动实例；
    第二发送模块，用于向所述目标容器对应的驱动实例发送所述容器运行请求。
  8. 如权利要求6或7所述的装置，其特征在于，所述第一接收模块具体用于：接收所述容器访问请求，所述容器访问请求携带所述目标容器的容器ID；
    所述第一选取模块具体用于：根据所述目标容器的容器ID，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
  9. 如权利要求8所述的装置，其特征在于，所述第一选取模块具体还用于：
    根据所述目标容器的容器ID，以及容器ID与容器类型的映射关系，确定所述目标容器的容器类型；
    根据所述目标容器的容器类型，以及容器类型与驱动实例的类型的映射关系，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
  10. 如权利要求8所述的装置，其特征在于，所述第一选取模块具体还用于：
    根据所述目标容器的容器ID，以及容器ID与驱动实例的类型的映射关系，从所述多个驱动实例中选取所述目标容器对应的驱动实例。
PCT/CN2017/100351 2016-09-07 2017-09-04 用于访问容器的方法和装置 WO2018045926A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP17848099.2A EP3499365A4 (en) 2016-09-07 2017-09-04 METHOD AND DEVICE FOR USE IN ACCESS TO A CONTAINER
KR1020197009003A KR102176298B1 (ko) 2016-09-07 2017-09-04 컨테이너를 액세스하는데 사용하기 위한 방법 및 디바이스
US16/294,591 US11321109B2 (en) 2016-09-07 2019-03-06 Container engine for selecting driver based on container metadata

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610806797.3 2016-09-07
CN201610806797.3A CN107797845B (zh) 2016-09-07 2016-09-07 用于访问容器的方法和装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/294,591 Continuation US11321109B2 (en) 2016-09-07 2019-03-06 Container engine for selecting driver based on container metadata

Publications (1)

Publication Number Publication Date
WO2018045926A1 true WO2018045926A1 (zh) 2018-03-15

Family

ID=61529900

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/100351 WO2018045926A1 (zh) 2016-09-07 2017-09-04 用于访问容器的方法和装置

Country Status (5)

Country Link
US (1) US11321109B2 (zh)
EP (1) EP3499365A4 (zh)
KR (1) KR102176298B1 (zh)
CN (1) CN107797845B (zh)
WO (1) WO2018045926A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10791065B2 (en) * 2017-09-19 2020-09-29 Cisco Technology, Inc. Systems and methods for providing container attributes as part of OAM techniques
US10587412B2 (en) * 2017-11-07 2020-03-10 International Business Machines Corporation Virtual machine structure
CN117348951B (zh) * 2023-12-04 2024-02-09 北京长扬软件有限公司 应用于linux内核的容器感知装置和容器感知方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101916208A (zh) * 2010-08-30 2010-12-15 芯通科技（成都）有限公司 一种用于多线程调用驱动模块的系统及方法
US20150256481A1 (en) * 2014-03-06 2015-09-10 Jisto Inc. Elastic Compute Cloud Based On Underutilized Server Resources Using A Distributed Container System
CN104951360A (zh) * 2015-06-30 2015-09-30 北京奇虎科技有限公司 基于Docker的配置管理方式及装置
CN105022626A (zh) * 2015-05-29 2015-11-04 克拉玛依红有软件有限责任公司 基于模型驱动的利用反射机制进行动态交互的系统及方法

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6061753A (en) * 1998-01-27 2000-05-09 Emc Corporation Apparatus and method of accessing target devices across a bus utilizing initiator identifiers
JP2001051935A (ja) * 1999-05-28 2001-02-23 Sony Corp 情報処理装置および方法、並びに記録媒体
US7584433B2 (en) * 2005-04-20 2009-09-01 Avp Ip Holding Co., Llc. Extendible and open camera connector system
US20070174429A1 (en) * 2006-01-24 2007-07-26 Citrix Systems, Inc. Methods and servers for establishing a connection between a client system and a virtual machine hosting a requested computing environment
EP1977317A1 (en) * 2006-01-24 2008-10-08 Citrix Systems, Inc. Methods and systems for providing access to a computing environment
US8856782B2 (en) * 2007-03-01 2014-10-07 George Mason Research Foundation, Inc. On-demand disposable virtual work system
US8244872B2 (en) * 2009-06-11 2012-08-14 Microsoft Corp. Educational adaptive provider architecture
US8813065B2 (en) * 2010-04-26 2014-08-19 Vmware, Inc. Microcloud platform delivery system
US9772831B2 (en) * 2010-04-26 2017-09-26 Pivotal Software, Inc. Droplet execution engine for dynamic server application deployment
US8683050B2 (en) * 2010-05-06 2014-03-25 Microsoft Corporation Directing service requests to providers
US9760415B2 (en) * 2014-05-16 2017-09-12 Microsoft Technology Licensing, Llc Code service for language-independent dispatch
US10726119B2 (en) * 2014-12-08 2020-07-28 Vmware, Inc. Monitoring application execution in a clone of a virtual computing instance for application whitelisting
CN107533469B (zh) * 2015-05-29 2022-03-29 英特尔公司 对图形处理单元资源的容器访问
EP3304295B1 (en) * 2015-06-05 2024-05-29 Nutanix, Inc. Architecture for managing i/o and storage for a virtualization environment using executable containers and virtual machines
US11438278B2 (en) * 2015-06-29 2022-09-06 Vmware, Inc. Container-aware application dependency identification
CN105045656B (zh) * 2015-06-30 2018-11-30 深圳清华大学研究院 基于虚拟容器的大数据存储与管理方法
WO2017019684A1 (en) * 2015-07-27 2017-02-02 Datagrid Systems, Inc. Techniques for evaluating server system reliability, vulnerability and component compatibility using crowdsourced server and vulnerability data
KR102294568B1 (ko) * 2015-08-19 2021-08-26 삼성에스디에스 주식회사 컨테이너 이미지 보안 검사 방법 및 그 장치
CN105099706A (zh) 2015-08-25 2015-11-25 华为技术有限公司 一种数据通信方法、用户设备和服务器
US9811386B2 (en) * 2015-10-23 2017-11-07 Oracle International Corporation System and method for multitenant execution of OS programs invoked from a multitenant middleware application
US9934073B2 (en) * 2015-10-23 2018-04-03 Futurewei Technologies, Inc. Extension of resource constraints for service-defined containers
US10216529B1 (en) * 2015-11-19 2019-02-26 Virtuozzo International Gmbh Method and system for sharing driver pages
US9832802B2 (en) * 2015-12-15 2017-11-28 At&T Intellectual Property I, L.P. Facilitating communications via a mobile internet-enabled connection interface
CN105847045B (zh) * 2016-01-04 2019-06-18 中国电子科技网络信息安全有限公司 一种基于Docker容器的应用封装系统及管理方法
US10892942B2 (en) * 2016-01-22 2021-01-12 Equinix, Inc. Container-based cloud exchange disaster recovery
US9898354B2 (en) * 2016-03-21 2018-02-20 Microsoft Technology Licensing, Llc Operating system layering
US10326744B1 (en) * 2016-03-21 2019-06-18 EMC IP Holding Company LLC Security layer for containers in multi-tenant environments
US20170371693A1 (en) * 2016-06-23 2017-12-28 Vmware, Inc. Managing containers and container hosts in a virtualized computer system
US10142109B2 (en) * 2016-08-16 2018-11-27 Hewlett Packard Enterprise Development Lp Instantiating containers

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101916208A (zh) * 2010-08-30 2010-12-15 芯通科技（成都）有限公司 一种用于多线程调用驱动模块的系统及方法
US20150256481A1 (en) * 2014-03-06 2015-09-10 Jisto Inc. Elastic Compute Cloud Based On Underutilized Server Resources Using A Distributed Container System
CN105022626A (zh) * 2015-05-29 2015-11-04 克拉玛依红有软件有限责任公司 基于模型驱动的利用反射机制进行动态交互的系统及方法
CN104951360A (zh) * 2015-06-30 2015-09-30 北京奇虎科技有限公司 基于Docker的配置管理方式及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3499365A4

Also Published As

Publication number Publication date
US11321109B2 (en) 2022-05-03
EP3499365A1 (en) 2019-06-19
EP3499365A4 (en) 2019-08-21
US20190205156A1 (en) 2019-07-04
KR102176298B1 (ko) 2020-11-09
CN107797845A (zh) 2018-03-13
CN107797845B (zh) 2021-06-15
KR20190044098A (ko) 2019-04-29

Similar Documents

Publication Publication Date Title
CN110275761B (zh) 调度方法、装置和主节点
US8830870B2 (en) Network adapter hardware state migration discovery in a stateful environment
US9588807B2 (en) Live logical partition migration with stateful offload connections using context extraction and insertion
US9058198B2 (en) System resource sharing in a multi-tenant platform-as-a-service environment in a cloud computing system
WO2020177482A1 (zh) 一种桌面虚拟化方法、相关设备及计算机存储介质
US9207989B2 (en) System and method for providing virtual device
US10411957B2 (en) Method and device for integrating multiple virtual desktop architectures
US9058205B2 (en) Automatically performing operations on applications based on dependencies on other applications
US11321109B2 (en) Container engine for selecting driver based on container metadata
CN110908753A (zh) 一种智能融合的云桌面服务器、客户端及系统
US20130151721A1 (en) Remote Session Management
US11252457B2 (en) Multimedia streaming and routing apparatus and operation method of the same
US9292318B2 (en) Initiating software applications requiring different processor architectures in respective isolated execution environment of an operating system
US10911371B1 (en) Policy-based allocation of provider network resources
US11604670B2 (en) Virtual machine live migration method, apparatus, and system
KR101089792B1 (ko) 애플리케이션 가상화를 위한 보안 제공방법
US9612895B1 (en) Method for prioritizing first failure data capture (FFDC) data for analysis
US7870276B1 (en) Interface plugin
US10754676B2 (en) Sharing ownership of an input/output device using a device driver partition
CN110520842B (zh) 针对传统应用兼容性的地址空间拆分系统及方法
CN113886000A (zh) 一种应用构建方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17848099

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20197009003

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2017848099

Country of ref document: EP

Effective date: 20190315