WO2019237584A1 - 容器的管理方法、装置、计算机设备及存储介质 - Google Patents

容器的管理方法、装置、计算机设备及存储介质 Download PDF

Info

Publication number
WO2019237584A1
WO2019237584A1 PCT/CN2018/109319 CN2018109319W WO2019237584A1 WO 2019237584 A1 WO2019237584 A1 WO 2019237584A1 CN 2018109319 W CN2018109319 W CN 2018109319W WO 2019237584 A1 WO2019237584 A1 WO 2019237584A1
Authority
WO
WIPO (PCT)
Prior art keywords
container
network
network card
management platform
bridge
Prior art date
Application number
PCT/CN2018/109319
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 平安科技(深圳)有限公司
Publication of WO2019237584A1 publication Critical patent/WO2019237584A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10Program control for peripheral devices
    • G06F13/12Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor
    • G06F13/124Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor where hardware is a sequential transfer control unit, e.g. microprocessor, peripheral processor or state-machine
    • G06F13/128Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor where hardware is a sequential transfer control unit, e.g. microprocessor, peripheral processor or state-machine for dedicated transfers to a network
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • G06F9/4411Configuring for operating with peripheral devices; Loading of device drivers

Definitions

  • the present application relates to the field of computer technology, and in particular, to a container management method, device, computer device, and storage medium.
  • Docker container is an open source application container engine that allows developers to package their applications and dependencies into a portable container and publish it to any popular Linux machine.
  • Docker containers In native network solutions of Docker containers, Docker containers often do not support direct communication with external devices.
  • third-party software such as flanne, calico, etc. can be encapsulated on the original network layer to be accessed by external devices. performance.
  • This application provides a container management method, device, computer equipment, and storage medium, so that the container can be accessed by an external device.
  • the present application provides a container management method, which includes: receiving a container creation request sent by a management platform, and creating a container according to the container creation request; receiving a container network address sent by the management platform, and The container network address configures the virtual network card of the container, wherein the container network address is a private network address allocated by the management platform to the container; creating a network bridge in a physical machine; and connecting the physical machine Both the network card and the virtual network card of the container are bridged to the network bridge, so that the container communicates with external devices through the network card of the physical machine.
  • the present application provides a container management device, including: a container creation unit, configured to receive a container creation request sent by a management platform, and create a container according to the container creation request; and a network card configuration unit, configured to receive A container network address sent by the management platform, and configuring a virtual network adapter of the container according to the container network address, wherein the container network address is a private network address allocated by the management platform to the container; a network bridge A creating unit configured to create a network bridge in a physical machine; a bridging unit configured to bridge a network card of the physical machine and a virtual network card of the container to the network bridge so that the container passes the physical machine The machine's network card communicates with external devices.
  • the present application further provides a computer device including a memory, a processor, and a computer program stored on the memory and executable on the processor.
  • the processor is implemented when the computer program is executed.
  • the container management method according to any one of the first aspects.
  • the present application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program, when executed by a processor, causes the processor to execute the first aspect.
  • the container management method according to any one of the above.
  • the present application provides a container management method, device, computer equipment, and storage medium. This method can quickly create a container in a physical machine, and the container can communicate with an external device without using third-party software, so as to be accessed by the external device and improve network performance.
  • FIG. 1 is a schematic scenario diagram of a container management method according to an embodiment of the present application.
  • FIG. 2 is a schematic flowchart of a container management method according to an embodiment of the present application.
  • FIG. 3 is a specific schematic flowchart of a container management method according to an embodiment of the present application.
  • FIG. 4 is a schematic diagram of another scenario of a container management method according to an embodiment of the present application.
  • FIG. 5 is another schematic flowchart of a container management method according to an embodiment of the present application.
  • FIG. 6 is another schematic flowchart of a container management method according to an embodiment of the present application.
  • FIG. 7 is a schematic block diagram of a container management apparatus according to an embodiment of the present application.
  • FIG. 8 is a specific schematic block diagram of a container management apparatus according to an embodiment of the present application.
  • FIG. 9 is another schematic block diagram of a container management apparatus according to an embodiment of the present application.
  • FIG. 10 is another schematic block diagram of a container management apparatus according to an embodiment of the present application.
  • FIG. 11 is a schematic block diagram of a computer device according to an embodiment of the present application.
  • FIG. 1 is a schematic diagram of a container management method in an embodiment of the present application
  • FIG. 2 is a schematic flowchart of a container management method provided in an embodiment of the present application.
  • This container management method is applied to the physical machine 20.
  • the management platform 10 may be deployed in a hardware server to manage information such as a container network address of a container in the physical machine 20.
  • the management platform 10 can manage one or more physical machines 20.
  • FIG. 1 only two physical machines 20 are illustrated. It can be understood that the number of the physical machines 20 can be set according to actual requirements, and can be more or less, which is not specifically limited herein.
  • FIG. 1 only illustrates the interaction scenarios between the management platform 10 and one physical machine 20.
  • the interaction scenarios between the management platform 10 and other physical machines 20 are similar, and are not drawn here one by one.
  • the container management method includes steps S101 to S104.
  • S101 Receive a container creation request sent by a management platform, and create a container according to the container creation request.
  • a user such as a developer or a maintenance person may send a request to the management platform 10 so that the management platform 10 sends a container creation request to the physical machine 20.
  • the physical machine 20 receives a container creation request, it will create a container 21 in the physical machine 20 according to the container creation request, as shown in FIG. 1.
  • a container orchestration tool is installed in the physical machine 20, and the physical machine 20 may receive the container creation request sent by the management platform 10 through the container orchestration tool, and create the container 21 according to the container creation request.
  • the container orchestration tool may be a tool such as Docker, Kubernetes, Marathon, and Nomad, and the container 21 created may be a Docker container.
  • the types of the container orchestration tool and the container 21 are not specifically limited.
  • S102 Receive a container network address sent by the management platform, and configure a virtual network adapter of the container according to the container network address, wherein the container network address is a private network address allocated by the management platform to the container. .
  • the physical machine 20 receives the container network address allocated by the management platform 10 for the container 21 created in step S101, and then configures the virtual network adapter of the container according to the container network address.
  • the container network address is a private network address of the container, that is, among the multiple containers 21 shown in FIG. 1, the container network addresses corresponding to each container 21 are different from each other.
  • FIG. 3 is a specific schematic flowchart of a container management method in an embodiment of the present application.
  • Step S102 specifically includes steps S1021 and S1022.
  • Step S1021 After detecting that the container is successfully created, send the creation success information to the management platform, where the creation success information includes container identification information.
  • the container orchestration tool can be used to monitor whether the container is successfully created.
  • the physical machine 20 sends the creation success information to the management platform 10 through the container orchestration tool, where the creation success information includes container identification information.
  • the container identification information may be, for example, identification information such as a number and a name of the container 21 for identifying the container 21.
  • the management platform 10 After receiving the creation success information, the management platform 10 parses out the container identification information in the creation success information, and assigns a private container network address to the container corresponding to the container identification information, and establishes a corresponding relationship between the container identification information and the container network address and This correspondence is stored to facilitate the management of container network addresses.
  • Step S1022 Receive a container network address sent by the management platform, and execute a Pipework command under the control of an Ansible remote command initiated by the management platform to create a virtual network adapter in the container and set the container network address to all The network address of the virtual network card, wherein the container network address is a private network address allocated by the management platform to a container corresponding to the container identification information after receiving the creation success information.
  • the management platform 10 sends the container network address to the physical machine 20 through the Ansible remote command, and simultaneously starts the physical machine 20 to execute the Pipework command under the control of the Ansible remote command, so as to create a virtual network adapter in the container 21 and according to the received
  • the virtual network adapter is configured for the container network address.
  • the containers 21 in the same network segment in the physical machine 20 may be bridged to the same network.
  • the containers 21 in different network segments are bridged to different network bridges 22. Therefore, before the network bridge 22 is created in the physical machine 20, it is necessary to first determine whether there is a container 21 in the physical machine 20 that is in the same network segment as the container network address. If there is no container 21 in the physical machine 20 in the same network segment as the container network address, step S103 is performed, that is, a network bridge 22 is created in the physical machine 20.
  • step S104 is performed, that is, the network card 23 of the physical machine 20 And the virtual network adapter of the container 21 is bridged to the network bridge 22 corresponding to the container network address.
  • the physical machine may directly perform step S103 after performing step S102, so that each container 21 corresponds to a network bridge 22.
  • S104 Bridge the network card of the physical machine and the virtual network card of the container to the network bridge, so that the container communicates with external devices through the network card of the physical machine.
  • the physical machine 20 bridges the network card 23 of the physical machine 20 and the virtual network card of the container 21 to the network bridge 22, so that the container 21 can be connected to the switch 30 through the network card 23 of the physical machine 20 to implement communication between the container 21 and external devices.
  • the network card 23 of the physical machine 20 may be a physical network card.
  • FIG. 4 is another schematic diagram of a container management method in an embodiment of the present application
  • FIG. 5 is another schematic diagram of a container management method in an embodiment of the present application. flow chart.
  • the physical machine 20 may be configured with two physical network cards. Before step S104 is performed, step S104a is also performed.
  • S104a Bind the two physical network cards to form a logical network card, where the logical network card includes a physical interface and multiple sub-interfaces, and the network segments of the multiple sub-interfaces are different from each other.
  • the network card 23 of the physical machine 20 is a logical network card 231.
  • the logical network card 231 is formed by binding two physical network cards.
  • the logical network card 231 includes a physical interface and a plurality of sub-interfaces.
  • the sub-interface is formed by VLAN tagging.
  • the logical network card 231 shown in FIG. 4 includes one physical interface and three sub-interfaces, and an interface name corresponding to the physical interface is represented as Bond0.
  • the three sub-interfaces have VLAN tags of 100, 200, and 300.
  • the three sub-interfaces correspond to different network segments.
  • the sub-interfaces corresponding to VLAN tags 200 and VLAN tags 300 can bridge to two different network segments in physical machine 20.
  • the bridge 22 is connected to the containers 21 of different network segments.
  • the network address of the sub-interface corresponding to the VLAN tag 100 is the network address of the physical machine 20.
  • step S104 is specifically: bridging the sub interface of the logical network card of the physical machine to the network bridge, and bridging the virtual network card of the container to the network bridge, so that the container passes through the network bridge.
  • the physical interface of the logical network card of the physical machine communicates with external devices. That is, the physical machine 20 needs to bridge the sub-interface of the logical network card 231 to the network bridge 22, and then bridge the virtual network card of the container 21 to the network bridge 22.
  • the Bond0 physical interface of the logical network card 231 is connected to an external device, such as the switch 30. In this way, the container 21 can communicate with external devices through the physical interface Bond0 of the logical network card 231, and at the same time, multiple containers 21 in the physical machine 20 can be in multiple different network segments.
  • FIG. 6 is a schematic flowchart of a container management method according to an embodiment of the present application. After step S104, steps S105 and S106 are further included.
  • S106 Send the running status of the container to the management platform, so that the management platform records the movement status of the container and marks the use status of the container network address of the container according to the running status of the container.
  • the running status of the container 21 may be monitored by a container orchestration tool.
  • the running state of the container 21 includes a starting state, a stopping state, and a restarting state of the container 21.
  • the running status of the monitored container 21 is sent to the management platform 10 through the container orchestration tool.
  • the management platform 10 can record the running status of the container 21 and mark the use status of the container network address of the container 21 according to the running status of the container 21. Specifically, when the running state of the container 21 received by the management platform 10 is a stopped state, the use state of the container network address of the container 21 will be marked as disabled; when the running state of the container 21 received by the management platform 10 is a starting state , The use status of the container network address of the container 21 will be marked as enable; when the running status of the container 21 received by the management platform 10 is the restart status, the use status of the container network address of the container 21 will be marked as disable first, Then mark it as enable. In this way, it can be ensured that the container 21 and the corresponding container network address are always in a binding state, and the container network address of the container 21 remains unchanged regardless of whether the container 21 is in a stopped, started, or restarted state.
  • the physical machine 20 may delete the container 21 under the Ansible remote command sent by the management platform 10.
  • the management platform 10 needs to delete the correspondence table between the container identification information of the deleted container 21 and the container network address, and recover the container network address of the deleted container 21 for subsequent processing. Assign the recovered container network address to other containers for use.
  • the container management method in this embodiment can quickly create a container 21 in the physical machine 20, and the container 21 can communicate with external devices without using third-party software, thereby improving network performance. At the same time, the method can also implement containers 21 from different network segments in the same physical machine 20.
  • the embodiment of the present application further provides a container management device, and the container management device is configured to execute the container management method in the foregoing embodiment.
  • FIG. 7 is a schematic block diagram of a container management apparatus according to an embodiment of the present application.
  • the container management device 300 may be installed in a physical machine. As shown in FIG. 7, the container management device 300 includes a container creation unit 301, a network card configuration unit 302, a bridge creation unit 303, and a bridge unit 304.
  • the container creation unit 301 is configured to receive a container creation request sent by a management platform, and create a container according to the container creation request.
  • the container creation unit 301 is specifically configured to receive a container creation request sent by a management platform through a container orchestration tool, and create a container according to the container creation request.
  • the container orchestration tool may be tools such as Docker, Swarm, Kubernetes, Marathon, and Nomad, and the container created may be a Docker container.
  • the container orchestration tool and the type of the container are not specifically limited here.
  • the network card configuration unit 302 is configured to receive a container network address sent by the management platform, and configure a virtual network card of the container according to the container network address, wherein the container network address is allocated by the management platform to the container. Private network address.
  • FIG. 8 is a specific schematic block diagram of a container management apparatus according to an embodiment of the present application.
  • the network card configuration unit 302 includes a sending subunit 3021 and a configuration subunit 3022.
  • a sending subunit 3021 is configured to send creation success information to the management platform after monitoring that the container creation is successful, where the creation success information includes container identification information.
  • a configuration subunit 3022 configured to receive a container network address sent by the management platform, and execute a Pipework command under the control of an Ansible remote command initiated by the management platform to create a virtual network adapter in the container and network the container.
  • the address is set to the network address of the virtual network card, wherein the container network address is a private network address allocated by the management platform to a container corresponding to the container identification information after receiving the creation success information.
  • a bridge creating unit 303 is configured to create a network bridge in a physical machine.
  • the container management device 300 further includes a judging unit, and the judging unit is configured to determine whether a network with the container exists in the physical machine before the network bridge creating unit 303 creates the network bridge in the physical machine.
  • Containers with addresses on the same network segment If there is no container in the same physical network segment as the container network address, sending a signal to the bridge creation unit 303 to cause it to create a network bridge; if the physical machine exists within the container network address Containers in the same network segment indicate that there is a network bridge corresponding to the network address of the container in the physical machine.
  • a signal is sent to the bridging unit 304 to cause the bridging unit 304 to bridge the network card of the physical machine and the virtual network card of the container to the The container network address corresponds to the bridge.
  • the bridging unit 304 is configured to bridge the network card of the physical machine and the virtual network card of the container to the network bridge, so that the container communicates with external devices through the network card of the physical machine.
  • FIG. 9 is another schematic block diagram of a container management apparatus according to an embodiment of the present application.
  • the physical machine includes two physical network cards.
  • the container management apparatus 300 further includes a binding unit 305.
  • the binding unit 305 is configured to bind two physical network cards to form a logical network card, where the logical network card includes a physical interface and a plurality of sub-interfaces, and the network segments of the plurality of sub-interfaces are different from each other.
  • the bridging unit 304 is specifically configured to bridge a sub-interface of a logical network card of the physical machine to the network bridge, and bridge a virtual network card of the container to the network bridge, so that the container passes A physical interface of a logical network card of the physical machine communicates with an external device.
  • FIG. 10 is a schematic block diagram of a container management apparatus according to an embodiment of the present application.
  • the container management apparatus 300 further includes a monitoring unit 306 and a sending unit 307.
  • the monitoring unit 306 is configured to monitor the running status of the container.
  • the sending unit 307 is configured to send the running status of the container to the management platform, so that the management platform records the movement status of the container and marks the container network address of the container according to the running status of the container. status of use.
  • the container management device 300 in this embodiment can quickly create a container in a physical machine, and the container can communicate with external devices without using third-party software, thereby improving network performance. At the same time, it is also possible to implement containers with different network segments in the same physical machine.
  • the above-mentioned container management device can be implemented in the form of a computer program, which can be run on a computer device as shown in FIG. 11.
  • FIG. 11 is a schematic block diagram of a computer device according to an embodiment of the present application.
  • the computer device 500 may be a physical machine.
  • the computer device 500 includes a processor 502, a memory, and a network interface 505 connected through a system bus 501.
  • the memory may include a non-volatile storage medium 503 and an internal memory 504.
  • the non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032.
  • the computer program 5032 includes program instructions. When the program instructions are executed, the processor 502 can execute a container management method.
  • the processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500.
  • the internal memory 504 provides an environment for running the computer program 5032 in the non-volatile storage medium 503.
  • the processor 502 can execute a container management method.
  • the network interface 505 is used for network communication, such as sending assigned tasks.
  • the structure shown in FIG. 11 is only a block diagram of a part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer equipment 500 to which the scheme of the present application is applied.
  • the specific computer equipment 500 may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.
  • the processor 502 is configured to run a computer program 5032 stored in a memory to implement the following functions: receiving a container creation request sent by a management platform, and creating a container according to the container creation request; receiving the container creation request sent by the management platform A container network address, and configuring a virtual network adapter of the container according to the container network address, wherein the container network address is a private network address allocated by the management platform to the container; creating a network bridge in a physical machine; The network card of the physical machine and the virtual network card of the container are bridged to the network bridge, so that the container communicates with external devices through the network card of the physical machine.
  • the physical machine includes two physical network cards; before the processor 502 executes bridging the network card of the physical machine and the virtual network card of the container to the network bridge, it also implements the following functions: The two physical network cards are bound to form a logical network card, where the logical network card includes a physical interface and multiple sub-interfaces, and the network segments of the multiple sub-interfaces are different from each other; the processor 502 is executing When the network card of the machine and the virtual network card of the container are bridged to the network bridge, the following functions are specifically implemented: bridging the sub-interfaces of the logical network card of the physical machine to the network bridge, and The virtual network card is bridged to the network bridge, so that the container communicates with an external device through a physical interface of the logical network card of the physical machine.
  • the processor 502 when the processor 502 executes receiving a container creation request sent by the management platform and creates a container according to the container creation request, the processor 502 specifically implements the following function: receiving a container creation request sent by the management platform through a container orchestration tool, and A container is created according to the container creation request.
  • the processor 502 when the processor 502 receives a container network address sent by the management platform and configures a virtual network adapter of the container according to the container network address, the processor 502 specifically implements the following functions: After the success, the creation success information is sent to the management platform, wherein the creation success information includes container identification information; receiving the container network address sent by the management platform, and under the control of an Ansible remote command initiated by the management platform Execute a Pipework command to create a virtual network card in the container and set the container network address to the network address of the virtual network card, where the container network address is the management platform after receiving the creation success information A private network address assigned to a container corresponding to the container identification information.
  • the processor 502 after the processor 502 executes bridging the network card of the physical machine and the virtual network card of the container to the network bridge, the processor 502 also implements the following functions: monitoring the running state of the container; The running status of the container is sent to the management platform, so that the management platform records the movement status of the container and marks the use status of the container network address of the container according to the running status of the container.
  • the processor 502 may be a central processing unit (CPU), and the processor 502 may also be another general-purpose processor, digital signal processor (Digital Signal Processor, DSP), Application Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • the general-purpose processor may be a microprocessor, or the processor may be any conventional processor.
  • a person of ordinary skill in the art can understand that all or part of the processes in the embodiment of the method for managing a container can be implemented by using a computer program to instruct related hardware.
  • the computer program may be stored in a computer-readable storage medium.
  • the computer-readable storage medium includes a non-volatile computer-readable storage medium, and the computer program is executed by at least one processor in the computer system to implement the process steps of the embodiment including the management method of each container as described above.
  • the storage medium may be various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a magnetic disk, or an optical disk.
  • program codes such as a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a magnetic disk, or an optical disk.
  • the disclosed apparatus and method may be implemented in other ways.
  • the device embodiments described above are merely schematic.
  • the division of each unit is only a logical function division, and there may be another division manner in actual implementation.
  • multiple units or components may be combined or integrated into another system, or some features may be ignored or not implemented.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each of the units may exist separately physically, or two or more units may be integrated into one unit.
  • the above integrated unit may be implemented in the form of hardware or in the form of software functional unit.
  • the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a storage medium.
  • the technical solution of this application is essentially a part that contributes to the existing technology, or all or part of the technical solution may be embodied in the form of a software product, which is stored in a storage medium. Included are instructions for causing a computer device (which may be a personal computer, a terminal, or a network device, etc.) to perform all or part of the steps of the method described in the embodiments of the present application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种容器的管理方法、装置、计算机设备及存储介质。该方法接收管理平台发送的容器创建请求,并根据容器创建请求创建容器;接收管理平台发送的容器网络地址,并根据容器网络地址配置容器的虚拟网卡;在物理机中创建网桥;将物理机的网卡以及容器的虚拟网卡均桥接至网桥上以使容器通过物理机的网卡与外部设备通信。

