Docker Pit (i)

Docker Tai Keng Posted on March 2, 2015March 2, 2015 by Sun Hongliang

Docker has become the new darling of cloud computing field is an indisputable fact, as a high-speed development of open source projects, there are inevitably such or such flaws. The author recently in the development of actual combat has fallen into some pits, some pits are deep, write to share, is equivalent to hanging a warning card in the pit, to avoid the same mistakes. Say not much, together to appreciate the Docker pit small WA. Images of different tags of the same type in 1.Docker are not interchangeable. Description:

Docker of the same type of mirror, usually using tag to differentiate each other. such as Docker in the MySQL Mirror, mirror tag There are many kinds, there are 5.6.17,5.6.22,latest and so on. If the user's environment is proficient in the use of mysql:5.6.17, does not mean that the user if the use of mysql:5.6.22, the environment is still working. Cause Analysis:

Different tag-type Docker mirrors can cause mirror differences for the following reasons. (1). Docker mirror content is different. The same type of Docker mirrors is different, largely because of the difference in the version of the application in the mirror. The dockerfile represents the process of Docker mirroring, in other words, the dockerfile difference, resulting in Docker mirroring. (2). The entrypoint.sh of Docker mirrors is different. The entrypoint.sh represents the form in which the application process in the container is started, and the difference in entrypoint.sh directly results in the use of the application container. For example, there are great differences between the entrypoint.sh of mysql:5.6.17 and mysql:5.6.22, the definitions of environmental variables that are important for isolation are inconsistent, and the difference between them is natural. Solution:

Different tag of the same type of image as a substitute, need to be cautious. Look at the difference between the Docker mirror layer layer, check dockerfile and entrypoint.sh differences, can provide a minimum of protection. 2. The different time period uses the tag to latest the mirror, the effect is different the question description:

Using a latest mirror at a point in time, the application container is functioning correctly, and then another point in time follows the corresponding dockerfile,build out mirror to run the application container and fails. Cause Analysis:

Docker official about the same type of Docker mirror latest label, does not permanently give a specified Docker mirror, but will change. For example: A point in time the Ubuntu image of the latest tag belongs to the ubuntu:12.04, then another point, the latest tag belongs to ubuntu:14.04, if the dockerfile at these two points in the build, the result will be different. The reason returned to the first pit of the first article. Solution:

Use latest labels with caution, preferably not, Docker mirrors use the specified tag. 3. Description of error problem when using FIG to deploy a dependent container:

Using FIG to deploy two dependent containers A and B, the start of the internal application of container A depends on the completion of the application in container B. When the application in container a tries to connect to the internal application of container B, the container a application fails because the application in container B is not started, and container a stops running. Cause Analysis:

The start of the container is divided into three stages, followed by Dockerinit, entrypoint.sh and CMD, the three stages will consume time, different containers consume varying time, depending on the Docker container entrypoint and command exactly what kind of operation. If the MySQL container B starts, executes the dockerinit first, then executes the entrypoint.sh through the Dockerinit, because the entrypoint.sh execution process needs to perform the mysql_install_db and so on the operation, will occupy more time , and finally by entrypoint.sh to execute CMD, run the real application mysqld. To sum up, from the start of the container to the operation of the mysqld, the front pull longer, the whole process Docker daemon that the MySQL container is alive, and mysqld normal operation, MySQL container does not provide MySQL services. If container A in fig is to access MySQL container B, although the fig will simply identify the dependencies, let B start first, then start a, when Fig cannot tell the state of the container application, causing A to connect B, the application in B is still not started, and the end A is out. Solution:

Have a minimum estimate of your own environment, such as the amount of time it takes to start the application in container B from the start of container B, to add a delay mechanism to the application logic within container A, or to add a mechanism for the application logic in a to attempt to connect, waiting for the application to start in container B. The author believes that the above solution is only to alleviate the possibility of error, not eradicated. 4.Swarm Manage multiple Docker node, Docker node Registration failure problem Description:

The author's Docker deployment mode is as follows: Install an Ubuntu 14.04 virtual machine in vsphere, install Docker 1.4.1 on the virtual machine, use the virtual mechanism as a mirror for the VM, and create the virtual machine node through that mirror. Thus the virtual machine contains docker that have already been installed. If you use swarm to manage Docker daemon on these virtual machines, only one Docker node registration is successful and the other Docker node registration fails with the error message: Docker daemon ID is already occupied. Cause Analysis:

If the Docker Daemon ID on more than one Docker host is the same, the Docker node registration failure occurs swarm. The principle is as follows: (1). Docker daemon at startup, it assigns an ID value to itself, which is created by Trustkey and Trustkey stored in ~/.docker/key.json location. (2). If you install a virtual machine vm1 that already has a docker on the IaaS platform, and then create a virtual machine vm2 on the IaaS platform by making a vm1 mirror, the vm1 file for vm2 and Key.json will be exactly the same, resulting in Docker The ID value of the daemon is exactly the same. Solution:

(1). After the virtual machine is created, delete the file ~/.docker/key.json and then restart Docker Daemon. Docker Daemon will automatically generate the file, and the content is inconsistent, the implementation of multiple Docker host Docker Daemon ID does not conflict. (2). When you create a virtual machine image, delete the Key.json file. Proposed use of scheme two, once and for all. 5.Docker container's DNS problem description:

Dockerfile in the process of build as long as the access to the extranet, all invalid. Cause Analysis:

When a user creates a Docker container without specifying DNS, Docker daemon defaults to Docker container DNS to 8.8.8.8 and 8.8.4.4. In this particular environment in the country, these two DNS addresses do not provide a stable service. In this way, as long as the Docker container internal domain resolution, it is immediately affected. Solution:

(1) When using the Docker Run command to start the container, set the –dns parameter, the parameter value is a trusted DNS address, the DNS address must be guaranteed Docker container accessible. (2) If modified according to the above, apply to the Docker Run command. While using the Docker build is actually multiple Docker run stack, because the Docker build has no DNS parameters, so Docker container can not guarantee the success of the domain name resolution. Solution:

When you start Docker daemon, set the docker_opts and add –dns parameters so that all Docker run uses this DNS address by default. These pits are different in depth, but are mostly concentrated in the Docker periphery configuration, behavior patterns and so on.

Although recently in Docker pit fell black and blue, but "docker abuse my times, I treat Docker like first love" feelings always unchanged, this goods must be the future of cloud computing, I firmly believe. In front of the big pit, I came, duang ...