Docker Learning 8--communication with the host under the container

This series of Docker learning is CENTOS7 under the study.

1. Container Host/Host Access container

Start a mirror that has been configured for JDK, Tomcat, named Tomcat01.

Use Route-n to view the route of the host, ifconfig to view the host's IP.

DOCKER0 network card is docker when the installation is started on the host generation, all containers will be sent through the DOCKER0 network card data. The container's CentOS is a simple version and many commands are not installed, so use Docker inspect to view the container IP in operation (when the container starts, it randomly generates an IP).

Through the view, know the host IP 192.168.174.129, container tomcat01 IP is 172.17.0.2, then test the host ping container IP, the container ping host IP pass.

2. External Network access container (-p host port: Container port)

Visible by default, hosts and containers can communicate with each other. If the container starts Tomcat within TOMCAT01, there is no doubt that Web tomcat can be accessed on the host, but once the container is stopped and then restarted, the IP of the container may change, which is unacceptable to the developer, So you can use-p to bind the host and container mapping ports. For example,-p host port 80: Container port 8080, so that the external network access, you can host ip:80, so that the actual access is the container 8080, so that when the extranet access, you do not have to care about the container's IP is what the port is.

Stop the container tomcat01 and delete it, then docker-i-t--name tomcat01-p 80:8080 web/tomcat/bin/bash boot, and then start the Tomcat inside the container (port 8080)

Then host Curl http://127.0.0.1:80

3. Communication of containers and containers

Above all is the communication between the container and the host, and the communication between the container and the container.

First try, container a can directly flat through the container B.

The test is OK, because container A and container B are actually the default bridge to the DOCKER0 network card.

Although the container on the host can also communicate with each other, but there are also the problems mentioned above, the container is the start of the allocation of IP, it is changeable. Add container dbdata is used to share data, container A to and dbdata communication, once the container dbdata Restart IP changed, that container a also want to modify it. That must have been unacceptable. Docker provides the--link container name: Alias, when the runtime container is started by--link to specify which container to communicate with. Docker will be in iptable.
Adds a ACCEPT rule to each of the two containers, allowing mutual access to the open ports (depending on the expose in the Dockerfile
Line).

Create the Dbdata container and start the inside Tomcat (default port 8080).

Create a container container_a, and--link to dbdata:db, and then Curl http://db:8080 test to see if you can access dbdata.

After the test is OK, let's take a look at the hosts file of the container container_a.

It is found that the/etc/hosts file in container_a the db/dbdata/container ID will parse to 172.17.0.2. That is a bit of doubt, Container_a Hosts file written dead Dbdata IP, that if dbdata IP has changed. Does container_a have to be restarted, too? That Dbdata stop, and then reboot (before restarting, first create another container B, the role is to occupy Dbdata IP, so restart dbdata, dbdata IP should be new).

Next we look at the container container_b/etc/hosts file, there is no automatic update.

found that the container container_b the dbdata IP of the container is also automatically updated. This solves the problem of communication caused by dbdata IP changes.

The container's connection (linking) system is another way of interacting with the container in addition to the port mappings.
The system creates a tunnel between the source and the receiving container, and the receiving container can see the information specified by the source container.