Description

容器的管理方法、装置、计算机设备及存储介质
本申请要求于2018年6月13日提交中国专利局、申请号为201810607066.5、发明名称为“容器的管理方法、装置、计算机设备及存储介质”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域,尤其涉及一种容器的管理方法、装置、计算机设备及存储介质。
背景技术
Docker容器是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上。在Docker容器的原生网络方案中,往往不支持Docker容器直接与外部设备通信。为了使得外部设备可以访问到Docker容器,目前需要通过第三方软件实现,譬如,通过flanne、calico等第三方软件在原来的网络层上再封装一层以实现被外部设备访问,但这样会降低网络性能。
发明内容
本申请提供了一种容器的管理方法、装置、计算机设备及存储介质,以实现容器可以被外部设备访问。
第一方面,本申请提供了一种容器的管理方法,其包括:接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器;接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡,其中,所述容器网络地址为所述管理平台为所述容器分配的私有的网络地址;在物理机中创建网桥;以及将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上,以使所述容器通过所述物理机的网卡与外部设备通信。
第二方面,本申请提供了一种容器的管理装置,其包括:容器创建单元, 用于接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器;网卡配置单元,用于接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡,其中,所述容器网络地址为所述管理平台为所述容器分配的私有的网络地址;网桥创建单元,用于在物理机中创建网桥;桥接单元,用于将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上,以使所述容器通过所述物理机的网卡与外部设备通信。
第三方面,本申请又提供了一种计算机设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现第一方面提供的任一项所述的容器的管理方法。
第四方面,本申请还提供了一种计算机可读存储介质,其中所述计算机可读存储介质存储有计算机程序,所述计算机程序当被处理器执行时使所述处理器执行第一方面提供的任一项所述的容器的管理方法。
本申请提供一种容器的管理方法、装置、计算机设备及存储介质。该方法可以在物理机中快速地创建容器,且该容器无需借助第三方软件即可与外部设备进行通信,实现被外部设备访问,提高网络性能。
附图说明
为了更清楚地说明本申请实施例技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例中容器的管理方法的场景示意图;
图2为本申请实施例提供的一种容器的管理方法的示意流程图;
图3为本申请实施例提供的一种容器的管理方法的具体示意流程图;
图4为本申请实施例中容器的管理方法的另一场景示意图;
图5为本申请实施例提供的一种容器的管理方法的另一示意流程图;
图6为本申请实施例提供的一种容器的管理方法的另一示意流程图;
图7为本申请实施例提供的一种容器的管理装置的示意性框图;
图8为本申请实施例提供的一种容器的管理装置的具体示意性框图;
图9为本申请实施例提供的一种容器的管理装置的另一示意性框图;
图10为本申请实施例提供的一种容器的管理装置的另一示意性框图;
图11为本申请实施例提供的一种计算机设备的示意性框图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
请参阅图1和图2,图1为本申请实施例中容器的管理方法的场景示意图,图2为本申请实施例提供的一种容器的管理方法的示意流程图。该容器的管理方法应用于物理机20中。在图1所示的场景示意图中,管理平台10可以部署在硬件的服务器中,用于管理物理机20中容器的容器网络地址等信息。该管理平台10可以管理一台或更多台物理机20。在图1所示的场景示意图中,仅仅示意出了两台物理机20。可以理解的是,物理机20的个数可以根据实际需求进行设置,可以为更多台或更少台,在此不做具体限制。另外,需要说明的是,图1仅仅示意出管理平台10与一台物理机20之间的交互情景,管理平台10与其他物理机20之间的交互情景类似,在此不一一绘制。
如图2所示,该容器的管理方法包括步骤S101~S104。
S101、接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器。
当需要创建容器21时,开发人员或维护人员等用户可以向管理平台10发送请求,以使得管理平台10向物理机20发送容器创建请求。当物理机20接收到容器创建请求时,会根据该容器创建请求在物理机20中创建容器21,如图1所示。
具体地,在一实施例中,在物理机20中安装有容器编排工具,物理机20可以通过容器编排工具接收管理平台10发送的容器创建请求,并根据所述容器创建请求创建容器21。
在一实施例中,该容器编排工具可以为Docker Swarm、Kubernetes、Marathon和Nomad等工具,所创建的容器21可以为Docker容器,在此不对容器编排工具以及容器21的种类做具体限制。
S102、接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡,其中,所述容器网络地址为所述管理平台为所述容器分配的私有的网络地址。
在本实施例中,物理机20接收管理平台10为步骤S101创建的容器21分配的容器网络地址,然后根据该容器网络地址配置容器的虚拟网卡。其中,该容器网络地址为容器的私有的网络地址,也即在图1所示的多个容器21中,每个容器21对应的容器网络地址互不相同。
具体地,在一实施例中,如图3所示,图3为本申请实施例中容器的管理方法的具体示意流程图。步骤S102具体包括步骤S1021和S1022。
步骤S1021、在监测到所述容器创建成功后,向所述管理平台发送创建成功信息,其中,所述创建成功信息包括容器标识信息。
具体地,在一实施例中,可以通过容器编排工具监测容器是否创建成功。当通过容器编排工具监测到容器已经成功创建后,物理机20将通过容器编排工具向管理平台10发送创建成功信息,其中,该创建成功信息包括容器标识信息。该容器标识信息可例如为容器21的编号、名称等用于识别该容器21的识别信息。
管理平台10接收到创建成功信息后,解析出创建成功信息中的容器标识信息,并为容器标识信息对应的容器分配一个私有的容器网络地址,并将容器标识信息与容器网络地址建立对应关系并存储该对应关系,以方便管理容器网络地址。
步骤S1022、接收所述管理平台发送的容器网络地址,并在所述管理平台发起的Ansible远程命令的控制下执行Pipework命令以在所述容器中创建虚拟网卡并将所述容器网络地址设置为所述虚拟网卡的网络地址,其中,所述容器网络地址为所述管理平台在接收到所述创建成功信息后为所述容器标识信息对应的容器分配的私有的网络地址。
具体地,管理平台10通过Ansible远程命令将容器网络地址发送至物理机20中,同时在Ansible远程命令的控制下启动物理机20执行Pipework命令,以在容器21中创建一个虚拟网卡并根据接收到的容器网络地址配置该虚拟网卡。
S103、在物理机中创建网桥。
在一实施例中,如图1所示,当物理机20中的多个容器21处于多个网段 时,为了节省资源,物理机20中处于相同网段的容器21可以桥接到同一个网桥22中,处于不同网段的容器21桥接至不同的网桥22中。因此,在物理机20中创建网桥22之前,需要先判断所述物理机20内是否存在与所述容器网络地址处于相同网段的容器21。若所述物理机20内不存在与所述容器网络地址处于相同网段的容器21,则执行步骤S103,即在物理机20中创建网桥22。若所述物理机20内存在与所述容器网络地址处于相同网段的容器21,说明物理机中存在与容器网络地址对应的网桥22,此时执行步骤S104,即将物理机20的网卡23以及容器21的虚拟网卡均桥接至所述容器网络地址对应的网桥22上。
需要说明的是,在其他实施例中,物理机在执行完步骤S102之后,也可以直接执行步骤S103,这样可以使得每个容器21都对应了一个网桥22。
S104、将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上,以使所述容器通过所述物理机的网卡与外部设备通信。
物理机20将物理机20的网卡23和容器21的虚拟网卡均桥接到网桥22上,这样容器21就可以通过物理机20的网卡23与交换机30连接,以实现容器21与外部设备通信。
在一实施例中,该物理机20的网卡23可以为物理网卡。此时,可以通过在物理网卡上创建至少一个子接口,并将子接口桥接至网桥22上。创建不同网段的多个子接口,分别桥接至不同网段的网桥22上,可以实现在同一个物理机20中起不同网段的容器21。
在另一实施例中,如图4和图5所示,图4为本申请实施例中容器的管理方法的另一场景示意图,图5为本申请实施例中容器的管理方法的另一示意流程图。物理机20中可以配置两个物理网卡。在执行步骤S104之前,还执行步骤S104a。
S104a、将两个所述物理网卡进行绑定形成逻辑网卡,其中,所述逻辑网卡包括物理接口和多个子接口,多个所述子接口的网段互不相同。
在该实施例中,物理机20的网卡23为逻辑网卡231。该逻辑网卡231通过将两张物理网卡绑定所形成。该逻辑网卡231包括一个物理接口和多个子接口。该子接口通过打VLAN标签所形成。譬如,如图4所示,图4所示的逻辑网卡231中包括一个物理接口和三个子接口,其中,该物理接口对应的接口名表示为Bond0。三个子接口的VLAN标签分别为100、200和300,三个子接口对应不 同的网段,VLAN标签为200和VLAN标签为300对应的子接口可以桥接至物理机20中两个不同网段的网桥22中,以与不同网段的容器21连接。VLAN标签为100对应的子接口的网络地址为物理机20的网络地址。
此时步骤S104具体为:将所述物理机的逻辑网卡的子接口桥接至所述网桥上,以及将所述容器的虚拟网卡桥接至所述网桥上,以使得所述容器通过所述物理机的逻辑网卡的物理接口与外部设备通信。即,物理机20需要将逻辑网卡231的子接口桥接至网桥22上,然后将容器21的虚拟网卡桥接至网桥22上,逻辑网卡231的Bond0物理接口连接外部设备,如,交换机30。这样就可以实现容器21通过逻辑网卡231的物理接口Bond0与外部设备通信,同时,物理机20中的多个容器21可以处于多个不同的网段中。
在一实施例中,如图6所示,图6为本申请实施例中容器的管理方法的示意流程图。在步骤S104之后,还包括步骤S105和S106。
S105、监听所述容器的运行状态。
S106、将所述容器的运行状态发送至所述管理平台,以使得所述管理平台记录所述容器的运动状态并根据所述容器的运行状态标记所述容器的容器网络地址的使用状态。
具体地,在一实施例中,在容器21的使用过程中,可以通过容器编排工具监听容器21的运行状态。其中,容器21的运行状态包括容器21的启动状态、停止状态和重启状态。通过容器编排工具将监听到的容器21的运行状态发送至管理平台10。
管理平台10可以记录容器21的运行状态,同时根据容器21的运行状态标记容器21的容器网络地址的使用状态。具体地,当管理平台10接收到的容器21的运行状态为停止状态时,容器21的容器网络地址的使用状态将被标记为disable;当管理平台10接收到的容器21的运行状态为启动状态时,容器21的容器网络地址的使用状态将被标记为enable;当管理平台10接收到的容器21的运行状态为重启状态时,容器21的容器网络地址的使用状态将先被标记为disable,然后再标记为enable。通过这种方式可以确保容器21与对应的容器网络地址始终处于绑定状态,不论容器21处于停止、启动、重启等状态,容器21的容器网络地址均保持不变。
另外,当需要删除容器21时,物理机20可以在管理平台10发送的Ansible 远程命令下删除容器21。在删除容器21后,管理平台10需要将已删除的容器21的容器标识信息与容器网络地址之间的对应关系表删除,并将已删除的容器21的容器网络地址进行回收处理,以便于后续将该回收的容器网络地址分配给其他容器使用。
本实施例中的容器的管理方法,可以在物理机20中快速地创建容器21,且该容器21无需借助第三方软件即可与外部设备进行通信,提高网络性能。同时,该方法还可以实现同一台物理机20中起不同的网段的容器21。
本申请实施例还提供一种容器的管理装置,该容器的管理装置用于执行前述实施例中的容器的管理方法。具体地,请参阅图7,图7是本申请实施例提供的一种容器的管理装置的示意性框图。容器的管理装置300可以安装于物理机中。如图7所示,容器的管理装置300包括容器创建单元301、网卡配置单元302、网桥创建单元303和桥接单元304。
容器创建单元301,用于接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器。
具体地,在一实施例中,容器创建单元301具体用于通过容器编排工具接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器。
在一实施例中,该容器编排工具可以为Docker Swarm、Kubernetes、Marathon和Nomad等工具,所创建的容器可以为Docker容器,在此不对容器编排工具以及容器的种类做具体限制。
网卡配置单元302,用于接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡,其中,所述容器网络地址为所述管理平台为所述容器分配的私有的网络地址。
在一实施例中,如图8所示,图8为本申请实施例提供的一种容器的管理装置的具体示意性框图。该网卡配置单元302包括发送子单元3021和配置子单元3022。
发送子单元3021,用于在监测到所述容器创建成功后,向所述管理平台发送创建成功信息,其中,所述创建成功信息包括容器标识信息。
配置子单元3022,用于接收所述管理平台发送的容器网络地址,并在所述管理平台发起的Ansible远程命令的控制下执行Pipework命令以在所述容器中 创建虚拟网卡并将所述容器网络地址设置为所述虚拟网卡的网络地址,其中,所述容器网络地址为所述管理平台在接收到所述创建成功信息后为所述容器标识信息对应的容器分配的私有的网络地址。
网桥创建单元303,用于在物理机中创建网桥。
在一实施例中,该容器的管理装置300还包括判断单元,该判断单元用于在网桥创建单元303在物理机中创建网桥之前,判断所述物理机内是否存在与所述容器网络地址处于相同网段的容器。若所述物理机内不存在与所述容器网络地址处于相同网段的容器,则向网桥创建单元303发送信号以使其创建网桥;若所述物理机内存在与所述容器网络地址处于相同网段的容器,说明物理机中存在与容器网络地址对应的网桥,此时向桥接单元304发送信号以使得桥接单元304执行将物理机的网卡以及容器的虚拟网卡均桥接至所述容器网络地址对应的网桥上。
桥接单元304,用于将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上,以使所述容器通过所述物理机的网卡与外部设备通信。
在一实施例中,如图9所示,图9为本申请实施例中容器的管理装置的另一示意性框图。该物理机包括两个物理网卡。该容器的管理装置300还包括绑定单元305。绑定单元305用于将两个所述物理网卡进行绑定形成逻辑网卡,其中,所述逻辑网卡包括物理接口和多个子接口,多个所述子接口的网段互不相同。相应地,桥接单元304具体用于将所述物理机的逻辑网卡的子接口桥接至所述网桥上,以及将所述容器的虚拟网卡桥接至所述网桥上,以使得所述容器通过所述物理机的逻辑网卡的物理接口与外部设备通信。
在一实施例中,如图10所示,图10为本申请实施例中容器的管理装置的示意性框图。该容器的管理装置300还包括监听单元306和发送单元307。
监听单元306,用于监听所述容器的运行状态。
发送单元307,用于将所述容器的运行状态发送至所述管理平台,以使得所述管理平台记录所述容器的运动状态并根据所述容器的运行状态标记所述容器的容器网络地址的使用状态。
本实施例中的容器的管理装置300,可以在物理机中快速地创建容器,且该容器无需借助第三方软件即可与外部设备进行通信,提高网络性能。同时,还可以实现同一台物理机中起不同的网段的容器。
上述容器的管理装置可以实现为一种计算机程序的形式,该计算机程序可以在如图11所示的计算机设备上运行。
请参阅图11,图11是本申请实施例提供的一种计算机设备的示意性框图。该计算机设备500设备可以是物理机。
参阅图11,该计算机设备500包括通过系统总线501连接的处理器502、存储器和网络接口505,其中,存储器可以包括非易失性存储介质503和内存储器504。
该非易失性存储介质503可存储操作系统5031和计算机程序5032。该计算机程序5032包括程序指令,该程序指令被执行时,可使得处理器502执行一种容器的管理方法。
该处理器502用于提供计算和控制能力,支撑整个计算机设备500的运行。
该内存储器504为非易失性存储介质503中的计算机程序5032的运行提供环境,该计算机程序5032被处理器502执行时,可使得处理器502执行一种容器的管理方法。
该网络接口505用于进行网络通信,如发送分配的任务等。本领域技术人员可以理解,图11中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备500的限定,具体的计算机设备500可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
其中,所述处理器502用于运行存储在存储器中的计算机程序5032,以实现如下功能:接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器;接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡,其中,所述容器网络地址为所述管理平台为所述容器分配的私有的网络地址;在物理机中创建网桥;将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上,以使所述容器通过所述物理机的网卡与外部设备通信。
在一实施例中,所述物理机包括两个物理网卡;处理器502在执行将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上之前,还实现如下功能:将两个所述物理网卡进行绑定形成逻辑网卡,其中,所述逻辑网卡包括 物理接口和多个子接口,多个所述子接口的网段互不相同;处理器502在执行将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上时,具体实现如下功能:将所述物理机的逻辑网卡的子接口桥接至所述网桥上,以及将所述容器的虚拟网卡桥接至所述网桥上,以使得所述容器通过所述物理机的逻辑网卡的物理接口与外部设备通信。
在一实施例中,处理器502在执行接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器时,具体实现如下功能:通过容器编排工具接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器。
在一实施例中,处理器502在执行接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡时,具体实现如下功能:在监测到所述容器创建成功后,向所述管理平台发送创建成功信息,其中,所述创建成功信息包括容器标识信息;接收所述管理平台发送的容器网络地址,并在所述管理平台发起的Ansible远程命令的控制下执行Pipework命令以在所述容器中创建虚拟网卡并将所述容器网络地址设置为所述虚拟网卡的网络地址,其中,所述容器网络地址为所述管理平台在接收到所述创建成功信息后为所述容器标识信息对应的容器分配的私有的网络地址。
在一实施例中,处理器502在执行将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上之后,还实现如下功能:监听所述容器的运行状态;将所述容器的运行状态发送至所述管理平台,以使得所述管理平台记录所述容器的运动状态并根据所述容器的运行状态标记所述容器的容器网络地址的使用状态。
应当理解,在本申请实施例中,处理器502可以是中央处理单元(Central Processing Unit,CPU),该处理器502还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中,通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
本领域普通技术人员可以理解的是实现上述容器的管理方法实施例中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成。该计算机程序可存储于一计算机可读存储介质中。该计算机可读存储介质包括非易失性计 算机可读存储介质,该计算机程序被该计算机系统中的至少一个处理器执行,以实现包括如上述各容器的管理方法的实施例的流程步骤。
该存储介质可以是U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域普通技术人员可意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的。例如,各个单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。
本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。本申请实施例装置中的单元可以根据实际需要进行合并、划分和删减。另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分,或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,终端,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到各种等效的修改或替换,这些修改或替换都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以权利要求的保护范围为准。

