Docker Learning summary of cross-host link

Docker Learning Summary of cross-host link

　　Docker is a powerful feature, but it's not easy to manage Docker. The following describes a user case that you will encounter in your daily work. For example, there are now two hosts, labeled Hosta and HostB, respectively. Hosta is used to run Oracle services, and HOSTB is used to run app services.

The data generated by the app in HostB needs to be written to the Oracle database in Hosta in real time. That is, Docker container in HostB needs the Docker container in link hosta.

To solve this problem, there are two solutions:

programme One:

The Oracle container in Hosta expose 1521 (which we assume is external to expose 1521), and then modify the HostB file in the container app/etc/hosts, Add the Hosta IP to the hosts file.

The Docker deployment diagram is as follows:

　　

The advantage of this scheme is that it can be freely configured according to the actual situation, " own app control in own hands ".

But the disadvantage is also very serious, the first time every run container need to modify the Hosts file, and every time the host environment changes, need to maintain the hosts file, so the subsequent maintenance costs are high. Second, if you encounter Docker image developed by someone else, we may not have permission to modify the Hosts file.

Therefore, this scheme is only used for development testing, and is not recommended for formal adoption.

Scenario Two:

Docker officially provides a ambassador agent scheme. This scenario uses an image named Svendowideit/ambassador to decouple the different hosts.

The Docker deployment diagram is as follows:

The specific implementation steps are as follows:

First we have to pull Svendowideit/ambassador between Hosta and HostB.

1 Docker pull Svendowideit/ambassador

　　According to the deployment diagram, it is hostb to link hosta container, so we need to start Hosta container (at this point we can understand Hosta as the server segment, HostB as the client segment).

Docker run-  d  --name Oracle Tirtool/oracle11g:latest

Then start the Ambassador container in Hosta.

Docker run  --link oracle:oracle-p 1521:1521 --name Ambassador Svendowideit/ambassador:latest

The red part is a key point to note, which is to expose Oracle container in Hosta directly to Ambassador so that Ambassador can forward access requests to Oracle container.

At the moment, everything in hosta has been dealt with, and we begin to deal with HOSTB.

With Hosta the container boot order is not needed, we need to start HostB Ambassador first. Because according to the deployment diagram, HostB is the app container call Ambassador container, so you need to ensure that ambassador is started before the app container can be launched.

--expose 1521-e oracle_port_1521_tcp=tcp://  < Svendowideit/ambassador

　The red section is important and directly determines whether HOSTB and hosta can communicate directly. Later, we can take a look at this part of the parameter.

When the ambassador in HostB started successfully, we started to launch the app container.

--name bw Base/ubuntu:14.04

Notice that we have ambassador-oracle alias as Oracle in App container, so there's a record in the/etc/hosts file in app container:

10.1.0.3 Oracle

Now that the app is generating data in app container, if you call oracle:1521, first send the request to port 1521 of ambassador, HostB. The HOSTB Ambassador forwards the data to port 1521 of Hosta. At this point, the ambassador in Hosta is listen port 1521, and when the request is received, the data is forwarded to the Hosta Oracle container. After the Oracle container processing is complete, the response return value Ambassador,ambassador and then callback. In order to achieve the purpose of container mutual access in different host.

Let's take a look at the HostB. --expose 1521-e oracle_port_1521_tcp=tcp:// < when something happened. One of the most important tasks for ambassador is port mapping of the HOSTB 1521 port to port 1521 of Hosta.

In fact, the following command is executed:

Socat tcp4-listen:1521,fork,reuseaddr Tcp4:

This command takes the fork mode and forwards 1521 of the local data to the Hosta 1521 port. The parameters required for this command come from a shell script:

env | grep _tcp= | Sed ' s/.*_port_\ ([0-9]*\) _tcp=tcp:\/\/\ (. *\): \ (. *\)/socat tcp4-listen:\1,fork,reuseaddr tcp4:\2:\3 \&/' | SH && Top

This command searches for all *_TCP environment variables in env, and we set the- e oracle_port_1521_tcp=tcp://< at startup ip>>:1521 So you can find oracle_port_1521_tcp this variable. After you find the Execute regular expression "s/.*_port_\ ([0-9]*\) _tcp=tcp:\/\/\ (. *\): \ (. *\)/socat tcp4-listen:\1,fork,reuseaddr tcp4:\2:\3 \&/" The replacement shell command is Socat tcp4-listen:1521,fork,reuseaddr Tcp4:

So the Ambassador scheme is a clever way to bridge the ports of different hosts, which are transparent to the Docker users. However, this scheme is also flawed, that is, if you need to restart or add ambassador after adding container, so if a ambassador corresponds to multiple container at the same time, then maintenance will be a little more trouble, But the cost of maintenance is much lower than the scheme one.

Docker Learning summary of cross-host link