CN105490910B - Network communication method and client - Google Patents

Network communication method and client Download PDF

Info

Publication number
CN105490910B
CN105490910B CN201410484051.6A CN201410484051A CN105490910B CN 105490910 B CN105490910 B CN 105490910B CN 201410484051 A CN201410484051 A CN 201410484051A CN 105490910 B CN105490910 B CN 105490910B
Authority
CN
China
Prior art keywords
docker
container
network communication
bridge
communication identifier
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN201410484051.6A
Other languages
Chinese (zh)
Other versions
CN105490910A (en
Inventor
许斯亮
赵鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Qihoo Technology Co Ltd
Original Assignee
Beijing Qihoo Technology Co Ltd
Qizhi Software Beijing Co Ltd
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 Beijing Qihoo Technology Co Ltd, Qizhi Software Beijing Co Ltd filed Critical Beijing Qihoo Technology Co Ltd
Priority to CN201410484051.6A priority Critical patent/CN105490910B/en
Priority to PCT/CN2015/086478 priority patent/WO2016041421A1/en
Publication of CN105490910A publication Critical patent/CN105490910A/en
Application granted granted Critical
Publication of CN105490910B publication Critical patent/CN105490910B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines

Abstract

The invention provides a network communication method and a client. Wherein, the method comprises the following steps: bridge is designated using docker, wherein bridge is generated as follows: when the virtual local area network vlan is set to be in a relay trunk mode, utilizing bridge equipment to associate the vlan with a network card to generate bridge; and distributing an independent network communication identifier for each container in the docker by using bridge, so that each container can independently communicate with the outside by using the network communication identifier through the vlan, wherein the container is the container started by the docker. According to the network communication method provided by the embodiment of the invention, each container in the docker can independently communicate with the outside.

Description

Network communication method and client
Technical Field
The present invention relates to the field of communications, and in particular, to a network communication method and a client.
Background
With the development of network technology, people are more and more accustomed to running multiple services simultaneously in the same server. For example, navigation services, cell phone assistants and other master station services are simultaneously run on a 64G server. When a plurality of services are simultaneously operated on one server, in order to ensure that when one service is attacked or problems occur in operation and the like, other services are not affected by relevant adverse effects, and resources are isolated from the server. In the resource isolation, since the VM virtual machine needs to occupy a large amount of resources of a Central Processing Unit (CPU), a virtualization scheme implemented by an open source application container engine docker managing a plurality of container containers is generally adopted in the prior art to perform the resource isolation.
However, in the prior art, when performing resource isolation by using a docker and a container, each container of the docker cannot independently communicate with the outside, and when performing port allocation on the container, each port can only be used by one container, and a technology or a protocol corresponding to the port cannot be shared by a plurality of containers, so that multiple complex operations are required to perform docking of multiple technologies or functions, and even some technologies or functions exist.
Disclosure of Invention
In view of the above, the present invention is proposed in order to provide a network communication method and a corresponding client that overcome or at least partially solve the above problems.
According to an aspect of the present invention, there is provided a network communication method applied to an open source application container engine docker including a plurality of container containers, including: bridge designation using docker, wherein the bridge is generated as follows: when the virtual local area network vlan is set to be in a relay trunk mode, utilizing bridge equipment to associate the vlan with a network card, and generating bridge; and distributing an independent network communication identifier for each container in the docker by using the bridge, so that each container can independently communicate with the outside through the vlan by using the network communication identifier, wherein the container is a container started by the docker.
Optionally, allocating an independent network communication identifier to each container in the docker includes: dividing network communication identifiers by using the vlan according to the number of contiiners in the docker; and distributing an independent network communication identifier for each container in the docker according to the division result.
Optionally, the step of starting the docker by using the bridge device with completed addition includes: changing configuration data in the docker to prevent network communication identifier allocation operation of the docker, wherein the configuration data comprises network card configuration data; and binding the appointed network communication identifier with the selected container in the docker so that the selected container can independently communicate with the outside by utilizing the appointed network communication identifier.
Optionally, the step of changing the configuration data in the docker includes: and changing the network card configuration data in the docker into a closed false state.
Optionally, the method further comprises: after the bridge is used for distributing independent network communication identifiers for each container in the docker, mapping all the containers in the docker to the same functional port, so that all the containers share the resources corresponding to the functional port.
Optionally, the network communication identifier includes an internet protocol, IP, address.
According to another aspect of the present invention, there is also provided a network communication client applied to a docker including a plurality of containers, including: a specifying module adapted to specify a bridge using docker, wherein the bridge is generated as follows: when the virtual local area network vlan is set to be in a relay trunk mode, utilizing bridge equipment to associate the vlan with a network card, and generating bridge; and the distribution module is suitable for distributing an independent network communication identifier for each container in the docker by using the bridge, so that each container can independently communicate with the outside world through the vlan by using the network communication identifier, wherein the container is the container started by the docker.
Optionally, when the bridge is used to allocate an independent network communication identifier for each container in the docker, the allocating module is further adapted to: dividing network communication identifiers by using the vlan according to the number of contiiners in the docker; and distributing an independent network communication identifier for each container in the docker according to the division result.
Optionally, the network communication client further includes: the data changing module is suitable for changing the configuration data in the docker to prevent the network communication identifier distribution operation of the docker, wherein the configuration data comprises network card configuration data; and the binding module is suitable for binding the specified network communication identifier with the selected container in the docker so that the selected container can independently communicate with the outside by utilizing the specified network communication identifier.
Optionally, when changing the configuration data in the docker, the data changing module is further adapted to: and changing the network card configuration data in the docker into a closed false state.
Optionally, the network communication client further includes: and the mapping module is suitable for mapping all the contiainers in the docker to the same functional port after the bridge is used for distributing independent network communication identifiers for each contiainer in the docker, so that all the contiainers can share the resources corresponding to the functional port.
Optionally, the network communication identifier includes an internet protocol, IP, address.
According to the embodiment of the invention, a bridge can be specified by a docker, wherein the bridge is generated by the following steps: when the virtual local area network vlan is set to the relay trunk mode, the bridge is generated by using the bridge device to associate the vlan with the network card. And then, an independent network communication identifier is distributed to each container in the docker by using the specified bridge, so that each container can independently communicate with the outside through the vlan by using the network communication identifier, and the problem that each container of the docker cannot independently communicate with the outside in the prior art is solved. Wherein, the container in this example is container started by docker. When the bridge created by the docker is used for distributing the network communication identifiers for all the container managed by the docker, all the container can only share the same network communication identifier, and when the specified bridge is used for distributing the network communication identifiers, the network communication identifiers can be divided by using the vlan in the bridge, so that each container forming the docker can be distributed to an independent network communication identifier and independently communicate with the outside by using the network communication identifier. Therefore, in the embodiment of the present invention, each container in the docker can directly communicate with the outside, so as to avoid the problem that a data packet cannot be timely distributed due to the fact that the container communicates with the outside through operations such as data distribution of a third party, reduce a packet loss rate, and improve the communication efficiency between the container and the outside.
In addition, because the network communication method provided by the embodiment of the present invention enables each container in the docker to have the capability of independently communicating with the outside (through an independent network communication identifier), when a plurality of containers exist in the docker, the containers can be mapped to the same port by using the independent network communication identifier of each container, and each container can communicate with the outside (including simultaneous and/or time-sharing use) by using the port without affecting each other. That is, by adopting the embodiment of the present invention, all containers can be bound to the same port, and seamless docking of functions or technologies corresponding to any port is realized.
The foregoing description is only an overview of the technical solutions of the present invention, and the embodiments of the present invention are described below in order to make the technical means of the present invention more clearly understood and to make the above and other objects, features, and advantages of the present invention more clearly understandable.
The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments thereof, taken in conjunction with the accompanying drawings.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
FIG. 1 is a process flow diagram of a network communication method according to one embodiment of the invention;
fig. 2 is a diagram illustrating a process flow for binding a specified network communication identifier with a container in accordance with a preferred embodiment of the present invention;
FIG. 3 is a process flow diagram of a network communication method in accordance with a preferred embodiment of the present invention;
FIG. 4 is a schematic diagram illustrating the structure of any container in the docker connecting with bridge to communicate with the outside independently according to a preferred embodiment of the present invention;
FIG. 5 illustrates a schematic diagram of a network communication client according to one embodiment of the present invention; and
fig. 6 shows a schematic structural diagram of a network communication client according to a preferred embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
In the related art, when resource isolation is performed by using an open source application container engine (hereinafter, docker) and a container (hereinafter, container), if port allocation is performed on any container of the docker, each port can only be used by one container, and a technology or a protocol corresponding to the port cannot be shared by multiple containers, so that multiple complex operations are required to perform docking of multiple technologies or functions, and even some technologies or functions exist.
In order to solve the above technical problem, an embodiment of the present invention provides a network communication method. Fig. 1 shows a process flow diagram of a network communication method according to an embodiment of the invention. Referring to fig. 1, the process at least includes step S102, step S104 and step S106.
Step S102: when a Virtual Local Area Network (vlan) is set to a relay (trunk) mode, using bridge equipment to associate the vlan with a Network card to generate a bridge (bridge), and using a docker to specify the generated bridge, namely changing the configuration of the docker, so that the docker can complete operations needing the bridge by using the generated bridge;
step S104: and distributing an independent network communication identifier for each container in the docker by using the generated bridge, so that each container can independently communicate with the outside through the vlan by using the network communication identifier, wherein the container in the example is the container started by the docker.
According to the embodiment of the invention, a bridge can be specified by a docker, wherein the bridge is generated by the following steps: when the virtual local area network vlan is set to the relay trunk mode, the bridge is generated by using the bridge device to associate the vlan with the network card. And then, an independent network communication identifier is distributed to each container in the docker by using the specified bridge, so that each container can independently communicate with the outside through the vlan by using the network communication identifier, and the problem that each container managed by the docker in the prior art cannot independently communicate with the outside is solved. Wherein, the container in this example is container started by docker. When the bridge created by the docker is used for distributing the network communication identifiers for all the container managed by the docker, all the container can only share the same network communication identifier, and when the specified bridge is used for distributing the network communication identifiers, the network communication identifiers can be divided by using the vlan in the bridge, so that each container forming the docker can be distributed to an independent network communication identifier and independently communicate with the outside by using the network communication identifier. Therefore, in the embodiment of the present invention, each container managed by the docker can directly communicate with the outside, so as to avoid the problem that a data packet cannot be timely distributed due to the fact that the container communicates with the outside through operations such as data distribution of a third party, reduce a packet loss rate, and improve the communication efficiency between the container and the outside.
In addition, because the network communication method provided by the embodiment of the present invention enables each container in the docker to have the capability of independently communicating with the outside (through an independent network communication identifier), when a plurality of containers exist in the docker, the containers can be mapped to the same port by using the independent network communication identifier of each container, and each container can communicate with the outside (including simultaneous and/or time-sharing use) by using the port without affecting each other. That is, by adopting the embodiment of the present invention, all containers can be bound to the same port, and seamless docking of functions or technologies corresponding to any port is realized.
As mentioned above, in the embodiment of the present invention, an independent network communication identifier is allocated to each container in the docker, so that each container can independently communicate with the outside world through the vlan using its network communication identifier. Specifically, when an independent network communication identifier is allocated to each container, the embodiment of the present invention divides the network communication identifiers according to the number of the containers in the docker by using the vlan. And then, distributing independent network communication identifiers for each container in the docker according to the division result. For example, when the network communication identifier is an Internet Protocol (IP) address and the contiiners in the current docker are contiiner 1, contiiner 2, and contiiner 3, the IP address is divided by vlan. The division results are 11.0.0.1, 11.0.0.2 and 11.0.0.3, and then each container is assigned an independent IP address, and the assignment result may be:
the IP address of Container1 is 11.0.0.1;
the IP address of Container2 is 11.0.0.2;
the IP address of Container3 is 11.0.0.3.
As another example, when the network traffic identification is an IP address, and the IP address is two network segments, 11.0.0 and 11.0.1, respectively. When the contiiners in the docker are contiiner 4, contiiner 5, contiiner 6, and contiiner 7, the IP addresses are divided by vlan. The division result is 11.0.0.1, 11.0.0.2, 11.0.1.1, 11.0.1.2, and then each container is assigned an independent IP address, and the assignment result may be:
the IP address of Container4 is 11.0.1.2;
the IP address of Container5 is 11.0.1.1;
the IP address of Container6 is 11.0.0.2;
the IP address of Container7 is 11.0.0.1.
It should be noted that the division result and the allocation result mentioned in the above example are only examples, and cannot represent the division result and/or the allocation result in the actual operation.
The process of assigning a separate network communication identifier to each container in the docker is described above. In this process, the embodiment of the present invention divides the network communication identifier by using the vlan according to the number of containers in the docker. After the partitioning, if it is only necessary that each container in the docker can independently communicate with the outside, as in the above-described process, an independent network communication identifier is directly allocated to each container in the docker according to the partitioning result. If the specified network communication identifier needs to be bound with the container, the corresponding operation needs to be executed according to the flowchart shown in fig. 2. Fig. 2 is a diagram illustrating a processing flow of binding a specified network communication identifier and a container according to a preferred embodiment of the present invention. Referring to fig. 2, the process at least includes step S202 and step S204.
Step S202: and changing the configuration data in the docker to prevent the network communication identifier of the docker from being automatically allocated, and specifically, if the configuration data in the docker is not changed, the docker can automatically allocate the network communication identifier to the started container by using bridge when the container is started. In this example, the configuration data in the docker is changed, so as to prevent the docker from automatically allocating the network communication identifier to the started container by using bridge. Preferably, in this example, the configuration data in docker includes network card configuration data. When the designated network communication identifier needs to be bound with the container, the network card configuration data in the docker can be changed into a closed state (hereinafter referred to as a false state) so as to prevent the network communication identifier of the docker from being automatically allocated;
step S204: and binding the designated network communication identifier with the selected container in the docker so that the selected container can independently communicate with the outside by using the designated network communication identifier, and ending the process.
In the embodiment of the invention, by means of a mode of using a docker to specify a bridge and starting the docker by using the specified bridge, independent network communication identifiers are distributed or bound for the container forming the docker, so that each container can communicate with the outside by using the network communication identifier. In addition, in the embodiment of the present invention, the network communication identifier may be any communication identifier that can be used by a container to communicate with the outside, which is not limited in the embodiment of the present invention. Preferably, in the embodiment of the present invention, an IP address commonly used in practical application is selected as the network communication identifier.
Example one
In order to clarify the network communication method provided by the above preferred embodiments, the network communication method provided by the embodiment of the present invention will be described with a preferred embodiment. Fig. 3 shows a process flow diagram of a network communication method according to a preferred embodiment of the present invention. Referring to fig. 3, the flow includes at least steps S302, S304, S306, S308, and S310.
Step S302: when the vlan is set to a trunk mode, utilizing the bridge equipment to associate the vlan with the network card to generate bridge;
step S304: designating bridge generated in step S302 using docker;
step S306: dividing the network communication identification by using a vlan according to the number of contiiners in the docker;
step S308: and allocating an independent network communication identifier to each container in the docker according to the division result, specifically, when allocating an independent network communication identifier to each container, if the specified network communication identifier is bound to the selected container, changing the configuration data in the docker (for example, changing the network card configuration data in the docker to a false state) so as to prevent the network communication identifier allocation operation of the docker. Then, binding the designated network communication identifier with the selected container in the docker, so that the selected container can independently communicate with the outside by using the designated network communication identifier;
step S310: and binding all the containers in the docker to the same functional port so that all the containers share the resources corresponding to the functional port, and ending the process.
Specifically, because the network communication method provided by the embodiment of the present invention enables each container in the docker to have the capability of independently communicating with the outside (through an independent network communication identifier), when there are multiple containers in the docker, the multiple containers can be mapped to the same port by using the independent network communication identifier of each container, and each container can communicate with the outside (including simultaneous and/or time-sharing use) by using the port without affecting each other.
Example two
Fig. 4 is a schematic structural diagram illustrating that any container in the docker is connected with the bridge to independently communicate with the outside according to a preferred embodiment of the present invention. As can be seen from fig. 4, in the fourteen-row implementation of the present invention, since each container (e.g., container1, container2, and container3 shown in fig. 4) has an independent network communication identifier, any container can be bound to any port. I.e., the correspondences of containers to ports may be one-to-one or many-to-one. In practice, the port of each function is fixed, so that if any function needs to communicate with the container, the container needs to be bound to the port of the function. For example, when the container needs to issue a code, the code needs to be issued based on a Secure Shell protocol (hereinafter referred to as ssh protocol), and therefore, the 22 ports corresponding to the protocol need to be bound. At this time, if another container is already bound to the 22 port, the current container cannot be continuously bound to the 22 port in the prior art. According to the network communication method provided by the embodiment of the invention, the current container and the 22 port can be directly bound, and the operation of releasing the code of the container is realized. In summary, according to the network communication method in the embodiment of the present invention, each container can have an independent network communication identifier, so that seamless access to the function corresponding to each port can be achieved without any modification.
Based on the network communication method provided by the above preferred embodiments, based on the same inventive concept, the embodiment of the present invention provides a network communication client, which is applied to a docker including a plurality of containers, and is used for implementing the network communication method. Fig. 5 shows a schematic structural diagram of a network communication client according to an embodiment of the present invention. Referring to fig. 5, the network communication client of the embodiment of the present invention includes at least a designation module 510 and an assignment module 520.
The functions of the devices or components of the network communication client and the connection relationship between the components of the network communication client according to the embodiment of the present invention are described as follows:
the designation module 510: it is suitable to specify a bridge using docker, wherein the bridge is generated as follows: when the virtual local area network vlan is set to be in a relay trunk mode, utilizing bridge equipment to associate the vlan with a network card to generate bridge;
the assignment module 520: coupled to the assigning module 510, it is adapted to assign an independent network communication identifier to each container in the docker by using bridge, so that each container can independently communicate with the outside world through vlan by using its network communication identifier, where the container is the container started by the docker.
In a preferred embodiment, the assignment module 520 is further adapted to: dividing the network communication identification by using a vlan according to the number of contiiners in the docker; and distributing independent network communication identifiers for each container in the docker according to the division result.
Fig. 6 shows a schematic structural diagram of a network communication client according to a preferred embodiment of the present invention. Referring to fig. 5 and fig. 6 together, compared to the network communication client in fig. 5, the network communication client (shown in fig. 6) according to the embodiment of the present invention further includes:
the data modification module 530: coupled to the allocating module 530, the module is adapted to change configuration data in docker to prevent network communication identifier allocation operation of docker, where the configuration data includes network card configuration data;
the binding module 540: coupled to the data modification module 530, is adapted to bind the designated network communication identifier with a selected container in the docker, so that the selected container can independently communicate with the outside world by using the designated network communication identifier.
In a preferred embodiment, the data modification module 530 is further adapted to: and changing the network card configuration data in the docker into a false state.
In a preferred embodiment, the network communication client (shown in fig. 6) of the embodiment of the present invention further includes:
the mapping module 550: the mapping module is coupled to the allocating module 520 and the binding module 540, and is adapted to map all the containers in the docker to the same functional port after allocating an independent network communication identifier to each container in the docker by using bridge, so that all the containers share the resource corresponding to the functional port.
In a preferred embodiment, the network communication identification comprises an internet protocol, IP, address.
According to any one or a combination of the above preferred embodiments, the following advantages can be achieved by the embodiments of the present invention:
according to the embodiment of the invention, a bridge can be specified by a docker, wherein the bridge is generated by the following steps: when the virtual local area network vlan is set to the relay trunk mode, the bridge is generated by using the bridge device to associate the vlan with the network card. And then, an independent network communication identifier is distributed to each container in the docker by using the specified bridge, so that each container can independently communicate with the outside through the vlan by using the network communication identifier, and the problem that each container of the docker cannot independently communicate with the outside in the prior art is solved. Wherein, the container in this example is container started by docker. When the bridge created by the docker is used for distributing the network communication identifiers for all the container managed by the docker, all the container can only share the same network communication identifier, and when the specified bridge is used for distributing the network communication identifiers, the network communication identifiers can be divided by using the vlan in the bridge, so that each container forming the docker can be distributed to an independent network communication identifier and independently communicate with the outside by using the network communication identifier. Therefore, in the embodiment of the present invention, each container in the docker can directly communicate with the outside, so as to avoid the problem that a data packet cannot be timely distributed due to the fact that the container communicates with the outside through operations such as data distribution of a third party, reduce a packet loss rate, and improve the communication efficiency between the container and the outside.
In addition, because the network communication method provided by the embodiment of the present invention enables each container in the docker to have the capability of independently communicating with the outside (through an independent network communication identifier), when a plurality of containers exist in the docker, the containers can be mapped to the same port by using the independent network communication identifier of each container, and each container can communicate with the outside (including simultaneous and/or time-sharing use) by using the port without affecting each other. That is, by adopting the embodiment of the present invention, all containers can be bound to the same port, and seamless docking of functions or technologies corresponding to any port is realized.
In the description provided herein, numerous specific details are set forth. It is understood, however, that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.
Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be interpreted as reflecting an intention that: that the invention as claimed requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.
Those skilled in the art will appreciate that the modules in the device in an embodiment may be adaptively changed and disposed in one or more devices different from the embodiment. The modules or units or components of the embodiments may be combined into one module or unit or component, and furthermore they may be divided into a plurality of sub-modules or sub-units or sub-components. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or elements of any method or apparatus so disclosed, may be combined in any combination, except combinations where at least some of such features and/or processes or elements are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.
Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features included in other embodiments, rather than other features, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments. For example, in the claims, any of the claimed embodiments may be used in any combination.
The various component embodiments of the invention may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art will appreciate that a microprocessor or Digital Signal Processor (DSP) may be used in practice to implement some or all of the functions of some or all of the components in an apparatus or device according to embodiments of the present invention. The present invention may also be embodied as apparatus or device programs (e.g., computer programs and computer program products) for performing a portion or all of the methods described herein. Such programs implementing the present invention may be stored on computer-readable media or may be in the form of one or more signals. Such a signal may be downloaded from an internet website or provided on a carrier signal or in any other form.
It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by one and the same item of hardware. The usage of the words first, second and third, etcetera do not indicate any ordering. These words may be interpreted as names.
Thus, it should be appreciated by those skilled in the art that while a number of exemplary embodiments of the invention have been illustrated and described in detail herein, many other variations or modifications consistent with the principles of the invention may be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Accordingly, the scope of the invention should be understood and interpreted to cover all such other variations or modifications.

Claims (10)

1. A network communication method is applied to an open source application container engine docker comprising a plurality of container containers, and comprises the following steps:
bridge is designated using docker, wherein the bridge is generated as follows: when the virtual local area network vlan is set to be in a relay trunk mode, utilizing bridge equipment to associate the vlan with a network card, and generating bridge; and
and distributing an independent network communication identifier for each container in the docker by using the bridge, so that each container can independently communicate with the outside through the vlan by using the network communication identifier, wherein the container is the container started by the docker.
2. The method of claim 1, wherein the step of assigning an independent network communication identifier to each container in the docker comprises:
dividing network communication identifiers by using the vlan according to the number of contiiners in the docker; and
and distributing an independent network communication identifier for each container in the docker according to the division result.
3. The method of claim 1 or 2, wherein the step of assigning an independent network communication identifier to each container in the docker using the bridge comprises:
changing configuration data in the docker to prevent automatic allocation operation of a network communication identifier of the docker, wherein the configuration data comprises network card configuration data; and
binding a designated network communication identifier with a selected container in the docker so that the selected container can independently communicate with the outside by using the designated network communication identifier;
wherein the step of changing the configuration data in the docker comprises: and changing the network card configuration data in the docker into a closed false state.
4. The method according to claim 1 or 2, wherein the method further comprises:
after the bridge is used for distributing independent network communication identifiers for each container in the docker, mapping all the containers in the docker to the same functional port, so that all the containers share the resources corresponding to the functional port.
5. The method of claim 1 or 2, wherein the network communication identity comprises an internet protocol, IP, address.
6. A network communication client applied to an open source application container engine docker including a plurality of container containers, comprising:
a designation module adapted to designate a bridge using docker, wherein the bridge is generated by: when the virtual local area network vlan is set to be in a relay trunk mode, utilizing bridge equipment to associate the vlan with a network card, and generating bridge; and
and the distribution module is suitable for distributing an independent network communication identifier for each container in the docker by using the bridge, so that each container can independently communicate with the outside world through the vlan by using the network communication identifier, wherein the container is the container started by the docker.
7. The client of claim 6, wherein, in assigning an independent network communication identifier to each container in the docker using the bridge, the assigning module is further adapted to:
dividing network communication identifiers by using the vlan according to the number of contiiners in the docker; and
and distributing an independent network communication identifier for each container in the docker according to the division result.
8. The client according to claim 6 or 7, further comprising:
the data changing module is suitable for changing the configuration data in the docker to prevent the network communication identifier distribution operation of the docker, wherein the configuration data comprises network card configuration data; and
the binding module is suitable for binding a specified network communication identifier with a selected container in the docker so that the selected container can independently communicate with the outside by using the specified network communication identifier;
wherein, when changing the configuration data in the docker, the data changing module is further adapted to:
and changing the network card configuration data in the docker into a closed false state.
9. The client according to claim 6 or 7, further comprising:
and the mapping module is suitable for mapping all the contiainers in the docker to the same functional port after the bridge is used for distributing independent network communication identifiers for each contiainer in the docker, so that all the contiainers can share the resources corresponding to the functional port.
10. A client according to claim 6 or 7, wherein the network communication identity comprises an Internet protocol, IP, address.
CN201410484051.6A 2014-09-19 2014-09-19 Network communication method and client Active CN105490910B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201410484051.6A CN105490910B (en) 2014-09-19 2014-09-19 Network communication method and client
PCT/CN2015/086478 WO2016041421A1 (en) 2014-09-19 2015-08-10 Network communication method and client

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201410484051.6A CN105490910B (en) 2014-09-19 2014-09-19 Network communication method and client

Publications (2)

Publication Number Publication Date
CN105490910A CN105490910A (en) 2016-04-13
CN105490910B true CN105490910B (en) 2020-02-07

Family

ID=55532538

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201410484051.6A Active CN105490910B (en) 2014-09-19 2014-09-19 Network communication method and client

Country Status (2)

Country Link
CN (1) CN105490910B (en)
WO (1) WO2016041421A1 (en)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105763670B (en) * 2016-04-08 2019-01-29 北京搜狐新媒体信息技术有限公司 A kind of method and device for container allocation IP address
CN106060122B (en) * 2016-05-20 2019-03-05 北京奇虎科技有限公司 Docker container uploads/downloads the control method and device of characteristic
CN105847108B (en) * 2016-05-24 2019-01-15 中国联合网络通信集团有限公司 Communication means and device between container
CN106067858B (en) * 2016-05-24 2019-02-15 中国联合网络通信集团有限公司 Communication means, apparatus and system between container
CN107181812B (en) 2017-06-08 2020-05-22 网宿科技股份有限公司 Acceleration agent device, acceleration agent method and content management system
CN107770298B (en) * 2017-09-30 2020-07-28 华为技术有限公司 Method and device for transmitting data
US10541924B2 (en) 2017-12-01 2020-01-21 International Business Machines Corporation Load balancing in data hosting systems
US11416274B2 (en) 2018-12-07 2022-08-16 International Business Machines Corporation Bridging a connection to a service by way of a container to virtually provide the service
US11681542B2 (en) 2020-01-16 2023-06-20 Vmware, Inc. Integrating virtualization and host networking

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013149634A1 (en) * 2012-04-02 2013-10-10 Nokia Siemens Networks Oy Network management system
CN103647692A (en) * 2013-11-04 2014-03-19 北京奇虎科技有限公司 Network processing method, device and system
CN103731514A (en) * 2013-12-29 2014-04-16 国云科技股份有限公司 Virtual network management method
CN103870314A (en) * 2014-03-06 2014-06-18 中国科学院信息工程研究所 Method and system for simultaneously operating different types of virtual machines by single node

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013149634A1 (en) * 2012-04-02 2013-10-10 Nokia Siemens Networks Oy Network management system
CN103647692A (en) * 2013-11-04 2014-03-19 北京奇虎科技有限公司 Network processing method, device and system
CN103731514A (en) * 2013-12-29 2014-04-16 国云科技股份有限公司 Virtual network management method
CN103870314A (en) * 2014-03-06 2014-06-18 中国科学院信息工程研究所 Method and system for simultaneously operating different types of virtual machines by single node

Also Published As

Publication number Publication date
CN105490910A (en) 2016-04-13
WO2016041421A1 (en) 2016-03-24

Similar Documents

Publication Publication Date Title
CN105490910B (en) Network communication method and client
CN109194502B (en) Management method of multi-tenant container cloud computing system
US11003480B2 (en) Container deployment method, communication method between services, and related apparatus
CN111885075B (en) Container communication method, device, network equipment and storage medium
US9965317B2 (en) Location-aware virtual service provisioning in a hybrid cloud environment
CN107278359B (en) Method, host and system for processing message in cloud computing system
CN109462534B (en) Local interconnect controller, local interconnect control method, and computer storage medium
CN110099014B (en) Message processing method and host in cloud computing system
CN104704471B (en) Virtual machine multicast/broadcast in virtual network
CN108924268B (en) Container cloud service system and pod creation method and device
CN105591820B (en) High-extensible container network management system and method
WO2016155394A1 (en) Method and device for establishing link between virtual network functions
CN106031116B (en) A kind of correlating method, the apparatus and system of NS and VNF
CN111030912B (en) Method for intercommunication between virtual private cloud VPCs
CN109451084A (en) A kind of service access method and device
US20170272400A1 (en) Network virtualization of containers in computing systems
CN108768692B (en) Network creation method, related equipment and system
CN105872129B (en) A kind of more network interface card outbound communication implementation methods of Linux virtual machine
CN111130838B (en) Dynamic expansion and network bandwidth limitation method and device for process-level service instance
US10841274B2 (en) Federated virtual datacenter apparatus
CN110769075B (en) Container communication method, system, controller and computer readable storage medium
CN105763670A (en) Method and device for allocating IP address to container
CN112099913A (en) Method for realizing safety isolation of virtual machine based on OpenStack
CN104506368A (en) Method and equipment for managing switchboard equipment in unified manner
CN108351798A (en) Expansible addressing mechanism for virtual machine

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20240108

Address after: 100088 room 112, block D, 28 new street, new street, Xicheng District, Beijing (Desheng Park)

Patentee after: BEIJING QIHOO TECHNOLOGY Co.,Ltd.

Address before: 100088 room 112, block D, 28 new street, new street, Xicheng District, Beijing (Desheng Park)

Patentee before: BEIJING QIHOO TECHNOLOGY Co.,Ltd.

Patentee before: Qizhi software (Beijing) Co.,Ltd.

TR01 Transfer of patent right