Claims (20)

  1. 一种容器的管理方法,其包括:
    接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器;
    接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡,其中,所述容器网络地址为所述管理平台为所述容器分配的私有的网络地址;
    在物理机中创建网桥;以及
    将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上,以使所述容器通过所述物理机的网卡与外部设备通信。
  2. 根据权利要求1所述的容器的管理方法,其中,所述物理机包括两个物理网卡;
    在所述将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上之前,还包括:将两个所述物理网卡进行绑定形成逻辑网卡,其中,所述逻辑网卡包括物理接口和多个子接口,多个所述子接口的网段互不相同;
    所述将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上,包括:将所述物理机的逻辑网卡的子接口桥接至所述网桥上,以及将所述容器的虚拟网卡桥接至所述网桥上,以使得所述容器通过所述物理机的逻辑网卡的物理接口与外部设备通信。
  3. 根据权利要求1所述的容器的管理方法,其中,所述接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器,包括:通过容器编排工具接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器。
  4. 根据权利要求1所述的容器的管理方法,其中,所述接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡,包括:
    在监测到所述容器创建成功后,向所述管理平台发送创建成功信息,其中,所述创建成功信息包括容器标识信息;以及
    接收所述管理平台发送的容器网络地址,并在所述管理平台发起的Ansible远程命令的控制下执行Pipework命令以在所述容器中创建虚拟网卡并将所述容器网络地址设置为所述虚拟网卡的网络地址,其中,所述容器网络地址为所述 管理平台在接收到所述创建成功信息后为所述容器标识信息对应的容器分配的私有的网络地址。
  5. 根据权利要求1所述的容器的管理方法,其中,在所述将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上之后,还包括:
    监听所述容器的运行状态;以及
    将所述容器的运行状态发送至所述管理平台,以使得所述管理平台记录所述容器的运动状态并根据所述容器的运行状态标记所述容器的容器网络地址的使用状态。
  6. 根据权利要求3所述的容器的管理方法,其中,所述容器编排工具包括Docker Swarm工具、Kubernetes工具、Marathon工具或Nomad工具;所述容器包括Docker容器。
  7. 一种容器的管理装置,其包括:
    容器创建单元,用于接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器;
    网卡配置单元,用于接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡,其中,所述容器网络地址为所述管理平台为所述容器分配的私有的网络地址;
    网桥创建单元,用于在物理机中创建网桥;
    桥接单元,用于将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上,以使所述容器通过所述物理机的网卡与外部设备通信。
  8. 根据权利要求7所述的容器的管理装置,其中,所述物理机包括两个物理网卡;所述管理装置还包括:
    绑定单元,用于将两个所述物理网卡进行绑定形成逻辑网卡,其中,所述逻辑网卡包括物理接口和多个子接口,多个所述子接口的网段互不相同;
    所述桥接单元,具体用于将所述物理机的逻辑网卡的子接口桥接至所述网桥上,以及将所述容器的虚拟网卡桥接至所述网桥上,以使得所述容器通过所述物理机的逻辑网卡的物理接口与外部设备通信。
  9. 根据权利要求7所述的容器的管理装置,其中,所述容器创建单元,具体用于通过容器编排工具接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器。
  10. 一种计算机设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,其中,所述处理器执行所述计算机程序时实现如下步骤:接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器;接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡,其中,所述容器网络地址为所述管理平台为所述容器分配的私有的网络地址;在物理机中创建网桥;以及将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上,以使所述容器通过所述物理机的网卡与外部设备通信。
  11. 根据权利要求10所述的计算机设备,其中,所述物理机包括两个物理网卡;所述处理器执行将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上之前,还实现如下步骤:将两个所述物理网卡进行绑定形成逻辑网卡,其中,所述逻辑网卡包括物理接口和多个子接口,多个所述子接口的网段互不相同;
    所述处理器执行将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上时,实现如下步骤:将所述物理机的逻辑网卡的子接口桥接至所述网桥上,以及将所述容器的虚拟网卡桥接至所述网桥上,以使得所述容器通过所述物理机的逻辑网卡的物理接口与外部设备通信。
  12. 根据权利要求10所述的计算机设备,其中,所述处理器执行接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器时,实现如下步骤:通过容器编排工具接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器。
  13. 根据权利要求10所述的计算机设备,其中,所述处理器执行接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡时,实现如下步骤:在监测到所述容器创建成功后,向所述管理平台发送创建成功信息,其中,所述创建成功信息包括容器标识信息;以及接收所述管理平台发送的容器网络地址,并在所述管理平台发起的Ansible远程命令的控制下执行Pipework命令以在所述容器中创建虚拟网卡并将所述容器网络地址设置为所述虚拟网卡的网络地址,其中,所述容器网络地址为所述管理平台在接收到所述创建成功信息后为所述容器标识信息对应的容器分配的私有的网络地址。
  14. 根据权利要求10所述的计算机设备,其中,所述处理器执行将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上之后,还实现如下步骤:监听所述容器的运行状态;以及将所述容器的运行状态发送至所述管理平台,以使得所述管理平台记录所述容器的运动状态并根据所述容器的运行状态标记所述容器的容器网络地址的使用状态。
  15. 一种计算机可读存储介质,其中,所述计算机可读存储介质存储有计算机程序,所述计算机程序当被处理器执行时使所述处理器执行如下步骤:接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器;接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡,其中,所述容器网络地址为所述管理平台为所述容器分配的私有的网络地址;在物理机中创建网桥;以及将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上,以使所述容器通过所述物理机的网卡与外部设备通信。
  16. 根据权利要求15所述的计算机可读存储介质,其中,所述物理机包括两个物理网卡;所述计算机程序当被处理器执行将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上之前,使所述处理器执行如下步骤:将两个所述物理网卡进行绑定形成逻辑网卡,其中,所述逻辑网卡包括物理接口和多个子接口,多个所述子接口的网段互不相同;所述计算机程序当被处理器执行将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上时使所述处理器执行:将所述物理机的逻辑网卡的子接口桥接至所述网桥上,以及将所述容器的虚拟网卡桥接至所述网桥上,以使得所述容器通过所述物理机的逻辑网卡的物理接口与外部设备通信。
  17. 根据权利要求15所述的计算机可读存储介质,其中,所述计算机程序当被处理器执行接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器时使所述处理器执行如下步骤:通过容器编排工具接收管理平台发送的容器创建请求,并根据所述容器创建请求创建容器。
  18. 根据权利要求15所述的计算机可读存储介质,其中,所述计算机程序当被处理器执行接收所述管理平台发送的容器网络地址,并根据所述容器网络地址配置所述容器的虚拟网卡时使所述处理器执行如下步骤:在监测到所述容器创建成功后,向所述管理平台发送创建成功信息,其中,所述创建成功信息包括容器标识信息;以及接收所述管理平台发送的容器网络地址,并在所述管 理平台发起的Ansible远程命令的控制下执行Pipework命令以在所述容器中创建虚拟网卡并将所述容器网络地址设置为所述虚拟网卡的网络地址,其中,所述容器网络地址为所述管理平台在接收到所述创建成功信息后为所述容器标识信息对应的容器分配的私有的网络地址。
  19. 根据权利要求15所述的计算机可读存储介质,其中,所述计算机程序当被处理器执行将所述物理机的网卡以及所述容器的虚拟网卡均桥接至所述网桥上之后,使所述处理器执行如下步骤:监听所述容器的运行状态;以及将所述容器的运行状态发送至所述管理平台,以使得所述管理平台记录所述容器的运动状态并根据所述容器的运行状态标记所述容器的容器网络地址的使用状态。
  20. 根据权利要求17所述的计算机可读存储介质,其中,所述容器编排工具包括Docker Swarm工具、Kubernetes工具、Marathon工具或Nomad工具;所述容器包括Docker容器。
PCT/CN2018/109319 2018-06-13 2018-10-08 容器的管理方法、装置、计算机设备及存储介质 WO2019237584A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810607066.5 2018-06-13
CN201810607066.5A CN108829384A (zh) 2018-06-13 2018-06-13 容器的管理方法、装置、计算机设备及存储介质

Publications (1)

Publication Number Publication Date
WO2019237584A1 true WO2019237584A1 (zh) 2019-12-19

Family

ID=64144944

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/109319 WO2019237584A1 (zh) 2018-06-13 2018-10-08 容器的管理方法、装置、计算机设备及存储介质

Country Status (2)

Country Link
CN (1) CN108829384A (zh)
WO (1) WO2019237584A1 (zh)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109412864B (zh) * 2018-11-26 2021-08-10 江苏华邦网络科技有限公司 一种非docker网络环境外部访问docker容器环境的方法
CN110266761B (zh) * 2019-05-17 2022-04-19 平安科技(深圳)有限公司 负载均衡应用创建方法、装置、计算机设备及存储介质
CN110262871B (zh) * 2019-05-17 2024-01-23 平安科技(深圳)有限公司 容器应用的容器实例启停方法、装置、计算机设备及存储介质
CN113037522A (zh) * 2019-12-24 2021-06-25 华为数字技术(苏州)有限公司 一种容器单元管理方法及相关设备
CN111209087B (zh) * 2020-01-15 2024-01-30 南京中新赛克科技有限责任公司 一种基于Docker的大数据学习平台搭建方法
CN111491040B (zh) * 2020-04-09 2023-03-24 北京城市网邻信息技术有限公司 一种ip分配方法以及ip分配装置
CN111796905B (zh) * 2020-05-22 2021-04-16 浙商银行股份有限公司 一种kubernetes容器云平台VLAN网络的实现方法及系统
CN111654559B (zh) * 2020-05-29 2023-04-07 深圳前海微众银行股份有限公司 一种容器数据传输方法及装置
CN112231044A (zh) * 2020-09-04 2021-01-15 北京金山云网络技术有限公司 对安全容器的健康检测方法、电子设备及介质
CN114528114B (zh) * 2020-11-09 2023-09-19 成都鼎桥通信技术有限公司 数据处理方法、装置及设备
CN112616153B (zh) * 2020-12-08 2023-07-25 京信网络系统股份有限公司 容器处理方法、装置、计算机设备和存储介质
CN112822060B (zh) * 2021-02-22 2022-11-22 优刻得科技股份有限公司 主机网络的构建方法、装置、系统、介质和主机
CN113746676B (zh) * 2021-09-01 2023-09-01 京东科技信息技术有限公司 基于容器集群的网卡管理方法、装置、设备、介质及产品
CN114172802B (zh) * 2021-12-01 2024-04-26 百果园技术(新加坡)有限公司 容器网络配置方法、装置、计算节点、主节点及存储介质
CN114301913B (zh) * 2021-12-24 2024-03-08 杭州萤石软件有限公司 一种请求处理方法及系统
CN114465847B (zh) * 2022-01-21 2024-05-28 中国船舶重工集团公司第七0九研究所 一种基于容器的动态冗余可靠系统和方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103312661A (zh) * 2012-03-07 2013-09-18 腾讯科技(深圳)有限公司 一种服务访问方法及装置
CN105681488A (zh) * 2016-01-28 2016-06-15 安徽四创电子股份有限公司 一种基于fleet集群服务分配的服务网络地址获取方法
CN106789526A (zh) * 2016-11-29 2017-05-31 北京元心科技有限公司 多系统网络连接的方法及装置
CN107276826A (zh) * 2017-07-24 2017-10-20 郑州云海信息技术有限公司 一种容器网络配置方法和装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7634608B2 (en) * 2006-06-30 2009-12-15 Sun Microsystems, Inc. Bridging network components
CN105763670B (zh) * 2016-04-08 2019-01-29 北京搜狐新媒体信息技术有限公司 一种为容器分配ip地址的方法及装置
CN105978781A (zh) * 2016-06-28 2016-09-28 浪潮电子信息产业股份有限公司 建立Docker容器的网络连接的方法、系统以及客户端

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103312661A (zh) * 2012-03-07 2013-09-18 腾讯科技(深圳)有限公司 一种服务访问方法及装置
CN105681488A (zh) * 2016-01-28 2016-06-15 安徽四创电子股份有限公司 一种基于fleet集群服务分配的服务网络地址获取方法
CN106789526A (zh) * 2016-11-29 2017-05-31 北京元心科技有限公司 多系统网络连接的方法及装置
CN107276826A (zh) * 2017-07-24 2017-10-20 郑州云海信息技术有限公司 一种容器网络配置方法和装置

Also Published As

Publication number Publication date
CN108829384A (zh) 2018-11-16

Similar Documents

Publication Publication Date Title
WO2019237584A1 (zh) 容器的管理方法、装置、计算机设备及存储介质
WO2019184164A1 (zh) 自动部署Kubernetes从节点的方法、装置、终端设备及可读存储介质
WO2019237588A1 (zh) Linux虚拟服务器的创建方法、装置、计算机设备及存储介质
US11693687B1 (en) Lifecycle management of VNFC software modules
US10742502B2 (en) Software modification initiation method, and metadata release method and apparatus
US11249788B2 (en) Cloud management platform, and virtual machine management method and system
US11363117B2 (en) Software-specific auto scaling
WO2018121625A1 (zh) 业务访问请求的处理方法和相关设备
CN102739645A (zh) 虚拟机安全策略的迁移方法及装置
WO2016161605A1 (zh) 基于网络功能虚拟化的故障处理方法和装置
CN108073423B (zh) 一种加速器加载方法、系统和加速器加载装置
WO2020232887A1 (zh) 容器应用的配置修改方法、装置、计算机设备及存储介质
US20210194769A1 (en) Methods and apparatus to configure virtual and physical networks for hosts in a physical rack
CN110225094B (zh) 负载均衡应用虚拟ip切换方法、装置、计算机设备及存储介质
US20160112342A1 (en) Machine providing method, machine providing system and computer-readable recording medium having stored therein machine providing program
US20210326162A1 (en) Lifecycle management of a vnfc included in a multi-vnfc vdu
WO2016029774A1 (zh) 基于虚拟化的应用存储方法、执行方法、装置及系统
WO2018045926A1 (zh) 用于访问容器的方法和装置
US11750558B2 (en) System and method for managing network connected devices
WO2019136798A1 (zh) 一种网关的创建方法、装置、计算机设备及存储介质
CN114647488A (zh) 一种任务训练方法、装置、设备及存储介质
JP5975003B2 (ja) 仮想化制御装置、仮想化システム、仮想化方法、および、仮想化制御プログラム。
WO2024174740A1 (zh) 虚拟机故障信息保存的方法、装置、存储介质及电子设备
US20240118990A1 (en) Monitoring a computer system
CN107391235A (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: 18922900

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 08/04/2021)

122 Ep: pct application non-entry in european phase

Ref document number: 18922900

Country of ref document: EP

Kind code of ref document: A1